Last target seems to get time changed and sequence goes past global end time

Description

This has now happened two nights in sequence. The last target for me is M101, which I had set to start a few minutes after transit, and I have specified an end time to the whole sequence of 04:30, however for the past two nights, something is happening where it is changing the time of M101 to after 8AM and the sequence is not ending at 04:30 like it should be. If I close SGPro and load it up again, M101 shows the correct time of a few minutes after transit, you can see here from this screenshot, SGPro states it is waiting until 08:07 for M101 target

And you can see here in the sequence that M101 has a start time of 08:07 (Which is wrong)

And you can see I have an end time of 04:30 here:
image

Running “End of Sequence Options” or Aborting the Sequence does nothing as you can see here:

However after a restart of SGPro, the correct start time for M101 is shown as you can see here:

Twice, on two consecutive days

Link to Logs

Useful Info
After the restart, you can see that SGPro sees the correct time during the loading of the sequence

[03/24/20 07:10:41.763][DEBUG][Main Thread][NONE] Populating the form controls…
[03/24/20 07:10:42.901][DEBUG][Main Thread][NONE] M101 - Start time has altitude lock, calculating start time for 86
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] Transit data → nt: 01:50:50; ot: 01:52:10
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] Transit delta → 80 seconds (nt: 1.01:50:50; ot: 1.01:52:10)
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] Adjusting start time by -80 seconds…
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] Current start time 24/03/2020 02:12:00)
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] New start time 24/03/2020 02:10:40)
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] M101 - End time has altitude lock, calculating end time for 44
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] Transit data → nt: 01:50:50; ot: 01:52:10
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] Transit delta → 80 seconds (nt: 1.01:50:50; ot: 1.01:52:10)
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] Adjusting end time by -80 seconds…
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] Current end time 24/03/2020 07:12:00)
[03/24/20 07:10:43.003][DEBUG][Main Thread][NONE] New end time 24/03/2020 07:10:40)

OS: Microsoft Windows 10 Pro
Ver: 3.1.0.457
.NET: 4.8

Same thing happened today

Did not perform anything on M101, but it changed the time to 08:11 which again was past the 04:30

Screenshot from last night showing start time of 02:08

Screenshot from this morning

SGPro is clearly doing something based on the altitude lock

[03/27/20 02:56:07.958][DEBUG][Sequence Thread][SQ;] M101 - Start time has altitude lock, calculating start time for 86
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] Transit data -> nt: 07:52:55; ot: 01:49:10
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] Transit delta -> -21825 seconds (nt: 1.07:52:55; ot: 1.01:49:10)
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] Adjusting start time by 21825 seconds…
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] Current start time 27/03/2020 02:08:00)
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] New start time 27/03/2020 08:11:45)
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] M101 - End time has altitude lock, calculating end time for 44
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] Transit data -> nt: 07:52:55; ot: 01:49:10
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] Transit delta -> -21825 seconds (nt: 1.07:52:55; ot: 1.01:49:10)
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] Adjusting end time by 21825 seconds…
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] Current end time 27/03/2020 07:08:00)
[03/27/20 02:56:08.061][DEBUG][Sequence Thread][SQ;] New end time 27/03/2020 13:11:45)

Yet after a restart the transit time info is correct:

I deleted the target M101 and re-created it yesterday, same thing happened last night, it adjusted the time to 08:11

Well, one of those things is easy to fix (the one where sequence end time is not honored when waiting for target start time). The other will take some time to figure out, but the log snippets you pulled out will definitely help.

1 Like