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

[Florian Pose]

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

Am 12.03.2012 00:03, schrieb Graeme Foot:
> Hi,
> 
> The slaves are not in OP before ecrt_master_activate().  They are
> in OP after ecrt_master_activate(), but before the first PDO
> datagrams were sent.

But this is what the application is responsible for. After activating
the master, the ecrt_master_send()/receive() methods have to be called
by the application, otherwise *no* bus communication (including slave
configuration) will take place. That's why I'm not understanding, why
slaves can go to OP before 'seeing' the fist process data...

> I was sorting out a few problems I was having at the time, so it's 
> probably not such an issue anymore.  However the main issue is that
> I'm running from a user space thread in RTAI.
> 
> What I originally had was:
> 
> ecrt_master_activate() ... setting up app objects to use pdo data
> etc ... rt_make_hard_real_time() rt_task_make_periodic(...,
> firstScanTime, ...) rt_task_wait_period() while (true) { ...
> ethercat polling stuff etc ... rt_task_wait_period() }
> 
> I needed to call ecrt_master_activate() (and then set up objects 
> referring to the pdo data) before making the thread hard realtime.
> In the time it took for the first hard period to start some of the
> slaves had already reached OP mode and missed a couple of PDO
> datagrams.

See above, after ecrt_master_activate() is called, there is no bus
configuration until you call ecrt_master_send() cyclically.

> So instead of that, I added an ethercat function to allow
> pre-assigning of the pdo data from user space so that the pdo data
> objects could be set up before calling ecrt_master_activate().  I'm
> also putting the ecrt_master_activate() call in a non-hard realtime
> helper thread so there is minimal time between the
> ecrt_master_activate() call and the PDO packets starting to be
> sent.
> 
> It all comes down to ecrt_master_activate() not being able to be
> called from a hard realtime thread in RTAI because it drops the
> thread out of hard realtime.

Sure, because memory has to be allocated. It never was never meant to
be called in real-time.

So before futher discussions I would like to have an explanation, why
the slaves are configured before the application calls ecrt_master_send().

Could you tell me the exact code revision including all patches you use?

- -- 
Viele Grüße,
Florian
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9dvNMACgkQABFOIMygR8w43gCfTxQNvONoIgTnwWubf55ih3rA
ekoAnA9IRkZwPkzq+KPxwijhAld5+4Lc
=aGCa
-----END PGP SIGNATURE-----