[etherlab-users] (libethercat) Reading list of all objects available in slaves object dictionary

[Frank Jeschke]

Hi Gavin, thanks for the clarification. Indeed I want the SDOs in the
object dictionary for configuration purposes and of course not in the real
time context.

Frank

Gavin Lambert <gavinl at compacsort.com> schrieb am Mo., 31. Okt. 2016 um
00:28 Uhr:

> On 28 October 2016 22:13, quoth Frank Jeschke:
> > Hi list, I'm implementing a EtherCAT master software using the
> > libethercat library. Now I need to read the list of all the
> > Objects in the device(s) object dictionary. Something similar
> > what I get with
> >
> > $ ethercat sdos
> > Sadly I couldn't find anything in the header ecrt.h which looks
> > like a function giving me desired result.
> >
> > So my question is, is there another posibility with the use of
> > libethercat or do I have to hack something with the ioctl call
> > to retrieve the list of objects?
>
> The ecrt.h API are just the functions that real-time applications are
> expected to use.  This does include read/writes to known SDOs, but not
> diagnostic information such as reading the list of SDOs; those are left to
> the "tool" APIs, which are exposed only as ioctls.  You can have a look at
> the "tool" source for usage examples.
>
> Bear in mind that fetching the object dictionary can be quite slow
> (several seconds per device), and is usually unnecessary in applications;
> unless you're trying to implement a "configurator" rather than a standard
> application.  In fact, one of the significant performance improvements in
> the unofficial patchset was to avoid fetching the dictionary at all most of
> the time.
>
> Also note that while it is safe to call these while a real-time loop is
> running (though not in the real-time thread itself, since they're
> blocking), they do acquire locks and might increase your real-time latency.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20161102/dd3f485e/attachment-0002.htm>