celkins

Taken early this morning - 5x15s frames, live stacked in SharpCap4, C11+Hyperstar & ZWO183MM 

1 hour ago, rpineau said:

Looks like the sourceforge page is no longer there : 

https://sourceforge.net/projects/arduinoascomfocuser/

This returns a 404 !!

 

 

Ok for me...

2 hours ago, Shelster1973 said:

Am alos going to use this with SGP, but need to get it fixed up to my new focuser once that is fitted.  Should be good as the fine knob has similar notches so the belt will fit over.

Did notice a weird one the last time I used it.  Using the AF control software I was not ablke to go into negative numbers on the steps.  If I set initial position to 0 then is fine going upwards but any commands to go lower than 0 and there is no movement.  Is no biggie as just set initial position to 2500 or something and then have full movement control

An absolute position focused can never go negative - what does it mean to be further in than "all the way in" (i.e. at zero) ?

You really should start fully wound in, and then track out to focus under software control, so that it knows your real position, not just some arbitrary starting point, as would be the case with a "relative position only" focuser...

Clear skies,

 Carl

I don't have the same setup, but I opted to use a NEMA 17 12v/200 step stepper from the off - over engineering, maybe, but it's been a fun project, and gives very precise control via the fine focus knob, which is good for my Hyperstar setup due to the very narrow CFZ.

This certainly doesn't lack torque.

I am new to Arduino based focuser design, and this is a great resource to get me started.

I have ordered Arduino Uno and motor shield board, and am still waiting for order to be delivered.

I am interested in to modify the sketch for Uno. This is a sample sketch I got from internet:

// Include the Stepper Library

#include <Stepper.h>

// Map our pins to constants to make things easier to keep track of

const int pwmA = 3;

const int pwmB = 11;

const int brakeA = 9;

const int brakeB = 8;

const int dirA = 12;

const int dirB = 13;

// The amount of steps for a full revolution of your motor.

// 360 / stepAngle

const int STEPS = 48;

// Initialize the Stepper class

Stepper myStepper(STEPS, dirA, dirB);

void setup() {

// Set the RPM of the motor

myStepper.setSpeed(30);

// Turn on pulse width modulation

pinMode(pwmA, OUTPUT);

digitalWrite(pwmA, HIGH);

pinMode(pwmB, OUTPUT);

digitalWrite(pwmB, HIGH);

// Turn off the brakes

pinMode(brakeA, OUTPUT);

digitalWrite(brakeA, LOW);

pinMode(brakeB, OUTPUT);

digitalWrite(brakeB, LOW);

// Log some [removed word]

Serial.begin(9600);

}

void loop() {

// Move the motor X amount of steps

myStepper.step(STEPS);

Serial.println(STEPS);

// Pause

delay(2000);

// Move the motor X amount of steps the other way

myStepper.step(-STEPS);

Serial.println(-STEPS);

// Pause

delay(2000);

}

So looks like in addition to have different initialization code, I just need to use step(1) and step(-1) to replace clockwise() and anticlockwise() routine. I dont need to touch ASCOM driver, is my understanding correct?

In essence, yes, correct - as long as you accept the same commands from the driver, and return the expected return codes, then it won't see any difference: my implementation uses an Adafruit motor shield to provide micro stepping control.

And is it possible to create a universal sketch to support Uno too?

It should *run* okay on an uno (I'm using an uno clone), but a "universal" sketch would be difficult due to the number of possible hardware variations - your motor board is different to mine, are both different to Dave's (IIRC).

You should need minimal changes as you outlined above to implement your own clockwise & anti-clockwise routines, using step(1) and step(-1).

Ask here if you have any problems...

I think you're right. The driver is remembering the last position in it's own variables when the focuser is disconnected and as long as the focuser stays powered up you can reconnect and it will force the focuser to use that initial position and then carry on from the same position.

If either the focuser is powered down OR the driver restarted the last known position is lost. That's why I made it always start from a fixed position of 1000 or whatever you put in the chooser's setup dialog. It's a bit of a kludge as I wasn't really aware of how it was supposed to work. Just getting it working at all was good enough at that stage. Also the focuser is not aware of it's real physical position as it has no encoders or suchlike. The only way as you say is to wind it to one end and reset the count to zero. With a continuous stepper motor & belt system you can always override that anyway so it's hardly worth doing.

Now I am realising that people want to use it in a certain way or certain client programs expect certain behaviour I hadn't anticipated.

The answer is to get rid of the default 1000 starting position and make the focuser remember it's last position even when powered off. The driver will just 'trust' the focuser to keep the correct position and ask it what that is when it connects. I think that is the way it needs to work. It is the focuser's role to keep tabs of the position. The driver asks the focuser what the current position is when requested by the client. The driver should not be storing the position at all - I think my driver variable savedPosition needs removing as it is part of the same kludge.

As ever I need to find the time to do all this.

I think the most significant thing, here, is whether the focuser declares itself to ASCOM as "absolute " - implying that it keeps a notion of an absolute position, or whether it's "relative" - in which case all motion is relative to where you are at the start, wherever that may be...

My variant on this uses non-volatile memory to store the stepper position regularly, and declares that it's absolute; it sounds like you support relative motion, at the moment, Dave, which is perfectly valid, and in some ways a more logical thing to do, since then any changes outside of the driver (manual movement, for example) don't matter.

This is an excellent thread, a super example of collaboration, and thanks to all.

I don't really want to connect an LCD to the focuser. The nano's serial connection is fully occupied by the Ascom driver so another program would not be able to access it without disconnecting the client program first then reconnecting again to use the focuser.

I'm also using i2c for a couple of temp sensors, to control a 40mm fan on the stepper heat sink - without cooling, it gets rather hot when position holding, but it's prone to jump if I de-energise the coils.

I just read the sensor directly, calculate the dew point, and report it on an LCD that I've attached; that will be located in my warn room.

I'm not sure how useful it would be for a focuser, but if you're going to have an arduino on the mount anyway, then it would be handy to have a humidity sensor on it to monitor viewing conditions.

Yet to test how effective automatic temp compensation is, but theory suggests that for my setup (C11/HyperStar), with its tight focus requirement, it's probably worth while. I also chose to use a sensor which reads humidity, so that I can keep an eye on how close I am to the dew point...

Good thread, everyone, and thanks, Dave, for inspiring me to build an auto focuser.

Steve,

it's your quality of service that keeps me coming back, time after time - if there's a choice, you guys get the order...

Your service has always been exemplary, and even when there have been difficulties, you've resolved them to my satisfaction, rather than simply declaring the issue resolved when you feel like it, as others sometimes do.

Thank you to all at FLO