Hi! Love the project. I saw some comments on the YouTube video which included your view on EtherCAT as
EtherCAT is closed source. You have to buy the IC/ASIC from Beckhoff for approx. 20€ p.p. You also have to buy product into the EtherCAT community. (Nothing for an open-source project). Ethercat is on a lower Ethernet OSI layer and can, therefore handle requests much faster before it is even decoded. Also you need specialized switches and routers. All of this makes this hard to use and expensive, if you just want to setup a tiny experimental assembly. Of course, if you need very deterministic/hard timing you could/should use i.e. Beckhoff servos. But they are 500€ pp + switches + very expensive cables ... And if you have limited space (robot, small machine) you don't need the big distribution boards etc. A cheap BotBlox switch is enough ;)
While I can certainly understand that viewpoint, I'm opening this issue in hope I can persuade you. Offering an EtherCAT model solves a couple of issues that are otherwise challenging in machine builds:
Addressing Since slave addresses are based on cabled positions, no DHCP or IP configuration is required. You plug your topology together and can address it based on how it is connected or via MAC.
Cabling and switching Since slave IC's include a two or three port "switch", no dedicated switch is required (daisy chaining)
Reliability in the face of excess traffic Due to EtherCAT's mailboxing design, a slave cannot be overwhelmed in the same way that a Microcontroller reading UDP other packets can be. The ASIC also offloads much of the complexity, allowing a lower cost micro to deliver better functionality.
The LAN9252/LAN9253 is regularly available for less than $10 (+ a second magjack) and replaces the cost of the ethernet MAC. I imagine this would also cut the microcontroller and OLED cost, and reduce firmware complexity.
The ASIC is the only licensed component. There are no special cables. Switches are not required since each slave is daisy-chained. Routers are not relevant, since it is not a routed protocol. There are $0 and open source controllers available for Windows and Linux (1, 2).
There are, of course, other benefits:
Time synchronization
Interoperability with PLC's, other controllers, and other motors
Safety without secondary cabling
I'm not associated with Beckhoff or any similar EtherCAT manufacturer. I've just been burned a couple times by Ethernet embedded devices that have tried to re-implement their own automation protocol, and each time have been burned by addressing or communication reliability. EtherCAT and CANBUS are dominant due to their merits.
Hi! Love the project. I saw some comments on the YouTube video which included your view on EtherCAT as
While I can certainly understand that viewpoint, I'm opening this issue in hope I can persuade you. Offering an EtherCAT model solves a couple of issues that are otherwise challenging in machine builds:
Since slave addresses are based on cabled positions, no DHCP or IP configuration is required. You plug your topology together and can address it based on how it is connected or via MAC.
Since slave IC's include a two or three port "switch", no dedicated switch is required (daisy chaining)
Due to EtherCAT's mailboxing design, a slave cannot be overwhelmed in the same way that a Microcontroller reading UDP other packets can be. The ASIC also offloads much of the complexity, allowing a lower cost micro to deliver better functionality.
The LAN9252/LAN9253 is regularly available for less than $10 (+ a second magjack) and replaces the cost of the ethernet MAC. I imagine this would also cut the microcontroller and OLED cost, and reduce firmware complexity.
The ASIC is the only licensed component. There are no special cables. Switches are not required since each slave is daisy-chained. Routers are not relevant, since it is not a routed protocol. There are $0 and open source controllers available for Windows and Linux (1, 2).
There are, of course, other benefits:
I'm not associated with Beckhoff or any similar EtherCAT manufacturer. I've just been burned a couple times by Ethernet embedded devices that have tried to re-implement their own automation protocol, and each time have been burned by addressing or communication reliability. EtherCAT and CANBUS are dominant due to their merits.