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.vorho...@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.lamb...@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-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
