<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
I have been using Graeme's patch w/ xenomai in kernel mode and been happy so far.<BR>
<BR>
I create a kernel level task with<BR>
<BR>
rt_task_set_periodic(&phaseclock_task,TM_NOW,phaseperiod);<BR>
<BR>
And in that task I tweak the periodic tasks interval based upon the ecrt_master_sync_slave_clocks_diff value returned from Graemes patch<BR>
ie. <BR>
<BR>
phaseclock_task.thread_base.ptimer.interval = xnarch_ns_to_tsc(phaseperiod_modifed);<BR>
<BR>
I think this is what you refer to as "you have to fix the master TIMER"<BR>
<BR>
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<BR>
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.<BR>
<BR>
It would be real nice to get a slave based distributed clock solution in the repository!!! <BR>
<BR>
It doesn't seem the slaves sync if the master is used as the reference clock.<BR>
<BR>
<BR>
<BR>
On Fri, 2012-09-14 at 21:49 +0200, Ben Yehuda, Raz wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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 [<A HREF="mailto:hbausley@deltatau.com">hbausley@deltatau.com</A>]
Sent: Thursday, September 13, 2012 10:16 PM
To: Ben Yehuda, Raz
Cc: <A HREF="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</A>
Subject: Re: [etherlab-users] Is Ethercat Master Enough to Control Servo
Raz,
Did you use Graeme Foot's DC patch?
<A HREF="http://lists.etherlab.org/pipermail/etherlab-users/2012/001642.html">http://lists.etherlab.org/pipermail/etherlab-users/2012/001642.html</A>
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.
<A HREF="ftp://support.deltatau.com/DT-USA/Henry/CopleyEtherLAB.mp4">ftp://support.deltatau.com/DT-USA/Henry/CopleyEtherLAB.mp4</A>
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).
>
> >
> > <A HREF="mailto:takeshi.ikeya@gmail.com">takeshi.ikeya@gmail.com</A>
>
Outbound scan for Spam or Virus by Barracuda at Delta Tau
</PRE>
</BLOCKQUOTE>
<BR>
<br>
</BODY>
</HTML>