[Neumi] over on Hackaday.IO wanted a simple-to-use way to drive stepper motors, which could be quickly deployed in a wide variety of applications yet to be determined. The solution is named Ethersweep, and is a small PCB stack that sits on the rear of the common NEMA17-format stepper motor. The only physical connectivity, beside the motor, are ethernet and a power supply via the user friendly XT30 connector. The system can be closed loop, with both an end-stop input as well as an on-board AMS AS5600 magnetic rotary encoder (which senses the rotating magnetic field on the rear side of the motor assembly – clever!) giving the necessary feedback. Leveraging the Trinamic TMC2208 stepper motor driver gives Ethersweep silky smooth and quiet motor control, which could be very important for some applications. A rear-facing OLED display shows some useful debug information as well as the all important IP address that was assigned to the unit.
Control is performed with the ubiquitous ATMega328 microcontroller, with the Arduino software stack deployed,
making uploading firmware a breeze. To that end, a USB port is also provided, hooked up to the uC with the cheap CP2102 USB bridge chip as per most Arduino-like designs. The thing that makes this build a little unusual is the ethernet port. The hardware side of things is taken care of with the Wiznet W5500 ethernet chip, which implements the MAC and PHY in a single device, needing only a few passives and a magjack to operate. The chip also handles the whole TCP/IP stack internally, so only needs an external SPI interface to talk to the host device.
Talking about firmware for a moment, to ease deployment, the network configuration is handled by DHCP, although some control over MAC address assignment is promised for the future. All control is via UDP over ethernet, and again the basic functionality is there, but some niceties such as motor synchronisation and state querying are again subject to further releases. Hardware design is implemented in KiCAD and FreeCAD, with Arduino covering the firmware and host control side in python. You can read all about it on the Ethersweep project GitHub, what is there not to like?
If you thought you’d seen this stepper-mounted driver setup before, you’d be correct, here’s a Hackaday Prize 2017 Entry for a CANBUS controlled driver. We also saw this on Dummy: the obscenely well made robot arm by [Zhihui Jun], which if you missed it, then do circle back and take a look, you won’t regret it!
This would be pretty great combined with Linux-based 3D printer firmware like Klipper. I’m picturing a Pi, an Ethernet hub, and a few of these modules replacing the control board, so all you’re left with is a smaller, simpler board handling heating and cooling.
For controlling multiple axis, you may want to look at RBGLhal. The Teensy variant has on-board Ethernet.
Did you mean grblHAL?
Or maybe something very similar but with RS-485/modbus and no hub or switch?
Actually.. you know what I really wish someone made… ArcNet on a chip, priced for hobbyists to use in large numbers. Imagine that with this!
Rubbish in page video from early last year. Here’s one released today that’s comprehensive
https://www.youtube.com/watch?v=GcEzCWUcEBY
Awesome, thanks for the link, but since I wrote this post several days ago, today’s video was not yet available to me to link to.
Now if you can sort me a time machine whilst you’re at it – just one or two days in advance will be acceptable – I promise to make good use of it :D
Apologies. The Doctor says the companion slots have already been filled.
Well there’s another Dr. that has a stainless steel two seater, but you have to listen to him ramble about bumping his head on the toilet and something he calls the flux capacitor.
Obvious next step: Power over ethernet: Single cable. Like Applied Motion and other vendors have been doing for 3+ years now, but at a price point almost certainly considerably higher than this project.
But UDP for motor control? Seriously? Why?
Presumably because of the real time requirements. By the time your packet has timed out, backed off, and been retransmitted you may well want the stepper to be at an entirely different position.
TCP is *very* poor for real time applications. In most streaming/realtime situations you’re better off skipping a bad packet and getting a new one shortly afterwards, versus stopping and retransmitting an old one. The time delay on a TCP retransmission is relatively huge. The protocols can be designed to work around some packet loss / lack of guarantee.
The best solution in this case is ethercat, and it can be used with a regular nic on a computer using an open source ethercat master like SOEM
You definitely need a tight connection for controlling a stepper/servo in real time. This is why most motion controllers are in close proximity to the actual driver (open or closed loop) electronics. A motion controller will buffer the position commands and then send real time commands to the stepper/servo motors. For a single axis device, integrating the motion controller into the servo would be ok. But when you have multiple axes, that doesn’t work.
UDP – seems a bit odd to me. A missed packet would spell disaster. Though if the source was directly connected (ie no routers in the middle) then lost packets are less likely.
Depends on the control loop. In a typical LinuxCNC setup you would have the position control loop on PC, and send velocity commands every 1 ms and receive position status. If one packet were dropped, it would be just a tiny inaccuracy in the path.
Nothing really stops integrating the control loop to the servo, as long as there is time synchronization between them. And also needs some shared control path to stop all axes if one of them stalls.
Why UDP? Because it needs to be real-time.
Why UDP works is that you can control the whole network and fix the issue of packet loss when they occur.
I’ve been musing about that TMS220x + AMS5600 pair to make nice hybrid steppers on the cheap since I found out about the latter, cool to see it works without having to do the work myself.
I’m curious if the existing design could be hacked to talk EtherCAT ( https://en.wikipedia.org/wiki/EtherCAT ), there are a lot of cool industrial/research things using EtherCAT for realtime distributed control, but the parts are prohibitively expensive to play with.
Maybe talk ethercat protocol yes. But not to replace a beckhoff ethercat phy and its looow latency features which that asic supports. As far as i remember they do some bitswap magic on the second layer to achieve high time syn capability.
There are some relatively cheap ethercat controller chips available from microchip and the likes that could be used to implement this as an ethercat slave device pretty easily. The burden of creating a slave device is much else than implementing a master, and something such as SOEM can be used on a PC to turn a regular NIC into an ethercat master.
The LAN9252 is nicely supported by SOES, but is unobtanium from normal sources. One scalper has them for $22 each plus $80 shipping (Europe to US). An Italian company, bausano.net, has breakouts with LAN9252’s on them for $50. I’ve got a couple I will start playing with next week. I’ll have to say, though, that I hate having even a $20 tax per axis on the slave side with ethercat. Wiznet at $2 is a lot more appealing. Ethercat gives you daisy-chain network topology, but if you have no-collision switched point-to-point topology, I think you can get the same reliability and low latency without the special ethercat packet manipulation.
To add to the discussion:
It is intentional to use as many standard protocols and components as possible. I think there is a value in having it as simple as possible, even though you loose some industrial or high tech features. There is no Ethernet connected stepper motor on the market, that can be used with standard cables, switches, connectors, and normal (widely used/known) communication protocols.
I though it might be good to make motion control accessible to programmers/developers/tinkerers who don’t have years of industry knowledge in industrial controllers.
This is really cool. But as a control engineer who works with Ethernet motion systems on a regular basis, this is will only work for a single axis in it’s current state. Multi axis coordination requires clocks synced down to the sub microsecond level. Until this supports that level of clock synchronisation, it will only be useful in single axis applications. I hope they can figure out how to implement support for multiple axis.
Maybe EtherCAT
Could implement a rudimentary ring bus, and do some PLL clock synchronisation. Would require dual NICs per device though
What kind of systems are you working with if you need sub microsecond sync? In a typical cartesian CNC machine with 10 000 mm/min travel, a 50 µs sync error would give less than 0.01mm position error.
Even that can be difficult to achieve through multiple Ethernet switches, but a broadcast packet on a single switch would probably work ok.
Maybe PTP 1588 to sync previously buffered instruction? Sure, hardware cost will skyrocket…
https://github.com/gredblue/Profinet-for-Arduino
This uses S7 protocol and not ProfiNET
XT30 needs extra strain relief on the cables if the motor is going to be part of moving axis. Probably power over Ethernet and a single cable is a better way to go, since the stepper does not need much.
Not sure the TMC2208 is suitable for a “servo” type control, it does not allow you to dynamically control the current on the motor windings or implement FOC.
POE is still on the list of features for a future version. Using many motors on one switch might bring it to its power limits though. The TMC2208 was used due to availability reasons unfortunately and will later be replaced by an TMC2209 most likely. Servo control is done with the AM5600 encoder and a feedback loop on the MCU.
I could see those motors being paired up with a system similar to this to make a highly modular and reconfigurable setup
https://www.youtube.com/watch?v=MvEpi4FDhuI
Minor correction: “…Wiznet WS500 ethernet chip…” > “…Wiznet W5500 ethernet chip…” Yeah, S > 5. Like I said, minor.
Corrected, thanks.
Im here for the timing wars!
I start: I got around 2-10ms parallelism tolerance (measured) with two motors on a shared (non-isolated) local network with two motors using UDP broadcast.
Jokes aside … Ethersweep was not meant to be used in CNC machines or other time critical devices. It is more of an approach to make motion control more accessible. Like this one: https://hackaday.com/2021/11/22/visualizing-wifi-with-a-converted-3d-printer/