[etherlab-users] rtdm sdo_request patch files
George Broz
GBroz at moog.com
Tue Jan 17 20:49:07 CET 2012
Thanks, Graeme! That helps us out.
We also concluded the preferred approach would be
to make SDO calls via RTDM and monitor
progress via state machine.
We'll be in the position to do some proof-of-concept
testing with this next week. I will post any
questions/feedback.
Best regards,
--George Broz
Moog, Inc. Industrial Group
-----<etherlab-users-bounces at etherlab.org> wrote: -----
>To: <etherlab-users at etherlab.org>
>From: Graeme Foot
>Sent by:
>Date: 01/16/2012 03:04PM
>Cc: George Broz <GBroz at moog.com>
>Subject: [etherlab-users] rtdm sdo_request patch files
>
>
>Hi,
>
>I have attached two patch files which add the following sdo functions
>to
>the rtdm interface:
>- ecrt_rtdm_sdo_request_timeout
>- ecrt_rtdm_sdo_request_data
>- ecrt_rtdm_sdo_request_data_size
>- ecrt_rtdm_sdo_request_state
>- ecrt_rtdm_sdo_request_read
>- ecrt_rtdm_sdo_request_write
>
>
>Attachments:
>"etherlabmaster-1.5-2124-c_rtdm_full.patch" is a complete rtdm patch
>file for 2124.
>"etherlabmaster-1.5-2124-b_rtdm_changes_2.patch" is an update to my
>previous patches with just the sdo additions.
>
>
>Other changes:
>- I renamed the struct "CstructMstrAttach" to
>"ec_rtdm_master_attach_t"
>so that it conforms better to the ethercat coding standards.
>
>
>Usage:
>1) create the sdo request object as usual in non-realtime
>
> sdoReq = ecrt_slave_config_create_sdo_request(slaveConfig,
> index, subIndex, dataSize);
>
>Note rtdm as you don't want memory allocations during realtime
>threads.
>Also, if you are reading a variable length sdo, set "dataSize" to
>the
>maximum memory required (the rtdm sdo read call will use as much as
>required as long as it fits, but will not realloc new memory if it
>doesn't).
>
>2) to write an sdo value...
>
> 2a) set up write:
>
> void *data = ecrt_rtdm_sdo_request_data(rtdmFD, sdoReq);
> EC_WRITE_S32(data, value);
> ecrt_rtdm_sdo_request_write(rtdmFD, sdoReq);
>
> 2b) wait for write complete:
>
> switch (ecrt_rtdm_sdo_request_state(rtdmFD, sdoReq))
> {
> case EC_REQUEST_SUCCESS : ... success logic ...; break;
> case EC_REQUEST_ERROR : ... error logic ...; break;
> default : break;
> }
>
>3) to read an sdo value...
>
> 3a) set up read:
>
> ecrt_rtdm_sdo_request_read(rtdmFD, sdoReq);
>
> 3b) wait for read complete:
>
> switch (ecrt_rtdm_sdo_request_state(rtdmFD, sdoReq))
> {
> case EC_REQUEST_SUCCESS :
> {
> void *data = ecrt_rtdm_sdo_request_data(rtdmFD, sdoReq);
> value = EC_READ_S32(data);
> ... success logic ...;
> } break;
> case EC_REQUEST_ERROR : ... error logic ...; break;
> default : break;
> }
>
>
>Let me know if there's something I've forgotten to mention.
>
>
>Regards,
>Graeme.
>
>
>-----Original Message-----
>From: Graeme Foot
>Sent: Wednesday, 11 January 2012 10:44
>To: etherlab-users at etherlab.org
>Cc: 'George Broz'
>Subject: 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
[attachment "etherlabmaster-1.5-2124-b_rtdm_changes_2.patch" removed by George Broz/ber/us/moog]
[attachment "etherlabmaster-1.5-2124-c_rtdm_full.patch" removed by George Broz/ber/us/moog]
More information about the Etherlab-users
mailing list