<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 15 (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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:2129543614;
mso-list-type:hybrid;
mso-list-template-ids:-149121722 336134159 336134169 336134171 336134159 336134169 336134171 336134159 336134169 336134171;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D;mso-fareast-language:EN-US'>I’ve posted some patches in the past that make some additional information available to the master application. But in general to detect errors you look at the “error_flag” from ecrt_master_get_slave() or ecrt_slave_config_state(). There are also some patches (made by others) that dramatically improve bus scan time.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D;mso-fareast-language:EN-US'>It’s also possible to open a separate handle to ioctl with as needed – that’s what the command-line client does after all. Just bear in mind that the ioctl API is more volatile and it’s not intended for application use; and doing it concurrently with realtime access may harm performance.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D;mso-fareast-language:EN-US'>If your network is changing, you have two choices:<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:#1F497D;mso-fareast-language:EN-US'><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D;mso-fareast-language:EN-US'>Drop out of operation phase, figure out the new configuration based on the auto-increment addresses of the devices that have actually shown up, and return to operation phase.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:#1F497D;mso-fareast-language:EN-US'><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D;mso-fareast-language:EN-US'>Assign aliases to at least the “tree points” (the first slave of every group that can appear or disappear as a whole unit), and then configure the maximum configuration based on the relative offsets from these known aliases. You can then remain in operation phase as devices appear and disappear from the network. (Note however that you’ll also have to create different domains for each group, or have some way to tell from the data itself whether a particular group has disappeared from a larger domain.)<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D;mso-fareast-language:EN-US'>Etherlab doesn’t have a direct way to assign aliases, but they are persistent so you can use another master to assign them and Etherlab will recognise them. In some cases you might be able to do a command-line CoE download using Etherlab to set an alias, but this depends on slave support.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> etherlab-users [mailto:etherlab-users-bounces@etherlab.org] <b>On Behalf Of </b>Tillman, Scott<br><b>Sent:</b> Saturday, 6 June 2015 09:14<br><b>To:</b> etherlab-users@etherlab.org<br><b>Subject:</b> [etherlab-users] Bus Scan<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-US>I am only beginning to grok the etherlab stack, but I’ve got some questions about bus scanning and topology discovery.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>First, is there a reason that the user library doesn’t have a method to trigger a bus scan? There is an ioctl for it (EC_IOCTL_MASTER_RESCAN), and the ethercat tool uses that to trigger a rescan, but I don’t see any way to reach this from the library (struct ec_master is opaque to the library user, so I can’t just call ioctl).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>When the bus scan fails (under a VM this happens a lot during SII reading) there doesn’t seem to be any direct indication of this. The best indicator I can find is that the VendorId and ProductCode fields are zeroed out for a slave that failed. Shouldn’t there be a status of some kind?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Since the bus scan takes a significant amount of time, is it possible to request a scan of only the slave(s) that failed? It doesn’t look like it, but I thought maybe I missed something.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>When the master is active I understand the very low response timeout (500us). However, when the master is deactivated we aren’t guaranteed to be in real time context, so that’s a *<b>really</b>* small timeout. Isn’t it reasonable to have a much longer timeout value for deactivated communications? On my development VM (using a USB to Ethernet adapter) I have to increase the timeout more than 1000x to avoid timeouts and failures in the bus scan. More generally, is there a reason that a user shouldn’t be able to set the timeouts programmatically, so I can set it via config file based on deployment platform?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>I see a wait queue tied to the bus scan completion, but there doesn’t appear to be a way to use it to just wait until scan completion. I’d like to be able to setup a thread that monitored the bus for changes and reacted, but it looks like that requires polling of the scan_busy flag? At the moment it looks like the only way to reach this wait queue is via ec_master_enter_operation_phase.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>When topologies change during active operation is there a way to use the slave port connectivity graph to indicate device configuration information? I know what my maximal configuration will be, and I know that dynamic connect/disconnect will affect a specific port<->port edge. That doesn’t alter any configuration except devices sharing that edge. Tying config info to auto-inc addresses seems fragile. Has this or anything like it be discussed previously?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>-Scott Tillman<o:p></o:p></span></p></div></div></body></html>