<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-NZ link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>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.)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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 <b>expected</b> (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.)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(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.)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>