I'm developing a software that controls robots via RSI, and I just noticed a really, really weird bug - RSI's actual motion execution in is ST_ETHERNET/ST_SKIPSENS() mode is delayed by approximately 5.6 IPO cycles(~68ms).
It's running on a 12ms cycle, because EthernetRSIXML 1.2 on KSS5.6.12 cannot run in the 4ms mode(it just times out immediately, because it still sends packets 12ms apart for some reason, not 4).
Now, here's the weird part: it perfectly executes the motions. There's no lost packets, the delay marker never indicates anything other than 0. It's just that everything sent to the robot happens several cycles after it's been sent, as if there's a small buffer of motion commands before they get executed.
Is this normal for RSI? Judging by documentation and every piece of code I've seen online, people are treating it as if it's cycle-instant - you send it a correction in IPOC=1, and you see it returned in the next packet, IPOC=2. This is just not what's happening for me.
The robot is unloaded, and the corrections are minimal(single digit mm/s^2 accelerations and ultimate speeds), but not insignificant(they're not being ignored as lsb errors/below encoder resolution).
This is obviously not a networking issue, since packet numbering is fully sequential with no delay errors. The robot is connected directly to a dedicated ethernet port, too, so there's no buffering/offloading issues.
Any clue as to what's going on?