[Etherlab-users] Patch for --enable-regalias

[Graeme Foot]

Yip, I stuffed up that first paragraph.  I blame covid brain.  What I meant to say was:

This patch will read 0x0012 if the SII alias is zero, but
if it is non-zero it will continue on to entering the slave into PREOP


The patch says it all:

diff --git a/master/fsm_slave_scan.c b/master/fsm_slave_scan.c
--- a/master/fsm_slave_scan.c
+++ b/master/fsm_slave_scan.c
@@ -589,14 +589,16 @@
         }
         // The SII image data is already available and we can enter PREOP
#ifdef EC_REGALIAS
-        ec_fsm_slave_scan_enter_regalias(fsm, datagram);
+        if (slave->effective_alias == 0) {
+            ec_fsm_slave_scan_enter_regalias(fsm, datagram);
+        } else if (slave->sii_image->sii.mailbox_protocols & EC_MBOX_COE) {
#else
         if (slave->sii_image->sii.mailbox_protocols & EC_MBOX_COE) {
+#endif
             ec_fsm_slave_scan_enter_preop(fsm, datagram);
         } else {
             fsm->state = ec_fsm_slave_scan_state_end;
         }
-#endif
     }
     else
#endif
@@ -1384,14 +1386,16 @@
     }

 #ifdef EC_REGALIAS
-    ec_fsm_slave_scan_enter_regalias(fsm, datagram);
+    if (slave->effective_alias == 0) {
+        ec_fsm_slave_scan_enter_regalias(fsm, datagram);
+    } else if (slave->sii_image->sii.mailbox_protocols & EC_MBOX_COE) {
#else
     if (slave->sii_image->sii.mailbox_protocols & EC_MBOX_COE) {
+#endif
         ec_fsm_slave_scan_enter_preop(fsm, datagram);
     } else {
         fsm->state = ec_fsm_slave_scan_state_end;
     }
-#endif
     return;

 end:

Graeme.

From: Gavin Lambert <gavin.lambert at tomra.com<mailto:gavin.lambert at tomra.com>>
Sent: Wednesday, 14 December 2022 11:16
To: Graeme Foot <Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>>; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: RE: Patch for --enable-regalias

You're using very confusing wording, which makes it hard to understand.  Admittedly I haven't reviewed the patch itself as yet.

Yes, if you have a slave that requires reading register 0x0012 then the SII
alias value will be zero.  This patch will read 0x0012 if the SII alias is zero, but
if it is non-zero it will continue on to reading the 0x0012 register.  Also if the
SII alias is non-zero then it should match the 0x0012 value, so reading 0x0012
is not required and can be skipped.

So it reads 0x0012 if the alias is zero, or it reads 0x0012 if the alias is non-zero, although it isn't required?  This appears to be some strange usage of the word "non-zero" that I wasn't previously aware of...

This patch will also improve scan performance of -enable-regalias by
skipping reading register 0x0012 if the slave has an non-zero SII slave alias.
Also if you do not use slave aliases in your system then you are unlikely to
Require -enable-regalias for this type of slave anyway.

This is a bit clearer, but it's different from what you said in your original post.

Gavin Lambert

Senior Software Developer TOMRA Fresh Food



[cid:image001.png at 01D90FB3.3D3DE750]

[cid:image002.jpg at 01D90FB3.3D3DE750]
 [tomra facebook] <https://www.facebook.com/TOMRA.Food/>  [tomra linkedin] <https://www.linkedin.com/company/tomra-food/>  [tomra twitter] <https://twitter.com/TOMRAFood>  [tomra youtube] <https://www.youtube.com/playlist?list=PLDD3B1A7BAE919EC6>  [tomra instragram] <https://www.instagram.com/tomrafood/>
 Compac Technologies Ltd | 4 Henderson Place | PO Box 13 516 | Onehunga 1061 | New Zealand
 Phone: +64 96 34 00 88 | https://www.compacsort.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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20221213/26043877/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6455 bytes
Desc: image001.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20221213/26043877/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 58287 bytes
Desc: image002.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20221213/26043877/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 10123 bytes
Desc: image003.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20221213/26043877/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 10214 bytes
Desc: image004.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20221213/26043877/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 10254 bytes
Desc: image005.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20221213/26043877/attachment-0009.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 10218 bytes
Desc: image006.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20221213/26043877/attachment-0010.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 10303 bytes
Desc: image007.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20221213/26043877/attachment-0011.jpg>