I have had an Unhandled exception the last two times I have run SGP, one resulting in a pier crash. The first was with 2.4.0.2769 and resulted in the pier crash. I didn’t report it because the meridian flip error was my own fault (I pushed the wrong button on the keypad of my Mach1GTO after resetting to daylight saving and exited out without saving the changes) which caused SGP to attempt a pier flip before the mount crossed the meridian. However, I expect in this situation that SGP will save me from my own incompetence and park the mount. It did not, I’m pretty sure because I had an Unhandled exception:
Microsoft .NET Framework
Unhandled exception has occurred in a component in your application. If you click Continue, the application will ignore this error and attempt to continue.
The write timed out.
[Details] [ Continue]
See the end of this message for details on invoking a
just-in-time (J IT) debugging instead of this dialog box.
Exception Text
System.TimeoutException: The write timed out.
at ASCOM.Utilities.Senal.Transmit(String Data) in C:\ASCOM Build\Export\ASCOM.Utilities.556\Serial.vb:line 1201
at ASCOM.MoonLite.Hardware.CommandBlind(String command, Boolean raw)
at ASCOM.MoonLite.Hardware.Command Sting (String command, Boolean raw)
at ASCOM.MoonLite.Hardware temperature Monitor_Tick (Object sender, EventArgs e)
I’m pretty sure now that the Unhandled exception prevented SGP from running the park script and I woke up to a pier crash and stalled motors. Logfile is here:
Last night I had the same Unhandled exception, this time with 2.4.0.2773, but it occurred later in the sequence when I was running dark frames, so the mount was already parked. No damage from this one, but I was unable to gracefully exit from SGP in the morning - had to use Task Manager to close the application.
This could be a corrupted or out-of-date MoonLite driver I suppose, but I’ve posted the logfiles in case this is SGP-related. Regardless, however, one would hope than an Unhandled exception wouldn’t prevent SGP from running safety protocols that would park the mount instead of allowing a pier crash.
Unfortunately, the very nature of unhandled is that it is indeed “unhandled”. We try to cover as many scenarios as we can, but there are some holes. Once we find them, they, of course, become “handled”.
Looking over your logs, they are so riddled with device communication errors that it is very difficult to figure out what is going on. In the first log, SGPro lost communication with both the telescope and the focuser. In the second log, the focuser connection was lost at some point. Not sure why you had to use the task manager to restart. These logs will take a while to go through.
May I stress again to you, and all other users, you should never run SGPro unattended unless you have safeguards in place to prevent damage to your equipment.
“riddled with device communication errors” - that’s alarming! Any idea where to even start looking at why that might be? Hardware? Software? One thing about my setup is that I run everything over a Cat5 cable between my office and observatory using an ICRON Ranger unit - anyone have any idea if that could be causing communication problems?
…Keith
Good recommendation Ken, but as far as I know the Mach1GTO doesn’t have hard mount limits. Recently AP has come out with APCC though which does allow mount limits to be set in software. As I understand it, APCC functions as a layer between the software and the mount (correct?), therefore if I bought APCC would that be a possible solution to prevent a pier crash if SGP ran into an Unhandled exception?
…Keith
From your first log it appears things started to go downhill around 12:43am. There are lots of focuser and telescope errors at this point. The telescope even states:
[16/03/2015 12:45:15 AM] [DEBUG] [CP Update Thread] ASCOM Telescope: Error in GetCurrentPos : Lost communications with mount.
The “Lost communicaitons with mount” is actually coming from the ASCOM driver for your scope. To me this indicates that a cable got pulled tight and came unplugged or there was some other sort of problem that happened with the communication between your ASCOM driver and your mount.
If it was a software (read SGP failure) then yes, it would likely protect you. But from the looks of those logs it seems to me like more of a hardware/communication issue between the ASCOM driver and your mount. I doubt that in a communication scenario APCC would save you. Really the only way to protect the mount in this case would be some type of hardware switch in the mount or a software setting that resides in the mount’s firmware. It sounds like the Mach1 doesn’t have a hardware switch but maybe there is a way to do it through firmware in the mount with APCC (or other means)? You’d have to ask AP about that possibility. My G11 implements a firmware feature that won’t allow it to track past a certain point. However this relies on an accurate sync to be correct. Essentially it won’t track a certain number of degrees pre/post meridian depending on the side of pier.
Actually, APCC has sets a dead man timer in the mount’s firmware so that even if the entire computer crashes tracking will automatically stop after a few minutes. Also, meridian limits can also be set to stop tracking if the client application has a software error and does not stop tracking or park the mount.
Communication error mystery solved I think. The reason my logfile seems to be “riddled with communication errors” is that it appears a hardware component was failing in my computer. I discovered this when it finally failed completely and threw a boot error that a hardware component was bad or missing. Bad news is that I’m unable to boot my computer any longer; good news is that by an amazing stroke of good luck my new laptop was delivered the day before! Now I’m in reload mode as I reinstall all of my software (and missed a perfectly clear night last night - the weather gods are poking me in the eye). But I’m hopeful that when I get back to imaging communication will be more stable.
…Keith
