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@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.
_______________________________________________
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev

Reply via email to