Digital outputs delayed?

    KSS 8.3.28, KRC4


    I have a subroutine that triggers a scanner using $out and sends the current robot pose through EKI to a PC. For some reason though, the measurements from the scanner arrive to the PC 12 ms after the robot pose, so I'm wondering if the output is actually set electrically right after the instruction or the next ipo cycle.

    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.

    I know EKI and $OUT are two different things, and the scanner is MicroEpsilon's ScanCONTROL 2700. $OUT is only used to trigger the scanner to synchronize the robot's movements and the scanner's measurements. Both the scanner and the robot send data to the PC independently. I know there are possible bus, network and scanner reponse delays, but the time difference being 12ms just sounds like ipo cycle, so I'm trying to make sure if $out is actually instantaneous. The KRL program is just a loop that calls the subroutine continuously, which toggles $out on and off periodically, and every rising edge sends the robot's pose to the pc.

    Edited once, last by Spl ().

    This is the code that I'm having problem with, and if as you are saying that the $out IS instantaneous, then I'll just ignore the time difference for now.


    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.

    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

    > 1. If you need real time and determinism use RSI. EKI is just not meant for that....


    I guess I could try RSI.


    > 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.


    I don't want to improve performance. I want to find out why the $out=true/false doesn't seem to happen instantaneously, because the message sent through eki has been arriving max. 13 ms before the data from the scanner that's pulsed with the output. The 50 ms delay is there for a reason to limit the frame rate of the scanner.

    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....

    Thanks. Didn't know that the code execution can transition like that. Will try with an interrupt tomorrow, and I think I have read from the manuals that pulse length is a multiple of the ipo cycle.

    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.

    Using interrupts worked. With two interrupts that use pulse(), data from the scanner arrives now constantly 5 ms later than the data through EKI. I'm guessing the 5 ms is just the scanner's response / output delay, and it doesn't really affect the data synchronization.


    Thank you SkyeFire for the help.

Advertising from our partners