[etherlab-users] Distributed Clock with Yaskawa SGDV drives

Graeme Foot GraemeF at touchcut.com
Thu Feb 23 23:58:25 CET 2012


Hi,

ecrt_master_activate is not available from a realtime context, so there
are two options:

1) call ecrt_master_activate just before starting hard realtime.
2) start hard realtime and call ecrt_master_activate in a non-realtime
helper thread

The problem I was having with option one is that after calling
ecrt_master_activate it takes a couple of milliseconds to go from soft
to hard realtime (in my case I'm starting the first realtime cycle to be
approx 10ms after the call to go hard).

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).
 
So I'm using option two, where ecrt_master_activate is called after the
pdo datagrams have been started.


Note: I also deactivate the master in the helper thread, but continue to
send the distributed clock messages in the hard realtime cycle for a bit
to avoid some errors I was getting on shutting down the system.


Regards,
Graeme.



-----Original Message-----
From: etherlab-users-bounces at etherlab.org
[mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Florian Pose
Sent: Thursday, 23 February 2012 21:11
To: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] Distributed Clock with Yaskawa SGDV drives

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Graeme,

Am 07.02.2012 04:45, schrieb Graeme Foot:
> create master_activate thread -------+ | start realtime
> | request master_activate     -->    | ecrt_master_activate 
> ecrt_rtdm_master_recieve           | (after first sync dc) sync dc
> | ecrt_rtdm_master_send              | <--    | master activated

I do not understand why it is necessary to call ecrt_master_activate()
from realtime context. If you call it and right after it start to
send() and receive() (including process data), the slaves already have
the possibility to "see" the process data during configuration (once
the FMMUs are configured).

- -- 
Best regards,
Florian
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9F9I0ACgkQABFOIMygR8z9GwCeIinIwYf9bB1rzbBthxTPB7iA
Q64An3jZpwNyc935ORX5SFsDyzXcq19b
=3W8y
-----END PGP SIGNATURE-----
_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users



More information about the Etherlab-users mailing list