Woke up today to my scope pointing up still (luckily not pointing east!)
Went and discovered SGP had crashed. This is the second time in the last week. Any ideas as to why?
sg_logfile_20180916195031.txt (731.6 KB)
Can you give some more details? Was there some kind of SGP error message, was it Ctrl Alt Del proof or was the PC looking like it has just restarted? For instance, if this is Win 10, and you have not paused downloads, Windows can reboot your PC when it wants to install what it believes is an important update.
This has happened to me twice. I wake up, the mount is still tracking and the PC is doing nothing.
It is Win10. I have updates delayed till 1pm (so they happen during the day) and am on the targeted update cycle
So no the laptop did not restart, my mount control app was running as was PHD2 - just not SGP. Previously, the last time it happened last week I was monitoring the imaging and just happened to notice that SGP wasn’t running anymore. In this case, I had determined that my bluetooth based focuser has disconnected during the session and that had apparently crashed SGP. I fixed that by changing out BT drivers and haven’t had any disconnects since.
Though my expectation is that devices becoming unresponsive shouldn’t crash SGP - which would help track down the problem device and a resolution via SGP’s log file.
In last night’s case, there’s no mention of any device causing an issue - beyond the dreaded “image failed to download…” issue. The error occurred during acquisition of many 30 sec LUM frames.
Expecting a Windows system to never crash is a big ask. There will always be unexpected obscure things that cause failure.
If you want something to protect your hardware in all circustances then you need some totally independent system that not only monitors the weather but also monitors SGP and if it sees it going unresponsive closes the observatory.
Applications using serial/USB/BT or other hot-plug interfaces should provide for and expect that some times the device may go away - it’s the nature of the interface.
I wrote the ASCOM driver for my focuser and provided for that possibility.
Regardless, I’m just trying to figure out why SGP crashed so that I can possibly do something about it.
We’re not the developers and so trawling through the log file is hit and miss. Some more details would be useful. The term ‘Crash’ can mean all sorts of things. Was it just unresponsive, or was there a windows exception and so on. There is no indication of when the crash happened, so it is harder to work out too. If there is some hardware event that occured just prior to the crash, that too may be a clue. There is a lot of experience on this forum, but you have to give us something to go on.
Indeed, there’s not much too go on. I wend to bed, SGP was running. The next morning SGP was not running any longer - but PHD2 and other apps I use for imaging were all up and going. Nothing in the event log regarding SGP.
I looked at the attached log file and could find no clue as to why SGP crashed, was just hoping someone else could. Crashing (when an app closes unexpectedly) is bad - and leaving no trace of the/a problem is worse. SGP should integrate some global exception handler to at least log what happened.
As it stands right now, SGP is now I can’t fully trust SGP. I’ve been using it for since last Spring. Generally worked well. But device handling/fault tolerance could be much improved.
Thanks, I haven’t seen a sink without trace before with SGP (or any of my other astro apps that I can recall). I have had a few lock-ups (especially with MDL) or an exception report that you have to dismiss. I’m guessing now, but it kinda indicates a unique event triggered by your particular system setup that is not caught by SGP.
The other thing we have not looked at are the ASCOM log files for your devices. Evidence from those may narrow the search.
Check to see if there was a windows update installed around that time. Tuesdays between midnight and 2am are pretty much prime time for windows update (one was installed on my observatory system this Tuesday as well)
Pretty suspect to have no crash indication inside of the SGP log.
Thanks,
Jared
I just experienced my second crash while using 3.0.2.94 early this morning. When I got up, I found SGP was no longer running. It was not even open. The PC was still running PHD2 and faithfully guiding. Gemini Telescope was still running too so it probably was not a PC reboot. My log file (attached) shows two very suspicious entries about 800ms prior to the last SGP logfile entry:
[10/08/18 00:19:42.093][DEBUG] [Environment Device Thread] GlobalExceptionHandler caught : Collection was modified; enumeration operation may not execute.
[10/08/18 00:19:42.093][DEBUG] [Environment Device Thread] Runtime terminating: True
My environment device was WundergroundObservingConditions.
I looked at nightfly’s log and found exactly the same entries about 700ms prior to that log terminating.
Here is my logfile, somewhat shortened to allow upload.
sg_logfile_20181007193751_shortened.txt (969.2 KB)
Phil
I did switch to using Wundergroud… for environment data late this summer…