Bug: not aborting

Bug report (latest beta as of this writing): I decided to take new flats tonight as I had some time before dark, so added flats to a flat target. (When I started the sequence, I got the warning about the rotation not being checked for some targets – I’m guessing this is intentional even though the targets aren’t checked.)

Anyway, the sequence was waiting for the camera to cool down (which is fine, though debatable for flats) so I decided to hit the pause sequence button to do other stuff. I was hoping the sequence would abort right away instead of waiting for camera cooldown, but not only did SGP wait for the camera to cool down, it kept going with all the flat events …it eventually hit the pause event after event 4 and then it kept going, with the “aborting” greyed out but never did actually abort.

Apologies for the low-color screenshot, all I could do.

sg_logfile_20151110163026.zip (205.4 KB)

No, that is a bug…

I can see by the screen shot that you are in a failure mode designed to continue capture of calibration events even when the sequence fails. I’m guessing that your abort might have accidentally been interpreted as a failure and then you entered the special mode. I’ll take a look.

Lots of stuff going on in the log. Any chance you can give me a hint with “about this time”?

Apologies, I left that out. It was around 6pm 11/11. I started the sequence around then, just the flats event in the screenshot. I pressed cancel pretty much right away, but let the whole target complete.

Thx. I’ll try and take a look shortly.

No hurry, I haven’t been able to reproduce. One thought that I just had. When I click abort/pause, usually it prompts if you wish to abort the current frame or keep it. I didn’t see that box, but I don’t think that box would appear as the camera wasn’t exposing and was only cooling down. I’ll try to repro tonight by starting a bogus sequence while the camera is cooling…

I did find a bug that caused some of the behavior you saw. Your abort during camera cool down was indeed interpreted as an error and the sequence restarted in calibration frame mode. What I don’t understand is why, when you started the sequence, it picked an inactive target:

[11/11/2015 5:51:26 PM] [DEBUG] [Sequence Thread] * Target ngc7635
[11/11/2015 5:51:26 PM] [DEBUG] [Sequence Thread] -Active: False

[11/11/2015 5:51:26 PM] [DEBUG] [Sequence Thread] ********** Run sequence started **********
[11/11/2015 5:51:26 PM] [DEBUG] [Sequence Thread] DoEventGroupChange: Changing to event group: ngc7635

I am wondering if this is a bug from having SGPro open for such an extended period of time. Like, despite being inactive, SGPro still chose the ngc7635 target because of the built-in “sticky target” behavior. I will need to look at this a little. This behavior is a bit more complex (compounding issues).