[etherlab-users] Slave DC start time calculation

[Graeme Foot]

Hi,

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.

https://download.beckhoff.com/download/Document/io/ethercat-development-products/ethercat_esc_datasheet_sec2_registers_2i7.pdf
says the sync1 cycle time is the "Time between SYNC1 pulses and SYNC0 pulse in ns".

However https://infosys.beckhoff.com/english.php?content=../content/1033/tcsystemmanager/reference/ethercat/html/EtherCAT_DistributedClocks.htm&id= (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.


So:
- 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.


Regards,
Graeme.



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

Hi,

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

Philippe

On May 16, 2018, at 6:22 PM, Philippe Leuba <pleuba at swissonline.ch<mailto:pleuba at swissonline.ch>> 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:

<Dc>
<OpMode>
<Name>DC</Name>
<Desc>DC-Synchron</Desc>
<AssignActivate>#x700</AssignActivate>
<CycleTimeSync0 Factor="1">0</CycleTimeSync0>
<ShiftTimeSync0 Input="0">30000</ShiftTimeSync0>
<CycleTimeSync1 Factor="-1">0</CycleTimeSync1>
<ShiftTimeSync1>1000</ShiftTimeSync1>
</OpMode>
</Dc>

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 ?

Philippe
_______________________________________________
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/20180518/5487dc75/attachment-0003.htm>