[etherlab-users] Distributed Clock with Yaskawa SGDV drives

[Henry Bausley]

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: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
> > 
> 
> 
>