implement slave task synchronization methods

[jimy-byerley]

The ETG.1020 describe several synchronization mechanisms between the master and the slave realtime task. We need to implement them for using with servodrives.
An initial attempt to implement it at the clock level was made in #7, but after experiments it seems that the DC can work without sync enabled, and that some kind of sync can run without the DC. We need hence to implement it in a separate way.

• FreeRun
• DC synchrounous (with DCSync0 and DCSync1)
• SM synchronous (with SMSync2 and SMSync3)

[Lomsor]

Hey jimy. I've been following this Project out of interest, and your comments on #7 didn't make much sense to me. I refrained from saying something, as I don't (yet) have access to the ETG, couldn't contribute with specific real-world timing tests and didn't want to intrude.

Concerning your comment here but after experiments it seems that the DC can work without sync enabled:
From what I figured, etherrage is supposed to be an EtherCAT master. Generally, EtherCAT masters are not set to be the Distributed Clock reference because they lack the dedicated hardware to facilitate the low jitter. For this reason, usually, the first slave/device with this DC hardware is selected to be the reference clock and all other slaves, as well as the master are synchronized with that slave/devices DC clock. In TwinCAT, any DC capable device can be set as the DC reference. Every EtherCAT servodrive (I know of) is DC capable, and some specialized I/O hardware is as well. Meaning they can be set to latch or act upon data at a specific DC time, that data does not have to arrive/leave trough EtherCAT frames at that exact DC time, though.

Beckhoff uses several different clocks in their master, TwinCAT, to handle DC being a separate entity. They don't really make much of an effort to try to keep them in sync, after a task is started, the offset is usually kept track of for calculation purposes. A sync with some master clock is possible, but optional and only actually done with specialized hardware to retain high precision.

From what I've read, the master is responsible for taking the appropriate steps to sync all the DC clocks in an EtherCAT frame to each other. Otherwise, DC wouldn't be much better than SM. The clock in the EtherCAT master doesn't need to be as precise, though, because the offsets can be calculated based on the Information gathered from the stand itself.
The only downside of having a less precise clock in the master is higher minimum cycled times, larger lead time required to
allow for jitter as well as higher drift to some non DC clocks. The last might be an issue depending on the application.

This issue here makes more sense to me compared to #7, as it seems to discuss the methods the slaves/devices are set to and according to what clock they should act upon:

• Free Run: Not synced, slave/devices run at a fixed internal clock. I/O and actions are done according to that clock.
• SM synchronous: I/O and actions are done when an EtherCAT frame arrives. Optional Shift times.
• DC sync. I/O and actions are done at a specified DC time/offset. DC time is synced by EtherCAT master.

[jimy-byerley]

Hello @Lomsor ! Did I already crossed your road on the ethercrab chat ?

EtherCAT masters are not set to be the Distributed Clock reference because they lack the dedicated hardware to facilitate the low jitter. For this reason, usually, the first slave/device with this DC hardware is selected to be the reference clock

This is true, As you can see on this scheme our current DC implementation enforce the first slave implementing DC as the reference

that data does not have to arrive/leave trough EtherCAT frames at that exact DC time, though.

This depends on the slave implementation, and the time precision we are talking about AFAIK. For instance in their interpolated modes, Omron servodrives are expecting to receive commands within a time window of 125µs each period, if the master is less precise than that it will cause unexpected behaviors.
This is a fair time window but needs to be held.

This issue here makes more sense to me compared to #7, as it seems to discuss the methods the slaves/devices are set to and according to what clock they should act upon:

#7 was only meant to make the master synchronize the slaves clocks, DC (synching the slaves clocks to the reference) is a predicate to DC-sync (synching the slaves tasks to the reference)

Anyway, thanks for your links to the beckhoff documentation, it is much clearer than the ETG specs !

[Lomsor]

Thanks for taking the time to look over my points. I heard of the ethercrab chat and tried to join once but for some reason didn't go trough with it. Seeing your answer, it would probably have been a better place to have this exchange. I'll try again.

For instance in their interpolated modes, Omron servodrives are expecting to receive commands within a time window of 125µs each period,

I wasn't aware of cases like this but for such a mode that makes sense of course. The numbers mentioned for the clock in #7 just really confused me back then as I double checked with what TwinCAT can theoretically achieve and the lowest task cycle time that can be set there is 100µs and the lowest jitter warning that can be set is 50µs. TwinCAT sends the frames after cyclic Task processing, which is usually the source of any significant jitter there.

#7 was only meant to make the master synchronize the slaves clocks, DC (synching the slaves clocks to the reference) is a predicate to DC-sync (synching the slaves tasks to the reference)

Ah I see. I think I didn't understand #7 and the difference between DC and DC-sync the way you described here. I am already greatful for the insights I am able to get into the development of both ethercrab as well as etherage here on github, even if I don't always have the time to do further on hands testing with these.
Coming from the application side of things I have to be aware that some things might be cryptic to me or of possible misunderstandings. I'll keep that in mind in the future and otherwise head over to the mentioned chat.

As for the Beckhoff docs, you're welcome. I know them quite well. But there's a reason I am here of course, looking for alternative, less restrictive solutions.