(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:[email protected]] Sent: Friday, 9 March 2012 05:01 To: Graeme Foot Cc: [email protected] 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----- _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
