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-boun...@etherlab.org> wrote: ----- To: <etherlab-users@etherlab.org>, George Broz <gb...@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-boun...@etherlab.org [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of George Broz Sent: Monday, 23 January 2012 23:08 To: etherlab-users@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@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users _______________________________________________ etherlab-users mailing list etherlab-users@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] _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
