×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Scheduler restarts Capture Sequence from the beginning after flip

  • 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 5 months ago #61193

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

  • Posts: 985
  • Thank you received: 160
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 5 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 5 months ago by Wolfgang Reissenberger.
3 years 5 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 5 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 5 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 5 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 5 months ago #61331

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

  • Posts: 1185
  • 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 5 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 5 months ago #61353

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

  • Posts: 1185
  • Thank you received: 370
Hi Pit,
no, it's vice versa. Slewing for an alignment step starts with a delay and between the slew request and the slew execution there is a parallel mount status request which receives a "Tracking" as result. Since from an EKOS perspective the slew command comes before the mount status "Tracking", EKOS thinks that the slew is already finished (there is no dedicated "Slew finished" state).

Jasem and I discussed this a while ago and we came to the conclusion that it needs to be resolved on INDI side - which has not happened so far...

HTH
Wolfgang
The following user(s) said Thank You: Jose Corazon, Peter Sütterlin
3 years 5 months ago #61354

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

  • Posts: 1119
  • Thank you received: 182


If this is mount dependent, then CEM25P users should be seeing this. Happened to me now 3 times at least. I am trying to figure out what the parameters are. Slew speed? What else?

Something else happened I cannot explain: In at least 2 instances, 2 luminous filter frame acquisitions were ADDED to my Capture sequence ahead of the rest of the sequence AND THE SEQUENCE FILE WAS SAVED (!). Apparently this was done by the scheduler, certainly not by me, although I have not ruled out the Smurfs yet (or some vast political conspiracy). I deleted the added Lum sequence entries, resaved the file, ascertained that the file had in fact been replaced, only to find the same 2 separate Lum sequence entries added AGAIN the next time I ran the schedule.

I did not report this earlier, lest the casual reader might think I was high on steroids (a common occurrence in my resident country these days), but I swear I wasn't (or on anything else for that matter).

Now how could that happen?

Jo
3 years 5 months ago #61367

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

  • Posts: 309
  • Thank you received: 40
Not saying this is a feature (and sorry it messed up for you), but boy I would love a feature like this!

After the flip restart from the top of the queue. The way I do it is... by adding more items in the queue than I think I'll need. I don't use the Scheduler and maybe if I did it would help.
And since I don't have total faith in the flip or auto-park, I check-in on the progress through the night (it's helped many times). Helps when your older and up many times during the night :whistle:
3 years 5 months ago #61378

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

Time to create page: 0.640 seconds