Where does the robot stop exactly after a PTP or LIN and proceed to other statem

[cosva]

Hello,

I have one small issue.  When I make either PTP or LIN motions I am not sure when the robot actually stops and proceeds with statements for example "wait for".
I have problems because I suppose that the robot doesn't reach the point exactly. Very near the point it just proceeds to the WAIT FOR statement and executes it. My workaround is putting a WAIT SEC 1 after these critical motions but this is certianly not the way to do it properly.
Can you please give me some advice how to be sure that only when the robot has reached the point it proceeds with the logic statements. Also I suppose that this has nothing to do with the advance run pointer as it breaks on those statements.  I have KSS 5.6

Thanks  ,

cosva

[neranol]

Hello cosva.
Can you share that part of code?
Maybe you are using the "cont" parameter in motion command.
If you want to stop the robot in a exact point you have to put PTP or LIN without the "cont".
This parameter is used to allow the robot to move without stopping.
There are others ways to stop the robot, depends of what you want.
Hope this help

[SkyeFire]

For any approximated motion followed by a WAIT FOR or other similar command, the WAIT is evaluated as soon as the robot reaches the approximation radius of the point.  So, for a sequence of two points P1 and P2, followed by a WAIT FOR, if the approximation radius of P2 is set to 100%, the WAIT statement will be checked as soon as the robot reaches the halfway point between P1 and P2.  If the WAIT statement has not been satisfied by that moment, the robot will move to P2 as a precision, non-approximated point, and then re-check the WAIT statement.
So, for some conditions, using a large approximation radius can result in the WAIT statement being evaluated too soon.  Reducing the approximation radius will help with this.  You can reduce the radius all the way down to 1% or even 0% if need be.
On the other hand, if you never need these motions to be continuous, you can simply make them non-continuous motions and the robot will move to each one and come to a full stop momentarily, regardless of the status of the WAIT statement.

[kr16_2]

According to my knowledge WAIT FOR instruction stops advance run.
Therefore no approximated motions are possible if followed by WAIT FOR.

PTP P1 C_PTP        ;Approximation not possible warning msg. Exact positioning
WAIT FOR $in[1]    ;Advance run stop

To overcome that KUKA has CONTINUE instruction to allow advance run evaluate WAIT FOR and if TRUE run forward.

PTP P1 C_PTP      ;Motion is approximated if $in[1] was TRUE ahead of time so advance run had a chance to run
CONTINUE      
WAIT FOR $in[1]   ; No advance run stop - only if input 1 is TRUE.

By default advance run is set to 3 so it is hard to tell when exactly input will be evaluated.

Please correct me if this is wrong.
thx

[the leg]

it will stop if you are looking at an input but i think if you look at a variable it can apporox through if it is true

PTP P1 cont
wait for true
PTP p2 cont

[kr16_2]

That is correct but I would think if advance run is 3 motions blocks ahead you can't tell when exactly this is evaluated (true/false)
SkyeFire described when exactly this evaluation happens which looks interesting since I never heard about it.
thx

[SkyeFire]

WAIT statements (either WAIT SEC or WAIT FOR) do break the advance run, I neglected to mention that.  WAIT FOR TRUE is in fact a standard KRL programming trick to deliberately break the advance run without introducing extra time delays.  WAIT SEC 0 is another equivalent.

The bottom line, though, is that a WAIT FOR statement, or other commands, is evaluated or executed when the advance pointer gets to it.  Just when that is depends on the setting of $ADVANCE, and the approximation radii of the motion points.  So for the following code:

Code:

$ADVANCE = 1 ; set advance to one motion block ahead of main run
PTP P0
PTP P1 C_PTP
CONTINUE
WAIT FOR BooleanVariable1
PTP P2 C_PTP
CONTINUE
WAIT FOR BooleanVariable2
PTP P3 C_PTP
CONTINUE
WAIT FOR BooleanVariable3

The robot should move smoothly through P1, if BooleanVariable1 is true before the robot physically reaches the approximation radius around P1.  The reason for this is that the approximation radius is the position where the path planner has to decide if it is going to follow an approximated path past P1, or if it will need to move physically to P1 and stop to re-evaluate the WAIT FOR.
OTOH, if $ADVANCE is set to 2, then the robot will only approximate through P2 if BooleanVariable2 is true before the robot physically reaches the approximation radius of P1.  That's because, with $ADVANCE=2, the path planner looks ahead two motion blocks.  This means that when the robot physically reaches the approximation radius of P1, it has to plan out the motions to P2 andP3, which includes checking both BV1 and BV2 right then.
The CONTINUE command is what allows the following command (and ONLY that command) to not break the advance run.  However, since using it this way can be risky -- in the example above, if $ADVANCE is set to 2, that means that BV2 is checked before the robot reaches P1.  If BV2 is true at that point, then BV2 is not checked again -- if BV2 were to become False for some reason while the robot is travelling from P1 to P2, the robot will not stop at P2 but just keep going.
The same effect applies to output commands, with potentially disastrous results (I learned that the HARD way, years ago).
One approach that can help with this is to use subroutines called by TRIGGER commands.  The TRIGGER command allows you to control precisely when/where the subroutine is called, and then you can have as many WAIT and CONTINUE statements inside the subroutine as necessary without creating advance-run issues for yourself.