BETA 4.1.0.730 - early EndOfSequence?

Sequence Generator
1

I had a failed run last night - my sequence has 9 “targets” most of which have multiple “events”: “Start_Up”, “HIP 3881”, “M31”, “Asellus Primus”, “M101”, “Flats”, “Bias”, “Darks”, “Shut_Down”

M31 had an end time set at 01:16.

  1. All ran as planned until 01:03:52 when the guider lost the guide star
  2. Recovery kicked in, did a successful plate solve but PHD struggled to lock onto a guide star (assume a passing cloud - although my weather station said sky was clear)
  3. “Recovery Sequence Thread” realised it was passed the end time set for M31
  4. SGPro then started EndOfSequence shutdown even though there were more Targets to action
  5. SGpro EndOfSequence disconnected from PHD and parked the scope
  6. My dome is slaved to the scope so started following the scope to its park position
  7. SGPro then looked for the next Target, found “Asellus Primus”, but couldn’t start the events … because PHD was not connected …
  8. SGPro then ran EndOfSequence again - PHD already disconnected, scope parked so next was camera warm up and SGPro stops.

The log shows “Checking RunEndOfSequenceEquipmentOptions, force = True” - but surely this should only have run after all Targets were actioned?

SGPro tried to start the next target, but couldn’t because it had already run some EoS and disconnected PHD?

Log snippet:

20/01/2022 01:03:52.159 Successfully imaged M31 until guide star lost
20/01/2022 01:03:52.348 Restarting frame " Restarting Current frame because: Distance was 100.0 pixels"
20/01/2022 01:03:52.510 Goes into recovery
20/01/2022 01:06:09.610 Performs successful plate solve
20/01/2022 01:06:09.800 Recovery: Centering is successful…
20/01/2022 01:06:09.802 PHD2: Auto Resume
20/01/2022 01:06:14.411 PHD2: Attempting to start guiding, waiting for PHD2 settle done message…
20/01/2022 01:07:41.695 Error: Guide star reported as lost!
20/01/2022 01:13:13.688 Guide star lost, no recovery required…
20/01/2022 01:13:37.623 Adding sequence level notification: (M31-M101-WO-Ha) Failure while integrating M31; Event 4; Frame 9 for 600s. Image has not downloaded in alloted time period.
20/01/2022 01:16:14.760 Time Check: Cannot complete current request prior to the target end time…
20/01/2022 01:16:14.760 Sequence recovery aborted due to target / sequence end time…
20/01/2022 01:16:15.361 Checking RunEndOfSequenceEquipmentOptions, force = True
20/01/2022 01:16:53.345 Adding sequence level notification: Disconnecting auto guider equipment…
20/01/2022 01:16:53.355 Parking telescope…

SGPro moves to next target

20/01/2022 01:16:53.920 Adding sequence level notification: Starting target “Asellus Primus”…
20/01/2022 01:16:54.435 Adding sequence level notification: Attempting to auto-start the guider…
20/01/2022 01:16:54.865 PHD2: Cannot start guiding, PHD2 says equipment is not connected…
20/01/2022 01:16:54.889 Adding sequence level notification: Sequence was aborted because the auto guider is required, but not running.
20/01/2022 01:16:54.987 AbortSignal “Global Abort Signal” set to True by Sequencer.SetSequenceAbort
20/01/2022 01:16:55.816 Checking RunEndOfSequenceEquipmentOptions, force = True

2
3

For better or worse, this condition (target end time) is considered as a recovery failure and you’ll need to provide permission to continue running the next target despite that failure.

image

4

Thanks @Ken, I set the attempt to move to next target option … naturally the same scenario didn’t occur again (target end time during recovery).

I had a different issue - a worm gear fell off my dome rotator gear box … which meant the scope kept moving but saw less and less of the sky as the dome didn’t track.

The sequence step that got stuck was autofocus. Autofocus tried and failed for 50 minutes - should there be a recovery action for autofocus taking too long?

It was resolved by me waking at 4:30 in the morning and heard the dome motor going continuously…and me repairing the gear box in my pajamas (only -6 degC…).

I do note that there were 151,886 rows in the sg_logfile of:

|DEBUG|Unknown|SQ;AF;| AbortSignal AutoFocusAbortSignal set to False by AutoFocuser.ProgressUpdateThreadFunc[]
|DEBUG|Unknown|SQ;AF;| AbortSignal - ClearAbortSignal for AutoFocusAbortSignal already inactive…

This rather clogs the log files?

Many Thanks, Martin

5

Yes, but this is a feature addition for a near future version of SGPro 4. We will be devoting a good amount of energy to making the auto focus data capture routine more robust. That said, SGPro will emit an emergency error notification if AF times out. This notification can be sent to email, your phone as a text message or can ring a claxon alarm loudly if you have GNS. If you are inclined you can even monitor a text file and create your own alarms. See “timed errors” here:

https://help.sequencegeneratorpro.com/NotificationSystem1.html

In version 4.1 though, I will investigate why it didn’t quit when it was lost, but the recovery part will be later.