Hi Willem Jan,
good to hear that my intuition was right. I think the solution as I mentioned is quite straight forward so we will fix it with the next release. The current one is already in the final stages so it will take 2 months until it will be fixed in a stable version.

Regarding your idea with the toggles, that sounds reasonable. I have to think about it whether this can at least be visualized. Currently, we are in a refactoring mode and are very reluctant touching the scheduler until the refactoring is through.

And regarding the limit: it's necessary to leave the edit field, you don't have to flip the MF enabling. At least it should...

All the best
Wolfgang

Read More...

Hi Willem Jan,
could it be that you had non-guiding dithering on first, but turned it off at a later stage? I found in the log that you had a dithering error at 20:28:17, but after this no dithering happened until the meridian flip started at 23:27:48.

If this is the case, then we really have an edge case here, since after the dithering error at 20:28:17 the guiding state remains in state "Dithering error".

When a meridian flip is detected to be necessary EKOS evaluates whether guiding is on at this stage. And this is not that easy, since at this stage it could be that some guiding error stopped guiding. If the non-guiding dithering option is set at that point of time, guiding is considered to be off.

The mean thing in your case: the previous dithering created a guiding state that leads to the conclusion that guiding should run after the meridian flip. If you then turn the non-guiding dither option off, this last guiding state is taken as an indication that guiding should run after the meridian flip - leading to the problem that you observed.

But this explanation relies on the hypothesis that you changed the non-guiding dither option from ON to OFF during the session.

@Jasem: maybe we should consider clearing the guiding state when this option is turned off to avoid such a situation.

HTH
Wolfgang

Read More...

I‘ll check it asap. Do you have the logs at hand, please?

Wolfgang

Read More...

Ah, you're right. It seems like there do not exist any optical trains for your profile. Is the button for editing optical trains active? That's the pencil right to the empty drop down list on the top.

Read More...

Could you please share a screen shot? Maybe we have different views what "all" means :-)

Read More...

Many thanks, Peter. Seems like the problem is fixed in the newer versions.

Read More...

Yes, that was the test I did as well. Re you also using 3.6.1?

If yes, could you please check in your log if you find entries like this:
[code [2022-11-25T10:57:45.205 GMT CRIT ][ ] - QWaylandShmBuffer: mmap failed (Invalid argument)][/code]

Read More...

Folks, please keep in mind that I didn't say it was fixed. I tested it with the latest 3.6.2 version and could not reproduce the problem. Since we reworked the filter manager integration, I'm hoping this has been fixed then.

But I would really appreciate if somebody could verify this.

Cheers
Wolfgang

Read More...

The simplest way would indeed be copying the AUX1 function and creating a second focuser on AUX2. Would that work for you?

Read More...

Try switching back and forth between two optical trains. This behaviour comes from remainings of intermediary versions. We couldn’t drill the origin down, since it happens exactly once.

HTH
Wolfgang

Read More...

Maybe you should consider switching to Ubuntu or Debian.

Read More...