Unconditional end of sequence options in 2.5.2.6

it looks to me like end of sequence options are unconditionally running in 2.5.2.6. tonight i aborted a sequence while it was waiting for the start time of the next target to arrive. i made sure that ‘run end of sequence options’ was unticked in the confirmation dialog box. when i started the sequence back up again i was greeted with the “can’t start a sequence when the TEC is warming up” dialog and sure enough i find in the control panel that the TEC is warming up. in addition the mount has stopped tracking and guiding has stopped. i’m pretty sure those 3 things are the totality of my end of sequence options.

and now that i’m thinking about it, this same thing happened last night as well.

i will post the log tomorrow morning since i’m in the middle of a run.

thanks

rob

Hi Rob,

This is happening to me too… but not every time I abort a sequence… a bit erratic… I also make sure the end of sequence box is unticked but still I face this from time to time… glad you mentioned it…

I’m on version 2.5.0.23 by the way.

hi sedat, yes this has happened to me prior to this version but for some reason it seems very consistent now.

here is the zipped logfile: https://goo.gl/azdrTh

thanks

rob

I’m not sure on this one. I have tried several different ways to produce this condition (mostly by forcing a condition where the sequence is waiting to start a target and then manually aborting. Everything works as expected in this case…

From my test:

[11/19/2016 7:32:04 PM] [DEBUG] [Main Thread] User requested sequence abort…
[11/19/2016 7:32:05 PM] [DEBUG] [Sequence Thread] Checking RunEndOfSequenceEquipmentOptions, force = False

From your sequence:

[11/17/2016 10:38:07 PM] [DEBUG] [Main Thread] User requested sequence abort…
[11/17/2016 10:38:11 PM] [DEBUG] [Sequence Thread] Checking RunEndOfSequenceEquipmentOptions, force = True

I have added some additional trace code to try and figure out why your end of sequence options are being forced. Maybe you can share your sequence and that might shed some light on the issue (maybe some setting I don’t have on)

ok i can upload the sequence… the check box seems to be unchecked by default and for sure i’m not checking it. 99.999% of the time i do not want to run the end of sequence options when i click abort, so unless i had a stroke or something i’m not sure why i would have checked the box :slight_smile:

rob

Right… I 100% believe this which is why I am looking for what produced that override. Maybe something specific to your sequence?

sorry for the delay - we had 2 days of rain and since my SGP computer lives on the mount, i can’t start it up if the weather is bad. here’s a link to a zipfile containing the sequence i’m using.

some possible related issues here are:

  1. as of late, sometimes when i cold boot, windows does not see my STT-8300M. this usually results in my doing a soft power-off followed by another cold boot. in this case i usually let SGP load the default sequence and then try to connect the camera, just to save some time. if the connection to the camera is successful (it always is), i then tell SGP to load the sequence attached here. i use “cool down on connect camera”, and i find that sometimes the cooler stops cooling down due to this sequence of events, so i have to go in to the camera tab and tell the camera to cool down after the sequence is loaded and i’ve clicked on “start” (i get the warning dialog that the temperature is not at the setpoint).

  2. even if the above “missing camera” problem does not happen, i generally start the sequence before the camera has reached the temperature setpoint. this is because almost always there’s a start time constraint on the first target which is far enough in the future that the camera will be cooled down by the time it starts, and even if it isn’t it’s not a big deal if the focus or pointing exposures take place while the camera is still warming up. this is all to say that even under normal circumstances i see the temperature warning dialog.

  3. before starting the sequence for the night, i generally change the start/end times of the first target to compensate for the latest astronomical twilight time and when the target goes behind the trees. i’ll then increase the max frame counts for each filter, if necessary. sometimes i’ll start the sequence and then when SGP gets to the first light frame, i’ll go in and change the start/end times/frame counts for the rest of the sequences that i’m going to run during the night.

not sure if any of those things are relevant, but i just wanted to let you know what happens on a nightly basis when i start SGP.

thanks

rob

https://goo.gl/uu8MFa

OK… wow, this one was tough to find and only conditionally presented itself during periods of wait between targets. I did find and fix it though. It will be out in 2.5.2.8

1 Like

ah - yeah. i should have mentioned that - when a target’s declination puts the camera in line with the west side of the pier, APCC’s meridian limit is set to stop the mount before the camera reaches the meridian to avoid a camera pier crash. unfortunately this is only necessary for some camera rotations, but better safe than sorry.

so that means there are some targets that i have to start only after they have crossed the meridian, like heart500. that usually necessitates a delay between the end of a target going into the trees and the next target. so in addition to the points above, if i happen to be awake when this pause is happening sometimes i will cancel the sequence and then restart it, which is essentially a workaround in itself. when the STT main imager is idle, the guide camera shutter has to actuate each time PhD takes an image and it’s out there clicking and clacking for many minutes unless i stop and restart the sequence.

anyway thanks for fixing that, it does sound like a difficult one to reproduce!!

1 Like