Wait, what? EKI and $OUT are two entirely different things. $OUTs are essentially instantaneous (although the Advance Run pointer can make things... interesting), but EKI transmissions are a different beast entirely. Since the robot runs on an internal 12ms cycle, depending on the structure of your program, yes, it's entirely reasonable that something like this could happen.
One thing you didn't detail was what kind of scanner this is, and how its data is being sent -- is it being passed to the robot, and then to the PC? Or do the robot and scanner send their data independently?
There's also I/O bus time to consider -- depending on how your $OUT is propagated to the scanner, there could be some delay times there as well. There's also whatever amount of time the scanner takes to respond to the $OUT, then process and transmit its data.
1. If you need real time and determinism use RSI. EKI is just not meant for that....
2. If you want to improve performance learn about advance run and CONTINUE, use flags or variables instead of io and remove that 50ms delay.
Also you are sending cares Ian position but have no check if tool and base are set
i give up...
Setting the $OUT is instantaneous (or effectively so, I think it takes place in ~4 microseconds), but everything else in your code is vulnerable to the 12ms IPO cycle. If the IPO cycle hits a transition at just the right time, you could get a 12ms delay between the execution of the $OUT[17]=TRUE and the EKI_SEND lines. The IPO cycle can "break" anywhere. This even effects the SPS. Add in the effect that the EKI execution time is essentially random (thanks to network lags, TCP/IP packet handling, etc), and the fact that your timebase of 50ms is not an even multiple of 12ms, and this random delay between 1ms and 13ms is entirely to be expected.
Single-line KRL execution is something on the order of 50 nanoseconds, IIRC. Which means that, when the IPO cycle doesn't break in between your EKI and your $OUT, the delay between them will be so close to 0 as to be irrelevant (aside from, again, the delays inside the EKI communications exchange). But any time the IPO cycle break nywhere occurs in between those two lines of code, you're going to see 12ms or so of delay.
A more ideal scenario would use a timebase that is an even multiple of 12ms (probably 48 in this case) and use an Interrupt watching $OUT[17], and transmit the position captured by $POS_INT. That way, any positional errors caused by the IPO cycle breaking in between $OUT and the capture of $POS_ACT_MES would be eliminated.
Hm... also, your timebase might work better as a PULSE($OUT[17], FALSE, 48) executed every time the Interrupt triggers, as well, rather than relying on the WAIT command.
Actually... you know, I've never tested to see if the PULSE command only works in 12ms increments, or if it reliably can work at smaller time increments. Wonder if I can find a way to test for that....
The 12ms IPO cycle in KRCs is rather like a pie. Each of the tasks the robot must perform effectively in "parallel" is actually executed sequentially, and each task gets a fix portion of the 12ms pie.
So, updating the Inputs gets a small slice, every 12ms. Executing the SPS gets a small slice every 12ms. The main run gets a slice, updating the path planner gets a slice, checking the resolvers and calculating the forward kinematics gets a slice, etc etc etc.
In order to keep the operating system hardware immune, the IPO cycle is fixed at 12ms, and stayed that way even as the main processors speeds increased over time. This made code execution more consistent, per IPO cycle, across multiple generations of KRCs. It also prevented the robot's overall program execution speed from being affected by SPS programs that were extra long, or extra short.
But one side effect is that execution inside each slice could be very different, as processor speeds changed -- a late-model KRC2 probably executed KRL dozens, if not hundreds, of times faster than an early KRC1. That's one reason the SPS cycle is so unpredictable. Once every IPO cycle, the SPS is executed for... 2ms? I'm not sure. But the SPS "runs free" for that amount of time. A short SPS might loop hundreds of times during that window, a very long SPS might take multiple slices to execute even once (and this is why WAITs in the SPS are generally considered poor practice). The main run is less obviously affected, simply b/c it's execution rate is so tightly tied to the robot motion most of the time. But on a newer controller, I can perform things like massive string parsing much faster than on an old controller, even running the same code.
However, each interpreter task runs without any knowledge of or reference to the IPO cycle. When a task's "slice" of time ends, its current state is saved and execution is paused until it's that task's turn to execute again. So the IPO break might happen when the SPS is at line 1, or line 101, or line 101010... it doesn't matter. The SPS is suspended at that moment in time, and ~10ms or so later it begins execution again at the point where it left off.
