Arduino Ascom focuser Mark2

[Mick J]

For now I'm happy that I got it working at all and it works fine in a manual mode without saving the position. 

I am happy you did as well    

Sorry I am no use with code, its as if the application - Focusmax or APT remembers all the driver settings except the start position AAF2 is using,  at the moment I am seeing it as a feature.

[russellhq]

That makes sense. I have just tested it myself and the position is preserved between disconnect/connect as it should be - the same instance of the driver is still running and the variables preserved. The position will be lost if the client program is restarted or the focuser powered down. This is to be expected as the position isn't persisted into non-volatile storage. The FM auto-connect must assume the focuser looks after it's own stored position and it will always be on the same COM port otherwise it will not be able to successfully connect again without using the chooser. How does FM cope if the focuser moves to a different com port?

I'm not sure about changing comm ports as the focuser always seems to be on comm 6 on my laptop. I have ran into scenarios where FM auto-starts the focuser but gives all sorts of errors in the FM log. And when I try to fix it by connecting through the dialogue, the comm port is blank and comm 6 is in the drop down for selection. This happens rarely and is difficult to reproduce.

The way I thought about the saved position was like this. When installing a new focuser there's no way for the focuser to know what position it's in so it either has to be told from software or installed in a known position i.e. 0 and have the focuser wound all the way in. From then on the focuser can store the position and report back when connected.

But looking at the way the AAF2 driver code is written, the client doesn't request the last saved position from the focuser, it requests it from the driver and assumes that the focuser reported it's last position when disconnected and this position is still saved in the driver. This won't be the case when the client is closed and the drivers variables and released.

I think having the driver report a default position is much the same as entering a default position in the dialogue. I don't think it's absolutely necessary to remember exactly the last position because you would never use that as your focus point. You would always carry out a focus run and have a new focus position.

Also, you might be able to use GetPosition() instead of savedPosition since the arduino is set up to default to position 1000. This might not work as well when disconnecting and reconnecting the focuser within the client. Maybe I'll give it a go and see how it performs.

[tekkydave]

I'm not sure about changing comm ports as the focuser always seems to be on comm 6 on my laptop. I have ran into scenarios where FM auto-starts the focuser but gives all sorts of errors in the FM log. And when I try to fix it by connecting through the dialogue, the comm port is blank and comm 6 is in the drop down for selection. This happens rarely and is difficult to reproduce.

The way I thought about the saved position was like this. When installing a new focuser there's no way for the focuser to know what position it's in so it either has to be told from software or installed in a known position i.e. 0 and have the focuser wound all the way in. From then on the focuser can store the position and report back when connected.

But looking at the way the AAF2 driver code is written, the client doesn't request the last saved position from the focuser, it requests it from the driver and assumes that the focuser reported it's last position when disconnected and this position is still saved in the driver. This won't be the case when the client is closed and the drivers variables and released.

I think having the driver report a default position is much the same as entering a default position in the dialogue. I don't think it's absolutely necessary to remember exactly the last position because you would never use that as your focus point. You would always carry out a focus run and have a new focus position.

Also, you might be able to use GetPosition() instead of savedPosition since the arduino is set up to default to position 1000. This might not work as well when disconnecting and reconnecting the focuser within the client. Maybe I'll give it a go and see how it performs.

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.

[Mick J]

I do get com5 and com6 on the lappy, netbook can be com3 or higher.  Of course while the focuser is plugged in & powered the com is constant, when I disconnect and possibly restart the computer I get a change. I cannot use any client with the wrong com# in the chooser, as you would expect.

I am com5 on the lappy now, chooser offers com3 or com5, device manager says com5.

[Mick J]

If nothing else - remember this thread is doing wonders for my post count   

[celkins]

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.

[russellhq]

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'm not sure it's that important to remember the position. What is important is repeatability of the steps, which is what we have. Given that a focus run takes only 1-2mins, then using the absolute position of the focuser may not be necessary.

The kludge seems to be working well for me and is giving repeatable behaviour. So for now, I'll be using it

[Davey-T]

  at the moment I am seeing it as a feature.

In true M'Soft tradition 

Dave

[tekkydave]

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.

Thanks. My understanding of the difference between absolute and relative is to do with how the driver interprets the value passed to the ascom Move method. If you say Move(1000) to an absolute focuser it will move to position 1000. If you say Move(1000) to a non-absolute focuser it will move up 1000 from it's current position. Maybe I'm wrong but that is why an absolute focuser needs to remember it's current position whereas a non-absolute doesn't - it is always moving relative to its current position. My focuser is working as an absolute focuser under that definition and also declares itself as absolute not relative. If you wound the focuser to one end and set the position to 0 it would maintain the absolute position as long as the driver or focuser is not terminated. The only thing missing is the storage of the position in non-volatile storage.

Edit: Ascom IFocuserV2.Move method http://www.ascom-standards.org/Help/Developer/html/M_ASCOM_DeviceInterface_IFocuserV2_Move.htm

Edited October 5, 2014 by tekkydave

[blackdragon72]

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?

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

[celkins]

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...

[iwannabswiss]

Welcome to the club blackdragon72.  Besides going with the Uno instead of the nano, did you go with the stepper motor I showed you?  You can use the sketch provided here and make it work on the Uno with no issues, but use the same wiring diagram.

[tekkydave]

I don't really want to get into supporting multiple hardware configurations as I won't have much time to spend on this going forward. If there is an easy way of asking the arduino what type it is and what shield is attached it may be simple to add some extra code to redirect the move subroutines. Probably the simplest thing is to modify my sketch according to your hardware configuration. As long as it adheres to the interface between it and the driver as celkins says you will be ok.

[Gina]

The type of Arduino is printed on it

[tekkydave]

The type of Arduino is printed on it

[blackdragon72]

Welcome to the club blackdragon72.  Besides going with the Uno instead of the nano, did you go with the stepper motor I showed you?  You can use the sketch provided here and make it work on the Uno with no issues, but use the same wiring diagram.

Thanks for the links to all the components.

I ordered this:

http://www.omc-stepperonline.com/9deg-thin-stepper-motor-125mm-05a-7ncm10ozin-14hr050504s-p-88.html

There are two main reasons:

- I want to drive coarse knob so I need at least 400 steps motor. And my knob is somehow stiff so I also want to have more torque. If it does not work then I will attach motor to fine knob.

- I need a small factor (esp shallow one) so I can still store the OTA with motor attached.

[blackdragon72]

There ought to be some way (eg, device ID or similar) to tell.

I did not mean to ask for support for every system, but for nano and uno only, since these 2 seem the most popular choices. I am thinking that once we have a working version for Uno, we could use the tool to patch the new changes from Nano sketch to Uno so we can release both together.

[blackdragon72]

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.

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...

Are you facing any issue with auto reset, as mentioned here?

http://arduino.cc/en/Main/arduinoBoardUno

[iwannabswiss]

I hate working, it takes away from the important things in life like finishing a project. Finally got the direct drive mounted and working.  Now I just need to powder coat the holder and make a decision, do I want to contain everything in the holder or just run a wire down the OTA to a electric base station with everything else.  I'm hoping to save as much on weight as possible.

[russellhq]

There ought to be some way (eg, device ID or similar) to tell.

I did not mean to ask for support for every system, but for nano and uno only, since these 2 seem the most popular choices. I am thinking that once we have a working version for Uno, we could use the tool to patch the new changes from Nano sketch to Uno so we can release both together.

Why not just get a nano when they are available for £3 from eBay? :-) you could also get the same stepper for an extra £2.

[wuthton]

Thanks for the links to all the components.

I ordered this:

http://www.omc-stepperonline.com/9deg-thin-stepper-motor-125mm-05a-7ncm10ozin-14hr050504s-p-88.html

There are two main reasons:

- I want to drive coarse knob so I need at least 400 steps motor. And my knob is somehow stiff so I also want to have more torque. If it does not work then I will attach motor to fine knob.

- I need a small factor (esp shallow one) so I can still store the OTA with motor attached.

I have mine attached to the coarse, it drives it fine even at vertical.

I think when you begin to package the focuser you'll appreciate that the Uno is suddenly quite large and a Nano would be a better choice.

[tekkydave]

Are you facing any issue with auto reset, as mentioned here?

http://arduino.cc/en/Main/arduinoBoardUno

Not in normal use as it is on Windows. Ascom is windows-only software. I have noticed it when using the nano on Linux for other projects but you just get a few random characters then it settles down.

[tekkydave]

There ought to be some way (eg, device ID or similar) to tell.

I did not mean to ask for support for every system, but for nano and uno only, since these 2 seem the most popular choices. I am thinking that once we have a working version for Uno, we could use the tool to patch the new changes from Nano sketch to Uno so we can release both together.

I don't think there is. The devices are deliberately made to all look identical to the running code as far as I can tell.

[Gina]

This would seem to be the case as the Arduino IDE can't tell which version it is or it would detect it automatically and we wouldn't have to enter the version by hand.

[sulaco]

I'm hooked on this thread and now want to build it but I've a few questions.

1. The stepper motor used has a 5.6deg step which gives 64 per rev if I'm not wrong. Would it not be better to use a finer motor?

2. If I swapped out for a 12v stepper could I power it with a mains adapter without frying the nano?

Thanks for any feedback

Campbell