DelayMicroseconds vs AccelStepper SetSpeed, very high gearing/RPM for imaging

Hello everyone,

I'm hoping for some advice/opinions on a project for astronomy imaging. I received some excellent guidance from this forum already regarding hardware questions and I was hoping I could pick your brains a bit more on the software side.

The design I'm working on uses a single stepper motor to move an equatorial table at the same speed as Earth's rotation - once every day. I'll be imaging with a large telescope, so it requires a great deal of precision. To accomplish this I'm using some gearing that is a bit extreme compared to what I have experience with. With a combination of a planetary gearbox and worm gears, I'm looking at several potential options ranging from 42960:1 (approximately 100 steps per second with the motor running at about 30RPM) all the way up to about 356,000:1 (approximately 827 steps per second with the motor running at about 248RPM). These figures are with a 200 step NEMA 17 with either a 26.85:1 or 99.05:1 planetary attached (specs here and here, respectively). Full steps on both - I will employ microstepping only if the processor (Arduino UNO) can handle it. I'm fine with sticking with full steps though as I want precision and microstepping can be less than precise for imaging purposes. The stepper driver will be in standalone mode, so no SPI or UART to contend with.

I'm weighing two options for the software side of things - controlling the speed via DelayMicroseconds (as I've done using the borrowed code posted here) or learning to use the AccelStepper library. Documentation on this site suggests DelayMicroseconds is accurate down to 3 microseconds, which is more than enough accuracy for this project. Documentation for AccelStepper (SetSpeed) however says that anything faster than 1,000 steps is unreliable. Am I better off sticking with the more simple DelayMicroseconds approach for greater accuracy? My largest reduction option is still only 827 steps per second if I do not employ microstepping.

The other question I have is the motor speed. My lowest reduction is a fairly reasonable ~30RPM, but the greatest is ~248RPM. I know with sufficient voltage, current, and cooling, the motor and driver can handle this, but the system won't always be running at the 'earth rotation' (sidereal) rate. The platform will run for approximately 73 minutes at the sidereal rate before hitting a limit switch, at which point I want it to return to the start position in no less than two minutes (increasing the speed of the motor by at least 36.5 times). This would equate to a motor speed of 1095RPM for the lowest reduction (reasonable, I think) and 9052RPM for the highest (way too fast). This makes me think I'm limited by the hardware (stepper RPM) and should select my lowest reduction in order to ensure the 'reset speed' is reasonable. I could even employ microstepping then, assuming I respect the limits of either the DelayMicroseconds or AccelStepper library, depending upon which I go with.

I'd love to keep this as simple as I can, so I am leaning towards the lowest reduction (42960:1) and using the DelayMicroseconds approach. Do you all think I can get away with this, given that it does not account for acceleration? Or ought I to use the AccelStepper library to enable acceleration? The limit switches will necessitate a hard stop, so deceleration won't factor in. Accuracy is not important at all with the faster 'reset speed', so missed steps won't matter there. Motion is all in one direction, so backlash isn't a big issue either. I'll have manual 'fast foward' and 'rewind' buttons that work in the fast reset mode for testing, so I can always blip the 'fast forward' button to take up slack/backlash before I start imaging.

I really apologize for the long post. I am trying to be thorough in my description but tend to go overboard at times!

A good rule of thumb is "if it works don't fix it"

In other words if you can get the performance you require with the delayMicroseconds() function that you are familiar with I would stick with that.

The AccelStepper library is really intended for situations where the motor must make a specific number of steps and accelerate up and down at the start and end of the move. I suspect your project is more concerned with continuous movement. And if you don't need acceleration then I see no advantage in using the AccelStepper library.

Even if you do need acceleration it is not very difficult to implement it without the library. See this Simple acceleration code.

...R
Stepper Motor Basics
Simple Stepper Code

Stepper motors don't like starting or stopping at much more than 1 or 2 hundred steps per second - at best they'll lose steps, but will probably just stall and make a horrible whining noise. For the speeds you're talking about I reckon you'll have to accelerate.

Thank you both - I really appreciate your input! I had wondered if I'm asking too much of the motor without looking at acceleration. I will look at the link you provided and educate myself on the use of the AccelStepper library. Even if DelayMicroseconds does work without stalling, it wouldn't hurt to learn it.

I'll try to use the code I posted as a template and see where I go from there. I need to learn how to implement the limit switches with the code but I'm sure I'll be able to track down some examples of those. Thank you!