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.
No eBay APP ID and/or Cert ID defined in Kunena configurationThe site won't let me post the ebay link - its too long.
All i did was search on "L6470 Stepper Driver Breakout 3A 8-45V" on the Uk ebay site, and loads of them popped up.
Chinese imports for arround £7
Last edit: 5 years 2 months ago by Rob Jones. Reason: add link
Great stuff to listen in on guys! That 350 KG video and the implied near degree per second movement at that weight is awesome to ponder, given the stingy load limits and performance of off the shelf mounts and what they cost to get even decent AP performance.
I have used perhaps a dozen different phidget products in non-astronomical projects so the 1067 "feels" right in addition to liking the usb programmatic control and the safety features. WBIRK I bet there would be general interest for all 1067 users in a well designed heat sink for that board. I am assuming that if the stepper is driving a worm then back EMF and torque holding issues are not the issues they would otherwise be.
I can see some limited advantages in the .9 degree 400 step NEMA 23 motor in an attempt to avoid or limit microstepping, but I would think I would still need a planetary gearing and couldn't go direct at 400 steps even with 360 teeth. Although I can brute force torque, the smoothness I need is only going to come from stepping/planetary ratios (I think). Doesn't the Phidgets 1067 automatically implement stepping through microsteps anyway?
Assuming you wanted to create a mount to drive a 20-30 KG load and didn't mind a slow slew rate, is there any hope for avoiding a planetary ratio in your stepper for RA tracking? Direct drive mounts are such an illusive goal in general, but even direct stepper drive of a 360 tooth 12 inch worm would seem illusive given the desire for arc-seconds smoothness regardless of the motor size or choice. I am going to either do planetary/microstepping or both.
BTW, I have a Phidgets servo motor controller and a nice high torque CR servo with metal gears.. I have a good python program to control rotation and acceleration (use it on a lesser CR servo for focus control)..how would a high end hobby servo do for mount control I wonder.
one more note: being a simple physicist and not an electronics engineer, I usually take for granted what my colleagues from EE explain to me, start to think about some general physics rhubarb why it makes sense and beyond that, I simply believe them. i did the same thing with the statement "a stepper motor at rest is integrating" ... especially as it somehow was my observation that the enabled stepper at rest gets hot whereas the moving stepper does this not to the same degree.