-
-
Notifications
You must be signed in to change notification settings - Fork 55
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
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: