Correct control of stepper motors

[hughgilhespie]

Hi @stash_old,

The Teensy library is pretty much a drop in replacement for AccelStepper. It can do everything that AccelStepper does and - as far as I can tell - quite a lot more. It uses the same basic step pin, direction pin and enable pin method and should be compatible with any driver board.

AccelStepper is basically a polled method - you have to call a move check on every loop iteration. This means that if there is - for instance - a lot of serial traffic happening at the same time then the time between loop iterations may be enough to cause motor stutter. As I understand it, the Teensy stepper library uses timer driven interrupt processing rather than polling so it it is more robust in as much as the stepper move calculations and actions are prioritised with respect to other loop activities.

The other significant advantage for my particular case is that the Teensy stepper library can operate at far higher pulse rates than AcceStepper. With a basic 16 MHz processor - Nano / Uno / Mega - you are limited to about 4 kHz step rate. With a Teensy 3.2 as I use, with a clock of 96 MHz, I can go to about 20 kHz. Using the Teensy library allows pulse rates up to 300 KHz. In my observatory I use geared steppers with large reductions to get high torque drives and Gecko 251X drivers with a fixed 10 microsteps. At present my shutter opening takes 112 seconds and if I would like to reduce that to around 30 seconds which equates to a 40 kHz pulse rate. QED!

HTH.

Regards, Hugh

[Vroobel]

3 hours ago, hughgilhespie said:

Hi,

If you don't mind giving up on the RPi and using a different board there is a very good stepper library for the Teensy range at https://github.com/luni64/TeensyStep

... 

Unfortunately over one year ago I moved from Arduino to Raspberry Pi and I don't want to change the platform. Thanks for your advice. 

[Gina]

I modify the INDI code to my requirements but you do need to know C++ to do that and a good read of all the online information about the INDI protocols.

[stash_old]

3 hours ago, hughgilhespie said:

Hi @stash_old,

The Teensy library is pretty much a drop in replacement for AccelStepper. It can do everything that AccelStepper does and - as far as I can tell - quite a lot more. It uses the same basic step pin, direction pin and enable pin method and should be compatible with any driver board.

AccelStepper is basically a polled method - you have to call a move check on every loop iteration. This means that if there is - for instance - a lot of serial traffic happening at the same time then the time between loop iterations may be enough to cause motor stutter. As I understand it, the Teensy stepper library uses timer driven interrupt processing rather than polling so it it is more robust in as much as the stepper move calculations and actions are prioritised with respect to other loop activities.

The other significant advantage for my particular case is that the Teensy stepper library can operate at far higher pulse rates than AcceStepper. With a basic 16 MHz processor - Nano / Uno / Mega - you are limited to about 4 kHz step rate. With a Teensy 3.2 as I use, with a clock of 96 MHz, I can go to about 20 kHz. Using the Teensy library allows pulse rates up to 300 KHz. In my observatory I use geared steppers with large reductions to get high torque drives and Gecko 251X drivers with a fixed 10 microsteps. At present my shutter opening takes 112 seconds and if I would like to reduce that to around 30 seconds which equates to a 40 kHz pulse rate. QED!

HTH.

Regards, Hugh

Thanks for the info Hugh - by Teensy Library do you mean https://github.com/luni64/TeensyStep  as stated earlier in the thread!

It appears that ,if it was the above  library, was only developed in April 2017, so may not be as mature but will be interested to see how you go on ? Plus the obvious you are stuck with Teensy boards ?

I will do some more reading next we have a cloudy night LOL

[hughgilhespie]

Hi #stash-old,

Yes - that's the library I meant.

I confess to liking Teensy boards. I use the 3.2 boards. They are more expensive than Arduino clones but.......

Feature	Arduino Nano	Teensy 3.2 Teensy 3.1
Price	3.00 ish	11.99
Processor     Core     Rated Speed     Overclockable	ATmega328 16	MK20DX256VLH7 Cortex-M4 72 96
Flash Memory     Bandwidth     Cache	32 ? 0	256 192 256
RAM	2	64
EEPROM	1	2
Direct Memory Access	0	16
Digital I/O     Voltage Output     Voltage Input	22 5V 5V	34 3.3V            5V Tolerant
Analog Input     Converters         Resolution             Usable         Prog Gain Amp     Touch Sensing     Comparators	8 1 10 ? 0 0 ?	21 2 16 13 2 12 3
Analog Output     DAC Resolution	0 -	1 12
Timers     FTM Type         PWM Outputs     PDB Type     CMT (infrared) Type     LPTMR Type     PIT (interval) Type     Systick     RTC (date/time) **	3 Total ? 6 ? ? ? ? ? ?	12 Total 3 12 1 1 1 4 1 1
Communication     USB     Serial         With FIFOs         High Res Baud         Fast Clock     SPI         With FIFOs     I2C     CAN Bus     I2S Audio         FIFO Size	1 2 ? ? ? 1 ? 1 0 0 ?	1 3 2 3 2 1 1 2 1 1 8

[hdutton]

On 27/01/2019 at 12:16, Vroobel said:

I prefer to use 8 micro steps. I don't need 0.45 arcsec/step accuracy. 0.9 is good enough at this moment, but I am still ready to do it, as A4988 can do it. Moreover, DRV8825, which I have as well, can do 32 micro steps. But the bigger number of micro steps the smaller torque and bigger possibility of loosing the steps. 

Not true, a lost step occurs when the rotor is displaced through a full step position.  A small(ish) fraction of a full-step worth of rotor displacement won't be lost over and over and accumulate.

Also more micro-steps generally are better, less vibration, smoother slews.  Resonance, as in "ringing" about step positions, at moderate rpm's robs the motor of torque (even to the point of stalling) and fine micro-stepping helps to combat this (as can changing acceleration rates and drive current.)   Generally more micro-steps is better as long as the driver/controller can handle the step rates.  There is really little to no accuracy gain in micro-step positioning past 16X or 32X though.
 

On 28/01/2019 at 12:35, skybadger said:

Yes, and you know roughly how long it takes to transition from slew to track so build that into your landing point estimate in terms of time and position then make small feedback adjustments when you get that based on a real time. 

 

Arrg, moving one axis at a time?  It's not like the synchronization can't happen on both axes essentially simultaneously.   Your idea is basically what OnStep does though...

OnStep "finishes" the goto then enters a mode where the tracking rates are adjusted +/- proportional to the delta between the actual axis position and the target (which are usually both moving for Axis1 and Axis2 in Alt/Az mode) in order to bring the actual position into very close agreement with the target.  Naturally the target RA(HA)/Dec (and so target Alt/Az for Alt/Az mode) is constantly in motion (sidereal tracking) during the slew and until the synchronization is done.
 

12 hours ago, hughgilhespie said:

Hi,

If you don't mind giving up on the RPi and using a different board there is a very good stepper library for the Teensy range at https://github.com/luni64/TeensyStep

If you use a Teensy 3.6 board you have over 40 GPIO pins available and hardware FP calculations at a 180 MHz clock rate, so way more than fast enough fpr motor control. The only other downside for you might be that the Teensy's use the Arduino IDE so you need to program in C++ - or at least the bastardized Arduino dialect.

I don't have any experience of this stepper library yet but I am planning to change my Obsy motor drives to use it in place of Accelstepper as it will offer some valuable improvements for my particular case. 

HTH

Regards, Hugh

OnStep will run on the Teensy3.2, 3.5, and 3.6 (and some older obsolete models as well.)  Thanks to Paul S's excellent libraries this took very little effort.  The Teensy3.6 is the fastest of all OnStep supported platforms, easily besting even the ESP32 (2 core 240Mhz) an every way that counts (4x higher step rates at 250KHz vs. 62KHz for the ESP32 and it's faster at FP intense ops too.)  The one area it doesn't beat the ESP32 in... price

Counting the SMT pins on the back and analog I/O the 3.5 and 3.6 have over 60 pins available for I/O in one form or another.

 

[stash_old]

2 hours ago, hdutton said:

The one area it doesn't beat the ESP32 in... price

And inbuilt Wifi

[hdutton]

49 minutes ago, stash_old said:

And inbuilt Wifi

Which I failed to get working alongside OnStep, fortunately I was successful with the onboard BT support.

 

[hdutton]

23 hours ago, stash_old said:

Thanks for the info Hugh - by Teensy Library do you mean https://github.com/luni64/TeensyStep  as stated earlier in the thread!

It appears that ,if it was the above  library, was only developed in April 2017, so may not be as mature but will be interested to see how you go on ? Plus the obvious you are stuck with Teensy boards ?

I will do some more reading next we have a cloudy night LOL

In OnStep I use simple hw timers to keep things portable.  I think it was that Library linked above I looked at a while back, used the PWM hardware in the Teensy M4 for higher performance, neat but not something OnStep really needs.

Step rate limits, for two axes:

Mega2560 (8 bit 16MHz) 31KHz step rates (steps are pulsed, all others are square wave.)
STM32 (72MHz) 41KHz.
ESP32 (2 x 240MHz) 62KHz.
Teensy3.2 (96MHz) 83KHz.
Teensy3.6 (180MHz) 250KHz.

The Timer ISR's do step counting, tracking, direction change, backlash comp, u-step mode switching, etc. aside from just sending step pulses.

Obviously, the basic 16 MHz processor - Nano / Uno / Mega - is not limited to about 4 kHz step rates.  The AccelStepper library might be thus limited but not the hw.  With an UNO etc. using just Timer1 for one output you should be fine to at-least 60KHz (pulse) or 30KHz (sqw.)

 

[hdutton]

On 29/01/2019 at 08:25, Vroobel said:

Unfortunately over one year ago I moved from Arduino to Raspberry Pi and I don't want to change the platform. Thanks for your advice. 

Now back on topic (apologies)...

Is the Raspberry Pi able to step fast enough?  [edit: you'd think a RPi running Python would be fast enough to not even need mode switching according to the GPIO Benchmarks]  Wonder how much timing jitter too (poorly timed steps rob the motors of torque)?

If you directly drive the worm of 896/897 tooth wheel gears with a 200 step motor you'll need to step at about 1 kHz to get to 2 deg/s when full-stepping.  If you switch between tracking 16x and full-step before/after the slew there's going to be lots of noise/vibration at the slew start so switching during the slew is preferred.   There are valid micro-step indexer locations for switching from 16x to 1x so that no steps are lost and you'll want to keep track of that.  Switching from 1x to 16x (lower to higher) is ok at any step position.  The stepper driver data-sheets cover this.

 

[hdutton]

On 27/01/2019 at 12:41, symmetal said:

If you want both drivers to step at the same rate then you can connect the MS inputs together on different drivers. The MS lines (along with the step, direction and enable inputs) are all high impedence input connections so there is no problem in connecting them together if you wish. 

Alan

This is doable but annoying on the software side.  You'd have to deliberately sync both axes positions by micro-stepping to (driver indexer) valid full-step positions before the switch to full-step.  If on-the-fly mode switching is desired then this would need to be done in the middle of an acceleration ramp up.