×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Scheduler restarts Capture Sequence from the beginning after flip

  • Posts: 969
  • Thank you received: 94

Jo, everyone,
Sorry I didn't reply. Haze and full moon prevented any urge.
I'll report back with a log next session.
Cheers
3 years 6 months ago #61040

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
I updated Kstars last night and the problem did not occur again. I don't know if that was a fluke problem or a bug in he previous build, but it is gone now, so disregard.
Jo
3 years 6 months ago #61061

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
Sorry for having to come back to this. This is still occurring, or occurring again with the new build from the source as of yesterday.

Here the sequence, analyze and guidelog files:

File Attachment:

File Name: KstarsLog10052020.zip
File Size:491 KB


The Analyze file shows clearly that the scheduler processed O3 before switching to S2. During the S2 sequence, the meridian flip occurred and after the flip the sequence was restarted with O3, instead of finishing the S2 exposure set. I did NOT have 'Remember job progress' set in the Scheduler. In the past, that was only relevant if I wanted to finish the sequence set between different days without starting at the beginning again. It should not apply to remembering job progress after the meridian flip.

Has anyone else experienced the same bug?

3 years 6 months ago #61142
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 969
  • Thank you received: 94
Hi Jo, everyone

This is with 432b0d356e43035a847d3267d0bdc21ec55a23b0 02 Oct.

I have remember job sequence checked. It looks to be OK, but please tell me otherwise.
Here's the log, .esl and analyze.

drive.google.com/drive/folders/1Q4jrc_Qn...jdZUgTmu?usp=sharing

HTH and clear skies,
Steve
3 years 6 months ago #61150

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
I am running the sequence as well with 'Remember Job Progress' checked tonight. I expect that that will fix it, but that is still not what should be happening. There should be no reset of the Capture Module after the meridian flip. It should continue along the preset sequence.

At least that is what it always did in the past. The philosophy of what 'Remember Job Progress' means may have changed in the meantime, but that does not mean that this is better. The logic why the flip should wipe out the memory of where the capture sequence was before the flip escapes me. It gives up flexibility, as now I have to delete my imaging folder every day if I want to collect additional frames in a filter that had already run.
3 years 6 months ago #61180

Please Log in or Create an account to join the conversation.

  • Posts: 989
  • Thank you received: 161

If I understand it correctly, you could avoid that by activating time stamps being added to your file names.

3 years 6 months ago #61188
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
No. This has nothing to do with the time stamp. I have that set, so I am no losing any images. It's just that it is Groundhog Day for the Scheduler, after the meridian flip. It starts the capture sequence at the beginning, it does not continue as it should be. I.e.my O3 exposures were finished and Capture had advanced to S2 before the flip. After the flip, the Capture module went back and restarted with O3 instead of continuing with S2.

If you want to simulate it, you may have to unselect "remember job progress' in the scheduler tab.
3 years 6 months ago #61193

Please Log in or Create an account to join the conversation.

  • Posts: 989
  • Thank you received: 161
That is understood. I was suggesting time stamps as I suspected you had to "delete [your] imaging folder" in orer to prevent images from being overwritten. I have no clue re scheduler since I never use it. Hope this bug is going to be fixed soon.
3 years 6 months ago #61240

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Jo, could you please post also the EKOS log? In the analyse log there occurs a problem where alignment is started too early. It looks like the root cause is that completion of the meridian flip is not recognized correctly. We see this problem from time to time where a slew command has been sent to the mount and nevertheless the INDI driver reports a TRACKING. This is a concurrency issue with the INDI driver.

When this happens, the mount module thinks that the slew is already completed and the capture module restarts the post flip actions - in your case alignment. But this fails since the mount is still slewing (can be seen in the analyze log) and subsequently capture fails. If this happens and the appropriate recovery option is set the scheduler, the scheduler re-starts the capture sequence - that's why you see no continuation but starting at the beginning of the capture sequence.

But this is slightly speculative, for confirmation I need the EKOS log.

There is no real workaround for this, but on the other hand, the only problem is that capturing does not happen in the exact sequence as it should. But no capture time is lost, no frame gets lost, post-flip actions are executed correctly.

HTH
Wolfgang
The following user(s) said Thank You: Jose Corazon
Last edit: 3 years 6 months ago by Wolfgang Reissenberger.
3 years 6 months ago #61286

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
Hi Wolfgang:

Here the log.

www.dropbox.com/s/weniybyx5688zyb/log_17-48-08.7z?dl=0

Hopefully it is not too extensive.

Thanks for having a look at this. Please let me know any potential fix you can see. I have had this happening three or four times by now. That's with a CEM25P mount. If it is a mount-specific problem, then other people should experience this, too. If not, then it must have something to do with the parameters I have set, because it would make no sense that I am the only one experiencing this otherwise.

Best

Jo
3 years 6 months ago #61309

Please Log in or Create an account to join the conversation.

  • Posts: 33
  • Thank you received: 7
For what it's worth, this bit me last night also. My meridian flip didn't fail, it just didn't happen at all. (Ekos fired the goto off to the mount, but my G-11 Gemini2 decided it was happy just as it was, despite a dozen daytime dry runs going perfectly)

No logs, because I forgot to log to a file, but it appears to be a general problem, not a mount specific issue.

Tonight doesn't look too hopeful, but I will verbose log the mount, scheduler and capture if it stays clear.

J.
3 years 6 months ago #61315

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Hi Jo,
your log shows exactly that behavior that I described above:
[2020-10-06T03:10:29.461 CDT INFO ][     org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "02h 34m 59s" DEC= " 61° 36' 32\""  Hour Angle  "00h 00m 40s"
[2020-10-06T03:10:29.526 CDT DEBG ][     org.kde.kstars.ekos.mount] - Slewing to RA= "02h 34m 59s" DEC= " 61° 36' 32\""
[2020-10-06T03:10:29.530 CDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope sending coords RA: "02h 34m 59s" ( 2.58306 ) DE: " 61° 36' 32\"" ( 61.6091 )
[2020-10-06T03:10:29.531 CDT INFO ][     org.kde.kstars.ekos.mount] - "Meridian flip slew started..."
[2020-10-06T03:10:30.211 CDT DEBG ][     org.kde.kstars.ekos.mount] - Mount status changed from  "Slewing"  to  "Tracking"
[2020-10-06T03:10:30.212 CDT DEBG ][     org.kde.kstars.ekos.mount] - Slew finished, MFStatus  "FLIP_RUNNING"
[2020-10-06T03:10:30.243 CDT WARN ][     org.kde.kstars.ekos.mount] - Meridian flip failed, pier side not changed
[2020-10-06T03:10:30.973 CDT INFO ][   org.kde.kstars.ekos.capture] - "Performing post flip re-alignment..."
[2020-10-06T03:10:30.975 CDT DEBG ][   org.kde.kstars.ekos.capture] - setMeridianFlipStage:  "MF_ALIGNING"
[2020-10-06T03:10:30.976 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Aligning"
[2020-10-06T03:10:31.163 CDT DEBG ][     org.kde.kstars.ekos.mount] - Mount status changed from  "Tracking"  to  "Slewing"
[2020-10-06T03:10:31.191 CDT INFO ][     org.kde.kstars.ekos.guide] - "Mount is moving. Resetting calibration..."
...
Your mount sent a "Tracking" signal after it has received a "Slew" command which created the confusion. This happens sometimes because the EKOS INDI client requests a status request in a separate thread so that the INDI server receives both commands. Since there is a certain delay between the mount receives the "Slew" command until it really starts slewing, it sometimes happens that it receives a status request and answers with "Tracking" although it already prepares the slew.

There is no 100% workaround for this. If you increase the polling period in the INDI settings of your mount, you will reduce the probability that this happens.

And by the way, if there is somebody out there interested in concurrency, resolving this is a challenge :-)

Wolfgang
The following user(s) said Thank You: Jose Corazon
3 years 6 months ago #61330

Please Log in or Create an account to join the conversation.

Time to create page: 0.537 seconds