[etherlab-users] Omron Servo Drive with Distributed Clocks

Fri Mar 2 00:03:19 CET 2012

Thats interesting we never had any DC problems with the Yaskawa drives
once they got their F/W to 3.01.  We run them consistently at 250usec,
I'm pretty sure they even run at 125usec.  However, I'm using embedded
hardware with my own clock generating an interrupt and not a PC. 

I have always read the H/W clock between each servo cycle and used that
value and not a += constant like you suggested.  Our code looks like

ServoISR()
{
master_receive(master);
EC_READ_xxx   // a bunch of these   
domain_process(domain);

master_application_time
master_sync_reference_clock
master_sync_slave_clocks

EC_WRITE_xxx // a bunch of these    
domain_queue
master_send
}

I'll try your suggestion and move the distributed clock statements to
right before master_send and see if that helps.

I'm don't even think method 1 for distributed clocks would even work
with us.  We also run motors from a parallel bus at the same time for
high performance systems which is why I'm working from an ISR.  Our
feedback is latched in H/W on a rising clock edge and the control effort
is transmitted on a falling edge. 

But I can have Omron try setting their reference slave clock based on
masters time and see if they see the same problem with TwinCAT which I
suspect they will.

Your thoughts are much appreciated.

Thanks,

Henry

On Fri, 2012-03-02 at 10:47 +1300, Graeme Foot wrote:
> Hi,
> 
> I have been working through some synchronization issues I've been having
> with the help of Yaskawa.
> 
> My setup is:
> - Linux 2.6.29.5
> - RTAI 3.8.1
> - EtherLabs EtherCAT 1.5
> 
> I have a user space application that makes the realtime EtherCAT calls
> via an RTDM patch.
> 
> My main problem was that sometimes my drives would stay synced, other
> times they would not.  Every time I rebooted the situation would change.
> 
> 
> I finally tracked it down to how Linux calibrates the PIT (programmable
> interval timer) timer to the TSC (time stamp counter).  This calibration
> value is used by RTAI to set the cpu frequency.
> 
> Linux does a quick calibration on startup but only to an accuracy of 500
> parts per million.  You can easily get a calibration value which results
> in a master clock drift outside of what the EtherCAT slaves can
> compensate for.
> 
> 
> As another issue, TwinCat has three types of Distributed Clock modes:
> 1) Update the master clock based on the reference slaves time
> 2) Update the reference slave clock based on masters time
> 3) Update the master clock based on an external clock source and then
> update the reference slave clock (or something like that).
> 
> The default TwinCat method is number 1.  Currently the only EtherLabs
> method is method 2.
> 
> Method 1 generally avoids sync errors because the slaves will generally
> have similar clock frequencies.
> 
> Method 2 relies on a reliable PC clock to polling period calibration
> (which I don't).
> 
> Note: The EtherLabs examples call ecrt_rtdm_master_sync_reference_clock
> then ecrt_rtdm_master_sync_slave_clocks, whereas TwinCat calls the
> datagrams in the reverse order.  The TwinCat order may be better as the
> ref slave may be able to smooth out master time jitter before it is
> propagated to the rest of the slaves (I'm not sure how immediate the
> drift compensation occurs on the slaves).
> 
> 
> >From what I understand:
> - you can update the ref slave to the master time any time you want as
> long as at the time of sending, the master time value is consistent.
> - you can update the slaves to the ref slave any time you want. 
> 
> The main time you run into problems is if:
> - the master clock time has too much drift for the slaves to compensate
> for.
> - you miss sending a pdo packet (or send too many) because the slaves
> loose sync and there is drift between the masters pdo polling cycle and
> the slaves dc cycle.
> 
> 
> So, for your situation I wouldn't have thought a ~20us jitter would be a
> problem, just as long as your drift is not too large and the master time
> you are sending to the ref slave is the current clock time (rather than
> just += 1000000).
> 
> Note: I call the dc sync methods just before calling
> ecrt_rtdm_master_send to ensure there is minimal variable between the
> master time and when the EtherCAT frames are sent out.
> 
> 
> I hope this helps.
> 
> Regards,
> Graeme.
> 
> 
> 
> 
> -----Original Message-----
> From: etherlab-users-bounces at etherlab.org
> [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Henry Bausley
> Sent: Friday, 2 March 2012 05:09
> To: etherlab-users at etherlab.org
> Subject: [etherlab-users] Omron Servo Drive with Distributed Clocks
> 
> 
> When using an Omron Servo Drive we are getting synchronization errors
> reported from the drive . 
> 
> Our code is bascially the dc_rtai example with the API rtos being a
> little different.  We use xenomai and use a PowerPC 1Ghz w/ RTL8168
> etherlabmaster 1.5 and operate based upon a H/W interrupt from a clock
> that can have see ~20usec of worse case jitter.  Omron in Japan
> currently has the drive what they report is as follows.
> 
> 
> 
> -------- Forwarded Message --------
> From: Satoshi.Kuramoto at omron.com
> To: Henry Bausley <hbausley at deltatau.com>
> Subject: Re: Fw: ECAT testing between PMAC and G5
> Date: Wed, 29 Feb 2012 16:48:40 -0800
> 
> Henry san, 
> 
> I am sorry to keep you waiting. 
> 
> I and Nakashima-san tested the EtherCAT connectivity between OMRON
> servos and some EtherCAT masters including the latest PMAC. 
> Unfortunately only PMAC had communication error. 
> 
> The reason would be that PMAC has the inaccurate timing in EtherCAT
> frames,  compared to the other masters. 
> OMRON servo, which equips 1 buffer , can not accept the inaccurate
> timing of the master frames. 
> 
> <Test result between PMAC and OMRON servos> 
> 
> WKC=2 was confirmed under the condition of the LRW , so Write was
> completed successfully but Read error occurred. 
> This means writing MPU ->ASIC was not completed during read instruction
> from the master. 
> 
> Normally there has to be timing gaps between a master and slaves, but
> the EtherCAT master has functions to compensate the timing  by checking
> into the timing of a slave. 
> By utilizing this function, Acontis , Beckhoff , and OMRON can realize
> the synchronous communication with OMRON servos. 
> PMAC also has this function , but it seems not to work well. 
> 
> When PMAC is connected to Yaskawa and Sanmotion who have 3 buffers, no
> communication error will exist. 
> However 1 buffer slaves like OMRON showed the communication error,
> because of smaller margins of the inaccuracy of frame timing. 
> 
> The reason for OMRON to have the 1 buffer is to realize higher accurate
> synchronous control than 3 buffer.
> 
> ------------------------
> 
> 
> We have used Control Techniques, Sanmotion , Yaskawa, Kollmorgen , ABB,
> Copley w/ DC without any issues.  
> 
> Does any one have any ideas for either proving or disproving Omron's
> theory so we find a solution?
> 
> 
> 
> 
> 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