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.
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
