Motion approximation when ARP is stuck

    Hi,


    Considering a path passing through several approximated points, let's suppose the robot is executing the following code:

    Code
    ...
$ADVANCE = 1
SPTP P1 C_SPL
SPTP P2 C_SPL
SubProgram()
SPTP P3 C_SPL
SPTP P4 C_SPL
...

    Considering $ADVANCE is set to 1, as soon as the main run begins the second motion instruction (SPTP P2 C_SPL) the advance run pointer enters SubProgram().

    What happens if SubProgram() keeps the advance run pointer stuck (or looping...)?


    My guess is, there are two cases:

    1) the advance run pointer is kept inside SubProgram() for a greater time than the one required for the robot to reach P2's approximation area

    2) the advance run pointer jumps out of SubProgram() before the robot reaches P2's approximation area


    So, for case 1, the robot should stop at the beginning of P2's approximation area and an alarm is triggered.

    For case 2, the robot can blend the motion between P1-P2-P3 without stopping.


    Is this correct? Normally I would try and experiment the code on the robot to observe the result, but I don't have a robot available right now.


    Thank you all

    To complicate things a bit, what will happen now?


    The code below represents a generalized concept of what I am trying to do: starting the execution of SubProgram() before reaching P2.

    In my case, SubProgram() just acts as a way to communicate to an external PLC that the robot is getting close to P2.

    To continue with the next instructions (SPTP P3, SPTP P4...) it is necessary to wait for the external PLC's answer (SubProgramAnswer) given AFTER the full execution of SubProgram(), hence the CONTINUE/WAIT FOR instructions.

    All of this without stopping the robot!


    But...


    As the "system integrator" manual says, when using the trigger when distance = 1 referred to an approximate point (in this case, P2), the maximum negative offset is limited to the start of the approximate positioning arc of the end point (P2).


    And...


    As of the original question, to avoid stopping the motion we must ensure that the next motion instruction is read by the advance run pointer before entering P2's approximation area.


    So...


    If the next instructions (SPTP P3...) can be read by the ARP only after the completion of SubProgram(), but SubProgram() can be started at least at the start of P2's approximation area, it is impossible to avoid stopping the robot.


    Is there any other way to anticipate the execution of SubProgram() but still while keeping the trigger referred to P2?


    Thank you all.


    Note: SubProgram() and the following instruction WAIT FOR SubProgramAnswer do not stop the advance run pointer.


    Code
    ...
$ADVANCE = 1
SPTP P1 C_SPL
TRIGGER WHEN DISTANCE = 1 DELAY = -100 DO SubProgram()
SPTP P2 C_SPL
CONTINUE
WAIT FOR SubProgramAnswer 
SPTP P3 C_SPL
SPTP P4 C_SPL
...

    So you want to stop the robot if SubProgramAnswer is not given fast enough? Why not using splineblock and stop when path feature? But maybe I misunderstood your explanation.


    Use trigger to signal send to plc using submit and then stop when path if answer is not there. No ARP involved anywhere.


    Fubini

    Think about SubProgram() as a notification sent by the robot to the PLC just to notify it is approaching P2, and about SubProgramAnswer as an acknowledge sent by the PLC.

    Stopping the motion must be avoided at all costs (unless communication problems occur...).


    Actually we might just forget about the above, and consider this:


    The ARP proceeds with the next motion instructions (SPTP P3 and so on), only at the end of SubProgram(), which is a one-shot routine...

    But using the TRIGGER WHEN DISTANCE referred to P2, SubProgram() can't be called before reaching P2's approximation area. So in this moment, no further motions have been planned (ARP has been waiting at the WAIT FOR SubProgramAnswer).

    If I am not mistaken, this should cause a stop in the motion.

    as already mentioned, consider spline stop. it makes this cleaner and more robust (menu Command>Logic>Spline Stop Condition)

    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

    Post
    Re: WAIT or HALT inside SPLINE BLOCK
    Lookup up STOP WHEN PATH or Conditional Stop in the system integrators manual. Using this feature you can specify a position along the track where the robot is stopped if a condition is fullfilled and automatically starts again as soon as the condition state swaps. The path value is specified by the same means you would do it in a trigger and hence could be placed at the end point of a move command. Furthermore the condition can be a input or a output (maybe also a CYGFLAG), so you could e.g.…
    Fubini

    Thank you all for your answers.


    I'll try to better explain my situation.


    The acknowledge sent by the external PLC causes the robot to follow one path rather than another:



    I want to avoid motion stop during movement, so the response of external PLC (execution of SubProgram) must be executed before reaching P2's approximation area.


    But what i want to do does not seem possible because TRIGGER WHEN DISTANCE referred to P2, SubProgram() can't be called before reaching P2's approximation area.

    I'm not entirely certain if this is workable, since the path planner needs to know which way to branch in advance. But with $ADVANCE=1, this might work if you use DISTANCE=0.


    DISTANCE=0 causes the TRIGGER to fire as the robot begins leaving P1. DISTANCE=1 will cause the TRIGGER to fire when the robot arrives at P2.


    With approximated points, "departure" and "arrival" are replaced with "closest approach". The KRL manual includes detailed illustrations of this.


    So, at minimum, you need to use DISTANCE=0 for what you're trying to do. The next problem is, does the path planner need to know which direction to move after P2 before leaving P1, or if it can wait until the approximation radius of P2. I've never experimented with this, so I'm not sure.

    lots of my projects involve machine tending and speed is everything. if robot does not really need to stop, i do not want it to stop. this means motions are fluid all the way around unless it is absolutely necessary to stop. in other word this is doable if done right. and one would need to look hard to find CONTINUE in my programs.


    so looking at the above code example, i would be really surprised if it worked:

    there is no clue about how N is defined or changed. sending info 100ms before reaching point.... how quick reply from PLC is supposed to be to still be ahead of approximation point? why not measure the time for round trip of the signal?

    also approximation distance value is not shown. same goes for velocity, distance between points etc.


    in fact i would be impressed if it could compile:

    declaration of SubProgramAnswer is not shown but in line 8 it is treated as boolean, then later on it is used as an integer.

    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 most speed-critical application I ever worked on was press linking. In that case, we used background control of $OV_PRO to reduce the robot's speed as it approached the approximation radius of a WAIT point, b/c (at least back then) dialing $OV_PRO up from 0 gave faster results than letting the robot hit the WAIT command. Of course, the primary reason for controlling $OV_PRO was to avoid ever pausing the robot at the WAIT point at all -- reducing speed until a press was clear to enter was better than letting the robot come to a complete stop.


    That might be a usable approach for the OP, if it were possible to bring the robot down to $OV_PRO 0 before the critical limit of the C_SPL was reached.

Advertising from our partners