×

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

Bi-monthly release with minor bug fixes and improvements

[Kstars 3.6.9][INDI][Sesto Senso 2] AF Overscan not working correctly

  • Posts: 32
  • Thank you received: 10
Hi John,
just for fun I've tried fix it at the kstars level; I've changed the if at line 3752:

by removing the check on the status.

The result is a correct movement of the focuser, as expected, no matter the polling time (tried with 100ms and 500ms).

These the relevant logs:
[2024-02-19T17:10:23.717 CET DEBG ][     org.kde.kstars.ekos.focus] - "Linear: extending outward movement by overscan 100"
[2024-02-19T17:10:23.717 CET INFO ][     org.kde.kstars.ekos.focus] - "Focusing outward by 200 steps..."
[2024-02-19T17:10:23.789 CET INFO ][           org.kde.kstars.indi] - Sesto Senso 2 :  "[INFO] Focuser is moving to position 3200 "
[2024-02-19T17:10:23.789 CET DEBG ][     org.kde.kstars.ekos.focus] - Focuser position  3000  and state: Ok  unchanged
[2024-02-19T17:10:23.834 CET DEBG ][     org.kde.kstars.ekos.focus] - Focuser position  3000  and state: Ok  unchanged
[2024-02-19T17:10:24.356 CET DEBG ][     org.kde.kstars.ekos.focus] - Focuser position  3000  and state: Ok  unchanged
[2024-02-19T17:10:24.879 CET DEBG ][     org.kde.kstars.ekos.focus] - Focuser position  3000  and state: Ok  unchanged
[2024-02-19T17:10:24.879 CET INFO ][           org.kde.kstars.indi] - Sesto Senso 2 :  "[INFO] Focuser reached requested position. "
[2024-02-19T17:10:25.014 CET DEBG ][     org.kde.kstars.ekos.focus] - Abs Focuser position changed to  3200 State: Ok
[2024-02-19T17:10:25.014 CET DEBG ][     org.kde.kstars.ekos.focus] - "Undoing overscan extension. Moving back in by 100 ticks in 0s"
[2024-02-19T17:10:25.014 CET INFO ][     org.kde.kstars.ekos.focus] - "Focusing inward by 100 steps..."
[2024-02-19T17:10:25.165 CET INFO ][           org.kde.kstars.indi] - Sesto Senso 2 :  "[INFO] Focuser is moving to position 3100 "
[2024-02-19T17:10:25.166 CET DEBG ][     org.kde.kstars.ekos.focus] - Focuser position  3200  and state: Ok  unchanged
[2024-02-19T17:10:25.209 CET DEBG ][     org.kde.kstars.ekos.focus] - Focuser position  3200  and state: Ok  unchanged
[2024-02-19T17:10:25.732 CET DEBG ][     org.kde.kstars.ekos.focus] - Focuser position  3200  and state: Ok  unchanged
[2024-02-19T17:10:25.732 CET INFO ][           org.kde.kstars.indi] - Sesto Senso 2 :  "[INFO] Focuser reached requested position. "
[2024-02-19T17:10:26.268 CET DEBG ][     org.kde.kstars.ekos.focus] - Abs Focuser position changed to  3100 State: Ok

The need for a correct driver remains, since this change could break something else, but it shows what is producing the bug (the change in status before the change in position).

Cheers,
Edoardo
2 months 1 week ago #99195
Attachments:

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

  • Posts: 602
  • Thank you received: 281
Hi Edoardo,

Yes it's possible to code around the bug as you have done. Given the current driver I think what you've done would work fine for the SensoSesto2.

However, it would break the valid situation where a focuser reaches position X but the timing results in an interim message of
"position = X, state = IPS_BUSY" followed by:
"position = X, state = IPS_OK".

Of course its possible to change this to...
if (focuser == sestosenso2)
A;
else
B;

But the abstraction of focuser specifics should, of course, be in the driver.
2 months 1 week ago #99196

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

  • Posts: 32
  • Thank you received: 10
Hi John,
Isn't this the case that breaks the Overscan for the SS2? I mean, what's a case of a driver correctly setting the IPS_BUSY before the change in position?
I expect it working like this:
  1. Movement requested of 100
  2. Movement start -> state: IPS_BUSY | position: 1000
  3. Movement in progress -> state: IPS_BUSY | position: 1000 (here I can expect the position changing while the focuser is moving, as you mentioned as a "nice to have" in the indi issue)
  4. Movement end -> state: IPS_BUSY | position: 1100
  5. Movement completed -> state: IPS_OK | position: 1100
or am I missing something?

This is the current behaviour:
  1. Movement requested of 100
  2. Movement start -> state: IPS_BUSY | position: 1000
  3. Movement in progress -> state: IPS_BUSY | position: 1000
  4. Movement end -> state: IPS_OK | position: 1000
  5. Movement completed -> state: IPS_OK | position: 1100

And the problem arise because, rightly so, Ekos at the step 4 request the next movement using the position 1000.

Cheers,
Edoardo
Last edit: 2 months 1 week ago by Edoardo.
2 months 1 week ago #99211

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

  • Posts: 602
  • Thank you received: 281
Hi Edoardo,

Sorry I think my previous post was unclear. What you just wrote is correct and the local change you made to Focus would, I think, work for the SS2 (as you tested).

What I was trying to say, is that if I made your change in Focus and released it to everyone then it would work for the SS2 but would likely break other focusers (as the state change from IPS_BUSY to IPS_OK would be ignored in the scenario I highlighted).

So...
1. The best (and proper) solution is a fix to the SS2 driver.
2. If we can't do 1. then we can either do:
2a. The timer change to Focus (that I sent you separate code for) where it defaults to 0, but the recommendation for SS2 users is to set it to 0.6s. This would add 1.2 seconds to an SS2 Autofocus run.
2b. I take your change to Focus that you mentioned above and enclose it in an "if (focuser == SS2)" statement.

So lets give it a few days and see if the Indi guys can do 1.
2 months 1 week ago #99212

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

  • Posts: 32
  • Thank you received: 10
Hi John,
your post was not unclear at all, sorry if it seemed like that. It's my last post that's unclear.
I absolutely agree that the proper way is the (1) and everything else is a workaround (and I don't like those).

My last post was just my curiosity regarding the actual behaviour for all the focusers, where:
if (currentPosition == newPosition && currentPositionState == newState)
is used.

Is there an instance, with any focuser, where the change in status (IPS_BUSY -> IPS_OK) happening before the change in position could be a wanted behaviour? I'm asking because I know you have a lot more knowledge about various focuser, while I only have the experience of the SS2.
If not, I could see the problem arise again for new focuser drivers where the status get reported before the change in position.

Cheers,
Edoardo
2 months 1 week ago #99213

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

  • Posts: 602
  • Thank you received: 281
Hi Edoardo,

That line of code predates my involvement with focus. There is a comment above it that explains why is was put there.

To my knowledge the only focuser reporting IPS_BUSY->IPS_OK before updating the position is SS2. This is the only focuser that can't use Overscan (at least to my knowledge).

The way most of the drivers work is to start the move and then every polling period query the focuser position and report IPS_BUSY & focuser position. Then when the focuser stops moving change state to IPS_OK, query current focuser position, and report that with the IPS_OK.
The following user(s) said Thank You: Edoardo
2 months 1 week ago #99219

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

  • Posts: 32
  • Thank you received: 10
Hi John,
thank you for the patience and the useful insights!

Now we just have to wait for the good guys over at indi!

Thank you for all the support!

Cheers,
Edoardo
2 months 1 week ago #99220

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

  • Posts: 32
  • Thank you received: 10
Hi John,
I think I've found the relevant code inside the indi driver.
I've tried the fix against official kstars and seems to work correctly.
I've sent a PR to the guys over at indi, I hope I've made everything ok (first time doing a PR on a project outside of work).

Again, thank you for your guidance. If you need other tests in kstars for this matter, I'm here.
Regarding the new Delay added for this matter, I think it should stay; I think that for heavy payloads, a delay in the movements made by the Overscan should help.

Cheers,
Edoardo
The following user(s) said Thank You: Alfred
2 months 1 week ago #99227

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

  • Posts: 602
  • Thank you received: 281
Hi Edoardo,

Great news! Well done!

Hopefully everything will be well with the SS2 and Focus going forward but let me know if you find any other problems. There are some other folks on the forum using the SS2 so when you're comfortable it would be good to drop an update to the forum saying that this bug is now fixed and AF Overscan now works (for those on bleeding-edge Indi, of course).

Well done agin, this issue has been ongoing for ages so it's great to finally have it fixed.
2 months 1 week ago #99241

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

  • Posts: 32
  • Thank you received: 10
Hi John,
thank you for the kind words.

Are there any rules or suggestions for the creation of a topic for an update about functionalities and bugfixes?

Cheers,
Edoardo
2 months 1 week ago #99244

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

  • Posts: 602
  • Thank you received: 281
Hi Edoardo,

No not really. I usually just put it in the title.
The following user(s) said Thank You: Edoardo
2 months 1 week ago #99245

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

  • Posts: 602
  • Thank you received: 281
Hi Edoardo,

I'm wondering whether to merge or delete the MR: invent.kde.org/education/kstars/-/merge_requests/1140

Now that you fixed the Sesto Senso 2 issue I'm not sure why it would be needed. You mentioned heavy payloads but the focuser shouldn't signal IPS_OK until its move is completed and by definition that makes it ready for the next move.

There could be some instability that needs time to settle before imaging but that shouldn't affect the second focuser move.

Anyway let me know what you think. If I do delete it, its easy enough to recreate in the future if a new requirement appears.
The following user(s) said Thank You: Edoardo
2 months 5 days ago #99296

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

Time to create page: 0.737 seconds