The SYNC1 Cycle register (0x09A4) is a little weird; it acts as both a cycle 
and shift in one register, depending on the value of the SYNC0 Cycle (0x09A0).

  *   Where SYNC0 Cycle is X and SYNC1 Cycle is 0, SYNC0 and SYNC1 occur at the 
same time – thus same cycle, no shift.
  *   Where SYNC0 Cycle is X and SYNC1 Cycle is less than X, SYNC1 occurs at 
(SYNC1 Cycle) ns after the SYNC0, but otherwise at the same cycle rate – thus 
it acts as a shift.
  *   Where SYNC0 Cycle is X and SYNC1 Cycle is equal to X, SYNC1 occurs at 
every second SYNC0 – thus it acts as a 2X cycle with no shift.
  *   Where SYNC0 Cycle is X and SYNC1 Cycle is equal to 2X, SYNC1 occurs at 
every third SYNC0 – thus it acts as a 3X cycle with no shift.
  *   Where SYNC0 Cycle is X and SYNC1 Cycle is greater than X but not an exact 
multiple, it acts as a combination of cycle and shift as above.

(Under the hood, it always does behave as a shift that fires exactly once 
non-overlapping offset from the SYNC0 pulse.  Or to put it another way, SYNC0 
starts the timer but doesn’t reset it if already running, and it fires SYNC1 
once when the timer finishes.)

The ecrt_slave_config_dc method essentially just sets the cycle values into the 
registers directly, while using the sync0_shift to calculate the overall DC 
start time relative to the master cycle.  The sync1_shift parameter is ignored 
and should always be 0 because there’s nothing it can actually do with it.

Exactly what these mean is slave-specific; some slaves want a simple shift at 
the same cycle rate because they use one to control output timing and the other 
to control input timing.  Other slaves might want a subordinated cycle (SYNC1 
occurring at the master cycle rate, SYNC0 occurring more frequently) because 
they want to oversample inputs.  Or there can be a number of other scenarios.  
The slave documentation should tell you what settings you need relative to your 
master cycle.

For what it’s worth, I do have a subordinated slave – it uses 
ecrt_slave_config_dc(sc, 250000, 100000, 750000, 0) to make SYNC0 pulse every 
0.25ms, SYNC1 pulse every 1ms (yes, 1ms, not 0.75ms), and both to be offset 
from the 1ms master cycle by about 100us – although that’s a little arbitrary.

I assume the change was probably motivated by this sort of slave configuration 
(since it does extend the “true” cycle time of the slave, from a certain point 
of view), but simple addition is probably wrong when a non-multiple sync1 cycle 
time is used to introduce any kind of shift into the mix.

From: etherlab-users [] On Behalf Of 
Graeme Foot
Sent: Friday, 18 May 2018 13:03
To: Philippe Leuba <>;
Subject: Re: [etherlab-users] Slave DC start time calculation


This piece of code is getting a start time that is in sync with the initial app 
time from a multiple of the sync0/sync1 cycle times, adjusted by the sync0 
shift time.
says the sync1 cycle time is the "Time between SYNC1 pulses and SYNC0 pulse in 

 (Twincat DC settings) and the information for my yaskawa drives are saying 
that the sync1 cycle time should be a multiple of the sync0 cycle time, and the 
sync1 offset is the offset between the sync0 and sync1 interrupts.

The master code doesn’t even look like it uses the sync1 shift time, and 
information from my Yaskawa slave says it's sync1 cycle time is readonly and 
matches the sync0 cycle time.

- It looks like the first documents registers 0x09A4:0x09A7 should actually be 
called sync1 shift time.
- It does not look like there is currently any slave support for a different 
(from sync0) sync1 cycle time.
                (anyone got a slave out there that does?)
- The EtherLab master should not be using sync1 cycle time in the calculation 
you mention below.
- The EtherLab master should be sending sync1 shift time to 0x09A4:0x09A7 
instead of the sync1 cycle time.
- TwinCAT is probably using its cycle time "multiple" parameters to figure out 
how often to send the PDO requests for each slave (just a guess).

In your case, set the second to last parameter to zero, i.e.:
ecrt_slave_config_dc(sc, 0x0700, 500000, 250000, 0, 0);

You have already adjusted the sync0 shift time (third to last parameter) anyway.


From: etherlab-users [] On Behalf Of 
Philippe Leuba
Sent: Friday, 18 May 2018 7:11 AM
Subject: Re: [etherlab-users] Slave DC start time calculation


I have changed how to calculate the slave start time by taking only the 
sync0->cycle_time as cycle time.
The results is good and I can see in the log that the 'remainder' is almost the 
same for all slaves.

@Florian: Why did you did this change on 2016-09-16 ?

Best regards


On May 16, 2018, at 6:22 PM, Philippe Leuba 
<<>> wrote:
Hi All,

I can not understand how to configure correctly my slaves with the 
ecrt_slave_config_dc() function.

I use nine EL7211-9014 servo controllers and the XML declarations is:

<CycleTimeSync0 Factor="1">0</CycleTimeSync0>
<ShiftTimeSync0 Input="0">30000</ShiftTimeSync0>
<CycleTimeSync1 Factor="-1">0</CycleTimeSync1>

SYNC0 and SYNC1 should be fired at each cycle.

My realtime cycle is at 500us, so initially I used:

    ecrt_slave_config_dc(sc, 0x0700, 500000, 30000, 1000, 0);

but I sometimes faced some hiccup on some motor movements (almost always on the 
same motor, but sometimes not), most probably due to frames late regarding SYNC 
events, so I increased the sync1_shift to half of the cycle time:

    ecrt_slave_config_dc(sc, 0x0700, 500000, 250000, 1000, 0);

This help, but I’m still not convinced that it is correct.

How can I debug this, I did not see any error on slaves COEs 1c32 or 1c33 ?

Startup debug messages are the followings:

EtherCAT DEBUG 0-12: Checking for synchrony.
EtherCAT DEBUG 0-12: 19 ns difference after 1 ms.
EtherCAT DEBUG 0-12: app_start_time=64456682505935
EtherCAT DEBUG 0-12:       app_time=64460192975876
EtherCAT DEBUG 0-12:     start_time=64460292975876
EtherCAT DEBUG 0-12:          cycle=501000
EtherCAT DEBUG 0-12:     shift_time=250000
EtherCAT DEBUG 0-12:      remainder=263941
EtherCAT DEBUG 0-12:          start=64460293462935
EtherCAT DEBUG 0-12: Setting DC cyclic operation start time to 64460293462935.
EtherCAT DEBUG 0-12: Setting DC AssignActivate to 0x0700.
EtherCAT DEBUG 0-13: Checking for synchrony.
EtherCAT DEBUG 0-13: 9 ns difference after 1 ms.
EtherCAT DEBUG 0-13: app_start_time=64456682505935
EtherCAT DEBUG 0-13:       app_time=64460854977928
EtherCAT DEBUG 0-13:     start_time=64460954977928
EtherCAT DEBUG 0-13:          cycle=501000
EtherCAT DEBUG 0-13:     shift_time=250000
EtherCAT DEBUG 0-13:      remainder=444993
EtherCAT DEBUG 0-13:          start=64460955283935
EtherCAT DEBUG 0-13: Setting DC cyclic operation start time to 64460955283935.
EtherCAT DEBUG 0-13: Setting DC AssignActivate to 0x0700.

I’m really surprised that the remainder can be so different, so I looked in the 
source code and can not understand the logic:

    // set DC start time
    start_time = master->app_time + EC_DC_START_OFFSET; // now + X ns (X being 
100000000 = 100 ms)

    if (sync0->cycle_time) {
        // find correct phase
        if (master->has_app_time) {
            u64 diff, start;
            u32 remainder, cycle;

            diff = start_time - master->app_start_time;
            cycle = sync0->cycle_time + sync1->cycle_time;
            remainder = do_div(diff, cycle);

            start = start_time + cycle - remainder + sync0->shift_time;

Why the cycle is the sum of the two sync->cycle_time, in my case 501000, should 
not it be: sync0->cycle_time (500000) ?

This was changed on 2016-09-16, but It seems it was right before.

I can see that sync0->cycle_time is written to register 9A0 (500000)
and sync1->cycle_time is written to register 9A4 (1000), this is correct.

It seems to me that the sync1_cycle parameter of the ecrt_slave_config_dc() is 
handled as as sync1_shift, this is really confusing.

Is it normal, can someone explain this ?

etherlab-users mailing list<>
etherlab-users mailing list

Reply via email to