×

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
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: 1187
  • 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: 1187
  • 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.

  • Posts: 1119
  • Thank you received: 182
Thanks, Wolfgang! So that must be happening to other users, too. Are they not noticing this?

Last question: Would setting "Remember Job Progress" prevent this from happening? I.e. will the Scheduler checking the status of prior captures overcome the "misconception"?

Jo
3 years 6 months ago #61331

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

  • Posts: 1187
  • Thank you received: 370
As far as I understand it, theoretically it could happen with all mounts. With my mount for example, I've never experienced it. But from time to time I experience it during alignment, but there it does not cause any problems other that solving needs to be restarted - which happens automatically.

Regarding "Remember Job Progress": sure, that helps, because I think at the end it's not that super important in which sequence exactly we capture the frames as long as we have the expected number of them. I personally have it always selected, because it enables shooting the same target over several nights until I have enough frames.

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

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

  • Posts: 1009
  • Thank you received: 133

Ah, I think I've seen that, too, on my CEM60EC. Sometimes, in the refinement step, capture of the control frame fails, claiming the mount is slewing. So could it be that there the previous state (slew) is still reported, although the mount is already tracking again?
During flip, I think I don't have seen that so far....
3 years 6 months ago #61353

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

Time to create page: 0.633 seconds