I Had exactly the same last night while running a simulated sequence, I’m waiting for Ken to get the 2.5.0.4 build back up & running again as he has added much more [DEBUG] code in an effort to lock this thing down. My feeling is that the cause is exactly the same thing as the freezes when pausing/aborting a sequence but just happening under different circumstances.
Ran a simulated sequence just earlier and it all completed fine…This is a slippery little sucker for sure
I wouldn’t be so sure about this… Right now, they look like 2 distinct issues. One is during the save of FITS files to disk, the other is when the call to Park does not seem to return control to the sequence.
Ditto. Almost exact same details. In my case the status bar says “Parking telescope”, but the mount stopped tracking and stays in its final position (Gemini 2 mount). Also the dome does not close, which I have selected. This has been happening for several months with all versions during that time frame. I have lots of logs if you need any more.
A small detail I noticed last night when it finishes the sequence and puts up the Parking telescope, the traveling progress bar initially was indicating progress, and then stopped. Also, when I finally give up waiting and terminate in Task Manager, SGP is consuming a lot of cpu.
However, I am usually running a second copy of SGP to simultaneously image on a second telescope. That version, which has no guider and no mount and no dome connected never hangs.
While I appreciate the responses pointing to issues here (because it helps us understand it is likely a real issue and not specific to someone’s environment), please include logs with “me too” posts. They are very important in establishing patterns. This is like a puzzle and the more clues we have, the more likely we are to find the issue.
@Andy (and others familiar with UI based software development). I can understand that there might be conditions in which calling out to devices might be problematic and never return control to the sequence (not saying this is happening, just saying I understand that it can). What boggles the mind is that SGPro is architected to remain response under almost all conditions. If the sequence thread locks, the UI (main) thread should still be responsive. I am a bit baffled as to what kind of hang can cause all threads in the app to lock.
OK. FWIW… I am not in a position to make a full release with an installer right now, but I can provide a an exe file for you. If you are inclined to continue the battle against these 2 sinister issues, we will be forever grateful:
Whole app lock / hang during end of sequence options (usually after park is called)
Whole app lock / hang during the code section that writes FITS files to disk.
To use (if you are interested), simply download the new exe file and replace the current EXE file in your Program Files (x86) directory. The issue where it would clobber older sequences is no longer present in this version so you can go back to using whatever method creates these issues for you (most quickly).
It looks pretty clear that the mount took about 34 seconds to park, then it seems to hang on the monitoring event. This is the last time we hear from the sequence thread. Looking at this now… I love the irony of a system designed to keep your rig safe actually working to destroy it.
OK… narrowing in on this. Does not seem to be the notification system either. I found a section of the code that will execute in the UI thread when the sequence ends. Still not clear what is happening, but the pieces fit… The sequence thread calls some “end of sequence” code in the sequence thread which then delegates to the UI thread for completion. Better logging coming to try and narrow this down.
Unofficial beta (you need to replace your exe file in the install directory to use this…)
The sequence I started tonight using 2.5.0.5 just finished all scheduled targets and performed exactly as I summarized earlier:
Here is the log (which I think may be very helpful):
Here is what it looked like when the UI quit responding:
After 5 minutes I had to terminate with Task Manager. Using 4% cpu.
As you can see from the video camera, the mount is not moving, still pointing out the shutter. Top video image, white square, points directly down the RC12.
Exact same results as with 2.5.0.5. However log ends very differently. Lots of Focuser errors because my focuser disconnected, a persistent issue I have been having with my 3 RigelSys focusers. I will put up another log tomorrow that should not have a focuser issue.
I would put up another pic of the screen, but it looks identical to the one in prior post. (same target)
I can also confirm that the crash that occurred when Pausing or Aborting an image appears to be fixed. Working fine for me to abort an image.
Same. I have logs if you need it. In my case, it parks the mount, closes my flip flat, and after that it freezes. I have to kill it with task manager to get it to stop.
Ken,
Look at the thread you started ref the 2.5.0.6 release on the main forum home page, might have what your looking for there with all logs from 2.5.0.6 for the end of sequence freeze
@jmacon Thx for the logs. The one from 2.5.0.5 looks like I expect. I’m not sure what to make of the one from 2.5.0.6. This one truly did lock in the attempt to park the mount. That said, the logs indicate that the mount was disconnected even before attempting to park. What is further confusing me is that maybe I don’t understand your setup. Why is the focuser reporting that the mount is disconnected? Are they dependent on one another in some way?
[1/28/2016 11:09:25 PM] [DEBUG] [CP Update Thread] ASCOM Focuser: Error in GetCurrentPosition. : The scope is not connected
Notice that the error reported is about the scope… but that it is the focuser complaining about it.
Mystery to me too. The focuser is not connected to the scope in any way. Nothing about the scope is in its setup.
I will get you a clean log first thing tonight where it tries to do a normal ending and the focuser is behaving.
SGPro 2.5.0.7 beta is released. I am still unable to produce any hang situation so I am still reliant on folks running SGPro to this failure and sharing the logs. Thx for all the help.
I was hoping to get a short clean failure last night or tonight, but the winter snow storm is upon me.
Last night I did a short sweet run with no guider, dome closed but tracking, SBIG and focuser attached. In other words, all equipment connected except the guider, since I can’t center without a guider.
Ran perfectly to the very end. Except it still did not move the mount or dome back to home when it was done.
But no hangs and no errors.
I have the log if you want it.
First clear night looks to be Wednesday, when I will run the same process with all equipment attached.
