[etherlab-users] Error reassigning removed PDO

[Richard Hacker]

Am 04/22/2014 09:33 AM, schrieb Gavin Lambert:
> Hi all,
>
> TLDR: when reassigning PDOs, why doesn't the master read mappings from the
> slave via CoE?
For the very simple reason, that the application can start without any 
slaves being attached to the network!

In order to be able to do that, the master must be informed of the 
network topology _and_ the SyncManager configuration of every slave.

The slaves themselves have different levels of intellegence. The 
simplest of them all don't support any reconfiguration, some support 
reconfiguring SyncManagers with different predefined and fixed PDO's and 
yet others support even reconfiguring PDO's themselves.

Some slaves don't even know their configuration until they have booted 
and been configured by the master, as in the case of completely dynamic 
slaves like bus converters, e.g. EtherCAT <-> ProfiBus converters. These 
slaves are completely dependent on the master telling the slave what its 
configuration looks like, in terms of SyncManager, PDO's and even PDO 
Entries!

Whether SyncManagers and PDO's are fixed or even mandatory should be 
documented in the ESI xml file.

Just by the way, SII does not necessarily contain valid information, but 
it might. SII is a sort of online data storage where the slave 
manufacturor can store some information. Here is a typical example of a 
"single point of truth" flaw: the information in SII should reflect the 
slave, but if it doesn't, the slave still works but you have been led 
behind the bush! Even though there is a certification test to check that 
the SII information is correct, slaves exist where this is not the case.

TLDR: RTFM of the slave and tell the master how a slave is to be 
configured ;) It is not a waste of space.

- Richard

>
> 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
>