mild disclaimer: I don’t really know that much about EtherCAT compared to people I’ve met, I’m just trying to explain as best as I can and play devil’s advocate for it in FRC.
I love communication protocols. In fact, it’s my favorite chapter in Art of Electronics by Horowitz and Hill.
After interning at a local company that works in surgical robotics for the past two summers, I’ve begun to discover the true power of different protocols. Specifically, I’ve discovered the beauty of EtherCAT.
EtherCAT has some stupid crazy advantages:
100 Mb/s vs the 1Mb/s that CAN bus has. (Vision through EtherCAT anyone?)
Based of the Ethernet Physical Standard, so you can literally just use CAT5/6/7 patch cables (or make your own!)
CANopen over EtherCAT means that you can literally run CAN packets through EtherCAT.
In my testing, STUPID fast. (I measured 73ms per loop cycle with CANopen vs 5ms with EtherCAT)
normal NICs can be used. So, in theory, you could just use the Ethernet jack on the RoboRIO.
Ability to use any topology you want.
My favorite part about EtherCAT by far is how it was initially explained to me. When I first learned about it, I was told that I can think of it as “A big data table that gets filled with data and updated by different devices on the chain.” I instantly though, “It’s just networktables on steroids.” It is, in fact, just networktables on steroids.
Anyways, that’s my rambling. Anyone see that weird movie about the german scientist in a wheelchair that proposes that we live in mines after some government nuclear blunder?
I wish I could share stuff, but everything I used to learn it is internal confidencial stuff for the company I interned at. The Beckhoff website does a good job of explaining it though.
Beckhoff has some free training that you can sign up for. One of the modules is on Ethercat. https://learn.beckhoffus.com/
I am using Beckhoff and Ethercat on the machines we build. It is very good and very fast. I’m not sure if we will see it in FRC any time soon but it is a very nice system.
Industrial busing is going largely to Ethernet based protocols. They have a lot of advantages. But they can be a little more complicated to understand and set up. There are places where you just want simplicity and you don’t have the speed demands.
At work we do all our new automation with Beckhoff technology (TwinCAT 3 with EtherCAT). Indeed, EtherCAT is an amazing I/O bus technology. It’s still ahead of its time and it’s not that young anymore. We run all our default scan times at 0.5 ms, and in any other PLC solution you’d have to buy specialized hardware to run in-to-out control loops that fast. Plus, EtherCAT can go faster.
EtherCAT is published as a standard. However, in order to become a developer, you have to join the EtherCAT technology group which includes money (I think) and signing an NDA.
Even though EtherCAT is based on off-the-shelf Ethernet hardware, and the Beckhoff EtherCAT driver will work with any Intel Ethernet chipset, the reality is that if you want to play with it, you kind of need to buy chips and hardware from Beckhoff. They have an ASIC that implements the device-level EtherCAT stack, and it’s proprietary.
I have seen open source implementations of an EtherCAT controller stack, but it wasn’t in a form I felt comfortable playing with at the time.
So yeah, EtherCAT is awesome, but I really wish it were more open. Particularly we need really inexpensive chips that implement the device side do we can integrate them into our own hardware.
3.4 How about Open Source? EtherCAT technology itself is not Open Source. Backed by the standardization of EtherCAT by IEC, ISO and SEMI, access to EtherCAT technology is available to everyone to non-discriminatory terms. Additionally, Master Licenses are free of royalties. Maintenance and all further development of the technology is available to all users by membership within the ETG, the user group for EtherCAT technology. If you have questions regarding implementing or using EtherCAT in conjunction with shared source or open source systems please contact ETG headquarters or Beckhoff, the EtherCAT technology licensor.
3.5 Are there multiple sources for the EtherCAT Slave Controller? Yes. EtherCAT Slave Controller (ESC) implementations are available from ASIX Electronics, Beckhoff, Hilscher, HMS Industrial Networks, Infineon, Innovasic, Microchip, Profichip, Texas Instruments, Trinamics, Renesas, as well as from Intel and Xilinx. Further implementations will follow.
An EtherCAT Slave Controller overview can be found within the download section here: EtherCAT Slave Controller
Or … the IT department at the company wants to own and control all wires and devices using RJ45 connectors, which makes setting up and managing a controls ethernet network impossible. So the work around is to use inferior and/or proprietary connections/networks. Happened in more than one place I’ve been.
It is amazing how many of the IT professionals really do not understand the Ethernet. I am not really pinging on the IT people. They are concerned with keeping their software integrated and keeping the boss’s, who know nothing about computers, computer working. Industrial equipment are notoriously bad from a security point of view. You really want to keep the industrial networks isolated from the business side. I have VFDs that will get confused with number of ARPs on our business network until I firewalled everything. This was not even malicious. Dilbert really is a accurate reflection of an engineer’s life. But it is the only life for those with the “knack”.
Yeah, I really don’t understand why people don’t just completely airgap their fieldnets more often. It seems ridiculous to make IT deal with things that they don’t understand just because it has a certain plug.
The plug and cabling is the biggest downside for using EtherCAT for FRC. You can’t beat the 2-wire twisted pair size and weight of CAN. 1-2 Ethernet plugs on every motor controller? No thanks.
This sounds like adding some fancy technology for the sake of having some fancy technology as bling.
Since there is never a free lunch, it will cost you somehow. In this case, one is taking on extra cost and extra complexity (leading to decreased reliability and greater difficulty in troubleshooting) for capabilities you won’t be able to use. In my day job, I am expected to design out unnecessary stuff to improve the cost and reliability.
I am not really pinging on the IT people. They are concerned with keeping their software integrated and keeping the boss’s, who know nothing about computers, computer working. Industrial equipment are notoriously bad from a security point of view. You really want to keep the industrial networks isolated from the business side. I have VFDs that will get confused with number of ARPs on our business network until I firewalled everything. This was not even malicious. Dilbert really is a accurate reflection of an engineer’s life. But it is the only life for those with the “knack”.