Strange slew failure with SGP / TSX

I’ll start off by saying I am not entirely sure where the problem lies. It may well be a combination of events.

I have seen a few instances where SGP issued a slew command through ASCOM TSX driver and the mount did not slew. This has occurred several times at start of sequence, after homing the mount. The home position is very close to my horizon limit and it may be the mount was not tracking when the slew command was issued. SGP thought it had slewed and carried on the sequence. I noted it at the time, slewed to some other position in the sky and restarted the sequence with no issue.

Last night - I was trying the 2.5.2.3 beta and the slew failure occurred between slewing between mosaic targets. SGP was still showing that it was slewing to target and TSX had crashed. I have saved all the various logs and will go through them later to try and nail down when and in what circumstances it occurred. I had been using the sync offset function and I noted this morning that the telescope had not meridian flipped. SGP was still working - once I had Ctrl Alt Del TSX and started it up again, I was able to park the mount, close the roof and start drying it out.

My question right now is that I have not used GNS for a while, so I am ignorant of what it does in the event of a never ending command - would it provide a warning?

In this latest instance, it was an ASCOM exception thrown by the TSX driver and a slew command that never completed. I’ll post on the SB website. Not sure how this will go down, now that Chris R has moved on.

I did some more searching through the log files - the ASCOM exception at 00:16:38 seems to be from a tracking enquiry but it recovered a little later on. Immediately before the slew command, there was a sync offset conversion. I’m not adept at deciphering the logs but it might be related.

This occurred at 00:21:44 - full log files are at:

There are definitely some kinks to work out on the syncless center. That said, the kind of exception you got (RPC_E_SERVERFAULT) is not super great. It is not the kind of exception you would get from normal behavior (meaning controlled exceptions from bad data or other). Not sure about that one…

thanks Ken - I posted on SB forum with their logs and they asked a few questions about what camera I was using - maybe a timing clash.
It hasn’t happened since. I also made up a mosaic and did short single exposures of each panel to exercise the sync. It behaved itself after I deliberately set the sync method to offset. (There is another thread where I had recurring issues with the sync setting persisting. If I stored it in a profile, it read back as if it was set to offset but behaved as if it was sync mount.