[etherlab-users] Multiple SDO requests

Gavin Lambert gavinl at compacsort.com
Wed Aug 30 02:02:24 CEST 2017


First off, note that using printfs inside your cyclic task is going to kill your latency.  By itself this shouldn’t cause any issues with SDOs, unless it’s sufficient to trigger the timeout.

 

The master does support a limited number of concurrent SDO requests, provided that they are always to different slaves.  By default it will only process up to 16 concurrent requests at a time, however.  So if you might have larger networks it’s a good idea to allow some downtime, perhaps only scheduling a read request once per second or even slower (depending how many slaves you have and how often you really need the data).

 

I didn’t spot anything obviously wrong in your code.  To diagnose further you should probably set “ethercat debug 1” and then examine your syslog after running your application; this will contain additional information about the progress of requests.

 

Another thing you might want to consider is trying out the unofficial patchset at https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme; this includes a number of patches to enhance mailbox stability and increase slave concurrency.

 

From: Jordan Palacios
Sent: Wednesday, 30 August 2017 02:03
To: etherlab-users at etherlab.org
Subject: [etherlab-users] Multiple SDO requests

 

Dear Etherlab users,

 

I have a setup with some Elmo Gold boards where I wish to access some data objects that unfortunately are not mappable. The information from these data objects is not really required each cycle, though it should be requested regularly.

 

I'm attaching a sample test code where I try to read the same data object in three different slaves each cycle. The result is that the sdo request for the third slave is never successful.

 

It is as if the master could not serve more than one SDO request at a time. Is this correct? I am doing something wrong?

 

Kinds regards.

 

Jordán.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20170830/83ac2a99/attachment-0003.htm>


More information about the Etherlab-users mailing list