[etherlab-users] Copley Drive w/ Distributed Clocks Drifting

Graeme Foot GraemeF at touchcut.com
Sat Apr 28 04:04:34 CEST 2012


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:hbausley at deltatau.com] 
Sent: Saturday, 28 April 2012 10:01 a.m.
To: Graeme Foot
Cc: etherlab-users at 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-bounces at etherlab.org
> [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Henry 
> Bausley
> Sent: Wednesday, 25 April 2012 09:46
> To: etherlab-users at 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 at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users





More information about the Etherlab-users mailing list