[Etherlab-users] EoE in userspace - Other mailbox response

Mon Mar 17 10:26:40 CET 2025

Hi Gavin,

Thank you very much for your reply. At least this confirms that this is a
problem in our setup - we were not aware of this limitation.

We found the relevant patch and are trying to incorporate it into 1.6 now,
hoping our understanding of the code will suffice. Do you think CoE and EoE
should then work together on the same slave with that patch? We're running
a userspace application, and I've read before about ecrt_master_callbacks()
being necessary to synchronize the EoE and master threads, but that only
seems to apply to kernel-space applications. We've also seen that a mutex
has recently been added to protect master access between the EoE and master
thread, so we hoped that this was not an issue anymore.

Best regards,

<https://www.robco.de/>

Bernhard Vorhofer

Junior Software Engineer

------------------------------

bernhard.vorhofer at robco.de

Augustenstraße 10-14, 80333 Munich, Germany

RobCo GmbH

Managing Directors: Roman Hölzl, Paul Maroldt

HRB 259870, Munich Local Court, VAT ID: DE338129593

On Sun, 16 Mar 2025 at 23:31, Gavin Lambert <gavin.lambert at tomra.com> wrote:

> Yes, that’s a known issue; CoE and EoE in the same slave do not play
> nicely together.
>
>
>
> Currently the only known workaround is to use the unofficial patchset for
> 1.5
> <https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme>,
> which includes some patches to fix.
>
>
>
> Some of the patches have also been ported to the devel branch
> <https://gitlab.com/etherlab.org/ethercat/-/tree/devel> (which I have not
> tested) but I don’t think they made it into 1.6 for some reason.
>
>
>
> *Gavin Lambert*
> Software Engineer
>
>
>
>
>  [image: tomra facebook] <https://www.facebook.com/TOMRA.Food/> [image:
> tomra linkedin] <https://www.linkedin.com/company/tomra-food/> [image:
> tomra twitter] <https://twitter.com/TOMRAFood> [image: tomra youtube]
> <https://www.youtube.com/playlist?list=PLDD3B1A7BAE919EC6> [image: tomra
> instragram] <https://www.instagram.com/tomrafood/>
>  *TOMRA Food (ANZ) Limited* | 4 Henderson Place | PO Box 13 516 |
> Onehunga 1061 | New Zealand
>
>  Phone: +64 96 34 00 88 | https://www.tomra.com/food
> 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:* Etherlab-users <etherlab-users-bounces at etherlab.org> *On Behalf
> Of *Bernhard Vorhofer
> *Sent:* Saturday, 15 March 2025 5:00 am
> *To:* etherlab-users at etherlab.org
> *Subject:* [Etherlab-users] EoE in userspace - Other mailbox response
>
>
>
> Dear all,
>
>
>
> we're currently investigating some issues with a particular slave (BBH
> SCU-2-EC FSoE Master). There are multiple issues (sometimes the slave
> refuses state change to OP, for example), but something that piqued our
> interest be seen in the following log excerpt:
>
> kernel: EtherCAT DEBUG 0: ecrt_master_sdo_upload(master = 0x00000000d53d8735, slave_position = 0, index = 0x4002, subindex = 0x00, target = 0x00000000f9b1cb01, target_size = 40, result_size = 0x000000007e76960b, abort_code = 0x000000002d1055bf)
>
> kernel: EtherCAT DEBUG 0-0: Scheduling SDO upload request.
>
> kernel: EtherCAT DEBUG 0-0: Processing SDO request...
>
> kernel: EtherCAT DEBUG 0-0: Uploading SDO 0x4002:00.
>
> kernel: EtherCAT DEBUG 0-0: Upload request:
>
> kernel: EtherCAT DEBUG: 00 20 40 02 40 00 00 00 00 00
>
> kernel: EtherCAT DEBUG 0-0: Upload response:
>
> kernel: EtherCAT DEBUG: 00 30 41 02 40 00 28 00 00 00 00 74 0B 00 DF 8C
>
> kernel: EtherCAT DEBUG: CC 04 00 00 00 00 00 00 80 3F 00 00 00 00 00 00
>
> kernel: EtherCAT DEBUG: 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00
>
> kernel: EtherCAT DEBUG: 00 00
>
> kernel: EtherCAT DEBUG 0-0: Uploaded data:
>
> kernel: EtherCAT DEBUG: 00 74 0B 00 DF 8C CC 04 00 00 00 00 00 00 80 3F
>
> kernel: EtherCAT DEBUG: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> kernel: EtherCAT DEBUG: 00 00 80 3F 00 00 00 00
>
> kernel: EtherCAT DEBUG 0-0: Finished SDO request.
>
> kernel: EtherCAT DEBUG 0: ecrt_master_sdo_upload(master = 0x00000000d53d8735, slave_position = 0, index = 0x4002, subindex = 0x00, target = 0x00000000f9b1cb01, target_size = 40, result_size = 0x000000004af47ed5, abort_code = 0x00000000d0acc148)
>
> kernel: EtherCAT DEBUG 0-0: Scheduling SDO upload request.
>
> kernel: EtherCAT DEBUG 0-0: Processing SDO request...
>
> kernel: EtherCAT DEBUG 0-0: Uploading SDO 0x4002:00.
>
> kernel: EtherCAT DEBUG 0-0: Upload request:
>
> kernel: EtherCAT DEBUG: 00 20 40 02 40 00 00 00 00 00
>
> kernel: EtherCAT WARNING 0-0: Other mailbox protocol response for eoe0s0.
>
> kernel: EtherCAT ERROR 0-0: Timeout after 1000 ms while waiting for SDO 0x4002:0 upload response.
>
> kernel: EtherCAT ERROR 0-0: Failed to process SDO request.
>
> The first SDO request is successful, the second one times out. Right
> before the timeout, the message "Other mailbox protocol response for
> eoe0s0" appears. It seems that the SDO response somehow ends up in the EoE
> thread, is dropped there and thus lost.
>
>
>
> Are we interpreting this behavior correctly? Is there anything that can be
> done to prevent this from happening, and could this cause some other issues
> we're seeing (slave refusing to go to OP due to "Invalid input
> configuration")?
>
>
>
> We've seen the function `ecrt_master_callbacks`, but it seems that it's
> only relevant in case the application is run in a kernel module. Our
> application runs in a userspace process.
>
>
>
> Thank you very much and best regards,
>
> Bernhard Vorhofer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250317/dea6c555/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png
Type: image/png
Size: 6455 bytes
Desc: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250317/dea6c555/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg
Type: image/jpeg
Size: 10123 bytes
Desc: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250317/dea6c555/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg
Type: image/jpeg
Size: 10214 bytes
Desc: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250317/dea6c555/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icons-social-media-twitter_small_2_4bae5ad2-4add-4314-a352-5b317f784956.jpg
Type: image/jpeg
Size: 2256 bytes
Desc: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250317/dea6c555/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg
Type: image/jpeg
Size: 10218 bytes
Desc: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250317/dea6c555/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg
Type: image/jpeg
Size: 10303 bytes
Desc: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250317/dea6c555/attachment-0009.jpg>