[etherlab-users] Syncing master to the reference slave: should I care?

[Graeme Foot]

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-bounces at etherlab.org> On Behalf Of Mohsen Alizadeh Noghani
Sent: Saturday, 17 November 2018 9:46 PM
To: etherlab-users at 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 at etherlab.org<mailto:etherlab-users at etherlab.org>

http://lists.etherlab.org/mailman/listinfo/etherlab-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20181118/66207c7f/attachment-0003.htm>