[etherlab-users] Question about DC synchronization in rtai_rtdm_dc example

[Gavin Lambert]

On 16 November 2017 04:14, quoth Christoph Schroeder:
> I stumbled upon a question regarding the dc example which is part of the
> EtherCAT master release. The Example mentions:
> "The initial application time is also used for phase calculation for the
> SYNC0/1 interrupts. Please be sure to call it at the correct phase to the
> realtime cycle"
> 
> What does this actually mean and is this even relevant if you don't use cyclic
> SYNC0/1? What confuses me is that we use dc_start_time_ns in:
>  > ecrt_master_application_time(master, dc_start_time_ns);

It is less important to match phases if you don't use SYNC0/SYNC1 on any slaves, but if any slaves use any DC timing (eg. event timestamping) it is still necessary as this is also the time used to synchronise the reference clock when you call ecrt_master_sync_reference_clock (if SYNC_MASTER_TO_REF is not set).  (Which is why you need to call ecrt_master_application_time cyclically immediately prior to that as well.)

If you do have SYNC_MASTER_TO_REF set and also don't use SYNC0/SYNC1 then I don't think it matters at all.

> but for the wakeup time we simply set:
>  > wakeup_time = system_time_ns() + 10 * cycle_ns;
> 
> right before starting the actual cycle. If we set a dc_start_time_ns, which
> might seem to be important, shouldn't wakeup_time be something like:
>  > wakeup_time = dc_start_time_ns + n * cycle_ns;
> 
> where n is the number of cycles already done in the past, so that it is "in
> phase" to the original start time (and thus with the internal time used by the
> master)?

The 10 * cycle_ns is only used on the very first sleep (so there are no previous cycles, by definition).  For each subsequent cycle it is incremented by cycle_ns.  Using 10 is a purely arbitrary choice to presumably delay the first cycle a little, perhaps to allow the slaves to start transitioning to SAFEOP -- although TBH I'm not sure why you'd want to do that as you do need to run cycles in order to progress the configuration state machine.

As for the initial offset, yes, in that context it probably does make the most sense to use the same dc_start_time_ns as in the first call to ecrt_master_application_time -- although it would be better to do a bit of both: start at dc_start_time_ns and add enough cycle_ns until the result is greater than system_time_ns() (which is trickier than it sounds; be careful of signed wrap), to ensure that the first cycle occurs strictly in the future.  (This might be an alternate explanation for the 10 multiplier; perhaps the code previously took a punt at this method without actually doing the loop, then was later changed to only use system_time_ns() to guarantee it picked a future time, albeit sometimes out of phase?)

In the dc_user sample code, ecrt_master_application_time is called for the very first time in the first cycle, so it is automatically in phase without doing any calculations.  Although in some cases this can result in warnings being logged if the cyclic thread is a little slow to start up.

I'm not sure why the RTAI sample does this differently, but it does seem suspicious.  Perhaps Graeme Foot might be able to explain a bit more?  I think he had a hand in creating this sample.