HANDLING NOT REACHABLE POINT DUE TO CALCULATED POINT

    Hi, it happens that I use a previously touched up point and add to this poin some calculations. Most of then are related to it's Z axe rotation. In some cases, due to this change, the robot is no longer able to reach the point with the touched up configuration. Tipically it could reach the point with a changed .S or mor aften .T parameter.

    I've partially solved this matter changind the .T parameter along with the angle required but is few cases the robot still stop sayng the point it is not reachable.

    Is there any way to handle this error and for example generate a signal to throw away this point and redo a calculation on to another one? Because I whant above all that the robot doesn't stop.

    Lookup the Inverse function. It allows testing your recalculated points. For an example on handling it you could checkout kue_weg.src in the UTILS folder of every controller. Also details matter: are we talking ptp or lin/circ movement commands. They handle status and turn differently.


    First thing usually people try to use frames instead e6pos for target position variable type, because it contains no status and turn and the internal krc strategies of choosing them somewhat optimal can be applied.

    This is what I did... Shift_X, Shift_Y and Shift_A are coming from a vision system. Unfortunately I didn't thought to use the same calculus using the frame I didn't have experience before. Basically the client touch up by himself the XPrel_Pz_Orig. He has many many pieces different to handle. The not reachable point is always the PTP XOver_Prel_Pz_Nastro.


    ;fold CALCOLI



    XPrel_Pz_Nastro = XPrel_Pz_Nastro_Orig


    XPrel_Pz_Nastro.X = Shift_X


    XPrel_Pz_Nastro.Y = Shift_Y


    XPrel_Pz_Nastro.A = Shift_A


       


       IF (XPrel_Pz_Nastro.A >= 140) AND (XPrel_Pz_Nastro.A < 160) THEN      


    XPrel_Pz_Nastro.T = 43


          ELSE


    XPrel_Pz_Nastro.T = 35         


       ENDIF



    XOver_Prel_Pz_Nastro = XPrel_Pz_Nastro


    XOver_Prel_Pz_Nastro.Z = XOver_Prel_Pz_Nastro.Z +100



    XOut_Prel_Pz_Nastro = XPrel_Pz_Nastro


    XOut_Prel_Pz_Nastro.Z = XOut_Prel_Pz_Nastro.Z +150


    ;endfold

    Ok. First of all you should use the : operator to shift positions. Simply adding them might be correct for xyz but certainly not for ABC angles in general. Also status and turn are bits so that I would not hard code them to certain integer values but always swap only certain bits.


    Moreover your problem code only shows problem with turn which always comes from limit switch errors. Is this correct? Btw this then is another case why details like exact messages matter. You only stated unreachable points before but not what exact messages. So for future reference if it is a software limit switch message it is always a turn issue. Status problems would lead to other messages and would need other methods to resolve them.


    To sum up: you only have ptp target positions that drive the robot behind limit switches. This is easy to test beforehand using the inverse function. You provide your target position and the return value tells you if the resulting position in axis coordinates lies behind limit switches. Lookup the documentation of inverse on details. Documentation is included in kuka xpert now. But you probably will also find the necessary documentation using the forum search. At least I remember to have posted it quite a while ago.

    Wich is the exact message I don't know in this moment. The point is then reachable symply using another configuration. So the point is reachable. My guess was that using this statement "IF (XPrel_Pz_Nastro.A >= 140) AND (XPrel_Pz_Nastro.A < 160) THEN" I would have solved this problem the problem is that with different touched up point it doesn't work.


    OK thanks a lot. I'll try the inverse function.

    :thumbs_up::thumbs_up::thumbs_up:

Advertising from our partners