Hello
I am testing the Startup-to-Shutdown script in DragScript and for the love of God cannot get the Go To Alt/Az command to work with my Astro-Physics mount.
I can definitely send a goto alt/az command from APCC or the AP ASCOM control but when I try to do it from within the script I get the following error:
I tried changing the tracking state to Not Tracking before sending the command but no luck.
Has anyone with an AP mount managed to get this going?
Thanks
this error coming from your driver. I have an AP mount but i dont have problem (i’m using old old driver to avoid problems). I also don’t use APCC because doesn’t add anything to my automation. Another user report the same problem and the bug was sended to AP driver developer without answer. Voyager is used by few people and i cant ask anything to driver developers.
I put a workaround in Dragscript adding a new block to simulate the altaz with radec conversion on realtime. Is under development.
Sorry but I cant do more … this is not a problem caused by Voyager.
Ok Leo; many thanks. I will bring this up with Ray Gralak. The spec of the latest driver still lists AltAz goto commands as accepted.
On APCC, it’s great for imaging without meridian flips and with counterweights up. It also allows me to create a profile of my observatory horizon to avoid possible crashes and obscured zones. I have two piers in a 6x10’ observatory!
Roberto
Leo
What version of the AP driver are you using where the Goto AltAz works? I have found the exception in the AP driver log for the AltAz GoTo command and will send it to Ray.
Since my setup is permanently mounted and locked, APCC is all I need to avoid crashes. I have had it like this since late 2014 and have never had a crash against pier or gone beyond the specified horizon. It can be done!
Thanks again
Roberto
I may have found part of the issue why the driver is confused. When I send the Goto AltAz command to the driver through Voyager I am instructing: Go To ALT 35 - AZ 120
Yet the driver’s log reports:
ASCOM: Info : SlewToAltAzAsync() Az=35, Alt=120
Which means is switching the ALT for the AZ and the AZ for the ALT.
And then reports an exception:
We tried it but without success … i’m going to see if i introduced a bug in altaz action but the code is the same for all mounts … this mean all mounts working with voyager had value inverted ??
The error in log is about track status … we have found driver and apcc mix the status of tracking depend no how started (first or second).
Yes, it’s good your code works. The AP driver is understanding the instructions in reverse order but doesn’t slew in either. So there is a problem with the way it understands the instructions as well as how it tries to implement them. I would be grateful if you let me know your AP driver version when you get a chance. If you have access to your logs, it will be written there. I am using the latest driver 5.20.08 (from December 2018) and the latest version of APCC.
Thanks
Ok. APCC doesn’t interfere here. The log I quote above is from the ASCOM driver. APCC is transparent to the driver and it’s not blocking the slew. The exception doesn’t even feature in the APCC log.
Thanks
This is not true … what i see with another user is different. APCC report a track status different from driver … depends on the order start of software. I don’t have mode to talk with their developer … i tried sometimes but without success to be listen. If you are more lucky i’m happy. If you found something wrong in voyager i’m happy to fix.
Ok, I am only reporting what I see in the logs. There is not exception or error in the APCC log. The timestamp of the error in the ASCOM log doesn’t even show in the APCC log.
I have already asked in the AP-GTO forum and Ray is pretty responsive over there. Don’t worry, I’m sure this can be fixed.
Your workaround using current RA/DEC will surely work but it’s a lot of development!
Roberto
Ray just posted this in the AP-GTO group. Will test and report back. I also told them about the coordinates being exchanged by the driver.
Hi Roberto,
> “10:07:44 154 - ERROR (FINISHED) Telescope Goto ALT/AZ : [(ASCOM) AstroPhysicsV2.Telescope] slew
> Alt/Az Async not done (Wrong tracking state)”
The message just indicates that Sidereal Tracking needs to be turned OFF first before the command can be accepted. This is a requirement of the ASCOM standard for slewing to an Alt/Az location. The reasoning is that Alt/Az location continually changes so when tracking is enabled the scope would immediately be at the wrong Alt/Az as soon as the slew completes.
BTW, if Voyager wants to slew to an Alt/Az and then continue tracking at sidereal, then it could either:
Convert Alt/Az to an RA/Dec and issue a slew to that RA/Dec.
Disable mount tracking, slew to Alt/Az, then enable tracking.
From Ray on the exchange of Alt and Az and their order according to ASCOM:
Hi Roberto,
> Another issue we have
> found is that when the software (Voyager) sends the goto order the Alt is being interpreted by the AP driver as
> the Az coordinate and viceversa. Strangely this doesn’t occur in the simulator or with other mounts.
The tricky thing is that despite the names of the ASCOM functions, SlewAltAz, and SlewAltAzSync, the Azimuth comes first, then Altitude according to the ASCOM documentation. The AP V2 ASCOM driver passes ASCOM conformance testing so I don’t think it has the parameters are backwards, so I am wondering if maybe the Voyager program has the Altitude and Azimuth arguments backwards?
BTW, if Voyager is new to ASCOM, it might be worthwhile for the authors to carefully check the ASCOM documentation to make sure they are using it correctly.
Sorry Roberto, i’m new to ASCOM . I used it only in the last 11 years.
I cant change the code of AltAz slew because nothing is inverted and all work fine. You can do test with simulator if you want. The only solution for AP users is to wait i’ll create a block with RA/DEC conversion. I can’t stop tracking because some driver doesn’t have a start/stop track implemented and if stop the track doesn’t slew. AP developer are right in stop track limitation , i read on the last row of methods.
good luck
