[etherlab-users] Error reassigning removed PDO

[Gavin Lambert]

On Tuesday, 22 April 2014 20:21, quoth Richard Hacker:
> For the very simple reason, that the application can start without any
> slaves being attached to the network!

I thought it might be something like that.  However this seems of very
limited usefulness to me as there doesn't seem to be any way to tell which
parts of the domain data are valid when only some of the slaves are online
-- querying the domain state will only tell you none/partial/all, without
more specifics (eg. per-slave success/failure).  It seems to me that it's
better to avoid going cyclic in the first place until all expected slaves
are present, since slaves coming online as they are booted will change the
topology and thus the ring positions anyway.  But maybe I'm just missing
something.

It does look like it's possible to call ecrt_master_get_slave in the cyclic
thread to check whether a particular slave is in OP or not (and handle its
corresponding domain data accordingly), but is this safe if the network
topology changes in the background?  (Even if there's internal locks, if the
data can change between calls then it could read the same slave twice or
miss one or try to read a no-longer-existing position.)  Also it seems like
it could be potentially heavy to call this for every slave on a large
network, especially from user mode.

But this is getting slightly off topic.


> In order to be able to do that, the master must be informed of the
> network topology _and_ the SyncManager configuration of every slave.

In this case, why do the examples indicate that CONFIGURE_PDOS is
"optional"?  Why does ecrt_slave_config_pdos permit not providing the full
mappings?  Why are there examples that don't even call
ecrt_slave_config_pdos or its related subfunctions?

These cases will not work unless the slave is present and online and already
has the PDO Assign registers set to at least a superset of the desired data.
(The latter of which seems like an odd restriction to me, and is mainly what
I'm trying to query here.)

The information provided to ecrt_slave_config_reg_pdo_entry is not
sufficient to discover the SM layout of the slave (and hence the memory
layout of the domain) without either an online slave or explicitly providing
the full PDO configuration.

> Just by the way, SII does not necessarily contain valid information, but
> it might. SII is a sort of online data storage where the slave
> manufacturor can store some information. Here is a typical example of a
> "single point of truth" flaw: the information in SII should reflect the
> slave, but if it doesn't, the slave still works but you have been led
> behind the bush! Even though there is a certification test to check that
> the SII information is correct, slaves exist where this is not the case.

I know that; in fact my slave is one of those (due to the way that the XML
is translated to SII, it omits some of the default PDOs, because they're
covered by parts of the standards that have not been standardised yet for
SII EEPROM).  It annoys me but there's not a lot I can do about it.

But given that Etherlab can do a CoE dictionary scan to augment the SII, I
don't know why it's only scanning *currently* assigned PDOs and ignoring all
the *potentially* assignable PDOs, especially for a slave with PdoAssign=1
and PdoConfig=0.