Lynxsky: I like the equipment in the link, and would love a setup like that. Further thoughts for your consideration:

If space/portability isn't an issue, i would tend to go with the bigger motor; not only does it take away the 'will-it/won't-it worry, but if you can wear the increase costs of power supplies etc, then the motors are better driven well within their working envelope, than on the ragged edges and run the risk of a missed step.
Also, further to a point made earlier in the thread, these motors will get warm if in use at full power to periods of time. An over sized motor would allow you to run them at lower power, but it still has a greater thermal mass to help reduce the effect of any temperature issues.

I would tend to stay-off motor gearing if possible, since using them will increase the backlash of the system. Motors direct onto the worm drives are probably best.

Also, although the majority of stepper motors are 1.8degs step, that are others. On ebay you can source 0.9degs for similar prices. This will double your resolution without degrading backlash.

Final thoughts on motor drivers: Using micro stepping will improve your resolution, but it is associated with a few issues:
1. The stepper motors are designed to step forward one complete step (say 1.8 degs). Using microstepping progressively energises the coils in graduated sequence to 'fight one another' to hold the angle of movement between the designed steps that motor has. As soon as you de-energise the motor, the motor will snap back to a 1.8deg integral angle.
2. you loose torque using micro stepping - so re-enforces the case for over-sizing.
3. Obvious really, but gives a much smoother angular rotation with less stepper vibrations, which (unless using a geared system) might be material issue in the system you design.
4. Higher the micro-steps means your microprocessor needs to work harder. I played around with Raspberry Pi systems, with driver code written in Python (being interpreted) will struggle to operate high slewing rates - i've tried 128 microsteps, and rotational limits were imposed by software (900MHz processors!). Ardinuo systems (8MHz) quite evidently would struggle. So: use multi-core-RPi-3 (not Zeros) and consider compiling your code!

hi!
rob, which os on the pi did you use? with raspian, all the joy of having such fast clock cycle is limited to the time slice allocated to the process running the stepper

as far as microcontrollers are concerned, you are righ, the 16 -25 MHz of most arduinos are an issue. Teensies are faster, i think.
yours
wolfi

Thanks for that Wolfi, ii'll check it out. Brass with conical bearings! Nice!

Rob, I looked at a .9 degree 400 step motor but the torque was quite a bit lower than similar nema17 200 step motors and it was still equivalent to a 2:1 which wasn't enough to get my rig into the sub arc second step range. I also thought about using a 400s with a 3:1 timing belt set I found to get to 6:1 which might be enough to make up for the lower current/torque specs.
I'll add to the microstepping vs snap back note that the RA track doesn't snap to index because it never stops, or shuts off in normal operation, but plan on holding current on the DEC axis as well even though it is usually stopped during tracking. Sleeping a peripheral stepper like a focuser could be problematic as well, though the gearhead on the one i'm working on should mask any snapping that goes on...probably in the massive lash it has.. Whaddya want for 5$ LOL they're originally little valve control units making them ideal for an open loop low torque slow operation like focus.
With full DIY systems, you have the "luxury" of choosing a large worm gear(check those prices !0.0!), but portable units or crossovers like mine that use slow motion axis worms on an existing mount don't have that option so we're stuck with some type of geartrain to make up the difference. The timing belt systems are a good alternative to the planetary, which is reported to have 1 degree backlash(the loose bit during direction changes).
I suggest dropping out of micro-step mode when slewing
in order to keep from overtaxing the processor or heating the drivers with tons of pwm and inductive skew,. I've been studying these DRV8825 modules and they have 3 input lines (8 modes) which can be tied to Arduino or gpio outputs to change microstepping modes.
Many of the stepper drivers have them in some arrangement making it pretty easy to drop into single step mode when you start slewing. Be sure to change the position return data accordingly if you try this. i.e. a slew of 2000 at 32:1 would need to become 2000/32 if you drop to single..or something like that.

This may not be quite on topic, but i'll include it for reporting aobut the prospective use of the new driver boards. I put together a prototype focuser on the on the bench using a 24BYJ-48 stepper and an Arduino nano for a test of the new boards but it will be a bit before I get to any real testing because I'm rewriting the motor section of an existing Indilib compatible focusing program that currently uses the out of date AF_motor library...while tiptoeing around a nested accelstepper library mostly out of curiosity...I'm apparently a glutton for programming punishment. :- D

hi!
- well, the planetary does add backlash, but that can be compensated for; also a drive belt/pulley combination may have some backlash, but this is less predictable, I would assume.
- in guiding mode, the RA drive may stop, but it does not invert direction usually, which minimizes backlash problems. denote also that, unless, the drive is disabled (on the DRV8825, this is the first pin on the left hand side) the motor does not snap back. it heats up. however, a worm wheel is usually self locking (i hope that is the right word, it is a literal translation from german).
- changing microstepping mode for GoTo might be a good idea. the phidget 1067 cannot do that and it is not necessary as its microcontroller is fast enough to provide sufficient rotation speeds. other solution (for instance rDuinoScope) that rely on DRV 8825 realize their ramps however by increasing step size.
- I have a pcb here for driving two steppers with an arduino mini pro and DRV 8825/RAPS 128 breakout boards, if anyone is interested. primary control is via SPI ...
yours
wolfi

Back lash is typically proportional the quality and number of the physical gears use in the gear train, so avoid adding in gears that you might be able to avoid; so spend more on a increased number of teeth on your worm gear wheel, and avoid using the planetary gear on the motor that drives the worm screw.
Design stuff: My celestron scope has spring tensioners that force the gears to one side of the gear groove, and with a well balanced (slightly biased in one direction) helps enormously with the backlash. Also note that software is usually used to correct of the backlash; normally scopes include a routine at the end of a GOTO command that runs the motors in a consistent direction, thus ensuring (no matter which way the gear slewed to the target), then will end up with a +ve (or -ve) RA & DEC direction, which applies force on a consistent side of the gear grove. This all helps for GE mounts - but standard non-GE mounts, then backlash corrections are more problematic due to tracking DEC/RA forcing the use of both sides of the gear grooves.

WBIRK: i have used many Rpis variants, my comments were intended as general remarks.
I have used Zeros, and found that (being only 1 core) they get quickly overloaded if multi-tasking, so a dedicated machine is really needed for realtime tasks (obvious really -LOL).
Rpis-B are fine, as too are 3's although they do have limits that can all be reached. Pushing the 3 to its limits, and found that with routines written in python and not complied are quite slow - especially using any computations inside the code loop.
Running 128 microsteps and ruining max slews was an issue if I was also tracking the stepper counts within the software. The fastest method/approach was to use the PWM output from a pi (with the frequency set from python) to drive the step input on the motor driver, and then read the PWM signal as an input on an interrupt basis, and count the pulses with an interrupt routine. This gave the best performance (and could get very high motor speeds), but i found that the interrupt routine often dropped pulses and therefore count accuracy suffered.

I haven't yet attempted complied C code,but I am guessing that the limits would not pose problems, as the its a lot faster at execution. I also never exploited the use of CORES in python, which I might expect would help to dedicate tasks to processors. I' also new to python, and very rusty with C, so its all been a re-learning curve for me!

Wow, great replies all. I have assumed in general that if I was going to get the torque I needed for a bigger load in the future, some sort of planetary was going to be desirable and that microstepping would be necessary for the smoothness I wanted. What do you think of this motor, and have you seen 400 step motors (.9 degree) with any more torque than this? www.automationtechnologiesinc.com/produc...th-flat-282-oz-in-2/

I appreciate the strategies for minimizing backlash. Without having a monster worm with greater than 360 teeth how far could this stepper take you torque and smoothness wise? Enjoying dark Smoky Mountain skies visual tonight hope to play with the download over the weekend.

The Smokies! Are you in the shadow of the eclipse? I'm planning a trip in that general direction next month. Either to Clingman's done or a "secret" rest stop near Anderson sc. either is about 4 hours one way for me. It's going to be a very long day.
There has been much back and forth about which is better but I think all of them have merit. I've also heard from some folks with larger systems that they have had good results from large servo motors with encoder feedback, but that's a different thread entirely.
That nema 23 400 step motor looks nice. Too big for my small rig but on a larger one like that lx3 it may work out nicely. When you start getting into torque figures things branch out quickly due to all the choices out there. with a well balanced rig, the stepper basically needs to be able to overcome the stiction(static friction) of the bearings and the of the worm gear/hob, or the bearings and the gearhead, or the mount bushings and the belts...etc. In larger units inertia comes more into play as well.
The higher powered 1.7amp nema17 200 step motor is rated at 51 oz-in holding power, the 400step nema17 that I found (sadly) had the lighter 300ma coils and only around 25 oz-in ..[figures and rambling erased]
so in short, yeah...that monster should have plenty of pull for the big guy. Looking at that spreadsheet I posted might give you an idea of what speeds you can get depending on your final ratio. You might want to count the teeth on the existing gear in the lx3 to get some idea what ratio you need to get it to the right speed, and if this photo is any indication, you only need a couple to get things going. That's a line frequency(60hz) synchro timer with a gearhead in that thing. You might be able to read the rotational speed of that motor if you have it out. RPM is usually on the side of the gear section.
Remounting the yoke on an equatorial angle(wedge) will take the rotation out of your photos. I think big yokes are Superior to gem mounts. No meridian flip is a big factor. This is a photo of one on a wedge mount. Your machinist could probably make you something for it, just a thought.
www.cloudynights.com/topic/497182-the-re...ic-–-meade-2080-lx3/ Getting somthing on the DEC axis might be a bit harder.

Hope all my late night rambling helps somehow.

hi rob!
indeed, the pi zero has only one core. as soon as one starts more than one thread. one is in trouble. On TSC, I run each routine that monitors a stepper in a separate thread. Therefore the program consumes 3 cores when in goto mode. I assume that in Python, you have something similar to the Concurrent Thread mechanism of Qt.
But my question was directed to the operating system. On Bare Bones Raspian, you will always lose steps as long as you do not take any special measures. You lose them at any point in time when the driver expects a digital input but the OS scheduler assigns a another process at that point in time ...
yours
wolfi

Ray: i am at a conference in Gatlinburg, TN today but I live in Nashville area which is in the path of totality. I am wiling to make an outing in either direction on the path of totality depending on the latest weather forecast 12 hours before the eclipse just to make sure I don't miss it . There is a true dark sky viewing location I love at the North Carolina/Tennessee border on the cherohala-skyway. that is at 5600 feet and pretty much a maximum duration location. It has the 360 panoramic views and I was hoping it was the sort of location where one might even see the moon's shadow zooming over the landscape..that would be breathtaking.. www.observingsites.com/ds_nc.htm#Robbinsville There is another nearby called Huckleberry Knob and other spots www.southeasterntraveler.com/travel-guid...ee/cherohala-skyway/

Cligman's Dome is another 1000 feet higher with a 100 mile view...I'm sure you have read up on what a big event its going to be there. Or...it could be a thunderstorm in progress right? It's a daunting task to know how to plan for it.

I suppose I should comment on the stepper info to keep this topical. As I commit some finanical resources to the idea of my own stepper mount control, I am leaning toward some sort of RPI 3 implementation with the phidgets 1067 as these are just products in my comfort zone of previous use. the LX3 I am playing around with does have a wedge already..I was just considering it as a vehicle for learning about mount control. not sure what my mature imaging setup might be. Given Rob's comments about microstepping I was just curious how far a 400 step (.9) with the added torque of the 23 might take someone to be able to avoid using a planetary 15:1 and still move around a good sized load. Clearly microstepping is going to be desirable for low arc-second precision as long as one is clear eyed about the tradeoffs of microstepping. All comments welcome-- I'm just a sponge for now

Wbirk: Yep, agree with all you comments. I rather hoped that using standard raspian/python i might avoid loosing steps by monitoring stepper drive pulses with a input interrupt routine which was connected to the drive pulse pin and i assumed the OS would schedule efficiently. It did work ok to a point, but i was surprised at how low my max slew worked out to be!

I amrelatively new to python, (and indeed a very rusty old coder), so managing Cores is a bit beyond me at the moment - Im at the stage of knowing what i don't know!

I fear clogged roads and crowds at the dome, I want to go there but I also don't want to have to watch from the roadside in a survival mode transportation disaster area(take the lightweight camera gear and a bike?). Oddly enough I can actually make Knoxville in about the same time, but then it's another hour to get in shadow from there.
Quick response to the stepper question. The nema23/400/265 is quite a bit stronger than normal and 400steps gets you to 2:1 over a direct single stepping motor so you can half the microstep number in the spreadsheet. If you can figure out the count on that wheel and plug it into the worm slot in the spreadsheet, then you can see the results of different gear arrangements and levels of microstepping. It's big enough that the 400s might just be enough to go direct...did I already write that? I looked for the ratio of the lx3 last night but that photo was all I could come up with fighting sleep. Might be a good thing to add to the list on sheet 2 if we do find out, lx200 as well. Knowing that is a big part of calculating needed gearings.