[etherlab-users] Is Ethercat Master Enough to Control Servo

[Henry Bausley]

I have been using Graeme's patch w/ xenomai in kernel mode and been
happy so far.

I create a kernel level task with

rt_task_set_periodic(&phaseclock_task,TM_NOW,phaseperiod);

And in that task I tweak the periodic tasks interval based upon the
ecrt_master_sync_slave_clocks_diff value returned from Graemes patch
ie.  

phaseclock_task.thread_base.ptimer.interval =
xnarch_ns_to_tsc(phaseperiod_modifed);

I think this is what you refer to as "you have to fix the master TIMER"

I was able to control the Copley at 16kHz in torque mode w/ quadrature
encoders and on the scope I see no drift.  Without the scope all I have
to
do is look at the time difference of ecrt_master_sync_slave_clocks_diff
and make sure its steady and I know its synced up.

It would be real nice to get a slave based distributed clock solution in
the repository!!!  

It doesn't seem the slaves sync if the master is used as the reference
clock.



On Fri, 2012-09-14 at 21:49 +0200, Ben Yehuda, Raz wrote:

> no. I do not use Graeme Foot's patch because it is was not enough. you have to fix the master TIMER ( not the time ) as well.
> 
> this is what i did:
> 
> 1. Sampling  sync0 -  rx port0 of slave 0. 
> 
> 2. do the above  5 times a second. 
> 
> 3.  calibrating hpet0 frequency according to delta = sync0 - rx port0. i chose delta=300 us . i am getting delta of +-50us in average.
>      Calibration is done by speeding up hpet or decreasing down the hpet clock frequency. i calibrated my system to 250HZ, and fixed
>     the hpet driver code to: 
>     3.1 provide a hardware timer hook . not a simulated one. ie, not hpet[1...] but hpet0. see hpet spec for that.
>     3.2 provide ioctl to hpet to be able to decrease/increase the speed of the clock in a mild manner ( i cannot change frequency to 249 or 251,,
>          it is too aggressive).
>    3.2 my cyclic task is done in kernel space in the hpet timer hook, the motion logic in user space.
> 
> 4. once system is rescanned i perform a STANDARD offset calibration. ie, sampling rxport of each slave. Etherlab reads 910 from each slave, not 0x900
>     as in the standard.
> 
> 5. send ARMW constantly each tick. also, i am reading 910 all the time. i will be fixing it to provide 910 from each slave to be able to see
>    if slaves are NOT calibrated without scope. 
> 
> i order to see how bad the master clock is i connected parallel wire to the master and out_b to the parallel (lpt) each time cyclic task woke.
> i connected probes to the parallel wire. 
> I was able to sync 3 hilscher slaves with sync0-rxport=300us +- 50us , and  3 hilscher slaves with sync0 -rx port = 300 += 70us jitter.
> currently i testing other slaves. i still have some way to go with these patches.  
>  
> I use preempt rt. i am not using xenomai or rtai. and i am not using threads for transmission. once you use threads, you are subordinates your 
> task the os heuristics more than in the case of hardware interrupt.  
>  
> ________________________________________
> From: Henry Bausley [hbausley at deltatau.com]
> Sent: Thursday, September 13, 2012 10:16 PM
> To: Ben Yehuda, Raz
> Cc: etherlab-users at etherlab.org
> Subject: Re: [etherlab-users] Is Ethercat Master Enough to Control Servo
> 
> Raz,
> 
>    Did you use Graeme Foot's DC patch?
> 
> http://lists.etherlab.org/pipermail/etherlab-users/2012/001642.html
> 
> 
>    I found that without using the slave's clock as a reference there was
> always drift even though I have a system with low jitter and my cycles
> are performed in kernel mode.  I still don't quite understand why if
> someone has a answer let me know.
> 
>   Using a scope we monitored the Copley sync0 interrupt and the arrival
> of the packet (Thank you for these diagnostic outputs Copley).  You can
> see them drifting with respect to one another in the mpeg link.
> 
> ftp://support.deltatau.com/DT-USA/Henry/CopleyEtherLAB.mp4
> 
> 
>    This would manifest itself as a periodic growling noise in the motor
> every time the packet would arrive at the same time as the sync
> interrupt.  You MAY be able to get away with this in a point to point
> application like a pick and place robot, however it would be
> unacceptable for machining.
> 
>   I found I could never get some amplifiers to properly sync up without
> using a slave as the reference clock.  The slave timing does not seem to
> modify its self to the master's clock.  Using graeme's patch and
> modifying my cycle time based on the slave's clock I was able to get rid
> of the drift you see in the scope in the mpeg and the growling noise in
> the motor.
> 
>   I use xenomai on PPC in kernel mode.  I am not sure how well
> RT_PREEMPT  would work but if the slave is used as the reference clock I
> think it might have a chance.
> 
> On Wed, 2012-09-05 at 09:13 +0300, Raz Ben Yehuda wrote:
> > On Sun, 2012-09-02 at 11:47 +0200, takeshi ikeya wrote:
> > > Hi Tahir!
> > > I think ENOUGH..
> > > If you need quick response, you'd beter use it under RTAI (Linux).
> > >
> > I must add that did not find the current design suitable for moving
> > servo drives. For this reason I modified etherlab to support slave DC
> > bus time ( currently etherlab is App time based).
> >
> > >
> > >   takeshi.ikeya at gmail.com
> >
> 
> 
> 
> 
> 
> 
> Outbound scan for Spam or Virus by Barracuda at Delta Tau
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20120917/7eeb3de3/attachment-0005.htm>