I have found an anomoly - if you look at the ASCOM log file 478830 and compare the two start-ups at 19:35:15 (which worked) with 19:38.13, (which didn’t).
In the first case, the mount unparked and tracking was turned on before the slew started.
In the second case, the tracking is turned on - then immediately off again, before the slew starts. When it finishes the slew, the tracking is still off. According to the ASCOM methods, if a slew to coordinate command is issued with tracking off, it should throw an error.
@Jared
Jared. I have just had a deja vue moment. I have seen this behaviour before where TSX immediately turns tracking off. If I’m right, it has nothing to do with SGP. I just need the wind and rain to stop to confirm. I’m guessing it’s a lottery if SGP manages to issue the slew command before TSX turns off tracking and probably the ASCOM polling misses the quick change in status.
@Jared
I pretty certain I found the problem and offer a theory for the anomaly. My setup is the likely cause but some variations in SGP startup timing changed the failure frequency. I have now run 544 with ASCOM 6.5 half a dozen times, without issue.
My park position for the mount is horizontal, to clear the ROR. It should be just above the horizon, facing North. At some point that park position had altered to 10 min below the horizon and, with the ‘stop tracking past horizon’ in TSX enabled, as soon as tracking was turned on after UnPark and prior to the slew, it was disabled directly by TSX. This occurs in about a second. I noticed the tracking status prior to the slew often corresponded to the tracking status afterwards.
During my experiments I noticed there was some variation in the time between the unpark and the slew starting in TSX. In some cases the mount would toggle its tracking status twice before slewing. It appears that when TSX had time to stop tracking before the slew occurred the tracking status/reported status was corrupted.
I updated my Park position to just above the horizon and the tracking has always been on before and after the initial slew.
My lingering doubt is that I returned to the prior park state and after a few attempts, I did not get it to fail again (in fairness, it didn’t happen every time in the first place).
Ah, well that will do it. Interesting that when we attempted to then enable tracking that we didn’t get an exception…or it’s completely possible that we successfully unparked, enabled tracking, waited a second for things to settle, and then checked the status.
Glad you got it figured out!
Jared
Interesting. I went back to device hub last night and had nothing but problems. My planetarium programmes also threw Ascom port closure errors. I took some screen shots of the errors if that would be of help.
SGP threw the same errors as in the past with Device Hub. I shut down Device Hub and switched back to Generic Hub. All seemed to work as it should but failed again in the middle of the night. I shut everything down and rebooted and all is good with Generic Hub and all my various programmes. I’m wondering if Device Hub left something residual behind?
I really don’t think this is an SGP issue but rather an ASCOM 6.5 Device Hub issue. Thoughts?
Gord - first things first - even though it might seem like software, make sure your hubs and cables are tip top.
I would then run the conformance checker, just to be assured - I am assuming you can run it through a hub too.
Over the years I have written a few simple ASCOM drivers and when it came to my ROR, I baulked at writing a hub. I could not use the generic hub or POTH as they blocked many non-standard ASCOM commands I needed for things like safety sensors. For a few years I used OPTECs ASCOM hub until it started messing up after a Windows update.
Fortunately the ASCOM developers mentioned Device Hub - this is transparent to the commands and I found I could discard OPTEC entirely. The reason I mention this is that AFAIK, DeviceHub opens up to many more commands, some of which may be causing you grief.
I have an earlier version of device hub, from December, which was available from the ASCOM org website before 6.5 was released. It worked for me (dome connection only) If you want to try it and cannot locate it, I can send it to you.
Thanks Buzz,
Good advice! Often problems are caused by cables and connexions. I use a PrimaLuceLab Eagle3 mounted right on the scope so the all peripherals go direct to the Eagle3. I checked the connexion to the G53F mount and, to be on the safe side, replaced the cable with a new cable. I have been able to image perfectly using Generic Hub as well as directly Using the G53F Pulsar2 ASCOM connexion.
The only time things go south is when I use Device Hub. Still a mystery to me. Easiest solution is to avoid Device Hub but…I love a mystery! 
Thanks for your help Buzz!
Gord
You occasionally see a newbie who wants a turnkey system and get frustrated when things don’t turn out like that. They are missing the point; if it were easy and just a question of money, it would be no fun at all or achievement.
The problem is finding the sweet spot when it is challenging enough without making one throw in the towel!