Blog: Software based microstepping driver
pedward
Posts: 1,642
So I got together some hardware to play with my software microstepping driver. I pulled a bonehead on my first stepper driver I built on a perf board, so I'm using an L293 and small stepper for testing. I setup a current sensor on the high side of the L293 to validate my current control method -- it works!
The stepper driver works by updating the counters at clkfreq / 256, so it has 8 bit signed resolution on the sine/cosine data. This was chosen because of the 512 immediate limit. Current control is achieved by changing the PWM range of the COG, so instead of clkfreq / 256, it's clkfreq / 320. This adjusts the duty cycle of the driver input, very similar to how the L297 works.
Say the prop is running at 80Mhz, the COG runs the PWM control at 312_500Hz. If you are stepping at 14k steps per second, you have 312_500 / 14_000 = ~22.32 cycles to repeat the PWM output value. If you increase the time value, you decrease the cycle rate, but you also change the off time of the PWM.
For ease, let's say you increase the time to 512, but the input max to the driver is still 8 bit, or 256. Your max duty cycle is 50% at that point, reducing the current input to the stepper.
I was able to watch the voltmeter and increase/decrease the current in relation to the steps/second. What I found for my motor was a max draw of 225ma at 9v, it seemed to be happiest at around 100ma, but once I started upping the steps per second, I had to increase the current to compensate.
Now, consider this: with the software driver, you can tune the motor dynamically to compensate for resonance. When a motor has come "unlocked" and stalled, the current draw goes way up. If you try to start a motor at too high of a step rate, the current draw spikes, which tells you the motor isn't spinning. As you adjust the step rate up and down, the current draw changes as well. At lower step rates the motor draws more current for the same PWM value, at higher step rates the current draw drops, requiring dynamic compensation to keep it spinning.
I know that the common step/direction drivers do current control, but I would doubt they do dynamic current control based on step rate, or for that matter give you the ability to "current boost" at higher step rates.
My motor would run at 100ma up to 12k steps, but once I got to 17k steps I had to ramp the current to 160ma to get it to stay locked and in sync.
Based on this testing, I think the motion controller will need to characterize the stepper and probably keep a small table (4 entries would probably be fine) of step rate/current setpoint. This requirement isn't unusual in motion control systems, otherwise you leave performance on the table.
I have previously used the Xylotex 3 axis stepper driver and their 269in/lb motors on a mini-lathe CNC conversion. What I found was a resonance at ~8k steps/s while 1/8th stepping. This limited the maximum speed of the lathe, I'm convinced that with the software driver and a simple H-bridge driver, I could probably double that rate.
Right now my test program is limited by SPIN, the number of clock cycles per loop has reached the steps/s limit, which breaks waitcnt.
I have validated up to 17k steps/s at 1/16th microstepping, I'll have to get the PASM code worked out to go further.
My list of things to do:
The stepper driver works by updating the counters at clkfreq / 256, so it has 8 bit signed resolution on the sine/cosine data. This was chosen because of the 512 immediate limit. Current control is achieved by changing the PWM range of the COG, so instead of clkfreq / 256, it's clkfreq / 320. This adjusts the duty cycle of the driver input, very similar to how the L297 works.
Say the prop is running at 80Mhz, the COG runs the PWM control at 312_500Hz. If you are stepping at 14k steps per second, you have 312_500 / 14_000 = ~22.32 cycles to repeat the PWM output value. If you increase the time value, you decrease the cycle rate, but you also change the off time of the PWM.
For ease, let's say you increase the time to 512, but the input max to the driver is still 8 bit, or 256. Your max duty cycle is 50% at that point, reducing the current input to the stepper.
I was able to watch the voltmeter and increase/decrease the current in relation to the steps/second. What I found for my motor was a max draw of 225ma at 9v, it seemed to be happiest at around 100ma, but once I started upping the steps per second, I had to increase the current to compensate.
Now, consider this: with the software driver, you can tune the motor dynamically to compensate for resonance. When a motor has come "unlocked" and stalled, the current draw goes way up. If you try to start a motor at too high of a step rate, the current draw spikes, which tells you the motor isn't spinning. As you adjust the step rate up and down, the current draw changes as well. At lower step rates the motor draws more current for the same PWM value, at higher step rates the current draw drops, requiring dynamic compensation to keep it spinning.
I know that the common step/direction drivers do current control, but I would doubt they do dynamic current control based on step rate, or for that matter give you the ability to "current boost" at higher step rates.
My motor would run at 100ma up to 12k steps, but once I got to 17k steps I had to ramp the current to 160ma to get it to stay locked and in sync.
Based on this testing, I think the motion controller will need to characterize the stepper and probably keep a small table (4 entries would probably be fine) of step rate/current setpoint. This requirement isn't unusual in motion control systems, otherwise you leave performance on the table.
I have previously used the Xylotex 3 axis stepper driver and their 269in/lb motors on a mini-lathe CNC conversion. What I found was a resonance at ~8k steps/s while 1/8th stepping. This limited the maximum speed of the lathe, I'm convinced that with the software driver and a simple H-bridge driver, I could probably double that rate.
Right now my test program is limited by SPIN, the number of clock cycles per loop has reached the steps/s limit, which breaks waitcnt.
I have validated up to 17k steps/s at 1/16th microstepping, I'll have to get the PASM code worked out to go further.
My list of things to do:
- convert sine/cosine table into lookup table for PASM
- alter PASM code to have interface to pass commands
- change to step base input instead of sine/cosine
- fetch step value from main memory
- fetch current setpoint from main memory
- enable/disable (tristate) output control
- write sample motion controller with dynamic current control???
Comments
If you are limited by spin, and want an easier way to get to assembler, may I suggest trying forth?
You can do your testing interactively, and when the code is working, you can convert just the ones that need it into assembler.
The long-announced final release is about out, and will support easier assembler, automagic paged assembler routines (so they swap in and out of memory as needed), and the ability to run from scripts in EEPROM or on SD, allowing Very Large programs without the need for additional memory.
Also, you can add more prop chip and thus more cogs pretty much transparently, so we need not run out of resources.