[etherlab-users] Error reassigning removed PDO

[Jun Yuan]

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 <gavinl at 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 at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20140529/9e88bfd2/attachment-0003.htm>