[Etherlab-users] Using DC to syncronise to reference slave clock

Tue Mar 1 01:12:11 CET 2022

Hi Celil,

Gavin mentioned seeing a user space example program at some stage.  I don't know if this is the one he was thinking of, but I have previously posted a cut down version of my app (email attached) to show how I control Yaskawa axes.  This application syncs the master PC to the slave reference clock.

Regards,
Graeme.

From: Etherlab-users <etherlab-users-bounces at etherlab.org> On Behalf Of Gavin Lambert
Sent: Tuesday, 1 March 2022 12:01
To: Celil Can Anık <bilko.celil at outlook.com>; etherlab-users at etherlab.org
Subject: Re: [Etherlab-users] Using DC to syncronise to reference slave clock

The only difference between ARMW and FRMW is the addressing mode for the slave; there is absolutely no reason this would cause synchronization issues, provided that both select the same slave as reference clock.  (The only "advantage" of ARMW over FRMW is that you can be a bit lazier with the former if declaring that your first slave is always your reference clock - and indeed you do want your reference clock to be earlier in the network than any slaves where you care about their times.)

There's fundamentally two different ways to try to sync the master clock and slave reference clocks.  The first is to use the ecrt_master_sync_reference_clock or ecrt_master_sync_reference_clock_to calls, which will try to keep the clocks fully aligned, essentially by trying to make the slave clocks drift approximately the same as the master's.  The second is to instead only call ecrt_master_reference_clock_time or ecrt_master_64bit_reference_clock_time (the latter requires extra steps) to only read the reference clock's existing time and then perform your own (usually virtual) adjustment to the master clock as needed.  Most of the examples only demonstrate the former; the rtai_rtdm_dc example is the only one that demonstrates the latter.  Which way makes more sense depends on which clock you expect to be "better", as well as whether you need the slaves to have something close to the "real" wall-clock time (only matters for 64-bit DC slaves) or if a relative close-to-zero clock is sufficient for their needs (usually true).

Separate to this is the timing loop for your master packets.  When using the former method you typically just try to send at a steady timestamp based solely on the master clock.  When using the latter, you can still do that if you don't mind jitter and drift, but it's better to try to realign your master cycle based on the reference clock (the rtai_rtdm_dc example demonstrates this as well - be careful you didn't accidentally eliminate that when converting to userspace calls; system2count is critical here).

It's also critically important to consider which values you're using in the ecrt_slave_config_dc call - make sure they match your vendor's recommendations for your intended cycle interval.  In particular, selecting a good shift value may reduce the effect of jitter, where reasonably tight.  (Also bear in mind that sync0 and sync1 cycle/shift times are not treated equivalently.)

Bear in mind that you usually want your packets arriving at a different time from the Sync0 trigger on the slave, allowing for capture and processing delays plus jitter.  It may be useful to connect a scope to observe the relative timing of each event.

I vaguely recall there being a userspace variant of the example code posted to the list a few years back, but I didn't manage to find it in a basic search.

Gavin Lambert

Senior Software Developer TOMRA Fresh Food

[cid:image001.png at 01D82D6D.05B8C530]
 [tomra facebook] <https://www.facebook.com/TOMRAFreshFood>  [tomra linkedin] <https://www.linkedin.com/company/tomra-fresh-food/>  [tomra vimeo] <https://vimeo.com/tomrafreshfood>  [tomra instragram] <https://www.instagram.com/tomrafood/>
 Compac Technologies Ltd | 4 Henderson Place | PO Box 13 516 | Onehunga 1061 | New Zealand
 Phone: +64 96 34 00 88 | https://www.compacsort.com
The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.
From: Celil Can Anik
Sent: Tuesday, 1 March 2022 03:11
To: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: Re: [Etherlab-users] Using DC to syncronise to reference slave clock

Hi again,

I still work on running Mitsubishi JET servo drives. We managed to run with DC synchronized to slave reference clock. When we check Wireshark data, "System Time Register" 0x910 is transferred with FRMW command. But engineers from Mitsubishi had told us Beckhoff Ethercat master is using ARMW command for "System Time Register" 0x910. Honestly, I don't have any idea why, but they claim this command difference causes synchronization problem. What do you think about this topic?

Also, I checked the source, but couldn't found usage of ARMW command. Is there any example for ARMW command?

Best regards,
Celil

Hi,

How should we use DC to synchronize to the slave reference clock? I implemented it by looking at the rtai_rtdm example. But it's not working as desired.

I guess I'm missing something. I would expect to change my sleep times to synchronize to slave clock. I couldn't see something like that.

* How can I stop drifting my send time relative to slave clock?

* Also, how can I measure the time I'm sending relative to cycle start of the slave clock? Can I just modulo the value returned by ecrt_master_reference_clock_time() to the cycle time?

For a little background:

We are using EtherCAT master for several years. We are using PREEMPT_RT patch with ubuntu 16.04, kernel 4.9.178. We had downloaded Gavin Lambert's unofficial patch sets a few years ago.

Normally we are using master PC as the master clock. This option is mentioned as option a in various mails in the mail list.

With this method we successfully integrated many servo motor drives from several vendors. We are generally using 1ms and 2ms cycle times on different machines.

We have recently added Mitsubishi Jet EtherCAT series to our database. Although this drive is working fine under lab conditions, somehow it gave synchronization errors from time to time at the machine. There are 4 drives and several IOs from Beckhoff on the bus.

Mitsubishi engineers claim that, the problem occurs because we are not synchronized to the slave reference clock. And ask us to change our mechanism to synchronize the master PC to the reference slave. This method is also described as the option b in mail list.

So I copied the related blocks from rtai_rtdm example in the examples folder. I modified RTAI specific functions to user space functions. At our lab we are testing two Jet drives connected to our master PC. The drives are changing to OP mode and I can control the position and speed.

There is no error in dmesg messages. Also no error on the display of the drives. But I hear knocking sounds in every few minutes while rotating.

It seems my send time is drifting relative to slave clock. But I don't see how can I stop drifting.

Best regards,

Celil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220301/44775787/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13399 bytes
Desc: image001.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220301/44775787/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 10123 bytes
Desc: image002.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220301/44775787/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 10214 bytes
Desc: image003.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220301/44775787/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 1540 bytes
Desc: image004.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220301/44775787/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 10303 bytes
Desc: image005.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220301/44775787/attachment-0007.jpg>
-------------- next part --------------
An embedded message was scrubbed...
From: Graeme Foot <Graeme.Foot at touchcut.com>
Subject: Re: [etherlab-users] No CoE communication
Date: Wed, 23 Aug 2017 06:49:05 +0000
Size: 44162
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20220301/44775787/attachment-0001.eml>