You are free to add additional requirements such as this to what you require but it doesn’t make it part of the ASCOM specification.
Hi - Having just written a dome driver I’m with the client side (SGP team on this one). As I understand it from the ASCOM folks, systems such as domes , focusers and other positioning equipment must be autonomous robotic systems. So the ASCOM driver will issue a slew/ move to position command to the positioning equipment and the positioning equipment executes whatever it needs to do to move to that position. The driver will monitor the robotic system to see when movement has stopped. The Client relies on the driver’s reporting and for that reporting to conform with the ASCOM standard. When I wrote my driver, I used the ASCOM templates and this helped greatly with conformance. Part of conformance is ensuring clients get what they expect for a given context.
I also found the ASCOM Conform tool to be very useful.
Regarding the accuracy with which positioning equipment arrives at the target position, this is down to the autonomous robotic system. I wrote my robotic system software to monitor an aboslute position encoder and convert the encoder ticks to an Azimuth angle. I did lots of testing and tweaking to ensure that if the client (SGP in my case) asked the driver for Azimuth X the system reported success if the robotic gear got + or - 2 degrees of X which was the allowable margin to ensure the scope and dome aperture were aligned. To me, it does seem self evident that the positioning equipment has to get to target, otherwise my scope would be looking at the wall of the observatory rather than the dome aperture.
best wishes,
Paul
Hi Paul,
my english is not very good a I did not understand what you exactly mean and where is the
problem. Can you write my what is your conclusion about this and what solution you recommend?
Peter
Just refering back to Ken’s four points above,
That’s what I did for my dome driver. For a focuser, the encoder ticks are mapped to the positions of the focuser. Any oscillation of the encoder output should be handled by the autonomous robotic system, perhaps as a tolerance e.g. ticks +/- 20 is equal to a fixed position which can be reported to the ASCOM driver.
It may be best to continue the discussion in the ASCOM Talk developer’s forum, I’m sure the focuser driver developers will be in there anyway.
best wishes and hope you get it sorted.
Paul
A have the same issue as you Peter. I recently contacted ASA and asking for their progress with this issue. It seems like they are not interested in solving this quite trivial problem. For me the solution seems quite simple.
- Move the focuser to the demanded position of the client.
- Report demanded position back once move is finished with hysteresis of 2-4 microns. IF the current position is within the threshold values, the comand position is reported. Else current position of the absolute encoder is reported.
When paying 1500 euro for a focuser one would expect it to work with such a widely used software as SGP… (not happy at the moment)
I am not at SW devolper but i have now decided to give it a try and fix this. I will try to program a “in betwwen ascom driver” to add a hysteresis to the current position of the absolute encoder.
Wish me good luck 
/Martin
Also if you want to use the auto focus in SGP, there is one manual work around. When you run the auto focus routine and the focuser does not reach the correct final position. You can help it with the ASA client by moving the focuser in 0.002 increments to the commanded position of SGP.
Took me a while to figure it out but the command position will be the lines on X-axis of the AF routine. If you see one line on the X-axis, for instance 7853 and the focuser stops at 7851. You just have to move it manually to 7853. As soon as this position is hit AF in SGP will continue. I do this since i run my observatory remotely. But is rules out complete automation, and sleeping while imaging.
/Martin
Ok, a little update. I have what i think is a complete fix for this issue. I did program a new ascom driver with filtering described in my last post. I ran 15 autofocus runs yesterday and it works perfectly.
It took me araound 20 hours to solve. But i have no experience in SW development of this kind, so most of the time was spent on learning about the ascom platform and learning VB and C# from scratch. To bad no one else could have solved this sooner…
If anyone want to try i out, contact me to get my new AAF3_SGP.exe ASCOM driver install package. The driver is really bare minimum, so there is still some work left to do with exeptions etc. But it worked just fine last night. I will continue testing but im not sure i will be able to make it 100% ASCOM compliant. Missing some programming skills.
/Martin
He would have liked it to work. If you think it will work reliably I’d try it. You’re very handy.
Peter
pepe30 I can’t promise that it will work perfectly for you and i can not take responsibility if something happends with your focuser. With that said i think that it is going to work for you. Make sure to have the newest “ACCServer” ASCOM driver installed. I think you make that choise when you configure the asa software for the first time.
Please report your results if you decide to try it
Can be downloaded from dropbox: Dropbox - File Deleted
Martin