[etherlab-users] Omron Servo Drive with Distributed Clocks

[Graeme Foot]

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