Has anyone verified distributed clocks synchronization with a scope? Initially I monitored the register 0x92C and it would move +/- ~1000 and assumed distributed clocks were working properly. Upon further research we noticed that our servo output and the servo drive had drift with respect to one another.
I assumed the frequency variations would be accommodated for by the slave ic since the reference clock came from the master by default. However, I never saw any frequency variation from the slave on the scope. It stayed at 3.99997kHz while my clock was at 4.00015kHz. Was this assumption wrong? I thought the slave frequency would change. The only way I have been able to sync my frequency and the slave is by using Graeme's patch and modifying my master's interrupt rate every cycle. What we saw until incorporating Graeme's patch is we would get an awful growl in the servo when sending data as our clock drifted into the drives sync0 interrupt. We were using cyclic torque. This we now believe is because a packet would arrive while the drive was servicing the sync0 interrupt and would return old data and cause spikes in the servo loop. For simple I/O I don't know if syncing the frequencies is critical but it definitely seems to be for servos. Is there any chance we can get Graeme's ecrt_master_sync_slave_clocks_diff and ecrt_master_setup_distributed_clock patches added to the repository? Many thanks to Graeme for posting the patch it works well!!!! Currently I have tested with a single drive but will add additional drives to my network soon. On Sat, 2012-04-28 at 14:04 +1200, Graeme Foot wrote: > Hi, > > Just try: > time += 250000 > You will get jitter, but will avoid the drift. > > Or better yet you can record your GetNsecHWClock() times over time and > calculate a drift factor so you can do something like: > time += HWClock - HWClockOld - drift > > Relooking at your code below, after the time increment I'd also do: > HWClockOld = HWClock > Rather than: > HWClockOld = GetNsecHWClock() > Otherwise you are introducing an extra drift due to the (small) time > difference between the two GetNsecHWClock() calls. > > > Graeme. > > -----Original Message----- > From: Henry Bausley [mailto:hbaus...@deltatau.com] > Sent: Saturday, 28 April 2012 10:01 a.m. > To: Graeme Foot > Cc: etherlab-users@etherlab.org > Subject: RE: [etherlab-users] Copley Drive w/ Distributed Clocks Drifting > > Thanks Graeme. > > I am actually reading my CPUs clock which runs at 1GHz with some > assembler instruction. However the H/W card of the custom ASIC > generating the interrupt runs off its own clock!!! > So it looks as if you pointed out there will be drift between when the > delta time of my ISR occurrence and the cpu based delta time I am sending to > ecrt_master_application_time. If the ASIC had a clock register to read I > think I would be in business but of course it doesn't. > I think you have found the flaw. > > On Fri, 2012-04-27 at 10:02 +1200, Graeme Foot wrote: > > Hi, > > > > Just a couple of thoughts. > > > > Does GetNsecHWClock read the time from your servo card? Does the time > > increment by 250000ns every period (ignoring jitter)? Ie is your > > clock time drifting with respect to the ISR? > > > > > > I would try moving the get time and ecrt_master_application_time call > > to just before the ecrt_master_send call. > > > > The reason for this is that ecrt_master_application_time caches the > > time value and then ecrt_master_send will send the time datagram > > without making any adjustments to the time value. So if theres any > > variance in processing time between ecrt_master_application_time and > > ecrt_master_send you will be creating a jitter in the time the slave > > is reading. (There is already enough jitter just with > > ecrt_master_send.) > > > > eg: > > > > void PhaseISR() > > { > > static time > > > > ecrt_master_receive > > EC_READs > > > > ServoLoopCalcs() > > > > EC_WRITEs > > Ecrt_domain_queue > > > > HWClock = GetNanosecHWClock() > > if(init_time) > > { > > clockgettime(&time) > > init_time = 0 > > } > > else > > { > > time += HWClock - HWClockOld > > } > > HWClockOld = GetNsecHWClock() > > Ecrt_master_application_time(time) > > Ecrt_master_sync_reference_clock > > Ecrt_master_sync_slave_clocks(pshm->ECAT[idxMaster].Master) > > > > Ecrt_master_send > > } > > > > > > What type of slave is being used as the slave reference clock? I have > > a Beckhoff CX1020 with a built in coupler (CX1100-0004) with a 32bit dc. > > I found that if this was the reference slave my yaskawa amps did not > > like syncing to it. I changed my reference slave to an EK1100 coupler > > (64bit dc) and things are much more stable. > > > > > > I don't know if this will make any difference but try reversing > > ecrt_master_sync_reference_clock and ecrt_master_sync_slave_clocks. > > This may (or may not) let the reference slave propagate a more stable > > time to the rest of the slaves before receiving the updated time from > > the master. > > > > > > Regards, > > Graeme. > > > > -----Original Message----- > > From: etherlab-users-boun...@etherlab.org > > [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Henry > > Bausley > > Sent: Wednesday, 25 April 2012 09:46 > > To: etherlab-users@etherlab.org > > Subject: [etherlab-users] Copley Drive w/ Distributed Clocks Drifting > > > > > > I am working with Copley attempting to use Cyclic Synchronous Torque > > Mode at 250usec. We have setup up the distributed clocks w/ > > Sync0_Cycle as 250000 and assign activate at 0x330. > > > > What is being seen on the scope is the time at which an EtherCAT frame > > arrives eventually drifts into when the Sync0 signal occurs on the > > slave. When this occurs the motor glitches since the drive cannot > > accept our torque command and provide feedback at this time. > > > > The engineers at Copley were gracious enough to create a pair of > > outputs so we could monitor something on the scope. Take a look at the > > video clip it displays this better than I can explain it. > > > > The lower signal rising edge occurs at SYNC0 time. The upper signal > > is high while receiving an EtherCAT frame. > > > > ftp://support.deltatau.com/DT-USA/Henry/CopleyEtherLAB.mp4 > > > > > > When we monitor the register 0x92C with watch -n0 "ethercat reg read > > -p0 -tsm32 0x92c" > > we see +/- 2000 > > > > Our code is virtually identical to the provided examples except it > > operates in an ISR triggered by a custom servo card. > > > > void PhaseISR() > > { > > static time > > > > ecrt_master_receive > > EC_READs > > > > ServoLoopCalcs() > > > > HWClock = GetNanosecHWClock() > > if(init_time) > > { > > clockgettime(&time) > > init_time = 0 > > } > > else > > { > > time += HWClock - HWClockOld > > } > > HWClockOld = GetNsecHWClock() > > Ecrt_master_application_time(time) > > > > Ecrt_master_sync_reference_clock > > Ecrt_master_sync_slave_clocks(pshm->ECAT[idxMaster].Master) > > EC_WRITEs > > Ecrt_domain_queue > > Ecrt_master_send > > } > > > > My ISR has ~10usec of jitter. I am using RTL8168B PCIe cards with a > > PowerPC AMCC460EX 1Ghz CPU. > > > > I don't have the setup in my hands but will be receiving it in a few > > days. > > > > Any ideas would be greatly appreciated!!!!! > > > > > > > > > > > > Outbound scan for Spam or Virus by Barracuda at Delta Tau > > > > _______________________________________________ > > 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
