Thanks for the detailed response and sharing your insights.
After fixing a few issues in my code, syncing the master's clock to
the reference works reliably.
Best,
Mohsen
On Mon, Nov 19, 2018 at 2:47 AM Graeme Foot <graeme.f...@touchcut.com> wrote:
>
> FYI option 2 is the default method for TwinCAT.
>
>
>
> Either method is fine, as long as you take care to reduce timing errors. You
> should call ecrt_master_application_time() just before the ecrt_master_send()
> to reduce the amount of time variation between telling the master the PC's
> time and that time going on the wire.
>
>
>
> If you are using distributed clocks you care about drift. If you are doing
> coordinated motion on your robot you should probably be using distributed
> clocks. If "all the clocks are drifting, as long as they are synchronized
> with respect to each other" then that is actually what you are trying to
> achieve anyway. You choose one clock as the master for the system and sync
> the rest to it. The main thing you need to achieve is make sure the master
> always sends out its frame so that it reaches all of the slaves before the
> slaves distributed clock SYNC0 events fire.
>
>
>
>
>
> I use option 2 for a few reasons:
>
>
>
> - Linux calculates a Timebase Frequency on startup. It is only a quick
> calculation so that it does not hold up booting Linux for too long, but that
> also means it is not particularly accurate, and can be different each time
> you reboot Linux. This affects the speed of your PC's clock so, if you use
> option 1, each time you reboot Linux your system may run at a different
> speed. (Note, I use RTAI and the time base can be calibrated and set so that
> it is the same each time, however I auto calibrate my PC to my reference
> slave clock.)
>
>
>
> - I use Yaskawa axes that do not like too great a drift compensation. If the
> timebase calculation above is too far out my axes can have issues and lose
> their sync.
>
>
>
> - I figure a slaves clock is most likely to more similar to the rest of the
> slaves clocks, so there will be minimal drift compensation (opinion, not
> confirmed).
>
>
>
> - If you use option 1 you rely on the time between calling
> ecrt_master_application_time() and the frame going on the wire and the
> position of the message in that frame being as constant as possible otherwise
> the slaves will get a lot of jitter in their drift compensations. The
> Etherlab master has multiple code paths which take various amounts of time
> each cycle so you cannot control this jitter. Using option 2 often means
> that the slaves have a much more stable drift compensation and all you need
> to really care about in your application code is that you keep waking up in
> time to process the datagrams, do your calculation and send out the new data
> before the slaves need it. You don't really care too much about jitter here.
>
>
>
>
>
> Lastly, if you are getting timing error's using option 2 then your master
> time compensation method is probably wrong. I don't use the timing method
> from the rtai_rtdm_dc example so I don't know what might be wrong there.
>
>
>
> Regards,
>
> Graeme
>
>
>
>
>
> -----Original Message-----
> From: etherlab-users <etherlab-users-boun...@etherlab.org> On Behalf Of
> Mohsen Alizadeh Noghani
> Sent: Saturday, 17 November 2018 9:46 PM
> To: etherlab-users@etherlab.org
> Subject: [etherlab-users] Syncing master to the reference slave: should I
> care?
>
>
>
> Hello everyone.
>
> In terms of choosing the reference clock in the network, there are two
> options. In the first method, PC clock is chosen as the reference and in the
> second one, slave 0's clock is the reference.
>
> 1- Syncing slave 0's clock to the master (application) time: this is the
> method used by default by the EtherLab master.
>
> 2- Syncing master (application) time to slave 0: requires implementing the
> synchronization algorithm by the user, as seen in "rtai_rtdm_dc"
>
> example. This method boasts lower drift, as the slave's clock is more stable.
>
>
>
> However, in my experience, the latter method is more prone to master's
> jitter, and thus less reliable during a long-term run (e.g. a 24h test under
> stress).
>
> My area of application is robot motion control.
>
> The question is, using the first method, should I care about clock drift? I
> feel that, even if all the clocks are drifting, as long as they are
> synchronized with respect to each other, there shouldn't be any issues.
>
> Best,
>
> Mohsen
>
> _______________________________________________
>
> etherlab-users mailing list
>
> etherlab-users@etherlab.org
>
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
