Last month, I wrote: > TLDR: when reassigning PDOs, why doesn't the master read mappings from > the slave via CoE? [...] > Shouldn't this scenario work? The PDO is always specified in the SII, > even if not presently in PDO Assign, so the master ought to know that it > exists. > And failing that, it could just try to read the mappings directly from > the slave (if CoE is available) when unable to load default mapping from > its cache. (I think part of the problem is that the CoE data appears to > be replacing the SII data in the master's PDO cache.) > > I'm also a little puzzled as to why (if it wants to have a cache of PDO > mappings) it seems to limit itself to reading only the currently > assigned PDOs during the initial scan, instead of fetching all of them. > They shouldn't be hard to find -- they can be identified purely by their > index.
There's a further problem with this that I've since discovered: if, during the master's scan of the PDO assignment registers, something goes wrong with the CoE transfer of 0x1C1x:0, then the master will log an error but proceed anyway under the assumption that the slave has 0 PDOs assigned in that SM. If this is not contradicted by the application using ecrt_slave_config_pdos (including both assigns and mappings, because it read no default mappings), then the master will *write 0 back* to the PDO assignment register (if writable) on activate. This guarantees that the next scan will not find any PDOs, unless the slave reloads the default assignments during INIT (and with my "slave author" hat on, all advice I can find says that slaves should not do that, although I couldn't find official word). So basically it all seems to point to applications being unreliable (at least for flexible-assignment slaves) unless they use ecrt_slave_config_pdos to configure *everything* (including mappings, even for fixed-mapping slaves). Which makes me wonder why it bothers scanning for PDO assignments at all. Doesn't that just waste time if apps have to use ecrt_slave_config_pdos anyway? Given how flaky mailbox handling is in general (as previously mentioned), I'm surprised this hasn't come up more often. _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users