[etherlab-dev] CoE SII enable_pdo_assign etc

[Gavin Lambert]

I was recently looking at the behaviour of the coe_details flags in
master/slave.c:ec_slave_fetch_sii_general and master/fsm_pdo.c, and I'm not
entirely sure that it's correct.  (I'm also not entirely sure that it's
not.)

 

Currently it appears that the master is treating these as capabilities - if
the PDO Assign flag is not set, for example, then it will refuse to write to
SDO 1C12/1C13 during device configuration, even if they are writable and the
application code does pass in specific PDO configurations it wants.

 

Maybe my interpretation is faulty or the standard is worded incorrectly, but
I don't read that meaning from the description in ETG2000 table 40 - my
interpretation of this is that these define whether the master is expected
(or required) to send the configuration to the slave, but does not imply
that the master is not allowed to do so if these flags are not set.  (That's
determined by the access rights on the mapping objects themselves.)

 

(I'm sure there ought to be a description somewhere in ETG1000 too, but I
can't find it.  The ETG1000 documents are really hard to follow.)

 

So I would think that the startup configuration process should raise an
error if PDO Assign is set but the application has not supplied PDO
configuration data, but if the application has supplied PDO config data then
it should try to write it regardless of the flag (and cope with the error
return if it was read-only).  Or if SDO Info is enabled and it's previously
queried for the available PDOs (which I'm not certain of but seems likely)
then it should already know if the mapping objects are writable or not.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20130327/ab78b819/attachment-0002.htm>