SmoothStepper

[bimac]

I recently tried to build a stepper controller based on Austin D (2005) -- the same algorithm (at least partially) used by Mike McCauley's AccelStepper. It offers a very smooth acceleration to top-speed. The main issue with my code: it's blocking code. At some point I would like to start an attempt at creating an efficient non-blocking implementation with interrupts for teensy.

I see two rather obvious options - both would be centered around projects of yours:

1. use TeensyTimerTool and continue with my own code, or
2. create an accelerator for TeensyStep, which is already highly optimized in itself

It would probably be a bit of a headache to support the more advanced features of TeensyStep (i.e., synchronization of several motors), but for a single motor it should be quite straight-forward. The logic mostly boils down to this. I would be interested in your opinion on this. Is this something that could be compatible with TeensyStep?

Cheers,
Florian

[luni64]

I recently tried to build a stepper controller based on Austin D (2005) -- the same algorithm (at least partially) used by Mike McCauley's AccelStepper.

The first part of the algorithm seems to be the standard integer approximation of a normal linear acceleration. I.e. v = a*t which is equivalent to v = sqrt(2as). The usual stepper algorithms try to calculate the next period on each and every step which is quite demanding. When I did TeensyStep I looked at the code of the fantastic GRBL which is able to control 3 steppers at about 30kHz with a lame Uno. The trick is that GRBL doesn't recalculate the period at every step but at fixed time intervals. TeensyStep is doing the same.

The second part seems to try to smoothen the abrupt changes of the acceleration (jerk). There probably are use cases where this is necessary, for me it never was important.

I see two rather obvious options - both would be centered around projects of yours:

• use TeensyTimerTool and continue with my own code, or
• create an accelerator for TeensyStep, which is already highly optimized in itself

Accelerator

Writing an accelerator should be pretty straight forward. As you probably saw, the library calls prepareMovement before it actually starts the movement. Here you can calculate all required values which won't change during a movement. It then calls update speed whenever the library needs a new speed value. This is where your algorithm (curPos->speed) needs to do its work. Since the algorithm in your link is called at every step you probably need to adjust it somehow.

it would probably be a bit of a headache to support the more advanced features of TeensyStep (i.e., synchronization of several motors), but for a single motor it should be quite straight-forward.

No, this is all handled by the library, it doesn't care about the details of the accelerator. Everything should just work. But of course Murphy's law is always valid...

TimerTool

Regarding using the TeensyTimerTool:
This is certainly possible but you then start more or less from scratch. Depending on your requirements this might be quite some work.

Compatibility

I would be interested in your opinion on this. Is this something that could be compatible with TeensyStep?

Sure, adding custom accelerators is the whole point in the accelerator structure of the lib. You don't even need to change the library, you simply can "plug in" your accelerator. Placing a

using SmoothStepControl = TeensyStep::StepControlBase<SmoothStepAccelerator, TimerField>;

at the beginning of your sketch should be all you need to do. See TeensyStep.h for details. If it turns out to work I can also pull the accelerator into the library of course.

Hope that helps

[bimac]

Thanks a lot for taking the time to write this comprehensive reply - it definitely helps! I'll try my luck with a custom accelerator then and will report back if anything useful comes from it!

[luni64]

Great, let me know if you need support