Hello,
I'm running a recent version (month or two old) of the IgH master stack (it supports the e1000e driver on Linux 2.6.37.6) on Xenomai 2.5.6. I had a handful of questions.
The information returned by ecrt_master_state() (slaves responding, al_states, and link_up) returns stale information if the first slave is unplugged after a slave network is brought up. The master has to be restarted (/etc/init.d/ethercat restart) before the slave count is accurate (and even then link_up never reads incorrectly). Expected behavior or a bug?
When do I need to use ecrt_master_callbacks()? I've read the docs and source. An internal mutex protects the datagram queue. If I'm doing PDO exchange (receive/process/queue/send) in one thread and want to piggyback short SDO commands from another thread onto the cyclic packet, do I need to use ecrt_master_callbacks() to coordinate? The source already adds fsm packets asynchronously with respect to the cyclic thread.
The state-machine implementation of the IgH stack is a pleasure to follow. It would be helpful to have access to the state flags of these state machines to integrate better with application code. Any plans for that?
Sometime back a patch was submitted for multi-domain support through the RTDM interface. Can anyone comment on its status? I'd be happy to help test this for the "default, (Xenomai-enabled)" branch. Are there any plans to include RTDM and Xenomai support in the "stable" branch?
The RTDM interface doesn't include support for SDOs b/c *configuration* is not needed during realtime. But often you need to *query* for additional information during realtime, e.g. the detailed cause of a raised error bit in the PDO. AFAIK, without an RTDM interface, this would drive the calling Xenomai task into secondary (Linux) mode introducing other issues... for another newsgroup.
Thanks in advance for any answers/comments,
--George Broz
Moog, Inc. Industrial Group
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
