Hi Ferdinand, The vanilla Etherlab master does not separate the different mailbox protocols. However, the Gavin Lambert patchset applied to the master does. The patchset can be found at: https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme
If you have Ethernet over EtherCAT (EoE) enabled it requires the ecrt_master_callbacks() method to be used to provide synchronization between the master realtime thread and the EoE thread. Note: This method needs to be called from a kernel space application, with kernel space callback methods. If you have a user space only application things become a lot more complex. If you don't want to use EoE then disabling it is fine and the above patchset should sort out the rest. Regards, Graeme. From: Etherlab-users <etherlab-users-boun...@etherlab.org> On Behalf Of Ferdinand Postema - LR Sent: Tuesday, 24 August 2021 04:12 To: etherlab-users@etherlab.org Subject: [Etherlab-users] EoE messages are disturbing CoE communication Hello, I'm using a Beckhoff EL6695 Ethercat Bridge terminal. This terminal can do many things, but I use it to exchange variables between 2 masters (IgH master and a CX2040). This device is also capable of multiple mailbox protocols (CoE, EoE and AoE). Recently I updated the IgH-master. Before the master was updated, I experienced an intermittent (rarely) startup problem: Sometimes the communication could not be established. Bringing the slaves to INIT and then back to OP resolved the problem. After the upgrade, it was almost not possible to get the communication up and running. After many hours of debugging I discovered that the problem is that the EoE messages are disturbing the CoE communication. I disabled the EoE protocol in the IgH-master with the -disable-eoe option when configuring and building the software. Now I'm able to get the communication running with de newer version of the IgH-master. But the occasional startup problems remain... While using wireshark to debug the problem further I still see EoE messages. These messages originate from the terminal and not from the IgH master. But these messages do disturb the CoE communication. The following short sample of a wireshark trace shows the problem: No. Time Source Destination Proto Length Info 875 0.000003 00:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 1052 'FPWR': Len: 1024, Adp 0x1, Ado 0x1000, Wc 0 Mbx(CoE SDO Req : 'Initiate Upload' (2) Idx=0x1c12 Sub=0) 876 0.000242 02:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 1052 'FPWR': Len: 1024, Adp 0x1, Ado 0x1000, Wc 1 Mbx(CoE SDO Req : 'Initiate Upload' (2) Idx=0x1c12 Sub=0) 877 0.000002 00:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 60 'FPRD': Len: 8, Adp 0x1, Ado 0x808, Wc 0 878 0.000240 02:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 60 'FPRD': Len: 8, Adp 0x1, Ado 0x808, Wc 1 879 0.000002 00:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 1052 'FPRD': Len: 1024, Adp 0x1, Ado 0x1600, Wc 0 880 0.000244 fe80::d9ac:9249:59ff:e2c5 ff02::1:2 EoE-DHCPv6 1052 EoE(Solicit XID: 0xaa5bf0 CID: 0001000120481c730001052d4758 ) 881 0.000005 00:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 1052 'FPWR': Len: 1024, Adp 0x1, Ado 0x1000, Wc 0 Mbx(CoE SDO Req : 'Initiate Upload' (2) Idx=0x1c13 Sub=0) 882 0.000237 02:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 1052 'FPWR': Len: 1024, Adp 0x1, Ado 0x1000, Wc 1 Mbx(CoE SDO Req : 'Initiate Upload' (2) Idx=0x1c13 Sub=0) 883 0.000002 00:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 60 'FPRD': Len: 8, Adp 0x1, Ado 0x808, Wc 0 884 0.000242 02:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 60 'FPRD': Len: 8, Adp 0x1, Ado 0x808, Wc 1 885 0.000002 00:0a:cd:30:30:f3 ff:ff:ff:ff:ff:ff ECAT 1052 'FPRD': Len: 1024, Adp 0x1, Ado 0x1600, Wc 0 886 0.000243 fe80::d9ac:9249:59ff:e2c5 ff02::1:2 EoE-DHCPv6 1052 EoE(Solicit XID: 0xaa5bf0 CID: 0001000120481c730001052d4758 ) In frame 875/876, the IgH master requests an SDO-upload In frame 877/878, the IgH master checks the SM-status to check if a mailbox message is ready to be read. In frame 879/880, the IgH master reads the mailbox message, expecting a response to the SDO-upload request, but receives an EoE message. This EoE message is probably generated by the slave much earlier, but was not read by the master. Due to this EoE message, the master aborts the 'upload RxPDO assignment/mapping' In frame 881-886, the same happens when the IgH master tries to upload the TxPDO assignment/mapping. Apparently, another EoE message was already queued for transmission to the master. I think the IgH master does not properly separate these mailbox protocols. The one should never influence the other. I think to realize this, would require a large change in the IgH master. Maybe a quick fix would be to ignore the other mailbox protocol messages during CoE communication (or when -disable-eoe is specified) and re-read the mailbox until a CoE meassage is read. I hope this contibutes to your great effort to realize a free ethercat master! I really appreciate this ethercat master. Kind regards, Ferdinand Postema
-- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
