# Trigger Questions

• KSS 8.3.34

When using Trigger When Path = - Distance, should the trigger happen at the start of the move if the distance is greater than the length of the move? I am trying to understand how this should happen when there is only one move to consider as well as when there are multiple motion commands before the trigger.

Code
``````\$Advance = 1
p1 = 0.0, 0.0, 0.0
p2 = 50.0, 0.0, 0.0

Lin p1
Wait Sec 0.0
Trigger When Path = -100 Delay 1.0
Lin p2``````

In the case above, would the 1.0 second delay happen before the motion to p2 starts?

In this case above, would the 1.0 second delay happen at { 20.0, 0.0, 0.0 } or would it happen at p2?

Also, when using Trigger When Distance = Switching_Point, can you use a decimal value to make the trigger happen between the start and end points?

• in this case

- means BEFORE/SOONER

+ means AFTER/LATER

reference point depends on type of sync (start,end,path) and approximation.

is using PATH, set delay to zero if trying to see how it works. delay is secondary tweak and should be ignored until you understand how trigger really works using only PATH.

when the sync points are out of range, trigger will still happen but the place will be automatically trimmed to fit switching limits range.

if you do use Delay, position will be offset before or after point specified by PATH. note that PATH point is strictly related to PATH but once you introduce Delay, robot speed also matters.

if delay is positive, you are moving actual switching point to be on path but LATER than what was set by PATH value.

if delay is negative, you are moving actual switching point to be on path but SOONER than what was set by PATH value.

same DELAY value will result at actual trigger point being closer to what was set by PATH if robot is moving faster

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

• Alright, I think I am understanding a bit more. I was misunderstanding delay completely.
I was using it in the example as if it was going to do a Wait Sec.

I have attached a sketch showing a path through 3 points. If I used the following code, would the trigger event happen before p2?

Code
``````\$Advance = 1
p1 = 0.0, 0.0, 0.0
p2 = 50.0, 0.0, 0.0
p3 = 100.0, 0.0, 0.0

Lin p1
Wait Sec 0.0
Lin p2
Trigger When Path = -70 Delay 0.0 Do Wait Sec 1.0
Lin p3``````

of course not, those motions are not approximated so limits (range) for switching are from P2 to P3.

that -70 is exceeding the limits and trigger will try to active at -50mm which is P2.

BUT....

because you also have 1sec delay, this switching will happen 1 sec AFTER passing point P2 or at the latest at P3.

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

• Good to know. I could have sworn that I have seen a trigger happen after the move it was specified with.

The move was ~25mm and the trigger was Trigger When Path=35.0 ONSTART Delay=0.0 Do Wait Sec 1.0. I am pretty sure the trigger happened after the next motion started.

• panic mode, since I can not make this work with triggers provided by KRL, is there a way to spawn a synchronous task to handle a custom trigger? I think I could set this up in the submit, but I would like to know if Kuka allows for additional synchronous tasks.

• What EXACTLY is the challenge? Triggers ARE the way to perform actions synchronous with path. Submit interpreters are asynchronous with robot interpreter so if any precision is required this is not option to use. So other option is interrupt though this will only complicat e things to get same job done as trigger would.

I looked at you code and see no reason for wait sec 0 and p2 motion. Two collinear straight segments and nothing else (speed change, aproximations, other logic.... Simply NOTHING...).

Removing p2 motion will give trigger working limits from P1 to P3 and as a bonus you will avoid stop at P2. Is that what you want?

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

• I was trying to draw simplified diagrams to just show the number of points being considered and the trigger relationship. The points will in fact cause a change in motion. There will also be changes such as velocity, ACC and APO among other changes of parameters at every point. The Wait Sec 0.0 was included to stop the advance run from reading ahead.

The parameter for toolOffTriggerDistance is controlled by an operator and this value changes very often. The points involved in this process are also always changing. The start point does not know how many points will follow before an end point in the path either. This is why the end point needs to trigger the tool to turn off. The problem is just that the end motion may be shorter than the length needed to stop the tool at the right moment.