Loads of stuff around, came across this refrence to some interesting work relevant to your endeavour. This a RPi development in python that's worth following. github.com/selste/TwoStepperControl.git
I'm interested in your progress, so keep the posts flowing.
No eBay APP ID and/or Cert ID defined in Kunena configurationNo eBay APP ID and/or Cert ID defined in Kunena configurationTo reliably control Stepper motors, my preference is to use a stepper motor controller board, which reduces the interface problem to two digital pins: Step and direction (CW/CCW). Its opto-isolated inputs and range of powers make them a good choice - but admittedly over kill! and there are smaller versions, but target the ones that are opto-isolated, as they provide protection to the electronics that is necessary(even when powered down, moving the motors will damage your system)!
The small added complication is that RPis work on 3.3v and these microcontrollers may not (TTL=5v, and needs c4.5v to register a logical true). But using a voltage level shifting circuit you can connect them up and they work very reliably.
hi! well, it is actually genuine c++ ... the driver boards used are cool (phidget 1067) but account for 100 bucks each. their power and rather coarse resolution of 16 microsteps render them mainly suitable for large scopes with big worm wheels ...
Do you mean the gpio is unstable/noisy/ill-timed with a desktop gui running? Or do you refer to the need for current handlers/ h-bridge drivers?
On the latter question, I'm planning to use l298 driver boards similar to those I used in the arduino project for the final outputs similar to the one I have handling motor PWM signals from the arduino mega. As set up now, the arduino gets overloaded by the LCD UI setup, especially in the version I made with extra screen writes. I'm planning for verison 2 to only use serial commands( or if possible direct gpio/drivers) in the next version to simplify the loop and reduce latency errors.
The RPI3 I'm using as an Indiserver now doesn't have a gui (Raspian lite/SSH/indi - no GPU/vnc or desktop gui) and is very stable, running for weeks at a time without glitching or hanging. Impressive little computers if they aren't overloaded.
Voltage differences in interfacing aren't a big deal as long as they are current limited and age old standard practice is to avoid fanout issues by operating pull down (logic low) on things anyway. As for the motor regenerative issue, the h-bridge used in most controllers isolates from that pretty well, but the optos are a good idea anyway as they allow you to drive with isolated supplies, which keeps the cpu supply more stable...see L293 or L298N for a good example. It's starting to sound like the Arduino is already ahead of the game at the control end if the RPI gpio can't reliably output pwm to make the sign/cosign needed for microstepping. Hope none of that comes off as snarky, as it's not my intention. I'm on the fence and any discussion is wonderfully helpful.
I could leave most of my hardware as is if I reuse the arduino and if there's no control stability to be gained by making the change to the pi then i'm inclined to take the familiar path and just rewrite for that, using the arduino as an lx200 emulator and leaving the pi in place as the indi/ccd comm hub. The dspin is on my mind at this point in either case, if I can find a dip one or a driver board for cheap it'll be even better, pretty much making the hardware swap to steppers a snap to recode.
What is the current state of your 2 motor stepper control library-- seems an issue with the latest commit?
I am interested in using the phidgets 1067 boards to control two stepping motors for RA and DEC control. I have used phidgets quite a bit for varios projects including the 1061 servo motor controller and prefer to work in python just because I am more familiar. Unfortunately, I only have 180 tooth worm drive in an old Meade LX3 to work with for my experiment. However, I have disassembled and the condition of the drive and worm is excellent and was well machined at the time.
I was thinking of swapping the 1/8 rpm motor with a Stepper and giving it a try to see what kind of results I might get For deep sky tracking, this drive would need to advance 1 tooth every 480 seconds with 2.5 steps per second without microstepping (based on 1.8 degree step angle?) Obviously, I am a complete newb to this but very attracted to the idea of stepper control. The 1067 micro stepping of 16 (while coarse by professional standards) would give me 40 steps per second theoretical? which would seem to limit vibration. Can you recommend a specific NEMA motor and a barebones strategy for a newbie approaching this task (assuming to start...DEC LOCK, one 1067 phidges controller and a raspberry pi 3 or windows machine available?? Thank you for any information.
are you referring to my project - TSC - tscatm.wordpress.com/? well, the current status is that the controller part is quite complete, it works with skysafari, cdc, kstars and stellarium. it does not yet fully work with ASCOM as this is not relaible. in other words -the advanced ascom LX200 driver works sometimes, which is kind of frustrating. there was an issue with a windows virus on the repository, but this was clarified. what is not yet working is the autoguider. there is activity towards using cheaper stepper controllers for smaller scopes, but this is not my main goal right now. hope to bring this to life in the next few weeks/months. but actually, 2 of my sons are leaving our house and we have ongoing movin/piantin/flat reconstruction work going on all the time.
the 1/16 microsteps of the phidgets are a problem for very small gear ratios. however, with my 288 teeth wormwheel and a 1:9 planetary gear, i do not see any issues with that. the phdigets can drive steppers down to 70 microsteps/ sec (=7.9° / sec) without any visible effect...
in case you missed it - here is a little video that demonstrates TSC () alongside with a little GoTo action using skysafari.
and - here is a video that shows 15 minutes of following sirius in the prime focus of my 33cm/f/4 ... ... one sees PEC but that is it ...
if you wnat to give it a try, i will provide you with a sd-card running the system.
As for my system, I've pushed back the upgrades till after the eclipse and have been chasing down other bugs getting ready for the big trip.
Besides Wolfi's extensive work(cool vids) I also found out that the Onstep guys, who started about when I did, have put together some very nice looking code for arduino. It's much easier to read than the "classes" warfare I inherited.
Sorry for the delay in my response. Thank you both for your helpful replies. Wolfi, I would love an SD card image to experiment with-- are you speaking of an SD image suitable for Raspberry Pi 3 Hardware? I need to order the appropriate stepper and the phidgets controller board.. A recommendation for a good stepper motor choice would be helpful as well as any sourcing recommendation for a planetary gear. I would just love to be pointed in the right direction sourcing wise. I am stuck with a 180 tooth gear RA only drive for now but i am looking for additional Worm drives to play with. Blueshawk thanks for the Gear ratio info and I'll peek at your solution as well.
I tested my share link and realized it need explaining. To use the worksheet you need to either download the .ods file and use a spreadsheet or open it in google sheets and then you can change the gear ratios and see calculated output right away. I found it especially useful for balancing planetary gearheads and or belt/pulley ratios against my fixed wormgear(130) at various microstep ratios. Also be aware that torque drops as you increase steps/per step which could lead to stalling when you hang that SBIG camera on the back. lol
Everyone please feel free to check my math on this. Any errors found would be appreciated. Expect some argument though, especially late on a Saturday night so be ready to show your work.
I based the targets on getting a sub 1 arc second per step ratio, which theoretically should not show up on sensors due to atmospheric limits. That said, aiming low is better for AP, and getting a fair median of around .5 seems like a good plan for observational use where goto may need to be faster to avoid sleep.
the spreadsheet looks reasonable. with my setup (288 teeth worm wheel, 1:9 planetary, 1.8° per step, 1/16 microsteps) i have a theroetical resolution of 0.15 " ...
however, there is a version int making that uses lower currents and standard drivers that support 1/32 or 1/128 microsteps. still it is to be said that the phdiget boards are more sophisticated than the DRV 8825 or the RAPS 128, which are tested right now. i have no experience, how these work on the telescope, on my desk, they do ...