Strange Happenings in the Dome

Sequence Generator
1

Hey all,
In the near future I am looking to install a Domed observatory in my new back yard so for the moment I thought it a good idea to have a play with the Observatory simulator to get my head around how that side of things work. Although most trials seemed to go fine, one test sequence appeared to show a problem so I am attaching the SGP Log along with my saved sequence file.

Sequence: Dropbox - M45_X.sgf - Simplify your life

SGP Log: Dropbox - sg_logfile_20191104120433.txt - Simplify your life

So my sequence is just all simulators and the Target is M45 which, had this been a real sequence, was set to fire up at 22:00:00 this evening and finish at 00:30:00. I actually forgot I had checked the time constraints on this sequence which led to the issue and a few questions ref the log.

The Issue: I ran this sequence a little after midday today so it would be around 10 hours until the sequence fires up. What happens though which is a bit scary is that SGP opens the dome and then goes into a wait state waiting for the fire up at 22:00 tonightā€¦Realllllllly ?..The dome is going to stay open for nearly 10 hours ? ? ? ? Surely the dome should have stayed closed until 22:00 !

So, I aborted the sequence and chose abort and checked run end of sequence events

The Log:

12:07:13 - Dome is opened

12:07:37 - Waiting for start time 04/11/1019 22:00:00

Surely the dome should not open until the 22:00:00 has been reached

12:09:14 - Attempting to abort exposure

How can you abort an exposure when the sequence has not even started

12:09:13 - User requests Sequence Abort

The obvious thing to do under the circumstances

12:09:14 - ASCOM Camera attempting to abort exposure
12:13:14 - Camera times out

12:17:** - Finally aborts sequence and closes the observatory shutter and stops

Between user requested Abort at 12:09:13 and 12:17 SGP showed ā€˜Abortingā€™ on the Sequence module but greyed out, SGP ā€˜APPEAREDā€™ to be unresponsive although I did confirm it was not by moving the focuser and turning on and off cooling as seen in the log.

Why did the observatoryā€™s shutter open when the sequence was not even due to begin for 10 hours

Why did it take 8 mins to actually abort the sequence trying to stop an exposure which was not even happening and leaving me thinking there was some sort of freeze going on.

Hoping for a little clarity here

Many Thanks
Paul

2

Just a bug

Iā€™ll look

Just beta life

1 Like
3

I may need to add more logging for this one. We have code that will not allow an abort to be requested if the camera state is ā€œidleā€. Since yours went ahead with the request, it reported some state other than idle (either exposing, downloading, error, reading, or waiting). I am not sure what ā€œwaitingā€ is actually

4

Thanks Ken,

Ref: Attempting to Abort exposure

The camera connected was just the Camera Simulator V2, maybe itā€™s something to do with that, tomorrow, iā€™ll hook out my normal imaging camera and see if the same thing happens with that.

<----- Loves Beta Life :crazy_face:

Regards
Paul

5

I have added code to protect against a long wait for the camera to abort when it clearly will never abortā€¦ itā€™s not so reliant on camera state and more so on SGPro state.

6

Hey Ken,
Build .341 solves the Dome shutter issueā€¦Thanks

Just ran the same M45_X sequence above and performed a full Abort while SGP is waiting for the start time to arrive for your reference:

Huge amount of lines in the log saying the same thing and still takes a long time to abort

The following box appears about half way through the abort sequence too, once the time
out finishes the information bar at the bottom says Sequence Aborted but the wait continues for a while longer.

Abort

Regards
Paul

7

I had this same behavior last night on .339. Fortunately I was monitoring and saved the sequence the first time. This same notification came up. I cancelled it, restarted the sequence. I left it running and went to bed. Earlier in the night while setting up I had the long delay after attempting to abort also - ended up just closing SGP and restarting fresh.

When the Iris Nebula sequence finished and attempted to start the Horsehead, the camera timed out and the sequence aborted. This is really frustrating and losing half a night of imaging again needs a solution.

Iā€™m using the QHY600 for imaging now. Is it possible that the large file sizes it generates - 120MB - could be a part of the issue?

NINA works great for the file sizes since it is x64. Is it possible to use SGP for dome control and NINA for sequencing? NINA doesnā€™t have dome control now. I hope that I can stay with a fully integrated SGP.

Thanks

8

You should probably not be using beta software.

I donā€™t think so

I am not sure how the architecture of an application has any bearing on writing a 120 mb file. For what itā€™s worth, we have a 64 bit SGPro almost ready to goā€¦ It will be a quick 3.2 release.

No

9

The good news is that the new code works (as evidenced by the fact that the log file told us so thousands of times). Bad news being, I forgot to actually do something when SGPro detects this situation. It has been fixed.

1 Like
10

LMAO

Nice one Ken, thanks for sorting it out

Paul

11

Ref .343 build - Aborting Issueā€¦

Cracking resolution Ken, aborting has never worked so good and in every situation
I could think of and try out.

My Compliments
Paul