[etherlab-users] Distributed Clock with Yaskawa SGDV drives

[Graeme Foot]

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:hbausley at deltatau.com] 
Sent: Friday, 9 March 2012 11:05
To: Graeme Foot
Cc: etherlab-users at 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:hbausley at deltatau.com] 
> Sent: Friday, 9 March 2012 08:58
> To: Graeme Foot
> Cc: etherlab-users at 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 at etherlab.org
> > http://lists.etherlab.org/mailman/listinfo/etherlab-users
> 
> 
> 
> 
> 
> Outbound scan for Spam or Virus by Barracuda at Delta Tau
>