[etherlab-users] failing dc-sync-check (and rtdm patch)

George Broz GBroz at moog.com
Wed Jan 25 20:46:06 CET 2012


Hi,

Thanks for the patch, Graeme. I'm hoping
we can try it out next week.


Here's what we found/did:

The timeout message comes from the DC-SYNC-CHECK state
in the slave configure state machine. It appears that 
the master is attempting to initialize the time offset 
(0x920) register of each slave to sync with the master's 
clock. The slaves at this point are still in PREEOP 
(no cyclic transfer). Hence, if you have many slaves and a 
long timeout, you can spend a long time in this state. I 
still don't understand why this takes so long to converge.
To make it converge a little faster, we clear the 0x920 
register explicitly using the command line tool 
(ethercat reg_write). This forces a new offset to be 
set by ec_fsm_master_dc_offset64() and seems to 
make things work a little more consistently.

Afterwards, assign activate is applied and cyclic transfer
begins.

But that was not the end of it.. as previously mentioned,
continually calling ecrt_rtdm_master_sync_reference_clock() 
did not result in a converging (0x92c) value for the network. 
Using the command line tool, one could see that the slaves'
individual 0x92c values were pretty good, except for the
first slave (holding the reference clock). Increasing the 
cyclic frequency from 1kHz to 4kHz, helped the first slave's
0x92c value reach smaller values (but not stable). 
We added logic to the application that waits for the 
aggregate 0x92c value to drop below 2000 micro-second 
threshold, at which point we stop calling 
ecrt_rtdm_master_sync_reference_clock() and just call 
ecrt_rtdm_master_sync_slave_clocks() from then on. This 
results in slave-slave synchronization in the 20 ns 
ballpark as reported by the individual 0x92c registers 
and verified in h/w by monitoring SYNC0 signals 
on a scope.

It would be extremely useful (for many reasons) to 
have an RTDM interface to a function that can read
and write slave registers directly - basically 
having functionality of the ethercat reg_read, 
reg_write command line tool from the real-time
thread. In this case we would use it to monitor
individual slave sync 0x92c registers because
we cannot subtract out the reference slave's
contribution. Do you know of any patches
out there that provide this???


BTW - We tried using both --enable-cycles 
and --enable-hrtimer options and that did 
not help. I am not sure I have the proper
underlying OS configuration setup to support
those options, so that's a little 
inconclusive.


Best regards,

--George Broz
Moog, Inc. Industrial Group


-----<etherlab-users-bounces at etherlab.org> wrote: -----
To: <etherlab-users at etherlab.org>, George Broz <GBroz at moog.com>
From: Graeme Foot 
Sent by: 
Date: 01/24/2012 10:37PM
Subject: Re: [etherlab-users] failing dc-sync-check (and rtdm patch)

Hi,

I've been having the same problem (ie: Slave did not sync after 5000
ms).  
In my case it was happening on most startups and sometimes after running
for a while.

When it happened after the app had been running a while the domain
working counter changed from 2 to 1 and one of the slaves got an error
0x0A11 - EtherCAT State Error (The EtherCAT AL state became not
"Operational" while the DS402 drive state is in "Operation enabled.").
I have no idea what this error means.


I fixed my startup case by waiting until the working counter state on
the domains used by the dc slaves were all EC_WC_COMPLETE (ie all
registered process data were being exchanged).


This of course meant that I needed to add another rtdm method
"ecrt_rtdm_slave_config_dc".  To do so I have rejigged the rtdm
framework so that the rtdm functions are now in the user space ec
library.  I needed to do this because I had to access more of the
library types and it was getting unwieldy keeping it separate.

Some little changes as a result:
- proper functions rather than defines
- ecrt_rtdm_master_application_time takes a direct value rather than
pointer
- ecrt_rtdm_domain_states now takes a ec_domain_state_t array pointer
- new function ecrt_rtdm_slave_config_dc


I have attached a full rtdm patch in case anyone wants it (for 2124).


Graeme.




-----Original Message-----
From: etherlab-users-bounces at etherlab.org
[mailto:etherlab-users-bounces at etherlab.org] On Behalf Of George Broz
Sent: Monday, 23 January 2012 23:08
To: etherlab-users at etherlab.org
Subject: [etherlab-users] failing dc-sync-check

Hello,

What would cause the dc-sync-check to fail (resulting in the "Slave did
not 
sync after..." message in the error log), even when the timeout 
(EC_DC_SYNC_WAIT_MS) is set long (30 seconds)? 

After 30 seconds, the "Sync after..." is still in the 4 milli-second
range - far from the 5 micro-seconds needed to pass.

In my application, after calling master_activate() 
a Xenomai task every 5 milli-seconds calls: 

* ecrt_rtdm_master_application_time()
* ecrt_rtdm_master_sync_reference_clock(), and
* ecrt_rtdm_master_sync_slave_clocks()
 
The first slave is the reference clock. It generally takes 10 to 20
seconds 
for the first slave to get past this step (if at all). The other slaves
take less, 
but still a couple of seconds. Slave to slave sync is good (<1000ns),
but gets 
much better (<100ns)when I stop calling sync_reference_clock().
 
I read in a previous post that --enable-cycles helped. Is this
necessary?

Is there something I can do (e.g. "adjust" the application_time) to make
this
converge faster? Should it help to rescan the bus before starting my
application?

I am running the "default-tip" (2271) version of the master.

Master-to-ref.slave synchronization (using EtherCAT) is not important to
us, but 
slave-to-slave sync is critically important to us.


Thanks in advance,
--George Broz
Moog, Inc. Industrial Group
_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users



[attachment "etherlabmaster-1.5-2124-c_rtdm_full.patch" removed by George Broz/ber/us/moog]



More information about the Etherlab-users mailing list