SGP disables tracking after park

Hello,

Not sure if it came with the latest update but i noticed that my 1000HPS gets set to stop tracking after park. Not sure if it is different with any other mount but park stops tracking anyway. However, disabling tracking is an issue as an unpark does not enable tracking again. Some weeks ago, this wans’t happening.

[11.20.17 02:34:07.222][DEBUG] [Sequence Thread] Parking telescope…
[11.20.17 02:34:07.225][DEBUG] [TEC Thread] SGM_CHANGE_COOLER_TEMP message received…
[11.20.17 02:34:07.225][DEBUG] [TEC Thread] TEC Change: Starting…
[11.20.17 02:34:07.226][DEBUG] [Sequence Thread] ASCOM Telescope: Park message received.
[11.20.17 02:34:07.226][DEBUG] [Sequence Thread] ASCOM Telescope: closing observatory shutter…
[11.20.17 02:34:07.227][DEBUG] [Sequence Thread] Dome: Closing Shutter
[11.20.17 02:34:07.229][DEBUG] [TEC Thread] TEC Change: Changing temp from -35,44 to 10,00 in 300 seconds…
[11.20.17 02:34:46.377][DEBUG] [Sequence Thread] ASCOM Telescope: Parked
[11.20.17 02:34:46.377][DEBUG] [Sequence Thread] ASCOM Telescope: Sending post-park stop tracking…
[11.20.17 02:34:46.377][DEBUG] [Sequence Thread] ASCOM Telescope: Setting tracking state to False

“Stop tracking when sequence completes” in Control Panel/Telescope is not ticked.

Any idea what i can do?

Thank you!

best regards
Matthias

Which version SGP are you using? I believe latest version does not do this anymore.

Peter

Its the latest V2.6.0.24 …

OK. My Astro-Physics A-P1100 mount automatically stops tracking after the mount is parked and automatically resumes/starts tracking when the mount is unparked. I would contact 10Micron about this because it sounds like a minor bug in 10Micron because there is no reason for this behavior. I am curious of what triggers 10Micron mounts to start tracking?

Peter

I found this:

I noticed the following statement:

“Any park command issued through SGPro will now be followed by a stop tracking command.”

To SGP developers: Is there a reason for this? IMO, it should not be an issue for any mounts but what prompted you to implement it anyway?

Peter

I don’t remember why, but I suspect that it was to compensate for a mount that moved to park, but did not stop tracking. We didn’t think it would be problematic as SGPro will unpark and start your mount tracking on sequence start.

Either way, this breaks rules we have in place about writing code around drivers that behave badly. So… I have modified this so that SGPro will stop tracking, but only if Park fails. In this way, we can help prevent gear damage. This change will be in the next 3.0 beta.

Hello Peter,

Correct, a park command automatically stops tracking and resumes after unpark on my mount. But in this case, SGP send a stop tracking command after park. Here, the mount does not resume tracking after unpark which is what i expect it to be.

Best regards
Matthias

Hello Ken,

I understand why you implemented this but not why you havent made this a user choice …

Best regards
Matthias

I am curious. When does 10Micron mount start tracking? As soon as you power up the mount or after building pointing models?

So, if SGP sends stop tracking command to 10Micron mount after park, there is no way to start tracking unless you power cycle the mount?

Peter

The mount starts tracking if it was set to tracking before the park command or if you set it to sideral tracking manually. Thats probably the same with any other mount.
Here, SGP issues park command which parks the mount and stops tracking automatically, then is sends a stop tracking command which changes the tracking mode from “sideral” to “no tracking”. Of course, the 10micron does not resume tracking after an unpark. Why should it?

You wont notice any issue if you work with SGP only, as SGP issues a start sideral tracking command after unpark to recover from the previous park and stop tracking commands. If you work with any other program after a SGP session, like Cartes du ceil different programs, you must unpark and enable tracking manually. My point to the developers is that it would be much better to make this user selectable instead of forcing everyone to accept this (weird) behaviour to workaround some mounts issues.

Mostly because we don’t want a horrible user experience full of a thousand choices. As I mentioned above, it was probably not the right decision to do this in the first place and it has been removed.