Stepper library

[ktritz]

Using CircuitPython to control stepper motors is currently pretty ugly. At the moment, I use PWMOut, precalculate the frequency steps needed to provide pseudo acceleration/deceleration, compute the time necessary for the total steps in each PWM window, sit in a timing loop while monitoring a digital input 'limit switch' and end up sorta close to the total number of steps I wanted. I realize that I may get better precision with PulseIO or AudioPWM, but they have their own issues. It would be pretty nifty if there was a C-level bit banging library that implemented a Stepper library with something like the following capability:

Stepper module:

• C-level generation of precise pulse train (total steps, frequency)
• frequencies up to ~2-3 kHz * multistep value (e.g. 32)
• built in smooth frequency acceleration/deceleration of pulse train
• capable of asynchronous pulse generation
• monitor "limit switch" input pins to stop motion
• STEP/target position mode or RUN/continuous motion mode

Pins:

• step_pin (digital): each pulse advances the stepper one step
• dir_pin (digital, optional): pin state controls stepper direction
• enable_pin (digital, optional): pin state enables stepper driver
• forward_limit (digital, optional): activating pin stops forward motion
• reverse_limit (digital, optional): activating pin stops reverse motion

Note: ideally select active HIGH/LOW for each pin

Properties/Functions:

acceleration (property) get/set

• how fast velocity goes from 0 to velocity_limit
• how fast velocity goes from velocity_limit to 0
• MIN < value < MAX
• scaled by scale_factor

mode (property) get/set

• STEP: target position mode
• RUN: async rotatation mode

engaged (property) get/set

• enable stepper driver operation
• holding current when stopped

failsafe (property) get/set

• watchdog timer
• stops operation if reset_failsafe is not called within time

is_moving (function)

• returns whether the stepper is currently moving
• either in RUN mode or async STEP mode

position (property) get

• get the current position (scaled steps)

scale_factor (property) get/set

• scale factor to translate steps into physical position
• also affects velocity and acceleration

multistep (property) get/set

• steps/velocity/acceleration multiplier
• can modify driver multistep setting without changing Stepper motion values

reset_failsafe (function)

• if failsafe is active, reset the timeout

target_position (property) get/set

• gets or sets the (scaled) step location
• blocks until motion is finished
• stops motion if direction limit switch becomes active
• doesn't move if direction limit switch is active

target_position_async (property) set

• sets the (scaled) step location
• immediately returns (non-blocking)
• stops motion if direction limit switch becomes active
• doesn't move if direction limit switch is active

velocity (property) get

• get the current stepper (scaled) velocity

velocity_limit (property) get/set

• get or set the (scaled) maximum velocity
• 0 < value < MAX
• immediately changes the velocity during RUN mode
• stops motion if direction limit switch becomes active
• doesn't move if direction limit switch is active

set_limits (function)

• set digital input pins for motion limits
• limit for forward and/or reverse directions
• set input value which triggers limit (False | True)

set_limits(forward_limit=None,
		forward_active=True,
		reverse_limit=None,
		reverse_active=True)

get_limits (function)

• get status of limit switches
• e.g. returns forward_limit.value == forward_active

[dhalbert]

Thanks for the API writeup. We generally recommend using a PCA9685 or similar to drive steppers, since it takes care of doing this without any timing difficulties. You need motor driver power components anyway, so the PCA9685 is the least of it. What are your reasons for preferring to do it directly?

[ktritz]

As far as I can tell, the PCA9585 CP library doesn't really handle any of the specific things I'm looking for, such as generating a precise # of pulses, smooth frequency acceleration/deceleration, and monitoring of limit IO to stop motion. Is there something I'm missing? If I need to separately modify and time the PWM frequency for acceleration, and separately monitor the limit IO, and then communicate over I2C to the PCA9585, that makes my problem even worse with regard to precision stepping.

Typically, we're using standalone stepper drivers which take digital IO for the step/dir/enable control (but don't have limit IO). We're also using a range of steppers from smaller NEMA17 to massive 220V 7A NEMA52s, so a generic stepper motor hat/shield won't quite cut it.

This might be something the seesaw could do well with the proper code.

[dhalbert]

I understand. Yes, an enhanced seesaw could do something like this. Have you looked at the Tic stepper controllers from Pololu?
https://www.pololu.com/category/212/tic-stepper-motor-controllers
https://www.pololu.com/docs/0J71

Perhaps a CircuitPython library that talks to them would be useful.

[dhalbert]

Another interesting possibility would be to use the RP2040 PIO capability to write the short control programs you would need. You can create and run PIO programs from CircuitPython.

[ktritz]

Yeah, the Pololu controllers would work, though they are considerably more expensive than the seesaw. They could replace our external stepper drivers for some of our steppers, and we could use the step/dir outputs for the NEMA52 drivers. The Status: Rationed and low stock is a bit concerning :) Not sure of their long term reliability.

I have thought about the RP2040 PIO, and it's a possibility I think, though it's a bit tricky to get the right math for smooth acceleration/deceleration. If JMP on PIN works, that at least could monitor limit switch IO. I've done simple PIO stuff, but I'm not sure if there are enough registers to handle all of the functionality. Come to think of it, JMP on PIN could allow two state machines to talk to each other, no? One could be in charge of counting the steps, and one could be in charge of the time period between steps to handle the acceleration and velocity.

[alustig3]

+1 vote for wanting a circuitpython stepper library

I don't know if this is helpful but https://www.airspayce.com/mikem/arduino/AccelStepper/ and https://github.com/luni64/TeensyStep are two libraries that I have used in the past that work well for Arduino.

[dhalbert]

Interesting PIO stepper links:
https://forums.raspberrypi.com/viewtopic.php?t=300874
https://www.youtube.com/watch?v=UJ4JjeCLuaI
https://vanhunteradams.com/Pico/Steppers/Lorenz.html
https://github.com/DasenB/PicoStepper
http://people.ece.cornell.edu/land/courses/ece4760/RP2040/index_rp2040_C.html
https://forum.micropython.org/viewtopic.php?t=10199&p=56656

[ladyada]

a user contribution library would be welcome!

[xgpt]

Just curious, would any of this lead to being able to use the incredibly common "StepStick" drivers that are frequently sold/utilized with 3D Printers?!

[Vexs]

I started on a similar path of discovery last night- pwmio + timing resulted in a significant deviation over time, as expected. PulseIO was... better, but the library's API is kind of awkward for this usage and you still missed/over steps.

Fortunately, I can just use digitalIO to toggle a pin on the rp2040 at 500hz which is sufficiently fast for my applications, but not ideal- particularly as I want to do sensor measurement along the movement of the stepper, and throwing blocking i2c reads into the loop is going to be painful. To that end, an async interface is badly needed- particularly given circuitpython's no-threading. A callback that could be scheduled to happen every say, N rotations would be welcome.

I've started playing with PIO for this personally, in part because it looks like it allows me to escape the single-thread issue.

Also, IRT external stepper controllers like the pololu boards- while these would appear to work, a 50$ premium for a stepper controller when I have a microcontroller that should be quite happily capable of doing the operation itself is more than a little frustrating- and if I wanted to use existing common 3d printer hardware is a bit of a no-op. Observationally, there don't appear to be many stepper-controller-controller boards out there either that break out things like the TMC4361 for an affordable price.

[ktritz]

PIO would probably be the easiest solution, but of course not generalizable to other boards. A C library like pulseio, but specifically written for stepper control would be the most useful and should be able to handle async calls with limit switch I/O as well.

…

On Mon, Jun 13, 2022 at 12:05 PM Vexs ***@***.***> wrote: I started on a similar path of discovery last night- pwmio + timing resulted in a significant deviation over time, as expected. PulseIO was... better, but the library's API is kind of awkward for this usage and you still missed/over steps. Fortunately, I can just use digitalIO to toggle a pin on the rp2040 at 500hz which is sufficiently fast for my applications, but not ideal- particularly as I want to do sensor measurement along the movement of the stepper, and throwing blocking i2c reads into the loop is going to be painful. To that end, an async interface is badly needed- particularly given circuitpython's no-threading. A callback that could be scheduled to happen every say, N rotations would be welcome. I've started playing with PIO for this personally, in part because it looks like it allows me to escape the single-thread issue. — Reply to this email directly, view it on GitHub <#6444 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIR6YKZQ6BQ7AEXJC6JIM3VO5L4NANCNFSM5XHOYXSA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ktritz]

Ok, I have some alpha code that does step accurate stepper control using the RP2040 PIO. Right now the state machine outputs steps to a stepper driver with the option of DIR control using either the state machine or manually with digitalIO. There is an option to enable a counter by tying the output to another pin, which can independently verify step counts. Finally, a jmp_pin can be configured to act as a limit switch which will immediately halt the step output (and require a state machine reset).

The files in the lib directory are what goes on the MCU. You can combine the files in the pc and lib directory on a PC to test and plot the step generation. Right now there are two acceleration curves available, a linear ramp and a cos-based S-curve for lower jerk acceleration. The S-curve has more overhead, so there's a small cache to speed up step generation when parameters aren't changing. Feedback is welcome, and I'm going to keep tweaking it.

https://github.com/ktritz/stepper_pio