[etherlab-users] Bus Scan

[Gavin Lambert]

I've posted some patches in the past that make some additional information
available to the master application.  But in general to detect errors you
look at the "error_flag" from ecrt_master_get_slave() or
ecrt_slave_config_state().  There are also some patches (made by others)
that dramatically improve bus scan time.

 

It's also possible to open a separate handle to ioctl with as needed -
that's what the command-line client does after all.  Just bear in mind that
the ioctl API is more volatile and it's not intended for application use;
and doing it concurrently with realtime access may harm performance.

 

If your network is changing, you have two choices:

1.       Drop out of operation phase, figure out the new configuration based
on the auto-increment addresses of the devices that have actually shown up,
and return to operation phase.

2.       Assign aliases to at least the "tree points" (the first slave of
every group that can appear or disappear as a whole unit), and then
configure the maximum configuration based on the relative offsets from these
known aliases.  You can then remain in operation phase as devices appear and
disappear from the network.  (Note however that you'll also have to create
different domains for each group, or have some way to tell from the data
itself whether a particular group has disappeared from a larger domain.)

 

Etherlab doesn't have a direct way to assign aliases, but they are
persistent so you can use another master to assign them and Etherlab will
recognise them.  In some cases you might be able to do a command-line CoE
download using Etherlab to set an alias, but this depends on slave support.

 

From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On Behalf
Of Tillman, Scott
Sent: Saturday, 6 June 2015 09:14
To: etherlab-users at etherlab.org
Subject: [etherlab-users] Bus Scan

 

I am only beginning to grok the etherlab stack, but I've got some questions
about bus scanning and topology discovery.

 

First, is there a reason that the user library doesn't have a method to
trigger a bus scan?  There is an ioctl for it (EC_IOCTL_MASTER_RESCAN), and
the ethercat tool uses that to trigger a rescan, but I don't see any way to
reach this from the library (struct ec_master is opaque to the library user,
so I can't just call ioctl).

 

When the bus scan fails (under a VM this happens a lot during SII reading)
there doesn't seem to be any direct indication of this.  The best indicator
I can find is that the VendorId and ProductCode fields are zeroed out for a
slave that failed.  Shouldn't there be a status of some kind?

 

Since the bus scan takes a significant amount of time, is it possible to
request a scan of only the slave(s) that failed?  It doesn't look like it,
but I thought maybe I missed something.

 

When the master is active I understand the very low response timeout
(500us).  However, when the master is deactivated we aren't guaranteed to be
in real time context, so that's a *really* small timeout.  Isn't it
reasonable to have a much longer timeout value for deactivated
communications?  On my development VM (using a USB to Ethernet adapter) I
have to increase the timeout more than 1000x to avoid timeouts and failures
in the bus scan.  More generally, is there a reason that a user shouldn't be
able to set the timeouts programmatically, so I can set it via config file
based on deployment platform?

 

I see a wait queue tied to the bus scan completion, but there doesn't appear
to be a way to use it to just wait until scan completion.  I'd like to be
able to setup a thread that monitored the bus for changes and reacted, but
it looks like that requires polling of the scan_busy flag?  At the moment it
looks like the only way to reach this wait queue is via
ec_master_enter_operation_phase.

 

When topologies change during active operation is there a way to use the
slave port connectivity graph to indicate device configuration information?
I know what my maximal configuration will be, and I know that dynamic
connect/disconnect will affect a specific port<->port edge.  That doesn't
alter any configuration except devices sharing that edge.  Tying config info
to auto-inc addresses seems fragile.  Has this or anything like it be
discussed previously?

 

Thanks,

-Scott Tillman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20150608/8b9f024e/attachment-0003.htm>