[etherlab-users] ecrt_slave_config_dc sync0_shift

Gavin Lambert gavinl at compacsort.com
Thu Aug 31 02:04:49 CEST 2017


You can see the calculations in fsm_slave_config.c's
ec_fsm_slave_config_state_dc_sync_check.  Enabling "ethercat debug 1" will
also print some diagnostic information to the syslog on activation which may
be of interest.

 

There will always be some jitter in the SM2/SYNC0 timing, as it's subject to
the stability of your main loop's call to ecrt_master_send.  But yes, you're
correct that the intent is to have SYNC0, shift time, then SM2.

 

Note that the example code assumes a fixed processing time and so focuses
all its timing efforts on a deterministic wakeup before calling
ecrt_master_receive, which in itself is not sufficient if you don't have a
stable processing time.

 

Another important factor is when you call ecrt_master_application_time for
the first time - ideally it needs to be just prior to the ecrt_master_send
call and always at the same period (which again assumes a stable processing
time), which can sometimes be tricky to arrange correctly.

 

If you don't have a fixed processing time, it could be useful to restructure
the loop with a two-step sleep so that your
ecrt_master_application_time/ecrt_master_sync_slave_clocks/ecrt_domain_queue
/ecrt_master_send group have the deterministic wakeup instead.  Though if
you want the best stability you'll probably want to use an RTOS layer.

 

Finally, the examples demonstrate trying to sync all slaves to the master's
clock (ecrt_master_sync_reference_clock), which is simple but can cause
drift over time if your master's clock isn't particularly good.  It's also
possible to sync purely from the reference clock
(ecrt_master_reference_clock_time) which can be a bit more reliable but
requires more work in the master code.  There are some discussions on this
in the mailing list archives.

 

There have also been some patches to alter DC behaviour posted from time to
time, most of which are included in the unofficial patchset
(https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme).
You might want to consider looking at those.

 

From: Greier, Thomas
Sent: Thursday, 31 August 2017 03:56
To: etherlab-users at etherlab.org
Subject: [etherlab-users] ecrt_slave_config_dc sync0_shift

 

Hello,

How is the sync0_shift argument used in ecrt_slave_config_dc?

 

I currently am using 1.5.2 version of the master with one slave device in
master-shift DC mode.

 

The slave is synchronizing successfully. However, when I probe the SM2 and
SYNC0 interrupts on the slave, I see that the location of the SM2 interrupt
within two SYNC0 interrupts is non-deterministic.  In other words, it
changes every time the master and slave resynchronize. I would have expected
the location of the SM2 interrupt (as far as its timing) to follow the
sync0_shift offset from the SYNC0 interrupt.

 

I am running at 1kHz SYNC0 frequency and specifying a 200us sync0_shift.

 

Thank you in advance for your help.

 

Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20170831/e8bf9f93/attachment.html>


More information about the etherlab-users mailing list