The topic I added earlier “Target Settings List/Editor” lists all the targets I imaged last night.
A sequence problem occurred after #1 and #2 finished running and #3 should have started. #1 and #2 ran perfectly within the allowed Start/End times.
However, after #2 finished, instead of running #3 which was next in line, it reverted back to #1, which it ran for the next 1.7 hours (from 10:24pm to 12:13am) which allowed it to finish the total of 3 hours of frames that were set in the events. After finishing the remaining frames in #1, it then ran Target #3 from 12:19am to 12:36am.
The rest of the targets ran perfectly, until the last target which quit with a bogus Unsafe condition at 5:07:05am. Or so my graph of clouds and weather using the AAG_CloudWatcher tells me. Perfectly clear all night long. I can post the weather log if you would like.
Target #1: IC1396 Elephant,…Start: 7:30pm, End: 9:00pm (a total of 1.5 hours) Frame/Event counts add up to total time of 3 hrs, if there were no time limits.
Target #2: LBN529 Cave,…Start: 9:00pm, End: 10:10pm (a total of 1.2 hours) Frame/Event counts add up to total time of 3 hrs, if there were no time limits.
Target #3: NGC7000 North A…Start: 10:10pm, End: 12:40am (a total of 2.5 hours) Frame/Event counts add up to total time of 3 hrs, if there were no time limits.
Running 2.4.3.12. No target swapping was done after Target #2 started running.
Log: Dropbox - Error
A closely related problem which has happened many times with previous 2.4.3.x releases is that the sequencing rules do not honor the Start/End times if you run the sequence later in the night and 1 or more of the initial targets are already past their End time. They get run even though the time is past the set End time. If you need a log for this issue, I will do a new run to confirm this is still an issue.
Well… this is not a bug. I’m not saying it’s right, but it is working the way we designed it. I have been digging through old posts, but I cannot find the old conversations around which this decision was made. It was made in Jul of 2014 so I am am having trouble trying to recall why we did this…
The decision was essentially to make ALL end times in the future. There was a big push for getting rid of end times that had dates on them. Once we removed them, we had to infer a date. I remember the original implementation essentially said an end time was in the past if it was within the last 12 hours and in the future of the time is in the next 12 hours. Then there was a bunch of conversation that led to the new implementation where all end times are in the future.
I can’t think of the reason why… but I just have this feeling that reverting back to the other way will end up making another set of people unhappy that do things a different way.
I think @Andy, @mads0100 and @joelshort participated pretty heavily in this conversation. Do you guys remember why end time interpreted as:
Time in the last 12 hours is past end time and in the next 12 hours is before end time was a bad idea (based on sequence start time)?
I can’t remember what I did last week, let alone last year
I remember that there was a clear reason why that decision was made…but I can’t remember what that clear reason was either.
Would it make any sense to use military time (24hour vs 12hr) instead?
In any event, if @jmacon had simply not designated start times for targets 2+ and only had end times for those targets, would the problem still have happened?
So Target 1 - end at 9:00pm (21:00)
Target 2 - end at 10:10pm (22:10)
Target 3 - end at 12:40am (00:40)
I’ve recently been doing this myself (no start times, just end times for targets) and have done so without any problems, but I also wasn’t doing such short durations of 1-1.5 hours on a target.
I think I remember Chris had a scenario where he wanted to start his SGP session in the early AM before he went off to work. Before the fix, if he started the sequence at 5AM today, a 6PM start time would have been interpreted as 6PM yesterday and started immediately.
Andy
I think that would’ve been a reason to keep dates That currently doesn’t work. I can’t remember where the swap happens but I know I’ve set it at 3-4am and came back from flying around 1-2am and not had it running due to the date/time issue.
I think people didn’t like having to change the date each night. It was time consuming and that was where the request came from. It sounded liked a good idea at the time
This makes no difference… .time is time. We should be using whatever time system your region is set to…
Yes. This issues has nothing to do with start times and everything to do with the fact that the sequence was on the second target, hit the end time and started looking for more work. It was past 9:00 pm so target 1 seemed like an eligible candidate since its end time is 9:00 pm tomorrow night.
Yes, I remember this. This was a start time issue that also fought the same 12 boundary battle for inferred dates.
If nobody has any compelling reasons, I will likely modify end times to work such that any time of day 12 hours before now is a past end time and any time of day that will occur 12 from now will be a future end time. This will eliminate the issues that @jmacon is seeing.
Looks good to me. Keeps all the times in the day they were set up to be in. A set of targets is intended to run in the order listed. If the targets contain start/end times, they should presumably be sequential from the 1st target in the early evening dark, to the last target prior to sunrise, and this logically should not change during the course of the night.
That currently doesn’t work. I can’t remember where the swap happens but I know I’ve set it at 3-4am and came back from flying around 1-2am and not had it running due to the date/time issue.