×
INDI Library v1.8.6 Released (21 Aug 2020)

August 2020 release of INDI Library v1.8.6 introduces new drivers while providing fixes and improvements to existing devices and core framework.

For those with focus issues

9 months 5 days ago
Frank L
Fresh Boarder
Fresh Boarder
Posts: 19
More
For those with focus issues #47171
this is a great step forward for all SCT owners!

Thank you for your work !

Frank

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

9 months 5 days ago
DerPit
Platinum Boarder
Platinum Boarder
Posts: 523
Karma: 1
More
For those with focus issues #47174

hy wrote: Peter,

Let me know how your imaging went.

I'd like to paraphrase your post, to make sure I understand. .....

Hy,
imaging went so-so. Seeing was horrible (for my site), but I got almost 6 hours on LDN1584. Will have to see.
Yes, that is what I sugested. As Chris wrote, it is one standard way of handling backlash in absolute position units:

ChrisRowland wrote: This is a common way of implementing backlash. All moves approach the final position from the same direction and distance. This eliminates backlash by ensuring that all moves finish in the same direction. Backlash is your M parameter.


It has the advantage that any value larger than the actual backlash will give you correct performance (maybe at the price of moving too much). This is however different from the BL handling within the focus units themselves. They usually move the additional amount if the direction is changed, and then change the reported position. This one only works correct if the amount you specify is exactly the BL. So IMO it is even superior to the driver-supplied BL.

In principle it's something that should be in the general focus module, a radio button to activate the always-end-with-inward-movement behavior, and an amount for the overdrive (because that can largely vary depending on the focuser). (I had tried to change the focus movement code to implement this, but I don't speak C++ and gave up quickly :sick: )

hy wrote: This makes sense to me . However, I won't be near my telescope for another week and a half, so won't be able to test. Feel free to modify your local code, if possible, and let me know.


I'll have a look. Maybe it's easier to test/modify in the focus module

I don't think making "M" configurable really is worth it, though. Don't you think that we could get all the value we'd need by setting M=4 or 6 extra steps (something that hopefully is beyond the backlash for most everyone) and it would work without adding more to an already large number of focuser parameters?


While you're right in principle, with a large BL that can get extremely unhandy for the refinement steps, even more if you still take measurements at each of those positions. That is why I'd prefer to have this as a separate configuration option. And ideally (as pointed out above) not even in (your) focus module, but in the general focus driver - then all focus algorithms will benefit.

ChrisRowland wrote: The example shown seems to have found the minimum with the focuser moving out instead of in but there is nothing except friction stopping the camera moving out the 100 steps of the backlash and being out of focus by 100 steps. If the focuser finishes by pushing the camera in which, with the telescope looking at the sky, will be up there will be less chance of unepected focus shifts.


Yes indeed, it did. It's not a desirable thing, as you point out. I might try to look at that again - but maybe you can also investigate how to implement that correction type in the general focuser class?

openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI1600+EFW+EAF+ASI290 mini

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

9 months 5 days ago 9 months 5 days ago by ChrisRowland.
ChrisRowland
Platinum Boarder
Platinum Boarder
Posts: 536
Karma: 9
More
For those with focus issues #47185

DerPit wrote:

ChrisRowland wrote: This is a common way of implementing backlash. All moves approach the final position from the same direction and distance. This eliminates backlash by ensuring that all moves finish in the same direction. Backlash is your M parameter.


It has the advantage that any value larger than the actual backlash will give you correct performance (maybe at the price of moving too much). This is however different from the BL handling within the focus units themselves. They usually move the additional amount if the direction is changed, and then change the reported position. This one only works correct if the amount you specify is exactly the BL. So IMO it is even superior to the driver-supplied BL.

All the drivers I've written have implemented backlash as I describe, see the CelestronSCT focuser driver for an example.

Doing it as you describe will be a nightmare for the user because it depends critically on the user setting the backlash parameters exactly right and the hardware retaining that backlash value regardless of position and temperature changes.

DerPit wrote: In principle it's something that should be in the general focus module, a radio button to activate the always-end-with-inward-movement behavior, and an amount for the overdrive (because that can largely vary depending on the focuser). (I had tried to change the focus movement code to implement this, but I don't speak C++ and gave up quickly :sick: )

Yes, in principle but I have a bad feeling about this, it could get far more complex than it appears. The code for a single focuser isn't complex and can be tailored to that exact focuser hardware.

Feel free to prove me wrong though!

Chris

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

9 months 5 days ago
DerPit
Platinum Boarder
Platinum Boarder
Posts: 523
Karma: 1
More
For those with focus issues #47188

ChrisRowland wrote: All the drivers I've written have implemented backlash as I describe, see the CelestronSCT focuser driver for an example.


Good to know!

Doing it as you describe will be a nightmare for the user because it depends critically on the user setting the backlash parameters exactly right and the hardware retaining that backlash value regardless of position and temperature changes.


Indeed, but (unfortunately) it seems to be how units like the DMFC or the ZWO EAF do it (in firmware, I assume). They do the correction both ways, and (just) add the BL without counting it. The method you describe would only do compensation when moving out, no? And of course you can see the movement of the motor.

Yes, in principle but I have a bad feeling about this, it could get far more complex than it appears. The code for a single focuser isn't complex and can be tailored to that exact focuser hardware.
Feel free to prove me wrong though!


Well, you (obviously) have (a lot more) experience there, so I'll trust you ;)
But it means you only get it for drivers that actually implement it. So in my case, I would prefer setting the driver-internal BL compensation to zero and use such a global end-inwards mode....

openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI1600+EFW+EAF+ASI290 mini

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

9 months 4 days ago
hy
Gold Boarder
Gold Boarder
Posts: 321
Karma: 3
More
Topic Author
For those with focus issues #47237
Chris, Peter,

Here's my reaction/interpretation of this conversation. I'm flexible, and of course want to implement the algorithm as best as possible. However, I'm being conservative, and until we prove we have an improved algorithm, I'm trying not to change the existing focus behavior (e.g. if you select the iterative or Polynomial algorithms, things will still work as they were). Those algorithms move in both directions. I intended for the Linear algorithm to just move in.

So, when I get a chance, I'll make a change to Linear, where, at the start of the 1st and 2nd passes, it will move out N+M, not take any exposure, and then move back in by M and start the exposure sequence. I'll set M at, say 5 steps. I don't think Peter's concern that a large M might affect refinement steps, because this is just applicable to the start of the two passes, which are not refinement moves. The half-step inward moves during the 2nd pass are my only refinement moves at this point, and they are all moving in after this backlash-removal moving is done. Hopefully the current change, and this modification, will improve things enough so that folks can test out the in-only "Linear" auto-focus algorithm, and demonstrate improvement over the previous algorithms.

I'm sure I can implement the above "N+M change", but I checked and it isn't a trivial mod (it may be small in number of lines, but not trivial in getting it right) so I want to do it carefully,

Let me know if this plan is OK,
Hy

PS Out of curiosity, I've read from Jasem, and Frank above, that this change should especially help SCT owners. Why is that? What is it about SCTs that is different than, say, refractors with respect to auto-focus?
The following user(s) said Thank You Herrhausen

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

9 months 3 days ago
hy
Gold Boarder
Gold Boarder
Posts: 321
Karma: 3
More
Topic Author
For those with focus issues #47239
FWIW, here's the code change for that
phabricator.kde.org/D26218
Jasem will review it.

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

9 months 3 days ago
ChrisRowland
Platinum Boarder
Platinum Boarder
Posts: 536
Karma: 9
More
For those with focus issues #47247
The reason that SCTs benefit from backlash correction is that they focus by moving the primary mirror. The mechanism has a lot of backlash, I've seen as much as one turn of the focus knob although more recent scopes are better. Focus is best done by pushing the mirror up against gravity because then it holds focus. If you focus downwards the mirror has a tendency to drift downwards through the backlash. Most people end up getting a secondary focuser and locking the mirror.

Having backlsh can't do any harm and I'd be inclined to implement it independently for all focus methods. I'd have a signed value where the sign controls the direction in which backlash is done and the user can set the amount, zero would be no backlash. I wouldn't have a separate switch. This is too radical for now though.

i've been looking at implementing backlash in the base indifocuser.cpp and the difficulty is that many focusers check that the move has finished in a timer and then do something like this:
FocusAbsPosNP.s = IPS_OK;
FocusRelPosNP.s = IPS_OK;
IDSetNumber(&FocusAbsPosNP, nullptr);
IDSetNumber(&FocusRelPosNP, nullptr);
LOG_INFO("Focuser reached requested position.");
IDSetNumber goes directoy to indibase. Can indifocuser.cpp intercept the IDSetNumber call so it can start the second move?

Chris

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

9 months 3 days ago
Frank L
Fresh Boarder
Fresh Boarder
Posts: 19
More
For those with focus issues #47250
Hi Hy,
as Chris said, my Celestron can have BL but especially the problem of the flip mirror when you change direction for focusing. This is the reason why I can not do autofocus, but maybe I do it wrong especially over the duration of the subs?

Merry Christmas to all !

Frank

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

9 months 3 days ago
DerPit
Platinum Boarder
Platinum Boarder
Posts: 523
Karma: 1
More
For those with focus issues #47251
Hy, thanks for this change, and Jasem already approved your submit :)
I'm having clouds (of course - it's New Moon.... :( ), but tomorrow night is predicted clear. I'll try the changed routine then and report back.

Chris: Yes, I agree BL compensation should eventually work independent of the focus algorithm (and, as I mentioned, probably also independent of the driver). One reason for that IMO is that the concept of 'outward' and 'inward' is really only known to EKOS (or am I completely wrong there?). But for now, the linear algorithm is a perfect test bed to check the best implementation. And getting it in the device independent part has several traps (like what to do with a driver-internal BL compensation? Should it be switched off when end-inwards is active?). So it's good to have one algorithm that uses it already now...

openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI1600+EFW+EAF+ASI290 mini

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

9 months 2 days ago
DerPit
Platinum Boarder
Platinum Boarder
Posts: 523
Karma: 1
More
For those with focus issues #47276
Hi Hy!

Just playing with the new version. The plateaus are now gone, that's very nice. Attached are three runs, the first with a step of 30, the second and third with 20.
The derived focus positions were 45638 (step30), 45648 (step20 1) and 45608 (step20 2). That the last one is lower for sure is a (real) temperature effect, it's currently dropping at 2 degrees/hour. So that's nothing to worry about.

But the stop criterion is still a bit sharp - it will largely be affected by seeing. Especially the second and third run got a good frame and stopped, both times I'd say a bit too early. Not sure though how to catch that other than doing a polynomial fit including all points after also the fine scan went (clearly) through the minimum. The latter might suggest to wait even one exposure longer for both repeats to make sure it wasn't seeing bending it up (I think this happened in the second scan). And in that scenario it would also need a final move-out and then back in to the detected focus.

But the general shape of the curves looks promising to me :D

Cheers,

Pit


openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI1600+EFW+EAF+ASI290 mini
Attachments:

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

9 months 13 hours ago 9 months 12 hours ago by El Corazon.
El Corazon
Platinum Boarder
Platinum Boarder
Posts: 871
Karma: 3
More
For those with focus issues #47328

ChrisRowland wrote: This is a common way of implementing backlash. All moves approach the final position from the same direction and distance. This eliminates backlash by ensuring that all moves finish in the same direction. Backlash is your M parameter.

The example shown seems to have found the minimum with the focuser moving out instead of in but there is nothing except friction stopping the camera moving out the 100 steps of the backlash and being out of focus by 100 steps. If the focuser finishes by pushing the camera in which, with the telescope looking at the sky, will be up there will be less chance of unepected focus shifts.

Chris



I am using a self-built, timed DC motor driven autofocuser. This is my decidedly low-tech solution how I overcame the friction/focus shift/slippage problem.

A couple of rubber bands:


Atlas Pro AZ-EQ, ASI1600MM-Pro, ASI120MM-S, ES102ED, WO-Z61, Nikon D3300, ASI-EFW, ZWO LRGB,Ha,O3,S2 filter set
Attachments:

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

8 months 1 week ago
universalmaster
Gold Boarder
Gold Boarder
Posts: 200
More
For those with focus issues #48194
Hi!

I now tried this, and I seem to just get an long loops of moving in's and moving out's with the same step until it finally reports an error. I also have to set the Initial step size quite low to not get errors like this
[2020-01-19T19:09:49.966 CET DEBG ][ org.kde.kstars.indi] - FCUSB1 Focuser : "Error: Invalid range for FOCUS_TIMER_VALUE. Valid range is from 0 to 5000. Requested value is 20000 "
[2020-01-19T19:09:52.093 CET DEBG ][ org.kde.kstars.indi] - FCUSB1 Focuser : "Error: Invalid range for FOCUS_TIMER_VALUE. Valid range is from 0 to 5000. Requested value is 10000 "
[2020-01-19T19:09:58.382 CET WARN ][ org.kde.kstars.ekos.focus] - Focus GSL error: invalid argument supplied by user

The last line persists even with a small initial step size.

I use a FCUSB focuser.

Best Regards,
Søren

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

Time to create page: 2.427 seconds