×

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

Bi-monthly release with minor bug fixes and improvements

Always focus from one direction

  • Posts: 421
  • Thank you received: 102
Excellent! I'm glad I asked before implementing! :)
3 years 10 months ago #54654

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

  • Posts: 421
  • Thank you received: 102
Well actually....

I looked at that picture. 21 iterations to reach focus! Wow. Polynomial works pretty well for me, and usually in 7 or 8 iterations.

I suspect a universal anti-backlash mechanism would be useful, so that it isn't tied to one focus algorithm. Or more likely, it will need to be added to polynomial algorithm. (Are there more algorithms? I don't remember).
Last edit: 3 years 10 months ago by Kevin Ross.
3 years 10 months ago #54655

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

  • Posts: 1009
  • Thank you received: 133
IIRC I had placed a wishlist request for this feature some time ago. As in a general option for all focusers to always end moving inwards, ideally with a configurable overshoot amount. I think it would be a very useful thing to have!
So I would definitely welcome it if you go ahead and implement it :D
The following user(s) said Thank You: Jose Corazon
3 years 10 months ago #54664

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

So you can implement this in your driver with Ekos needing to know about it. Once you detect a switch in direction, you perform the large move and then go back to that position again. As far as Ekos is concerned, it's just waiting for you to finish your move.
3 years 10 months ago #54667

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

  • Posts: 1009
  • Thank you received: 133
But couldn't (shouldn't?) that capability go to the general INDI focuser class, so that any driver can benefit?
3 years 10 months ago #54669

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

  • Posts: 1119
  • Thank you received: 182

I also would love to have that configurable overshoot amount, both on the initial way out (how far from established focus the module moves the focuser before homing in again) and on the return after the U-curve has been established.

In theory, the polynomial algorithm should be faster, but that only applies to a system without backlash or with only minimal amounts. The moment there is any backlash, the linear approach is clearly superior in my hands.
3 years 10 months ago #54671

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

  • Posts: 1119
  • Thank you received: 182

The approach to the minimum is very methodical and does take longer than the polynomial, but it is also very versatile, as it works GREAT with analog focusers and FCUSB. There, the movements of the focuser are highly load dependent, in contrast to steppers. Nonetheless, the linear focuser handles that with flying colors. But making it more configurable, as Peter suggests below, would definitely be especially useful for such analog systems, I agree.
3 years 10 months ago #54672

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

  • Posts: 421
  • Thank you received: 102

I've already done that. I was asking if putting this in Ekos as a universal solution was better. :)
3 years 10 months ago #54705

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

  • Posts: 421
  • Thank you received: 102

Doing it there, rather than in the Ekos UI, is also an option. I hadn't considered that.
3 years 10 months ago #54706

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

  • Posts: 554
  • Thank you received: 138
A number of focuser drivers already have backlash implemented. it isn't difficult.

Implementing it in the base class could be quite a lot more work because it would still need to refer to the actual driver to handle detecting when the initial slew has stopped, start the final slew and wait for it to stop. All of that is currently done in the driver at present.

There's also a lot of variability in how backlaash is done. I've described one that is handled in the Indi driver but it could also be in the low level driver hardware.

Better to let each driver handle it in the way that suits it.

If you need an example the Celestron SCT focuser driver has one implementation.
3 years 10 months ago #54740

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

I concur with Chris. This has a very good potential of introducing regressions if introduced at the base class. Let each driver handle it as it sees fit.
3 years 10 months ago #54741

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

  • Posts: 421
  • Thank you received: 102
Very well. That certainly makes it easier for me, since I've already done most of the work in my Waveshare driver. :)
3 years 10 months ago #54743

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

Time to create page: 0.671 seconds