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.
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 ...
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.
answering to a number of points above:
That 0.9 deg motor looks to me be be a good contender.
There's bags of force with that motor, but my mind has now jumped to heating issues. Under normal conditions, the RA motor will constantly be moving (and Alt-z mounts will have both going 100%), and if you run these motors at full wack, then i expect will get very warm fairly quickly. So do you maths and check the torque requirements for your set-up.
Mitigations to this effect:
1. Most decent controller boards (phigets included) do reduce current to c50% the motors when in idle for a period (second or so), but as explained above, this won't help if the motor is on a long imaging run and side-real tracking!
2. You could run the whole system at lower power - BUT NOTE - by "lower power" means managing current limits to these motors (just lowering power supplies voltages won't have the desired effect!), if you need further explanation on this then I'll provide a reference and more details separately.
3. There are motor controllers that have RS232 interfaces that allow the controller to be programmed dynamically, (rather than the DIP switches). Now - I haven't investigated this so you will need to research - but it occurred to me that programming the current limits and micro-stepping values dynamically via software will open up a very useful way of maximising high speed slews on full step, whilst reprogramming to track objects using micro-stepping. By also cleverly adjusting the current limits (high power for accelerations and lower power for simple constant tracking), you will also dramatically help reduce the temperatures of these motors. (Power = I2R, so half the motor current will reduce the power dissipation in the motor coils by 75%.
Final point: don't under estimate the heating effects and hitting a temperature problem. These motors at full power typically consume 12v * 3amp = 36W or more. 1kg of steel warms up at the rate of 500J/C, so every minute at full power will raise the temperature by about 4Degs! (assuming no heating losses to air). Motors typically have an operating/design limit of around 80Degs before contact between internal parts might begin (the stator teeth start to rub and begin to make iron filings!), and bearing grease starts to leave by the nearest exit! - well ok, i'm being a little dramatic, but take heed, it will be an issue to manage you power settings on (not so) long imaging runs. I guess 30mins will be your limit without power management (unless you are in the artic).
1.) well, heating is an issue, mostly when the drive is NOT running. BUT - it only occurs if the drive is enabled/powered up. this can be controlled both for the DRV 8825/RAPS 128 and the phidget 1067 - and the drives should be disabled when they are not running as long as you don't need their holding force. the bigger issue is the heating of the driver chips. the phidget board solves this in an elegant fashion, the DRV and RAPS need massive cooling bodies. i doubt whether this problem on the chip has a positive effect on the life expectation of those things ... i never had problems with hot motors when driving the telescope, but i had hot drives on the bench when not running them
2.) from my experience, the only current that you can run the system on is the current that allows for smooth operation under the given load. this is easier with the phidget controller as you can control the current via software. for the DRV / RAPS, this requires turning a little pot ...
3.) when using a non - RTOS like Raspian, you NEED motor controllers with interfaces because you need a microcontroller to drive motor as a realtime application. i remember the interfaces with RS232 when i was a young guy, we drove them with a microVAX! fortunately those days are over ... BUT the phidget 1067 is controlled via usb, this is how TSC works. there is an interesting driver that already has a microcontroller on chip and can be directly addressed via spi - STMicro L6470 dSPIN, and there is a breakout board from spark fun. i made a pcb that features an arduino mini pro and 2 DRV-drivers and also has connectors for controlling the arduino via spi ...
4.) well, you may have seen my video on that thread - this is 350 kg moving at a rate of ~ 0.7°/per sec in two axes. the motors are set to 1.5 and 1.7 A, and the are powered by 12 V - let us assume a power consumption of ~20W per drive. No heating problems on the drive. Big heating problems with boards other than the phidgets as the thermo protection switch on the driver chip drops with in seconds if you don't take additional measures (cooling bodies, ventilator...)
Score one for the Phidget!, The ability to control current remotely means you can determine needed holding current, often less than running current - especially vs. slewing, and turn the thing down when parked or possibly even use PEC (periodic error correction) or full position feedback from encoders to autotune for best minimum results for each mode. You would want to run it as a tuning process and then lock it though, I've seen tuning loops do some crazy stuff.