Hello Gavin, for that specific part of the CoE transfer problem you mentioned, I may have observed the same problem, and I did some analysis on it. This is actually a big problem, makes the master quite unreliable for me. I have a temporary fix for it. But I don't know who should be responsible for this CoE mailbox bug. Is it the master? Is it the slave? or is it a design error in the EtherCAT standard for the mailbox? I'll write another email to elaborate the problem with the flaky CoE mailbox.
Regards, Jun On 29 May 2014 09:37, Gavin Lambert <gav...@compacsort.com> wrote: > 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 >
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users