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. _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users