Unpark on sequence start

Sequence Generator
#1

Hi - Is it possible to unpark the mount on sequence start?

The reason I’m asking is that if I start a sequence with the mount parked it causes problems in SGP which I can’t recover from other than by restart of SGP.

I use SGP with the Sitech II controller.

thanks
Paul

#2

It should do that - my sequences all start from park (Paramount)

#3

thanks for reply. Mine doesn’t; most of the time I remember, but when I don’t I have to restart SGP. It may be clear again tonight and if so I’ll try to run a sequence with the scope parked. The last opportunity I had to use the kit was last November due to weather issues, so I can’t remember the error message I had, but it is a consistent problem. I’ll post back.

#4

Here’s a couple of screen grabs which show the problem:

Message 1
and when I choose ‘Yes’:

Message 2

So in my limited ASCOM programming experience, either SGP isn’t sending an unpark request or the Sitech controller isn’t receiving it or isn’t processing it. I’ve posted on the Sitech Controller forum too.

It would be nice to have a solution to this as you can see it’s a process pain.
thanks
Paul

#5

Paul - have you run the ASCOM conform utility on the driver? That would identify if it is supported or whether it is producing an error.

#6

Thanks for the suggestion Buzz. I have posted on the Sitech controller forum too so hopefully between the SGP team and the Sitech team, the issue will be resolved. I used Conform once or twice when I built my dome driver, I’ll see what it reports…
Paul

#7

Here is an extract from the ASCOM Conform output, it seems that unpark conforms, but throws an exception if it is asked to slew when parked - marked as ‘xxxxx’ below. On reflection, I’m not sure anything here explains the problem.

Methods
13:54:49.865 CanMoveAxis:Primary OK CanMoveAxis:Primary True
13:54:49.917 CanMoveAxis:Secondary OK CanMoveAxis:Secondary True
13:54:49.964 CanMoveAxis:Tertiary OK CanMoveAxis:Tertiary False
13:54:50.578 Park OK Success
13:54:50.591 Park OK Success if already parked
13:54:50.612 Parked:AbortSlew OK AbortSlew did raise an exception when Parked as required
13:54:50.662 Parked:MoveAxis Primary OK MoveAxis Primary did raise an exception when Parked as required
13:54:50.732 Parked:MoveAxis Secondary OK MoveAxis Secondary did raise an exception when Parked as required
13:54:50.788 Parked:PulseGuide OK PulseGuide did raise an exception when Parked as required
13:54:51.301 Parked:SlewToCoordinates OK SlewToCoordinates did raise an exception when Parked as required

xxxxx

13:54:51.356 Parked:SlewToCoordinatesAsync OK SlewToCoordinatesAsync did raise an exception when Parked as required
13:54:51.629 Parked:SlewToTarget OK SlewToTarget did raise an exception when Parked as required
13:54:51.685 Parked:SlewToTargetAsync OK SlewToTargetAsync did raise an exception when Parked as required
13:54:51.975 Parked:SyncToCoordinates OK SyncToCoordinates did raise an exception when Parked as required
13:54:52.352 Parked:SyncToTarget OK SyncToTarget did raise an exception when Parked as required
13:55:07.848 UnPark OK Success
13:55:22.858 UnPark OK Success if already unparked
13:55:22.936 AbortSlew INFO Tests skipped
13:55:22.946 AxisRate INFO Tests skipped

#8

Paul - that is how it should be. If you look at the SGP log, it should issue an UnPark command before trying to slew. SGP doesn’t “know” your mount and simply issues ASCOM commands. There may be a gotcha though, it is possible that either the ASCOM driver, or any intermediate hub, may be disabling/blocking those commands. For instance, in the ASCOM driver for TSX, the ASCOM properties have a dozen or so options. In the case of this particular driver, some options are disabled if the driver gets an exception thrown after trying it out. Some hubs also filter out commands and if they have a settings page, you need to see what’s what.

#9

thanks Buzz, I’ll check the log to see if unpark is issued before slew. I think I know what the result will be - there’d be many more post like mine if SGP didn’t unpark before slew, but just for the hell of it :slight_smile: I’ll check…
Paul

#10

Probably worth posting the SGP log here. My guess is that we ask to unpark, wait for Parked to return false, and then issue the slew. It could be that the ASCOM driver is reporting unparked before the mount is truly unparked.

Things like that happen fairly frequently where the ASCOM driver will buffer the response to the hardware.

Jared

#11

thanks Jared, here’s a log of a session I did a few mins ago specifically to provide data on this issue.
I don’t have a log file viewer as yet, but just scrolling to the bottom of the log, it seems to request slew, but I couldn’t see an unpark…

https://drive.google.com/drive/folders/1w41XJ8LhvN59XLe9eNnpr09aDWru_s77?usp=sharing

regards,
Paul

#12

How was this log generated? It seems VERY different from a normal sequence startup. Did you right click a target and select “Slew”?

Jared

#13

So when right clicking or using the “Slew now” option there was a bug. I have addressed that. However the path that is taken when a sequence starts is very different from that.

Jared

#14

Hi Jared,
I used framing and mosaic wizard to set up M45. Then connected all the gear so that a sequence would run and then from the M45 target settings dialog I clicked slew now. I then get the dialog message about not tracking or parked and when I click unpark in that dialog I get the second error (as shown in earlier posts). I then went to ‘help’ ‘view log’ and saved the log to a file. The log you see is the contents of that file.

After saving the log, I disconnected all the equipment and left the observatory.

If you’d like me to try anything different let me know…

btw at the point I clicked ‘slew now’ the mount was parked.

thanks very much for help,
Paul

#15

also Jared, can I try the bugfix? will it appear as a new version or will I get it by another route?

thanks
Paul

#16

Ok, that’s kind of what I thought. There is a bug with the slew now which I have addressed. But the slew on sequence start goes down a different path. If you’re seeing the same behavior on sequence start then it’s likely a different issue than how you duplicated it with Slew Now.

Jared

#17

Basically the issue is that the target you were slewing to didn’t have any work to do or wasn’t within the time constraints…basically we should ignore those things (and now are) for a manual slew. But for the Start Sequence slew those things are completely valid to check and should not attempt to even slew to that target.

Jared

#18

ah right, I guess I’ll have to wait for some night sky to check it from sequence start as it will need PHD2 to run - I might just go and check that and report back.
thanks
Pauk

#19

The “slew now” does run through a decent chunk of the same code as the run sequence start. You’ll just need to make sure that the target is valid for “now” until that is released. Basically make sure start/stop times are valid or disabled and that the target has light frames and is selected to run.

You should be able to use the slew now to check things out during the day. Or create a sequence with a single target that is up now and try the sequence start logic.

Jared

#20

ok thanks Jared. I was stating M45 but it was M82. I have just used the same M82 target again but with a practice guider. This time I started from ‘Run Sequence’ and that all seemed to go ok (there was a dialog but it was info about parked rather than error). However, the scope did not slew - it started to track, but did not slew from its park position (Az 270).

Here’s the log file

https://drive.google.com/drive/folders/1w41XJ8LhvN59XLe9eNnpr09aDWru_s77?usp=sharing

thanks,
Paul