[etherlab-users] distributed clocks query

[Paul Mulligan]

Thanks.
It seems the however that the EL7031 stepper motor module does not work in DC mode even tho the AssignActivate word is listed in the device description xml file as 0x300.  

    On Tuesday, 1 March 2016, 17:04:39, Richard Hacker <ha at igh.de> wrote:
 

 DC is quite an intricate aspect of EtherCAT.

In DC enabled slaves, there are two clocks that generate events. You 
specify the time at which these clocks run as well as the time when the 
clocks start off for the first time. What the slave controller does at 
these events is implementation detail and must be documented by the 
manufacturer of the slave.

There is documentation available at
http://download.beckhoff.com/download/document/io/ethercat-terminals/ethercatsystem_en.chm
Check out Distributed Clocks -> Slave synchronization -> DC Modes.

In the master, it is configured using
void ecrt_slave_config_dc(
    ec_slave_config_t *sc, /**< Slave configuration.*/
    uint16_t assign_activate, /**< AssignActivate word.*/
    uint32_t sync0_cycle, /**< SYNC0 cycle time [ns].*/
    int32_t sync0_shift, /**< SYNC0 shift time [ns].*/
    uint32_t sync1_cycle, /**< SYNC1 cycle time [ns].*/
    int32_t sync1_shift /**< SYNC1 shift time [ns].*/
        );

You will be stetting sync0_cycle to your cycle time in nanoseconds and 
play around with sync0_shift somewhere half of your cycle time. The 
other values will be zero in your case (in fact, sync1_shift is not even 
used in the master!)

To check whether your slave is synchronizing, run:

watch -n0 "ethercat reg_read -pX -tsm32 0x92c"

where X is the position of your slave. This value should be quite low, 
in the order of a few hundred. This is a correction value in nanoseconds 
of the slave's clock.

On 01.03.2016 12:44, Paul Mulligan wrote:
> Hi,
>
> I'm still unsure as to what values are given for the last four
> parameters of this function. I believe the sync1_cycle and sync1_shift
> can be ignored but how is the sync0_shift value determined? I believe
> the frame should reach all the slaves before this time but also the new
> frame should not be received before this time. In the examples given, a
> scan time of 1ms is used but the sync0_shift value is 4.4 ms. How can
> this be correct?
>
> ecrt_slave_config_dc(modules[index].sc, 0x0300, scanTime, ??, ??, ??, ??);
>
>
> On Monday, 29 February 2016, 15:57:30, Richard Hacker <ha at igh.de> wrote:
>
>
> I only configure DC on the slaves that are actually required to be
> synchronized.
>
> Otherwise it seems correct what you are doing...
>
> Am 2016-02-29 um 14:45 schrieb Paul Mulligan:
>  > Hi,
>  >
>  > Just a question or two about distributed clocks.
>  >
>  > I have a system with an EL1008 digital input module, EL3001 analogue
>  > input module, two EL7031 stepper motor driver modules and two EL2008
>  > digital output modules in that order. I am using the EK1100 bus coupler
>  > terminal as the first module.
>  >
>  > Do I need to call ecrt_slave_config_dc() for all of these modules before
>  > activating the master, or just the first module on the bus? My
>  > understanding from reading about distributed clocks is that the first
>  > module on the bus with DC capability should be used as the reference
> clock.
>  >
>  >  From looking at the example "dc_user" supplied in the master download,
>  > it calls ecrt_slave_config_dc() only for the IDS_COUNTER module.
>  >
>  > In the cyclic_task(), the functions ecrt_master_application_time(),
>  > ecrt_master_sync_reference_clock(), ecrt_master_sync_slave_clocks() are
>  > then called in that order. I notice ecrt_master_reference_clock_time()
>  > is not used at all here.
>  >
>  > Is this all that is required to control the distributed clocks ? Thank
>  > you in advance.
>  >
>  >
>  > _______________________________________________
>  > 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/20160301/ae7f85d8/attachment-0003.htm>