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 [cid:TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png] [cid:TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg] <https://www.facebook.com/TOMRA.Food/> [cid:TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg] <https://www.linkedin.com/company/tomra-food/> [cid:icons-social-media-twitter_small_2_4bae5ad2-4add-4314-a352-5b317f784956.jpg] <https://twitter.com/TOMRAFood> [cid:TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg] <https://www.youtube.com/playlist?list=PLDD3B1A7BAE919EC6> [cid:TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg] <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-boun...@etherlab.org> On Behalf Of Bernhard Vorhofer Sent: Saturday, 15 March 2025 5:00 am To: etherlab-users@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
-- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
