MAC addresses used in EtherCAT frames

[radar_macgyver]

What is the source and destination MAC address used for frames sent on an EtherCAT link? I could see that the source address is that of the master, but since there can be multiple nodes and the same packet traverses each one, what would the destination address be?

[radiolistener]

It seems that there is no free and open documentation.
But at a glance it uses UDP packets or ethernet packets with etherType=0x88A4 as envelope.
So it seems that it uses usual MAC addresses, the same as usual ethernet. Probably with the same ARP.

[fchk]

If you use direct mode (Master - slave1 - slave2 - slave3 ...), then the mac addresses aren't checked.

If you use open mode (Master - Switch - n slave chains), then the destination MAC is the MAC of the first slave of the chain being addressed.

Reference: ETG1000.3 Section 4.7.2

And no, UDP is not used. These are special Ethercat frames.

[radiolistener]

And no, UDP is not used. These are special Ethercat frames.

[jbb]

It’s been a while, but I seem to recall something about ‘proper’ - I.e. no Ethernet switch - EtherCAT setups being able to all use the same MAC address

[radiolistener]

It’s been a while, but I seem to recall something about ‘proper’ - I.e. no Ethernet switch - EtherCAT setups being able to all use the same MAC address

Does it means that it just ignore eth.src and eth.dst? Such implementations definitely will not work on any medium, as promised...

[ajb]

The UDP- and TCP-encapsulated variants would need to handle MAC addresses normally, after all the whole point of those modes is to allow the protocol to be transported over a standard IP network with standard switches.  In the direct modes, according to this link, messages are sent with the broadcast MAC address as the destination, which is sensible enough I guess, and a specific bit of the source address is set by the receiving devices so that the master device can distinguish the returned message: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1364579/lp-am243-ethercat-mac-address-used-in-communication-messages-between-slave-computers

[radar_macgyver]

Thanks all for the replies. Sorry I did not specify, I was interested in the mode where the master directly creates Ethernet frames with Ethertype = 0x88A4, not the UDP version. After I posted, I found the following reference that may help, or may just add to the confusion:

https://wiki.wireshark.org/Protocols/ethercat

This includes a Wireshark capture dump of ~5 seconds of EtherCAT traffic. It seems like the source address is set to the MAC of the master, and the destination is broadcast, as @ajb pointed out above. If the source address is the only one modified, then inserting a switch into the traffic should not impact the operation, right?

If you use open mode (Master - Switch - n slave chains), then the destination MAC is the MAC of the first slave of the chain being addressed.

Hmm - in this case, how would the master know the MAC addr of the first slave node? In IP networks this is done with the ARP protocol (whose Ethernet frames are broadcast) - what's the equivalent in EtherCAT? Sorry, it seems like the spec document ETG1000.3 is paywalled...

My design uses a set of EtherCAT servo drives attached to an SBC with a direct connection. The drives and SBC, along with a high-speed data acquisition system need to communicate through a shared fiber-optic link that traverses a rotary joint. In 'normal' operation, no EtherCAT frames need to traverse the shared link (I send the SBC a command via a TCP socket on another network interface, it serves as the EtherCAT master and tells the servo drives what to do and sends status back via TCP). I would like to have EtherCAT available through the fiber link for 'commissioning' the servo drives (doing the initial tuning, maintenance etc) so I was wondering if I could use a VLAN on a managed switch on the fiber link to allow both EtherCAT frames and TCP to share the same link. Performance/latency is not so critical here so it seems like this might work since each VLAN has a separate broadcast domain. The limitation is the servo drive commissioning software only uses the 'direct mode', and does not support UDP tunneling.