[etherlab-users] FW: Distributed Clock with Yaskawa SGDV drives

[Graeme Foot]

(forgot to replyall)

-----Original Message-----
From: Graeme Foot 
Sent: Friday, 9 March 2012 10:23
To: 'Florian Pose'
Subject: RE: [etherlab-users] Distributed Clock with Yaskawa SGDV drives

Hi,

Its effectively due to a race condition between calling
ecrt_master_activate() and the realtime cycle starting.  The slaves can
get to OP mode before the the hard rt cycle has started.  I'm using RTAI
in user space so I can't call ecrt_master_activate() once the thread has
been set to hard realtime (and it blocks for approx 2-3ms which is
longer than my cycle period).

So to avoid the race condition, I just call ecrt_master_activate() (in a
parallel non-hard rt thread) as soon as the hard rt thread is up and
cycling.  I have found it is better to start cycling too soon rather
than too late.


Graeme.


-----Original Message-----
From: Florian Pose [mailto:fp at igh-essen.com] 
Sent: Friday, 9 March 2012 05:01
To: Graeme Foot
Cc: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] Distributed Clock with Yaskawa SGDV drives

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