tekkydave

I'm not sure the arduino is aware of its locale. It might be possible to change the dot to a comma in the driver as it will be able to access the language/locale settings from the PC. I'll look into it next time I do some work on the driver.

Yeah, I have done that in Win 7 although you have to use ctrl-Enter I think. The problem is the setup program should do it automatically but it doesn't. Ill get to the bottom of it one day

I havent got the auto register quite figured out yet. Its low down on a list that keeps getting longer.

Nice job. I should have used a slightly bigger box, mines a bit of a squeeze.

I would appreciate any comments,reviews,feedback on the SF site BTW

Thanks for your comments, I am truly inspired by the number of people who have used my project. It will probably help if you are near correct focus to start with. I am working on a new version that will remember the position of the focuser even when it is powered down and it will start again from that position unless overridden. I haven't really used mine for any imaging yet as I have been concentrating on building my pier and obsy/shed when I get my little free time.

Is it a powered hub? Do you have anything else connected and is it ok if the focuser is the only device?

Sounds interesting. I have no experience of Macs. What client program do you plan to use and how will it interface to the arduino?

Cheap! How very dare you. Inexpensive please

By 'app' do you mean the sketch, client program or driver? Any focuser client that uses ascom should work with my focuser if you use my driver.. The device-dependant coding is in the driver. If you want to use the driver of another focuser you will need to find out what the comms protocol/commands are and rewrite the arduino sketch to work with it. I designed my own protocol in this case because I wanted to learn about both parts. I believe someone on SGL has made an arduino-based focuser that uses the Moonlight protocol & driver but I can't remember who it was.

No reason why you couldn't use that board but you would need to modify the clockwise() and anticlockwise() functions in my sketch as it uses direction/step signals instead of 4 separate data lines.

Yes it works fine. As the arduino site says if you are using the serial port in your program you need to make sure you put a short delay in your program before doing any comms. You will only ever use the focuser on Windows so its not an issue for that.

1. You can use any stepper that suits your project. I chose the one I did because it was cheap 2. You can feed 7 to 12v into the Vin pin (pin30)

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.

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.

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.

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

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.

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? Edit: Just tested with FM and when I move the focuser to a different com port (COM5 instead of COM8) it can't connect to the focuser. If I go through the driver setup dialog (System Tab, Disconnect, Setup) and set the new COM port it all works again. It shouldn't be an issue if you have everything connected up the same way all the time e.g. permanent Obsy. Not sure it stricly follows the Ascom model but it will save a few clicks each time you start your imaging session. I think I need to add some code to the Arduino sketch so the position is stored in non-volatile memory at each driver disconnect. Gina - any code examples of how to do this?

I think what is happening is that the autostart is bypassing the chooser and assuming some other section of the driver will have saved the position from last time. I haven't catered for this anywhere at the moment. Are there any other drivers you know of that work that way I could maybe look at the code and see how it is done (nothing like a bit of plagiarism)

I was aware it was possible but it's not something I had thought of doing. I didn't realise the Ascom model catered for saving the focuser position between connections. I will do a bit of research in the coming days to see what Ascom actually expects and whether the functionality needs to be in the focuser or the driver. Unless someone can point me at the correct documentation. 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'm ok if anyone wants to take my code as a basis for a new project otherwise I wouldn't have made it public. Any code snippets fed back will be appreciated and even stolen borrowed for AAF2 One thing I have noticed since adding the temperature sensor is that the client programs I have tested it with all seem to request the temperature every second. I think that's a bit too frequent and could even interfere with the other commands if the 1-wire routines are a bit slow - I set my FocusAAF2 utility at 10s which should be fine.

Thanks Ron, it's nice to be appreciated. I must say I get more respect and appreciation on SGL than I get at work these days

There is nothing in the driver and focuser to retain the position between sessions. Ill look into how this is supposed to work.

Don't know why I used SF as an abbreviation for FocusMax. Not awake yet