uP stepper driver

In the long history of 3d Printers, most of which I don't know, someone must have tried driving steppers directly with a microprocessor and an H-bridge rather than using a stepper driver controller chip. Presumably it wasn't cost effective. But going through a stepper chip, a lot of information about the desired motion of the axes is lost. More importantly with the open-loop nature of how steppers are used a great deal of high-frequency energy gets pumped into the mechanical system (see the first graph at [www.linearmotiontips.com] ) because the motor starts and stops (and the stage tries to start and stop) for each step. The stepper controller is limited in the motion optimizations it can do because it generally only has a STEP and DIR input - it can't know when the next step command is going to happen, nor can it know if the desire is to move three steps or three thousand. The high frequency energy problem is covered up by using e.g. 16x microstepping, and trying to space the steps to provide uniform motion - but most of our microprocessors aren't capable of doing that well, due to both limited timing resolution, high step rates, and piss-poor CPU performance (though the ARM-based controllers help with the latter).

I was looking at the Raspberry Pi Pico a while back - a new board with ridiculous processing capabilities for ridiculously cheap. It has a dual-core, 133 MHz Arm chip with 256KB of RAM and a 2MB external program flash for $4. It's interesting feature is a pair of programmable hardware state machines that can drive the I/O ports as fast as 32 MHz with no processor intervention - imagine it driving 4 H-bridges for 4 stepper motors, and being capable of multiple megasteps per second while the CPU kinda twiddles it's thumbs doing pretty much nothing. One of their examples is driving the timing for a 640x480x60fps VGA stream - that's over 18 megapixels / second.

The PICO is capable of ridiculously high step rates at precisely timed intervals to create extremely uniform motion at the maximum speeds the hardware is capable of. The Pico could monitor the current in the steppers, and operate them in closed-loop mode. No more looking for an error indication from the driver chip (if it provides one) - a Pico could in real time (like, during a step) notice that the motor isn't completing the step and choose to delay the next step until the current one is complete, and then perhaps slow down a bit. It could notice that the current step is nearly complete and start the next without stopping - a feat not currently possible.

All that would be required would be an h-bridge (four FETs) per stepper. If you didn't want to deal with heat, use a modern FET with low Rds specs - here's a nice 6 amp, 30V, 0.034 ohm FET for $0.40 for the full H-Bridge worth. Throw in a nice current sense amplifier for another $0.25, and you've got a high quality stepper motor driver that allows a competent CPU to fully optimize every move for speed, quality, and/or noise.

And this could be CHEAPER than current approaches with significantly better performance.

... way back, with the Gen3-board the stepper drivers were connected per RS485, had a µP aboard and the motors were driven by half-bridges.

If really interested -- I have some of them in my "random"-box and the schematics should be available online too (or in one of my archives) ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]