<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;
mso-fareast-language:EN-US;}
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.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
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:windowtext;}
.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;}
--></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">When the slave goes to safeop+error it should also output an AL error code which might give a hint as to why. This should be logged to the syslog when the master acknowledges the error.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">AL error 0x001B, for example, indicates that the slave stopped receiving SM frames (typical of a comms interruption) – and features/quick-op in the patchset tries to do a quicker recovery for this case by trying to go straight back to OP
instead of going through a full PREOP reconfiguration. It’s possible that some slaves may need the full reconfigure, so you can disable this behaviour at configure time.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Other AL error codes mean other things, such as your DC cycle being poorly synced and frames not occurring in a strict SYNC0-SM-SYNC0-SM ordering.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">But I wouldn’t normally expect any standard registers to fail WC when this occurs, unless perhaps the slave was performing a full power reset (or otherwise holding the slave’s ESC in reset). Though this would interrupt comms to any downstream
slaves as well, so it’s not something that slaves are supposed to do of their own accord. (And it shouldn’t stay in safeop+error in that case, it should revert to Init, although that’s up to the slave implementation.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">90ms seems a bit slow for just an ESC power-on SII read, although it’s possible that it’s doing something more complicated.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m not really familiar with those modules, however; you’re probably best off asking Beckhoff directly.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<P
style="FONT-SIZE: 100%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)"><STRONG>Gavin Lambert<BR></STRONG>Senior Software Developer<BR></P>
<P style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<TABLE>
<TBODY
style="FONT-SIZE: 75%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)"> </TBODY></TABLE></P>
<P style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><IMG border=0
src="cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png"><BR><A
href="http://www.compacsort.com"><IMG border=0 alt=TOMRA
src="cid:compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png" width=33
height=37></A> <A href="https://www.facebook.com/Compacsort"><IMG border=0
alt=Facebook src="cid:facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png" width=35
height=37></A> <A
href="https://www.linkedin.com/company/compac-sorting-equipment/"><IMG border=0
alt=Linkedin src="cid:linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png" width=35
height=37></A> <A href="https://vimeo.com/compacsort"><IMG border=0 alt=Youtube
src="cid:youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png" width=37 height=37></A>
<A href="https://twitter.com/compacsort"><IMG border=0 alt=twitter
src="cid:twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png" width=33 height=37></A>
<A href="https://www.instagram.com/compacsort/"><IMG border=0 alt=instagram
src="cid:insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png" width=33 height=37></A>
</P>
<P
style="FONT-SIZE: 75%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)"><B>COMPAC
SORTING EQUIPMENT LTD</B> | 4 Henderson Pl | Onehunga | Auckland 1061 | New
Zealand<BR>Switchboard: +64 96 34 00 88 | <A
href="http://www.tomra.com">tomra.com</A> </P>
<TABLE
style="BORDER-TOP-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-COLLAPSE: collapse; BORDER-BOTTOM-STYLE: none; BORDER-RIGHT-STYLE: none"
cellSpacing=0 cellPadding=0 border=1>
<TBODY>
<TR>
<TD
style="BORDER-LEFT-STYLE: none; BORDER-TOP: #595959 1pt solid; BORDER-BOTTOM: #595959 1pt solid; BORDER-RIGHT-STYLE: none"
vAlign=top>
<P
style="FONT-SIZE: 75%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)">The
information contained in this communication and any attachment is
confidential and may be legally privileged. It should only be read by the
person(s) to whom it is addressed. If you have received this communication
in error, please notify the sender and delete the communication.
</P></TD></TR></TBODY></TABLE>
<P
style="FONT-SIZE: 75%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)"></P><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" style="mso-fareast-language:EN-NZ">From:</span></b><span lang="EN-US" style="mso-fareast-language:EN-NZ"> Graeme Foot<br>
<b>Sent:</b> Tuesday, 24 September 2019 17:20<br>
<b>To:</b> etherlab-dev@etherlab.org<br>
<b>Subject:</b> [etherlab-dev] Hot plugged modules failing to read DC register<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I've had occasional issues with EL7332 and EL7342 modules where they will go to SafeOp + Error if you try and use them in DC mode. I've finally had some time to look into it a little further.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When the modules go to SafeOp + Error the master outputs the message "Slave has no System Time register; delay measurement only." (with debug level 1). This occurs due to the datagram reading register 0x0910 returning a working counter
of zero.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I created a quick hack to retry reading the register up to 100 times before failing. After approx. 90ms the EL7342 module I'm testing with successfully returned the datagram and the slave entered Op state successfully.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In my test setup I also have an EL5101 module that was doing the exact same thing (and taking around the same time), but I've never really had issues with them before. I suspect the difference is that if you have incorrect settings on
the EL7342 module and try to run a motor it can error out and reset itself, causing a situation equivalent to a hot plug.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Without my hack both modules need to wait for the SII read to complete for a similar length of time, so it looks like the slaves do not respond to the 0x0910 register request until the EEPROM read is complete. Does anyone know if this
is expected behaviour, or know of a better solution than to retry reading the register (up to 200ms ???)?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Graeme.<o:p></o:p></p>
</div>
</body>
</html>