<div dir="ltr"><div><div>Hello Gavin,<br><br></div>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.<br>

<br></div>Regards,<br>Jun<br><div class="gmail_extra"><br><br><div class="gmail_quote">On 29 May 2014 09:37, Gavin Lambert <span dir="ltr"><<a href="mailto:gavinl@compacsort.com" target="_blank">gavinl@compacsort.com</a>></span> wrote:<br>

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