[etherlab-users] Error reassigning removed PDO

Thu Jun 5 04:23:49 CEST 2014

Hi Jun,

While that patch looks like an improvement, it will still have the same trouble if the master service is restarted between runs, or if an application wants to include a PDO that is not assigned by default.

I think having ecrt_slave_config_pdos (or actually ec_slave_config_load_default_mapping) upload the mapping from the slave is actually the better solution and not ugly at all, in theory.  Bear in mind that this should only happen if the slave is online and if the mapping was not already found in the application-supplied mappings or the previously-read cache.  (Though note that the current code structure would do it regardless of whether the application supplied mappings or not, as an unfortunate consequence of the API structure.  But it will meet the other two conditions.)

And it would only be one SDO upload if the slave supports Complete Access, which the master should already know at that point.  (Although that’s an optimisation missing from the current PDO configuration code as well.)

Regards,

Gavin Lambert

From: Jun Yuan [mailto:j.yuan at rtleaders.com] 
Sent: Saturday, 31 May 2014 04:24
To: Gavin Lambert
Cc: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] Error reassigning removed PDO

Hi Gavin,

I have a gift for you. The attached patch should make your scenario with different PDOs of interest in different apps working. The problem was that the master always makes the last PDO assign in SyncManager as the default PDO assign, and it don't remember any older PDO assignment. I made a patch to get a memory for the PDO mappings, and it always merge the new PDO mapping list into the old list, instead of throw the old list away. It remembers things. 

It is still not so smart like you said to fetch the PDO assign using their index via CoE automatically. I don't know if it's a good idea for the master to do it blindly. The question is when should the master fetch it. If the master fetches all the PDO mappings during the bus scan, isn't that a waste of time, because most of the time we don't need all of them? If fetch it when needed, the master needs to call several ecrt_master_sdo_upload() in the function ecrt_slave_config_pdos() to fetch the mapping, which makes the code quite ugly. And actually the app can do it itself, and then provides the correct default PDO mapping to the master.

Hope you enjoy it!

Regards,

Jun

On 22 April 2014 09:33, Gavin Lambert <gavinl at compacsort.com> wrote:

Hi all,

TLDR: when reassigning PDOs, why doesn't the master read mappings from the
slave via CoE?

I have a (custom) slave that provides a number of different PDOs.  I have a
couple of different master applications which are interested in different
subsets of these PDOs.  As an example, let's say that the slave has an RxPDO
at 0x1600 that points to 0x7000:0x00:0x20, and one app wants to use this
value and the other doesn't.

If the master apps just use ecrt_domain_reg_pdo_entry_list to register the
PDOs of interest, then they both work (assuming that the slave has all the
required PDOs assigned by default), but it wastes space in the packet as the
whole SM is transferred even if some of the data is not of interest to that
particular master app.  (And in the case of outputs, it forces the master
app to write something even when it doesn't want to, lest the slave get
uninitialized data and think it needs to do something with it.)

If the master apps use ecrt_slave_config_pdos to select the PDOs of
interest, then things get troublesome.  If the master apps specify the full
mappings explicitly, then again things work, but as the slave does not
support remapping (just reassignment) this generates warnings, and it just
seems ugly to me to have to specify all this data that the slave already
knows.  (And it makes things more brittle, as if the mapping is changed in a
future version of the slave it will generate an error instead of just
working, as it would if it had loaded the slave's current mappings.)

If the master apps don't specify the full mappings, however (just the sync
manager -> PDO assignments, which seems like it's a supported scenario given
the docs and examples), then results are mixed.  If the slave is rebooted
prior to running either master app, it works.  If not, then the master app
that wants the extra PDO will fail to run.

The problem case seems to be:
  - slave boots, has all PDOs in SII and CoE PDO assign.
  - first app runs, specifies PDO Assign to not include 0x1600.
    - runs successfully.
    - PDO Assign is updated in the actual slave.
  - second app runs, specifies PDO Assign to include 0x1600.
    - fails at ecrt_reg_pdo_entry_list as it cannot find a mapping for
0x7000:0x00.
    - problem is "Loading default mapping for PDO 0x1600." - "No default
mapping found."
    - PDO Assign of the actual slave is never actually updated in this case
as it fails before it activates the slave configs.
  - "ethercat rescan" / "ethercat pdos" at this point does not show 0x1600.
  - it requires rebooting the slave, or manually updating PDO Assign (and
rescanning) before the master will admit that it exists again.

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.

It shouldn't be all that uncommon to have a slave that provides PDOs that
aren't in the default PDO Assign, or to provide more information than needed
for particular master apps.  Is it just expected that master apps always
hard-code the full mappings, instead of fetching the mappings from the
slave?  Or is this something missing from the library at present?

Regards,
Gavin Lambert

_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

-- 
Jun Yuan
[Aussprache: Djün Üän]

Robotics Technology Leaders GmbH
Am Loferfeld 58, D-81249 München
Tel: +49 89 189 0465 24
Fax: +49 89 189 0465 11
mailto: j.yuan at rtleaders.com

Umlautregel in der chinesischen Lautschrift Pinyin: Nach den Anlauten y, j, q, und x wird u als ü ausgesprochen, z.B. yu => ü,  ju => dschü,  qu => tschü,  xu => schü. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20140605/d4e2d33a/attachment-0002.htm>