My cyclic thread really isn't a thread. My cycles start based upon a real hardware interrupt clock from hardware we designed. So overrun wouldn't apply.
ie. in my kernel driver I have HardwarerInterruptServiceRoutine() { DoLocalServos.... if (EcatEnable = 1) { ecrt_master_recv() ecrt_master_send() } } ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg) { case ECATENABLE: ecrt_master_activate() pdata = ecrt_domain_data(); EcatEnable = 1 break; } In user space fd = open ioctl(fd,ECATENABLE,0) I'm not in a position at this time to measure ecrt_master_activate but I will when I get a chance. On Fri, 2012-03-09 at 11:31 +1300, Graeme Foot wrote: > I think that's the main difference then. In user space > ecrt_master_activate() can't be called from a hard realtime thread > (RTAI). So the two options are: > - call it before making the thread hard rt > - call it in a parallel non-hard rt thread > > How long do you find that your call ecrt_master_activate() takes? Mine > is taking 2-3ms. Does it cause your cyclic thread period to overrun? > > Graeme. > > > > -----Original Message----- > From: Henry Bausley [mailto:hbaus...@deltatau.com] > Sent: Friday, 9 March 2012 11:05 > To: Graeme Foot > Cc: etherlab-users@etherlab.org > Subject: RE: [etherlab-users] Distributed Clock with Yaskawa SGDV drives > > > The kernel module does contain the cyclic loop and it is always running. > The kernel module also has an ioctl interface so when the user space app > tells it to activate, the kernel module calls activate then sets some > flags so that the cyclic loop starts sending and receiving at its next > cycle. In my case within 125usec - 500sec depending on the users setup. > > On Fri, 2012-03-09 at 10:40 +1300, Graeme Foot wrote: > > Hi, > > > > I'm not using any kernel side modules. It sounds like what I'm doing > is > > effectively the same, where there are two threads, one (hard rt) for > the > > data cycle and the other to call ecrt_master_activate(). The cycle > > thread signals the ecrt_master_activate() thread when the master > should > > be activated (on the very first cycle), whereas in your case your > cycle > > thread is signalling to a kernel module instead. > > > > Or is your kernel module doing the data cycle and the > > ecrt_master_activate() in one? > > > > I'm being very conservative with my soft to hard transition delay > > (~50ms) to ensure I don't miss the first wakeup. > > > > I also only enable the drive once in cyclic mode (and the drive has > > reached OP mode). > > > > I've also replied to Florian with a bit more info. > > > > Graeme. > > > > > > -----Original Message----- > > From: Henry Bausley [mailto:hbaus...@deltatau.com] > > Sent: Friday, 9 March 2012 08:58 > > To: Graeme Foot > > Cc: etherlab-users@etherlab.org > > Subject: Re: [etherlab-users] Distributed Clock with Yaskawa SGDV > drives > > > > Graeme, > > > > I have always called ecrt_master_activate in my xenomai kernel > driver. > > That same xenomai kernel driver has its cyclic loop running all the > time > > but waits for a flag indicating whether to start ethercat activity. > > > > I trigger the kernel driver call to ecrt_master_activate with a user > > space application that makes an ioctl call to the xenomai kernel > > driver. > > > > Using this methodology I don't have the "soft" to "hard" delay you > > describe and have not ever seen the errors you described with the > SGDV. > > Also I always enable the drive when in cyclic mode ie. index 6040 = > > 0x80 -> 6 -> 7 -> 15 . > > > > > > > > > > > > On Thu, 2012-03-08 at 17:01 +0100, Florian Pose wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Hi, > > > > > > Am 23.02.2012 23:58, schrieb Graeme Foot: > > > > I configure my amps to use cyclic position mode which requires the > > > > pdo data to arrive consistently. In the time it takes to go from > > > > soft to hard rt the amps often miss too many pdo datagrams and > they > > > > were raising the alarm A12 (Sync Error). > > > > > > ecrt_master_activate() is intended to be called when no slaves are > > > operational and there is no necessarity to have any meaningful > > > operation anyway. Why are your slaves complaining when they are not > in > > > operation yet? They should checks for sync errors earliest when in > > > SAFEOP state. > > > > > > - -- > > > Regards, > > > Florian > > > -----BEGIN PGP SIGNATURE----- > > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > > > iEYEARECAAYFAk9Y19YACgkQABFOIMygR8yOUgCfQFmLKM4LByWMzPrpiAmMoW3F > > > gu0An06I0j0Y+satXo9OAVmby5aamLnD > > > =WxIg > > > -----END PGP SIGNATURE----- > > > _______________________________________________ > > > etherlab-users mailing list > > > etherlab-users@etherlab.org > > > http://lists.etherlab.org/mailman/listinfo/etherlab-users > > > > > > > > > > > > Outbound scan for Spam or Virus by Barracuda at Delta Tau > > > > > _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users