stepper losing count - Page 1
Forum section: electronics / general

author: fearless
author_rank: Contributor
timestamp: March 23, 2025, 04:52:08 am
content: Short form:I have a NEMA11 stepper driving a linear stage via a lead screw. I need to shuttle it back and forth without losing counts. I'm driving it with a PWM whose frequency ramps up and down at each end of the travel, but even with that, I'm not getting repeatable results. Suggestions?Details:Hardware:Linear stage with NEMA11:https://www.amazon.com/dp/B08D3S5T1Z?th=1Raspberry Pi HR8825-based driver hat:https://www.amazon.com/dp/B0B4T8XDWGRaspberry Pi 3B24VDC 10 A power supplySoftware:I'm using Python's GPIO package to drive a PWM at 50% duty cycle, updating every 12.5 milliseconds. At the start of travel, it ramps from 0Hz to 2000Hz, holds 2000Hz for 2 seconds, then ramps back down to 0Hz.Observations:It usually shuttles back and forth reliably, returning to the same point after each cycle. But once in a while (e.g. on average maybe every three minutes), it jogs a little extra or a little less. (I can hear the change in the whine of the stepper.)Things I've tried:I upped the power supply from 24V 1.5A to 24V 10A. No apparent change.I tweaked the current limit on the HRB8825 driver board. Too low and it stalls sometimes, too high and it moves erratically sometimes.(I have not found a middle range of current limit that works 100% of the time)Some thoughts:A: Ditch the Python and re-write in C (without any dynamic allocation). It's possible that Python's garbage collection to kick in just at the same time Python is about to update the PWM parameters.B: Ditch the Raspberry Pi. It's possible that some system task gets run just at the same time the Python code is updating the PWM.C: Ditch the Python code and the Raspberry Pi and use a bare-metal driver with precise interrupt-driven timing.But on the other hand, the stepper motors on my Ender 3 3D printer are driven by an RPi (are they not it not?) and appear to have no timing problems.What would you suggest for debugging and/or tweaking?

author: Kean
author_rank: Unknown
timestamp: March 23, 2025, 07:02:18 am
content: You don't mention trying to increase/decrease of max velocity or acceleration values to see if they make it better or worse - i.e. seeing how close you are to the limits.I suspect 2kHz (600rpm) should be fine depending on mechanical load. I think the real issue is that you are relying on software timing and not pulse counting.I would suggest trying the pigpio library so you send an exact number of pulses.https://abyz.me.uk/rpi/pigpio/I can dig out some C code that I wrote years ago (or possibly hacked together from someones else’s code) that does pulse generation with basic acceleration ramps. I actually wrote the C code to act as a server that I could send commands to from python. If interested, send me a PM.

author: fearless
author_rank: Contributor
timestamp: March 23, 2025, 03:19:20 pm
content: After a good night's sleep, I now suspect that the likely culprit is the preemptive scheduling in the RPi and/or the periodic garbage collection and other non-deterministic behavior in Python itself.In short, it's not reasonable to use Ubuntu + Python in something that needs relatively hard real-time scheduling. Going forward, I'll dedicate a microcontroller or 3D printer controller board to control the steppers.@Kean: I did test several sketches using pigpio and bit-banging. The results "sounded"worse rather than a smooth whine. This was probably due to erratic timing, but in the end, it may actually be producing more constant results. But given my target use case (a coil winder), I'll probably still go with a dedicated microcontroller driven by the RPi.

author: langwadt
author_rank: Super Contributor
timestamp: March 23, 2025, 03:38:14 pm
content: Quote from: fearless on March 23, 2025, 03:19:20 pmthere's quite a few stepper driver IC with build-in motion controller, so you just tell it speed/acceleration and where to go, via spi/uart

author: phil from seattle
author_rank: Super Contributor
timestamp: April 01, 2025, 03:54:11 am
content: Way late to this but there are lots of motion controller boards out there that have finely tuned acceleration curves with no loss of steps (unless you set the acc or speed too high). Grbl is free and runs on an Arduino. grblHAL (32bit Grbl) is also free and runs on all sorts of arm processors (the RPi Pico and Pico2). You can talk to them via USB so might fit easily with your RasPi.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: April 08, 2025, 06:48:17 am
content: Another vote for GRBL. (or grblHAL). Even when you need only one motor. Microcontrollers are so cheap these days that it's hardly worth fussing about, and using well tested software is quite a big plus.But more general, step loss can have many different causes. From simply overloading (your small Nema11) motor, or just a bit too much friction on some part of the movement, to electrical problems with the driver (bad design, excessive noise, bad cabling, different logic levels, etc) and indeed software problems. I would not even consider using Python for driving a stepper motor, unless nearly everything is handled by hardware, for example, a timer peripheral handles the step generation via ISR's, and Python just modifies the timer value every now and then to change motor speed.

author: phil from seattle
author_rank: Super Contributor
timestamp: April 09, 2025, 05:38:49 am
content: Quote from: Doctorandus_P on April 08, 2025, 06:48:17 amIndeed, a poor mechanical system or electronics can cause lost steps as well. Adherence to good design principles is critical.One of the reasons I like grblHAL on the RP micros is that PIO allows generation of a very low jitter pulse stream.

author: Kean
author_rank: Unknown
timestamp: April 09, 2025, 03:39:26 pm
content: I agree that grbl is an excellent solution, and I have used it on quite a few projects - e.g. specialised CNC machining, manipulation/dispensing, and mechanical testing apparatus.In the case I mentioned above, the python/C/pigpio combination worked pretty well as it was a special test jig for characterising some custom built spherical light sensors. So it involved only small slow (potentially single step) movements for tilt & rotation, without significant mechanical load. It was a one-off one-day build, and if I hit an issue I would certainly have switched to grbl.