Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EtherCAT option #17

Open
mgaffigan opened this issue Oct 9, 2023 · 0 comments
Open

EtherCAT option #17

mgaffigan opened this issue Oct 9, 2023 · 0 comments

Comments

@mgaffigan
Copy link

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:

  1. 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.
  2. Cabling and switching
    Since slave IC's include a two or three port "switch", no dedicated switch is required (daisy chaining)
  3. 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:

  1. Time synchronization
  2. Interoperability with PLC's, other controllers, and other motors
  3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant