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 [[email protected]] > Sent: Thursday, September 13, 2012 10:16 PM > To: Ben Yehuda, Raz > Cc: [email protected] > 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). > > > > > > > > [email protected] > > > > > > > > > Outbound scan for Spam or Virus by Barracuda at Delta Tau >
_______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
