Revision history [back]

I believe this to be the culprit, but not the underlying cause:

A sanity check first…

In EtherCAT, the network cabling is daisy-chained and looped back to the Master. For every frame the Master transmits, it should receive this frame back before any other frames transmitted by the Master are received back--they will always be in order. It should be impossible for a Master to transmit two frames onto the network, and then receive the frames back in the wrong order.

An EtherCAT slave cannot initiate any frames onto the network but only can modify a passing frame as it 'flies' by, so the slave cannot change the order.

So what is probably happening is this:

1. Under normal expectations, the Master transmits the frame at 0ms. The return frame is received about 11 microseconds later (~0.01ms). The Master pauses for ~0.99ms and then transmits the next frame.
2. The Master (here TwinCAT running on Windows 11) falls behind, possibly by other processes activating in the system.
3. Being behind, the Master misses a scheduled frame to transmit in the given period and the frame is stuck in queue.
4. In the next period, the Master transmits the queued frame and the scheduled period's current frame as well. This results in two frames transmitted back-to-back from the Master with identical timestamps.
5. With the two Master frames in transit, they both return about ~11us later as two responses that are also back-to-back with identical timestamps.

The log shows the timestamps in only microsecond precision, while the actual timestamp is probably in nanosecond ranges which would falsely give the appearance of identical timestamps that are actually off by nanoseconds.

These steps would explain the log anomaly, but not the specific cause of the PC Master lagging. I will continue investigating this avenue and give updates.

In the meanwhile, I very much appreciate suggestions, corrections, and alternate ideas!

---