Dome driver progress.

[KathyNS]

I am mostly caught up on my wife's gardening projects, so I am back to working on my dome driver.

I just got a heavy-duty stepper motor driver, which I hooked up, and ... IT WORKS!! With the Arduino driving it, the motor accelerates over one second to what appears to be the right speed to drive the dome, then decelerates at the end of the movement. Yay! The previous controller I tried should have been able to drive the motor, according to the specs, but didn't. This one has lots of reserve capacity and a big honkin' heat sink.

The next step is physical mounting, which should be straightforward.

One thing that concerns me is that the motor runs quite roughly at low speeds: about the first 1/4 sec and last 1/4 sec of each movement. I am driving it in single steps. I might have to do micro-stepping to smooth it out. Which will mean reprogramming the speed control.

Still, I am happy that it is working.

[KathyNS]

I recalculated the acceleration / deceleration parameters for the stepper motor based on 8x micro-stepping, and modified the Arduino code accordingly. Hopefully that will smooth out the low-speed operation.

[Gordon]

I built a motorized focuser using Arduino, DRV8825 ,easydriver and a Nema17pg27 (gear reduction). It took a bit to get everything working but it does now! Lots of power and nice and smooth.

If you still have rough operation the gear reduction motor might help solve the problem.

[mcolbert]

I built a motorized focuser using Arduino, DRV8825 ,easydriver and a Nema17pg27 (gear reduction).

I think that it's always good that we identify the items that we use so that others can follow in our footsteps, or avoid them like the plague. . I for one have to start seriously going through the Arduino catalogue. Thanks Gordon.

[Gordon]

I built a motorized focuser using Arduino, DRV8825 ,easydriver and a Nema17pg27 (gear reduction).

I think that it's always good that we identify the items that we use so that others can follow in our footsteps, or avoid them like the plague. . I for one have to start seriously going through the Arduino catalogue. Thanks Gordon.

Spend some time here. Robert has plans, drawings, and the 'sketch' to get you up and running.

https://sourceforge.net/projects/arduin ... erpro2diy/

[mcolbert]

I built a motorized focuser using Arduino, DRV8825 ,easydriver and a Nema17pg27 (gear reduction).

I think that it's always good that we identify the items that we use so that others can follow in our footsteps, or avoid them like the plague. . I for one have to start seriously going through the Arduino catalogue. Thanks Gordon.

Spend some time here. Robert has plans, drawings, and the 'sketch' to get you up and running.

https://sourceforge.net/projects/arduin ... erpro2diy/

but no OSX support. Something to follow up on... Thanks!

[KathyNS]

Today, I tested the microstepping revision. The startup and stop are much smoother now. The steady state speed isn't what I wanted, so I may have missed a constant somewhere in the code. Still a bit of tweaking to do, obviously, but it is getting there.

Between the microstepping, the motor planetary gearing, and the reduction from the drive pinion / ring gear on the dome, one revolution of the dome is going to be more than 500,000 motor steps. I can probably afford to miss the odd step at that rate!

[SkyHiker]

I don't know your code but I have noticed that delays in microseconds vs. delay in milliseconds can make a difference. IIRC this is actually documented. I ended up writing code using a combination of them depending on the size of the step. It has been a while but for sure there are issues there. BTW I use the native .ino not C/C++, this may not make a difference in this regard.

Also, don't step "open loop" but define a time line and keep stepping and asking for the time until you hit the next time point. Otherwise numerical errors will accumulate. The clock is quite accurate but don't trust that when not using a clock, the Arduino is real-time enough to make this work accurately.

[KathyNS]

I tracked down the timing/speed issue. To run the motor at 8x microstepping, I need to send a pulse every 125 microseconds. But the program loop takes 280 microseconds to run. So between the 280 us for the code and the 125 us for timing the pulse, it is running at about 30% of the design speed. This perfectly accounts for the speed deficit I was measuring.

So, back to the drawing board. I may have to slow the microstepping down to 4x and restructure the program loop to do less when the motor is running.

[KathyNS]

It may not be an elegant solution, but it works... I reduced the microstepping to 2x. It is still a bit rough at low speeds, but not as bad as at 1x. Since the cycle time is 500 us, which is 250 us on and 250 us off, and the program latency is 280us, I just eliminated the timing for the off phase of the cycle, letting the latency handle that. That is giving me a calculated steady dome rotation rate of 5.1 degrees per second, which is in the range I was looking for.

So the next step is assembling the hardware. I have to MacGyver the dome drive pinion onto the motor shaft, and then mount that to the dome bracket. I'll have to run the USB and power cables to the motor location (they are currently on my work bench). I am starting to see light at the end of the tunnel.

[Gordon]

Congratulations of figuring it out!!!

That's usually the hard part. (at least for me!)

[KathyNS]

It was a rainy day today, so no yard work. Nothing to do, in fact, but work on the dome.

I finished the mounting bracket for the motor and got it installed. I immediately moved the Arduino and its breadboarded wiring over to the motor location and connected it up. Guess what: IT WORKED!!! The motor seems to have lots of torque for turning the dome, especially with the 1-second acceleration I programmed into it. In fact, it is much smoother than the old DC motor, which had 100x more torque than it needed and shook the whole building when it started or stopped.

On the test slews, the dome appeared to go exactly where it was asked to. And on the slew to home, it stopped right where it was supposed to.

I have re-measured the mount-to-dome dimensions, since I extended the pier since the last time I had a functioning dome system. So, next time I point the scope somewhere, the dome should follow.

I still have some work to do. I need to mount the Arduino and the stepper driver in a box, and run power and USB to the box. And I have to connect the various sensors (home, rain, shutter movement completion) and switches for manual operation. Still, this is the biggest tangible progress in a couple of years.

[Gordon]

Great to hear everything is working the way it should!!!

Congratulations.

[SkyHiker]

Great news! I feel partly responsible for putting you on the Arduino + stepper motor track (see some old AF thread) so I am glad it all worked out.

[KathyNS]

I gave the dome its first real-world test today. Up until now, I was testing with an ASCOM scope simulator. Today, I connected it to the real mount and pointed in several areas of the sky. In each case, it drove the slot to be perfectly centered in front of the scope. And, when I returned to the Home position, it didn't have to do any fine-positioning to re-establish the home position: it stopped at exactly the right spot by count alone. So I am not losing any steps.

So, YIPPEE!!!

I still have to connect the shutter relays and position sensor, the rain detector, and wire up a remote for manual operation. However, the basic tracking function is working well!

[Gordon]

Congratulations!!!

[jmfloater]

Another piece of the puzzle in place, congratulations!!

[KathyNS]

Progress continues incrementally. I now have the shutter relays and shutter motion completion sensor wired into the Arduino. The driver is now able to operate the shutters and report on their status.

The next step will be to connect the rain sensor, which I consider an essential part of an automated observatory.

Each of these changes involves cannibalizing hardware out of the previous iteration of automation, which was the DC motor version. Eventually, all that will be left of that unit will be the power relays for controlling AC and DC power and lights throughout the dome.

[KathyNS]

I have been working on the rain detector. I cannibalized the moisture sensor unit out of the previous iteration, and started incorporating it into the new setup.

Ran into a problem. The old system was all relays. The new system has fewer relays, but it still needs some big ones to operate the shutter motors. Relay logic is robust and can easily handle motor currents. Unfortunately, relays produce static that can drive electronic inputs nuts.

I found that I was getting crosstalk on the rain detection wire every time I operated the shutter relays. Since I am more into software than hardware, I opted for a software solution. I told the software to not recognize the rain detection signal until it has been asserted 10 times in a row. That allows it to ignore the crosstalk signal from the relay operation. It only adds a delay of about 3ms to the detection of rain, so it will not be critical.

[Gulf Coast Guy]

I have been working on the rain detector. I cannibalized the moisture sensor unit out of the previous iteration, and started incorporating it into the new setup.

Ran into a problem. The old system was all relays. The new system has fewer relays, but it still needs some big ones to operate the shutter motors. Relay logic is robust and can easily handle motor currents. Unfortunately, relays produce static that can drive electronic inputs nuts.

I found that I was getting crosstalk on the rain detection wire every time I operated the shutter relays. Since I am more into software than hardware, I opted for a software solution. I told the software to not recognize the rain detection signal until it has been asserted 10 times in a row. That allows it to ignore the crosstalk signal from the relay operation. It only adds a delay of about 3ms to the detection of rain, so it will not be critical.

Relay contacts are robust but inductive loads like motors can throw off some serious spikes that have the potential of pulling arcs that can weld contacts closed. It'd probably be a good Idea to double up with some extra contacts in series as a fail safe that something doesn't get stuck in an energized condition.