The Teensy platform is very popular with hackers — and rightly so. Teensys are available in 8-bit and 32-bit versions, the hardware has a bread-board friendly footprint, there are a ton of Teensy libraries available, and they can also run standard Arduino libraries. Want to blink a lot of LED’s? At very fast update rates? How about MIDI? Or USB-HID devices? The Teensy can handle just about anything you throw at it. Driving motors is easy using the standard Arduino libraries such as Stepper, AccelStepper or Arduino Stepper Library.
But if you want to move multiple motors at high micro-stepping speeds, either independently or synchronously and without step loss, these standard libraries become bottlenecks. [Lutz Niggl]’s new TeensyStep fast stepper control library offers a great improvement in performance when driving steppers at high speed. It works with all of the Teensy 3.x boards, and is able to handle accelerated synchronous and independent moves of multiple motors at the high pulse rates required for micro-stepping drivers.
The library can be used to turn motors at up to 300,000 steps/sec which works out to an incredible 5625 rpm at 1/16 th micro-stepping. In the demo video below, you can see him push two motors at 160,000 steps/sec — that’s 3000 rpm — without the two arms colliding. Motors can be moved either independently or synchronously. Synchronous movement uses Bresenham’s line algorithm to plan motor movements based on start and end positions. While doing a synchronous move, it can also run other motors independently. The TeensyStep library uses two class objects. The Stepper class does not require any system resources other than 56 bytes of memory. The StepControl class requires one IntervallTimer and two channels of a FTM (FlexTimer Module) timer. Since all supported Teensys implement four PIT timers and a FTM0 module with eight timer channels, the usage is limited to four StepControl objects existing at the same time. Check out [Lutz]’s project page for some performance figures.
As a comparison, check out Better Stepping with 8-bit Micros — this approach uses DMA channels as high-speed counters, with each count sending a pulse to the motor.
Thanks to [Paul Stoffregen] for tipping us off about this new library.
And I see the teensy 3.5 is out now too. This is impressive!
“Version 3.5 features a 32 bit 120 MHz ARM Cortex-M4 processor with floating point unit. All digital pins are 5 volt tolerant”
Just the thing for complex kinematics. I will be getting a 3.5 and trying this code … thank you [Lutz Niggl]
who else read “fast stepper library for teens”
Now to transfer Marlin to Teensy to give my 3D printer an upgrade :)
300’000 steps/second? Nice. If you want to go fast, there’s this: https://github.com/Traumflug/Teacup_Firmware/issues/189 That’s 1’602’000 steps per second, also on a Cortex-M4. And also synchronized for up to 4 steppers, of course.
Impressive, how do you generate the step pulses at that rate?
It’s a combination of a number of things:
– Well tuned code. Teacup Firmware runs in a clock-accurate simulator and every code change which might affect performance is verified there. Scripts exist to make this a simple command. Even seemingly trivial changes can hurt performance because it removes optimization opportunities. This scripts detects such changes.
– Running the relevant section of code from RAM. Flash is too slow and causes wait-states.
– Remove whatever unused code one can find. Including unused sections of CPU initialization (CMSIS) code. This firmware compiles to just some 10 kB, while a firmware like Marlin doesn’t fit into 64 kB. Still it’s feature-complete (synchonization, linear acceleration, lookahead)
– Did I mention fine-tuning? Code doing a synchronized stepper step and checking movement end consumes just 135 CPU clocks (on Cortex-M4, some 200 on Cortex-M0, some 220 on AVR ATmega, IIRC). Starting from 500+ clocks, they were shaved away in tiny amounts, like unrolling some loops, rolling up others, sorting math operations for best register usage, and so on. 180 MHz / 135 = 1.3 MHz step rate.
– These additional 0.3 MHz step rate are apparently some voodoo CPU feature called ‘ART’.
but other “just because you can” what is the point? steppers can’t keep up with those silly rates anyway and even if they could the drivers can’t
You are right, steppers and drivers can’t follow that speed. But the higher the max speed, the higher the code efficiency. So, at more reasonable pulse rates the processor has more time left to do other things while the motors are moving in the background.
This is especially important for CNC or 3d-printer applications like Traumflugs Teacup firmware where the processor needs to do a lot of things while the motors are moving more or less permanently.
This, and there are also stepper drivers which can follow such rates. IIRC, the hunt for speed was started in order to find a solution for a driver with 1/512 microstepping and the goal to run the connected stepper at 500 RPM, which means 512*200*500/60 = 860 kHz. Such drivers chime in at a bit more than $8, of course.
It looks like the real benefit of this library is accurate acceleration/deceleration to those blinding rates so that steps aren’t lost as the motor starts and stops.
not that i have a use for this library or blinding rates, i wonder what the jiggle would look like. example: 5 degrees one way, 10 the other, 15 back, 20 ahead. ..or randomized angles in opposite ways. at speed. or simulated the ‘bouncing ball’ physics. or maybe in a similar fashion to a VU meter. (no need for any suggestion of ‘why don’t you try it?’ ..i’d rather just wonder.)
Thanks Lutz Niggl. you da man.
Wait, is that a real name? Or some anagram? But anyway, thanks.
Sure, that’s a normal German name. Greetings from another German :)
Not too common though https://de.wikipedia.org/wiki/Niggl
Doh, I thought my steppers were slow because of some mechanical limitation. Faster = better.
This demonstration is a demonstration of how fast you can get the pulses to the stepper motors by elimination the code bottlenecks that previously existed. It’s not a real word demonstration.
If you have a 8-bit micro-controller driving steppers then this will be faster. Even if you have a 32-bit micro-controller driving your steppers this will still be an improvement.
However the real world limitations are friction and the moving mass. In this demonstration the friction is minimal being just bearing friction and a little friction from the air. The moving mass is very light being just a small piece of plastic so you will never get this demonstrated performance in the real world however you will get much more performance than you currently have in some instances.
In the real world the limitations are generally that your maximum acceleration is (the force of the motor minus any friction) divided by twice the mass squared of the moving parts. You also need to consider that momentum (mass times velocity) must be conserved.
Yes. All of this and also induction considerations. Even a stepper without any load can’t reach infinite speeds. A stepper with 12V nominal voltage and supplied with 12V can reach barely 500 RPM without load.
Without getting into the details: the higher the supply voltage and the lower a stepper’s nominal voltage, the higher the reachable speed.
If your steppers actually step (listen to the sound), it’s likely a mechanical limitation.
Slow stepping libraries consume a lot of CPU cycles and if that’s the limitation, a too high step rate results in CPU overload, which in turn results in spontaneous reboots, sudden erratic stepper movements or similar weird stuff.
Steppers are slow because they are designed to be. They are intended for open loop control applications and are therefore designed to have a (relatively) high holding force with a known number of steps/cycle. Driving them faster means the advantages of the motor soon disappear as the holding force per step is reduced and slipping steps are common rather than something exceptional. So the rotation angle of the output axis isn’t (really) known and the motor is much weaker than e.g. a DC motor.
Or at least that’s how I remember it. Corrections are welcome.
If the supply voltage is higher than the stepper’s nominal voltage, there’s a speed range where steppers keep their full torque. That’s why this nominal voltage is usually choosen to be much lower than the supply voltage. For example, 2.5V stepper nominal voltage with a 12V or even 24V supply.
This requires current limiting, which about all stepper drivers feature. I move my steppers (cheap NEMA17) with up to 2500 RPM, with zero step losses.
OK, I admit my stepper programming experience is limited to 6502 assembly language and Uno IDE. I did it with and without micro-stepping and I think the best I ever did was maybe 200 RPM. But with a more recent processor, surely the programming and electronics are not the limiting factor of the speed of the stepper motor. There is a huge range of RPM numbers here in the article and in the comments, does anyone have documentation of motor size vs voltage vs speed, etc? Is it just a matter of creating the right wave form to drive the motor? Aren’t there chips for that?
https://www.allaboutcircuits.com/tools/stepper-motor-calculator/
http://www.osmtec.com/unipolar_vs_bipolar.htm
HTH
Yes, there are chips and boards for that. E.g. in the video I used cheap DRV8825 boards for generating the waveforms for the motors. The library only generates the step and direction signals to accelerate, move and decelerate up to 10 motors in parallel. Even if they move different distances they will reach their targets at the same time. (See the chapter movement modes in the readme of the library for details. https://github.com/luni64/TeensyStep)
Maybe this will be the dawn of real robots that aren’t so sluggish as you often see them be.
They can be fast, you sometimes see fast industrial ones, but often even the industrial robot demonstrations seem very slow making you wonder why.
If the hobby ones are all speedy then the force of embarrassment alone will force manufacturers to try harder, or to buy a teensy :)
https://www.youtube.com/watch?v=j5tf-SkJcqc
I’m pretty sure that most industrial robots that play ping pong to epic cinematic scores use servo control, not steppers.
Actually AFAIK most such videos on youtube are an exercise in After Effects editing rather than involving real human-robot interaction.