I recently replace a Losmandy G11T mount with a Software Bisque Paramount MX+ mount and now I am getting a intermittent Mount Error: The mount is parked or not tracking! Would you like to start tracking? Answering No will abort the Sequence. The SkyX program shows the mount tracking at sidereal rate and telescope is on the target. After answering Yes the sequence continues normally. SGP version is 2.7.0.608, ASCOM is version 6.6, OS is Windows 10, SkyX is latest version 10.5.0 Build 13339. Below is the log showing when the error started at 22:14:20:897. Any help would be appreciated. I also contacted Software Bisque.
[05/31/22 22:14:20.448][DEBUG] [Sequence Thread] Attempting to move to next event…
[05/31/22 22:14:20.448][DEBUG] [Sequence Thread] Attempting to find next event…
[05/31/22 22:14:20.448][DEBUG] [Sequence Thread] Current event[0] frame count: 5/8…
[05/31/22 22:14:20.448][DEBUG] [Sequence Thread] Current event event[0] has remaining frames. Returning current event.
[05/31/22 22:14:20.448][DEBUG] [Sequence Thread] Running pre event…
[05/31/22 22:14:20.623][DEBUG] [Sequence Thread] Running capture event…
[05/31/22 22:14:20.897][DEBUG] [Sequence Thread] Mount is not tracking! Aborting capture event (and sequence… recovery is not allowed here… assuming mount is not tracking for safety).
[05/31/22 22:14:34.305][DEBUG] [Sequence Thread] User elected to start tracking…
[05/31/22 22:14:34.306][DEBUG] [Sequence Thread] ASCOM Telescope: Setting tracking state to True
[05/31/22 22:14:34.500][DEBUG] [Sequence Thread] Attempting to resurect mount…
[05/31/22 22:14:35.734][DEBUG] [Sequence Thread] Mount resurected, continuing sequence…
[05/31/22 22:14:35.734][DEBUG] [Sequence Thread] SetStartTemp: Using focuser for temperature…
[05/31/22 22:14:35.734][DEBUG] [Sequence Thread] Set start frame temp to 23.4533333333333…
[05/31/22 22:14:35.912][DEBUG] [Sequence Thread] ------------- Starting capture frame for event[0] -------------
I can’t be sure, but I don’t recall any issues in 2.7 regarding a failure to determine if a mount is tracking… but, that code base is also about 7 years old at this point and I’m afraid my memory can’t reach back that far. Off hand, I can’t think of anything specific, in a generic sense it’s possible that the PMX+ uses more data than the G11. Because of this it may have exposed some unknowingly fragile part of your rig like a failing USB hub, a “not great” USB converter or maybe even a failing power supply for the hub. This is all conjecture of course…
I don’t believe it’s a usb or power supply issue because the mount is still connected to the SkyX software when this error occurs and PHD2 is still tracking. Maybe a communication error between SkyX-ASCOM-SGP.
I tried using N.I.N.A. software to eliminate one piece of the puzzle. I ran two full nights with N.I.N.A. software with no problems. I then tried SGP again and the problem returned on the second target. Also, when this error occurres, the sequence does not abort and the mount will continue tracking until it hits its limit. I really like SGP but may be switching to N.I.N.A. to forgo the problems with SGP and this mount.
That’s totally fine… this hobby is complex enough without adding additional headaches from mysterious errors and incompatibilities. I wish we could be more help, but don’t really have enough information. All mounts use the same code (there is no special code for any particular mount) and there are no general problems with mount operation in 2.7. This means that whatever the issue is, it is environmental. That’s not to say that SGPro can’t handle things better, just that we have nothing to go on.
If I were forced to guess though, I would say that this issue to do with traffic congestion through the hub. SGPro is almost certainly more aggressive than NINA with this respect. SGPro gets, analyzes and displays a lot of information about your rig. A thing to keep in mind… whatever causes this congestion may not even be remotely related to the mount. It might just be a totally separate thing causing congestion. For instance, a safety monitor or environment device might unintentionally consume a lot of bandwidth.
The other possibility is that this issue DOES happen in NINA, but NINA is more tolerant of it because it maybe doesn’t care. SGPro, in a lot of cases, is forced to care because of how sequence recovery works… it has to continually query certain aspects of the sequence to determine if there is something from which to recover.