Motion optimization

    Hi guys,


    I am currently working on a project with several KUKA Robots for a typical pick and place routine. The thing is that we are trying to optimize the path of the Robot during the handling of the material (stainless steel sheets).


    The program of the Robot is like this:


    - Cell program calls a "Main" program

    - Main program is scanning for signals from PLC, and calls all the pick/place programs.

    - Once a pick/place program is finished, the robot cames back to Main and continues the scanning for another program to be called.


    On one of the programs, let's say program "PICK", in the last point of the program the robot reaches a final position, and after this position another program is called for continue with the "PLACE" program. The idea is that if all the conditions for execute the program "PLACE" are "TRUE" the robot should smoothy go from the last point of "PICK" to the first point of "PLACE". But this is not happening... The Robot is stopping for about 1 second on the last point, then it continues with the next program. Is there any reason why this could be happening?.


    Any advise will be appreciated.


    Thanks!

    Does the PLACE program begin with an INI Fold? If so, that's your problem. INI contains code, particularly BAS(#INIT), that forces a break of the ARP.


    The easy fix is to eliminate the INI Fold. The downside there is that it hurts you if you ever want to hand-select PLACE and run it in Teach mode -- LIN motions will be prevented, for one thing.


    The better fix is to put the INI Fold inside an IF statement checking $MOVE_BCO.

    Quote from SkyeFire

    Does the PLACE program begin with an INI Fold? If so, that's your problem. INI contains code, particularly BAS(#INIT), that forces a break of the ARP.


    The easy fix is to eliminate the INI Fold. The downside there is that it hurts you if you ever want to hand-select PLACE and run it in Teach mode -- LIN motions will be prevented, for one thing.


    The better fix is to put the INI Fold inside an IF statement checking $MOVE_BCO.

    Oh okay, but if i remove the INI fold, it will prevent to start the program with a LIN movement that's it?? or i will not be able to do any manual movement with the Robot? (Including PTP movement).


    Thanks for the answer, i am pretty much new with KRC4, and i don't even know what $MOVE_BCO does.

    Quote from SkyeFire

    Does the PLACE program begin with an INI Fold? If so, that's your problem. INI contains code, particularly BAS(#INIT), that forces a break of the ARP.


    The easy fix is to eliminate the INI Fold. The downside there is that it hurts you if you ever want to hand-select PLACE and run it in Teach mode -- LIN motions will be prevented, for one thing.


    The better fix is to put the INI Fold inside an IF statement checking $MOVE_BCO.

    It starts with a BASISTECH INI, is that the same?

    Quote from Maverick

    Oh okay, but if i remove the INI fold, it will prevent to start the program with a LIN movement that's it?? or i will not be able to do any manual movement with the Robot? (Including PTP movement).

    Yes and no :winking_face:

    It will prevent to start the program with a lin if you select it manually, but not when it is called from an external program, that called the INI.

    You will not be able to start any movement without the INI if you selected it manually, but it won't be a problem if you stop the program after it was called by another one that has called the INI.


    Usual workaround is to use something like:

    IF $MOVE_BCO then

    INI

    ptp $pos_act ; for allowing LIN movement at beginning

    endif

    approximated motion or blending requires considering of values for both current target point as well as the next point... INI resets motion planner so you lose some of that info.


    INI is not essential, one can write functional KRL programs without INI. But as mentioned, programs that use INI will not work without it... at least not as a standalone program. They can still work if they are not used as main program but called as a subprogram - in this case another (main) program would need to have INI (or equivalent).


    so to have it both ways, one can leave INI in place but make sure it is not called unless BCO run is needed.


    so normal workaround is

    Code
    IF $MOVE_BCO then
INI
PTP $AXIS_ACT
ENDIF

    or

    Code
    IF $MOVE_BCO then
INI
$TOOL=tool_data[...] ; 1..16
$BASE=base_data[...] ; 1..32
PTP $POS_ACT
ENDIF

    or similar

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    The other item of note is that INI execution is "inherited" -- that is, once it's been run once, it never needs to be run again unless/until a program Reset or Cancel/Select has been carried out. That's why sub-programs don't have to have INI, if the "main" program that calls them executes INI.


    However, if you hand-select a module in Teach mode and run it as a 'standalone', so to speak, you're going to want to run INI. To try this out, just hand-select the PLACE program, then do a Block Select on a line below the INI Fold, and try to run the program. You'll see the consequences of skipping INI soon enough.


    That's where the IF $BCO_MOVE comes into play. It lets you have your cake and eat it too -- it'll run INI if it's needed, but will skip the INI if it's not needed.

Advertising from our partners