[etherlab-dev] Hot plugged modules failing to read DC register

Wed Sep 25 07:05:39 CEST 2019

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.

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.

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.

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

90ms seems a bit slow for just an ESC power-on SII read, although it's possible that it's doing something more complicated.

I'm not really familiar with those modules, however; you're probably best off asking Beckhoff directly.

Gavin Lambert
Senior Software Developer

[cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png]
[cid:compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png]<http://www.compacsort.com> [cid:facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png] <https://www.facebook.com/Compacsort>  [cid:linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png] <https://www.linkedin.com/company/compac-sorting-equipment/>  [cid:youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png] <https://vimeo.com/compacsort>  [cid:twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png] <https://twitter.com/compacsort>  [cid:insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png] <https://www.instagram.com/compacsort/>

COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +64 96 34 00 88 | tomra.com<http://www.tomra.com>

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.

From: Graeme Foot
Sent: Tuesday, 24 September 2019 17:20
To: etherlab-dev at etherlab.org
Subject: [etherlab-dev] Hot plugged modules failing to read DC register

Hi,

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.

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.

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.

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.

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

Regards,
Graeme.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190925/dc8cd384/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
Type: image/png
Size: 11438 bytes
Desc: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190925/dc8cd384/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
Type: image/png
Size: 1629 bytes
Desc: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190925/dc8cd384/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
Type: image/png
Size: 1750 bytes
Desc: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190925/dc8cd384/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
Type: image/png
Size: 1855 bytes
Desc: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190925/dc8cd384/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
Type: image/png
Size: 1970 bytes
Desc: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190925/dc8cd384/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
Type: image/png
Size: 20278 bytes
Desc: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190925/dc8cd384/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png
Type: image/png
Size: 1506 bytes
Desc: insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20190925/dc8cd384/attachment-0013.png>