[etherlab-users] API questions (plaintext repost)

[WIEGAND Ralf]

Hello,

we also use the RTDM-interface. I've patched the current stable release
with the RTDM-interface-patch from Graeme Foot. We use it with kernel 2.6.32.11 
and rtai-3.8.1 without any problems at the time of this writing. Thanks to 
Graeme Foot for the great job.
I can provide a patch for the current stable version (1.5.0) during the next week.

I've some further suggestions for the RTDM-Interface development:
- Usage of rtdm-types (rtdm_sem_t,...) in the rtdm-module (realtime system independent)
- Integration of the sdo-interface-functions

We also like to know the state of the integration into the stable release.


Ralf Wiegand





Hexagon Metrology GmbH
Siegmund-Hiepe-Str. 2-12
35578 Wetzlar
Deutschland

Phone: +49 6441 207-410
Fax: +49 6441 207-387

E-Mail: Ralf.Wiegand at hexagonmetrology.com 



Hauptgeschäftsführer: Holger Fritze
Geschäftsführer: Per Holmberg - Erik Steinbacher - Arno Seuren
Amtsgericht Wetzlar, HRB 1201



-----Ursprüngliche Nachricht-----
Von: etherlab-users-bounces at etherlab.org im Auftrag von Graeme Foot
Gesendet: Di 1/10/2012 22:43
An: etherlab-users at etherlab.org
Cc: George Broz
Betreff: Re: [etherlab-users] API questions (plaintext repost)
 
Hi,

Re: RTDM patch for 2124

I did the update to RTDM to get the multiple domains going.  I haven't
heard the latest status either.


As for SDO's via RTDM, I was about to add some of them to the RTDM api,
in the next couple of weeks probably.

SDO requests take a bit of time to process and you don't want to block
the realtime thread, so you have a couple of options with SDO's via a
realtime thread:
1) pass off a request to a helper thread to get/set SDO information then
poll for a response.
2) make the SDO methods available via RTDM and set up a state machine to
monitor the SDO's progress.


For my application I'm thinking #2 is the slightly better option.


Graeme.


-----Original Message-----
From: etherlab-users-bounces at etherlab.org
[mailto:etherlab-users-bounces at etherlab.org] On Behalf Of George Broz
Sent: Tuesday, 10 January 2012 23:16
To: etherlab-users at etherlab.org
Subject: [etherlab-users] API questions (plaintext repost)

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 reads incorrectly). Typical 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? 
 
In October, 2011 a patch (2124) 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 at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users