:is I a trying to get my Vixen ss2kpc mount to work with SGPro ,I have downloaded the latest ascom drivers and selected the correct port , also have tried running the software in administrator but a error code came up saying the mount cannot connect, the mount works with The Sky, Maxim , Apt with no issues, can anyone help please.
Is the driver a hub? Can you connect more than one application to the device at the same time? The other thing to try is using administrator mode on all applications that are accessing the mount.
Thanks for the reply, no the driver is not a hub and have tried Admistration start up but the good news is I have managed to communicate with the SS2KPC mount through selecting " Pipe diagnostic tool" in the mount selection panel and this now allows for "nudge " movement but not too sure if the mount will park unpark when asked so will need to wait until the RAIN dies down before opening the Observatory!
J
I’m afraid the problem has returned with the SS2KPC mount not being recognised by any of the hubs in the chosen dialog of SGPro ! HELP!
[changed] Are you using the driver from the ASCOM website? Looking at other forums there were issues with this system communicating to other acquisition programs (APT for one) but there were insufficient details to know if this was old news.
Hi Buzz
Yes the ascom drivers pass the compliance test with no faults, its very odd I am starting the think the SGPro has a bug the mount is recognised by ALL other software including The Sky in conjunction with Maxim DL Pro through Telescope API which used the POTH hub with no problems yet if I try to select POTH in SGPro it gives "aye right " so it is a bit of a mystery.
Many thanks for giving the problem som thought .
JW
Hello again Buzz
This is just to give like minded people like yourself some insight to my setup.
The mount was designed and produced by myself and was featured in the Astronomy Now magazine some time ago, the worm and wheels were supplied by GEARS and were the only mechanical part not produced by me, I then adapted motors and hand set given to me by a astro friend who had updated his setup and no longer needed the mount which has its limitations weight bearing wise.
The wheels are 200t 100mm radius which was accommodated in the SS2KPC software ( this is a very underestimated handset) this gave me the opportunity to maximize the design potential of a home built GEM concept which has proved to give sub arc second tracking results.
Equipment:
Main Scope -APM 107 mm+ WO F/F RE
Guide Scope 80mm WO + .65 reducer
Camera SVX H9 and manual filter wheel and Canon 100D Modified and cooled
Guide camera QHY5
Software The Sky- Maxim DL5 Pro- PHD2- APT
I use EQMOD adapted Mount once again recovered from going to scrap but is now my main mount for Star parties and performs vey adequately for this use , waste not want not!!!
Clear sKys
James Wood
Yes - I have written my own ASCOM drivers for my observatory but I’m by no means an expert. Obviously SGP assumes a set of ASCOM commands without knowing the mount version itself, so the commands it issues are the same. The areas that I have seen things fall down is around supported ASCOM features upon which SGP depends (for instance TSX ignores sync commands if it is connected to a Paramount and throws an exception) and timing. Timing is tricky - some commands take a while to execute and everything waits for it to complete, others are more immediate. It can happen that a command is supposed to complete and the driver will throw an exception if another command is issued. For instance on the TSX driver, the TSX API goes awry if you try to send an abort command through ASCOM, or if I remember correctly, you ask if the slew is complete when there has been no slew command… It is a right PITA for application developers. I’m sure Chris will chip in, but some of this stuff is probably already specified in the ASCOM methods and properties but OEMs do not entirely follow it, other stuff maybe one of those learning curve things where further guidelines are required.
There’s nothing I can suggest, I’m not clairvoyant.
We’ve not been told what goes wrong, or where it goes wrong.
All I can suggest is to follow my simple two step process for fixing things
- Find out what is really happening, not what you think is going wrong.
- Fix it.
Driver logs are a great help but in addition the ASCOM DriverAccess log gives chapter and verse about exactly what commands are sent to the driver and what ones are returned.
Hi Buzz
I appreciate your obvious knowledge of writing drivers it must be quite frustrating when things just doint do what you would expect for no lodgical reason .
In the mean time I am going to optimize the combination of the Software that works and try to use the PLATE SOLVE feature of MAXIM to allow re- positiong of the imaging field , also looking at using SCRIPTS .
Regards JW
JW - maybe use Maxim as an interim but Chris has extensive experience and his advice is the industry standard - find out what is really going on and then get a fix for it. It is a better long-term solution. It is easy to jump to the wrong conclusions (Chris knows that I have done that, even when it looks obvious and I still bear the scars 
).
It’s like assuming “I have flu” when the reality is “I have a slight temperature, sore throat and back pain”
Ok point taken😀