DragScript - Go To Alt/Az in AP mounts


#1

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:

ERROR (FINISHED) Telescope Goto ALT/AZ : [(ASCOM) AstroPhysicsV2.Telescope] slew Alt/Az Async not done (Wrong tracking state)

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

Roberto


#2

Hello Roberto,

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.

All the best
LO


#3

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


#4

:roll_eyes: good luck

Without absolute encoder or end point sensors checked by hardware no ones can save you from crash, my Mach1 doesn’t have.

All the best
LO


#5

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


#6

Its a version of 2014 … i need to look when i come back imaging in mountain.


#7

Leo

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:

check_connected: Exception : Track <> g_bTracking: False, True : SlewToAltAzAsync

Could this be part of the problem? I will try switching the Alt and Az in the order and see what happens.

Roberto


#8

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


#9

Tried with AZ35 and ALT 120 and same problem. AP driver reports correct order (originally intended AZ 120 and ALT 35) but same exception:

ASCOM: Info : GET Azimuth = 89.5833333333333
005412 2019-01-20 10:36:22.984: ASCOM: Info : GET Altitude = 89.3597222222222
005413 2019-01-20 10:36:22.996: ASCOM: Info : GET Tracking = True
005414 2019-01-20 10:36:23.018: ASCOM: Info : GET CanSlewAltAzAsync = True
005415 2019-01-20 10:36:23.030: ASCOM: Info : GET Tracking = True
005416 2019-01-20 10:36:23.030: ASCOM: Info : GET Slewing = False
005417 2019-01-20 10:36:23.051: ASCOM: Info : SlewToAltAzAsync() Az=120, Alt=35
005418 2019-01-20 10:36:23.051: check_connected: Exception : Track <> g_bTracking: False, True : SlewToAltAzAsync

Roberto


#10

I tested again on ASCOm simulator (the voyager code is the same fro all ASCOM mount) and all is ok … nothing inverted. Just to be sure again. :sweat_smile:

You can see on the image the request, the action ok and the position reached

All the best
LO


#11

Seems they have something to fix inside …


#12

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

Roberto


#13

You dont need to know my driver version. If your driver have problem just enough to send a trouble ticket to AP.

In anycase when i go back in mountain i can help you about, but i dont use APCC !!

LO


#14

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

Roberto


#15

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.

All the best
LO


#16

Leo

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


#17

No problems Roberto … only reporting what i’m see directly in 3 hours of remote help

All the best
LO


#18

Leo

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:

  1. Convert Alt/Az to an RA/Dec and issue a slew to that RA/Dec.

  2. Disable mount tracking, slew to Alt/Az, then enable tracking.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


#19

Leo

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.

-Ray Gralak


#20

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.

All the best
LO