End of sequence abort

There is no win here. SGP does not know the conditions that cause a startup to fail, or what you want to do in the circumstances. If it did do something clever, you can bet that someone else will want something else. For instance, a failed plate solve or autofocus could mean that you have cloud and it should give up for the night… or simply that your settings are too far off for them to work. Either way, it needs a manual adjustment… but SGP does not know which.

I think there is confusion about what is termed ‘optional’. It is an option, because you can enable or disable it. You tend to adjust to its way of working- but the ‘end of sequence options’ dialog is the only cop-out that I know.
These options are scattered in the control panel, sequencer and options menu. One might argue that all these ‘options’ could be located in one place…

Ok - I’m confused. You state that these are all the things you want done once a sequence has completed - so are you saying that you have all those optional actions enabled in your sequence?

If so, then when SGP determines it needs to end the sequence, those actions will be executed, right?

If you happen to be sitting at your pc when the end sequence countdown dialog appears, then you have 10 seconds to override and prevent the end of sequence events running, but otherwise SGP will execute those optional steps (because you have explicitly enabled them and told it to do so).

I think what you are looking for is an option for SGP to pause rather than end the sequence if it hits a “fatal” problem, and to sit there and wait for user intervention? This would be equivalent to manually hitting the pause button while a sequence is running - none of the end of sequence actions are executed, and the user must then manually restart the sequence (or abort it) themselves.

If this is the behavior you want then you should make a new feature request and see if the devs are interested in implementing it.

Yes, of course. Please read my original statement: the error occurs during the initial steps of a sequence - at a very specific point:

  1. I start the sequence
  2. the mount slews to the target
  3. Centering beginns by using plate solving - ok up to now?
  4. I notice that for some reason plate solve is not finding the target (maybe the scope is out of focus - happens to me occasionally or the the field of view has been set incorrectly, because I’m using a new camera etc.)
  5. I decide that I don’t want the plate solve to continue ad infinitum and I press the cancel button (what would you do in this situation?)
  6. The Message pops up say that the I need to uncheck the box or the optiional end of sequence steps will run.
  7. I don’t want them to run, so I can go back to the sequence correct whatever is wrong and resume/restart the sequence - which then goes throoug the steps 1 to 3 above and now centers correctly.

BUT: instead of just closing the message after I’ve unchecked the box, SGP just ignores the my input and continues with the optional end of sequence steps. I’m not expecting SGP to do anything magical. All it needs to do, is to register the fact that the box has been unchecked and close the message and wait for me to do the next step. Where’s the problem? You’re all thinking way to complicated.
It’s a simple stop or go issue. I tel SGP to stop and it still goes, so my input is either not being examined or it’s just being ignored.

Anyway, I give up! Thanks for the support and I’ll just have to be more carefull about having all the conditions just right before starting a sequence in future or start looking for some other software.

Well that just sounds like a bug :). Have you submitted an issue with the accompanying log file?

fwiw: I have also had to manually interrupt a sequence at various points, including during plate solving, and have unchecked the end of sequence events, and it has done the right thing (i.e. camera was not warmed up, mount did not park).

Are you running the latest SQP release?

Agree with everything thus far, however if SGP “pauses” the sequence and waits for intervention, IMO this does not pause the tracking. Depending upon which side of the pier the scope is on, “pausing” the sequence could cause meridian flip to fail as well. Many nights I take a snooze and due to hearing loss I don’t always hear the alert messages to my phone. Again not knowing what the pause would entail, I feel better ruining a night of images verses equipment crashing into the pier. Maybe I am missing the point I just wanted to add this.

Thanks

CL

Hm, I must be missing something here to reproduce this (I’m using 4.0). When I attempt to reproduce this and abort the plate solve during an Auto Center attempt during a target change, or sequence start, I get the behavior you’re desiring. Basically SGP just stops what it’s doing…I don’t even get the “Sequence Aborted” dialog asking if I want to run the End of Sequence options. Everything just stops … scope is where it was, camera is not warming up.

Jared

Thanks Jared. My impression is, that this only happens under certain circumstances, which I tried to repeat yesterday. No success.
So, I think we can close this issue for now. I’ll open a new ticket if it happens again.

Allen

Might it be the difference between a user abort and a fail condition determined by SGP?

Last night it happened twice. See attached link to the logfile.

https://1drv.ms/u/s!AiJtNazoGA2vhoJKJ7qx-r0qY4kuPg?e=CnSGry

At around 23:15 hours - scope successfully slewed to the target but the the ASTAP plate solve failed and SGP went into recovery mode. I then aborted the recovery which then brought up the message where I can uncheck the “End of Sequence actions”, which I do. SGP then proceeds to disconnect all equipment.
I manually reconnect the equipment and restar the sequence, with the same result. ASTAP fails, recovery mode, abort Recovery, message pops up, I uncheck the field and all equipment is disconnected.

I can’t see anything in the Log that the plate solve failed, but that might just be, that I don’t know what to look for.

Thanks for your support.

The plate solve failure (well, failed to auto-center after successful plate solve) is there in the logs, and once it fails SGP is running the end of sequence actions:

[06/13/21 23:17:53.547][DEBUG][Sequence Thread][SQ;] Aborting sequence: Auto center failed
[06/13/21 23:17:53.547][DEBUG][Sequence Thread][SQ;] Set sequence abort
[06/13/21 23:17:53.617][DEBUG][Sequence Thread][SQ;] DoEventGroupChange: Complete
[06/13/21 23:17:53.625][DEBUG][Sequence Thread][SQ;] Cannot start seqeunce. EventGroupChange failed.
[06/13/21 23:17:53.625][DEBUG][Sequence Thread][SQ;] Set sequence abort
[06/13/21 23:17:53.629][DEBUG][Sequence Thread][SQ;] ********* Run post sequence *********
[06/13/21 23:17:53.629][DEBUG][Sequence Thread][SQ;] Recovery failure failed or was after target end time, moving to next target…
[06/13/21 23:17:53.629][DEBUG][Sequence Thread][SQ;] Finding next active group…
[06/13/21 23:17:53.629][DEBUG][Sequence Thread][SQ;] There are no valid targets remaining, ending sequence.
[06/13/21 23:17:53.629][DEBUG][Sequence Thread][SQ;] SGPro capture cal frame mode is OFF…
[06/13/21 23:17:53.632][DEBUG][Sequence Thread][SQ;] Clearing timed monitoring events…
[06/13/21 23:17:53.632][DEBUG][Sequence Thread][SQ;] Checking RunEndOfSequenceEquipmentOptions, force = False
[06/13/21 23:17:53.632][DEBUG][Sequence Thread][SQ;] In RunEndOfSequenceEquipmentOptions
[06/13/21 23:17:53.633][DEBUG][Main Thread][SQ;] Adding sequence level notification: Warming the CCD…
[06/13/21 23:17:53.636][DEBUG][Sequence Thread][SQ;] Sending Notification: Status - Warming the CCD…

You’re sure that the “Run end of sequence options” is disabled when you abort the sequence?

Looking more closely at the logs, it seems to suggest that the flag to force end of sequence options is “false” and so shouldn’t run, but then immediately enters end of sequence options execution… a bug?

Yeah, I’m starting to wonder if there is a particular state of “Restart on Unsafe” being enabled and something else failing that we’re getting into here. Not 100% certain at the moment what is causing it.

Jared