I'm trying a split approach with :FR... and :FS... in a branch, based on what you've done already.

Both of those move using the stepper and the definition of StepsPerMicrometerAxis4 (Focuser 1) So shouldn't be subject to timing issues.

(Apparently it wasn't limited to us, Meade added this to the Autostar 2, but OnStep doesn't have it (the FR and FS are probably better):
:FPsDDDDD#
Autostar II – Pulse Focuser for the number of milliseconds specified in the signed number sDDDD. The range is limited to
–65000 to +65000. Positive moves the focuser inward, negative moves the focuser outward.
Max/RCX – Move focuser relative to its current position by the specified count
)

James,

I am a bit perplex on this topic and here is why.

When we are speaking about focuser position there are four things to consider:
1) The Software side is handling absolute position in micrometers at high accuracy and reproductibility which is a fine thing.
2) The mechanic which is composed of the stepper and the gear / belts. This has a limited accuracy and reproductibility and certainly not in the micrometer range, rather in the 1/100 mm range. On my homebrew focuser I reach a +/- 0,03 mm reproductibility when moving 20mm and I suppressed backlash by doind 0 to 20 then 20 to 19 then returning to 20)
3) The camera fixture, depending on the type of fixture, difference between setup can be as big as 0,03 mm (measured on my focuser)
4) The temperature influence (For aluminium there is a 23µm difference between 0°C and 20°C for 50mm (and considering the tube length of a 1,5m Focal where elongation would be 736µm for this 20°C delta T)

So by the end all together the absolute position precision is in the best case not better 1/100 mm and most probably worse.

Additionally to this, OnStep is considering that focuser is at 0 when starting so one has to position this focuser to middle coarse before start which is also not trivial. My opinion would be more accurate to use full In or Out which would be easier to achieve.

Where I want to come, is simply to say that all I need from a focuser is to have the possibility to adjust it with the most little displacement steps to reach focus and this without vibrations and once is is focused to stay in place.

I set up the focuser in this way:
1) Mount the camera
2) Set manually the focuser at mid coarse (the 0 for OnStep), again I woulkd prefer full In or Out (I included a clutch in my focuser)
3) find focus on liveview by entering an arbitrary relative travel
4) then use any tools I have to fine adjust the focuser and here I use also relative +/- travel

Honestly, I never use the pulse movements, I prefer the relative which is predictible.

By the end I really don't care about the absolutre position except for the two max/min positions but even here I did cheat
the firmware by telling +/- 18 instead of +/- 19 (may fosuser has 38mm travel) so that I never reach the mechanical limits (which can rapidly detroy the friction mechanism).

Now most probably I am certainly missing something here because may other posts are discussing around absolute focuser position. Till now I never found the rationale behind.

Attached what I use for my Focuser

Each focuser is 100% dependent on the ratio of the motor steps and connection hardware, and especially in the case of diy this is a very wide range of possibilities. The end result is always the same at the control end. 1 step = one position change. All the belts and gearheads and microstepping are relative to this. Unless a dc motor is used on a focuser I see no reason to ever do timed output either as it would only end up recalculated to steps anyway.

I think somebody in the OnStep group may have used the micrometer term in relation to a project and it stuck.


Just be sure to set max steps to something just short of infinity. :laughing:

Right, to be able to use something like a repeatable function, you'd want to put it (IMO) in full in. To initialize, you'd get :FI# (Full In) and :FM# (Max) and then issue a command to move to the 0 point using FR. At that point if you have a saved general absolute value for a camera or eyepiece, it can move to there. That's when I'd switch to relative, to adjust for deviations everything. Doing it that way allows for cameras/eyepieces to be easily switched. (To an extent.)

(I can actually see 3 initialize buttons, I doubt I'd use 2 of them. Initialize from Full in. Full Out and at Zero.)

You also need to have the number correct in the function for it to be accurate (StepsPerMicrometerAxis4) if you want units in software to match units in real life. Frankly, that's less important than having it adjustable to a usable value for your setup.

As far as timed input, I agree. That last was pointing out that Meade appeared to have encountered a similar problem with doing the timed input over serial lines. Which is not surprising to me at all.)

I never actually use the saved positions in Moonlite, since focus is condition specific anyway. I don't even bother to home the thing in most cases, just fire it up, hit framing and the hit in or out till the disks get small enough on the preview that I think the auto routine will go and then stop framing and hit autofocus. I usually use full frame to avoid having to select a star. Works pretty good in dark skies.

Blueshaw,

I more or less use focuser as you describe.

James,

Are you sure the ":FI#" and ":FM#" do initialize Focuser at Min respectively Max? As far I see it only returns Min and Max but no action.*

- Timed control does not work or at least makes no sense for stepper focuser, I think we all agree on this, good this is one thing we can lease aside.
- Initialization, I believe we also agree we need a fixed starting point if absolute positioning is the way we wana go.

May be we can suggest this to howard (at least as a config like Focuser_Init_In or Out).
I checked on my board to init considering focuser is full In and starting from there I could have acceptable reproductible positions.

So the plan could be:
- leave the pulse as is (I am not happy with it but some other people may)
- leave the relative setpoint as is
- add an absolute setpoint.
- add three butons to initialize (but this would required change code in OnStep or I am wrong)
- add a function to save / retrieve values, ideally saved by name.

Joke of the day for you guys
I dismantled my EQ6 to add an indexer on the RA axis for the PEC and since it is dismantled to clean and renew grease .... tune ... tune ... tune
By remounting axis stays blocked in the middle of coarse, no way to move anymore
Hours of axis cooling and body heating later finally it slipped in place

I knew I missed someting!

I am stupid, why do you guys not tell me

Just checked with focuser travel set as hereunder
#define MinAxis4 0.0 // minimum allowed Axis4 position in millimeters, default = -25.0
#define MaxAxis4 38.0 // maximum allowed Axis4 position in millimeters, default = 25.0
and now I have my defined reference point.
I didn't see the forest, to much trees !!! and really was stuck in the idea by default the initial position was in the middle travel ... I'm getting old!

Mount is remounted, PEC sensor is working, motors run in the right direction, I now can test the real world but sky is still cloudy and it is snowing.

Good you are here to challenge the topic.

Argh, it ate my reply. (Or I'm stupid in hitting butons!)

(Unless it's queued or something the jist is)

For min position (or max) initialization.
Use FI, FM to get min/max
Calculate 0, issue FR to move to 0, if not already there.
Issue FZ? to set it to 0.

If it's at 0: Just issue FZ.

Now, the issue comes in that, to get autofocusing working like Blueshaw with the Moonlight, it needs to be implemented either through INDI::FocuserInterface or INDI::Focuser (As far as I can tell the 2 lx200 based ones with focuser support... also don't do it right, and shouldn't be looked at as models.) I think it's just the interface which is needed as Focuser duplicates a lot of things that the telescope class has as well. www.indilib.org/api/classINDI_1_1FocuserInterface.html

I'll be looking at that more to make sure I'm right before jumping in.

As far as the timed stuff, it's in the focuser interface, but nicely, there's a speed argument passed, so what we pass to OnStep can be simply speed*time. As well as the absolute and relative movements.

I can't test it tonight, because I screwed up part of my focuser disk (laser cut and it was a bit too shallow anyway), but I'll see about making a new one tomorrow. And maybe get that done by Sunday.

James,

there are some days where it's better do nothing ...
I have a lathe, if you need some special parts may be I can help, just need a drawing and material spec.

regards

James,

as you can see I merged your pull request but discovered later on the few ".directory" entries in github.
I removed those but take care next time as these entries are rejected when it comes to merge in main stream.

All seems to work, another step towards infinite .... perfection

I would suggest the following user interface for the Focuser
See below picture (Assuming the Focuser is set 0 to 38000 but calculated from :FI# and :FM#



Oups, Half Travel should be 19000 not 38000 in the drawing, and I forgot the Save/Retrieve Functions

@Azwing: Mount bashing for fun and profit!
My post during the power outage appears to be missing. Must have been the 8 inches of snow that prevented it. My wife is ready for buggy summer months but I'm wishing for more clear 20F nights as I spent most of the season bashing on this upgrade and the rest dodging ice, snow, cloud, rain, sleet, mud, and the occasional windstorm complete with flying cows!

I thought it might be nice to see a screenshot of Ekos for reference here. This is the screen used most for focus. You set the number of steps to take (in or out) when you push the "focus in" or "focus out" in the box labeled "Step:" near the bottom. I usually start "framing" which takes shots as fast as the Exp: will take them and click in and out till I get the best short shots. I've had mixed results from autofocus but if you get close before you invoke it the script will net you the lowest HFR in most cases. Polynomial is used to calculate best position based on previous movements and HFR focus readings for faster results. The box marked "ticks" shows your current position in steps and is a stored variable. You can set an absolute value in the next box and push "Set" to go there, or as above focus in or focus out will move relative and in the amount preset near the bottom.
There's now a filter select in the ccd section which is handy for those of us afflicted with monochrome cameras. The filter wheel is the best excuse for having preset focus points I can think of with even decent filter sets needing a quick retune before use due to the different wavelengths passed, but the ccd tab has an option to re-autofocus on filter change so presets aren't not really needed. Atmospheric and mount condition changes often require a periodic refocus anyway.
Moonlite.cpp has a speed setting code as well as half or full step and also might be worth a look for some Ekos interfacing skeleton to link Onstep to that ekos screen. Others may also yield usable code examples, I've just been using that one for a while since I found a fellow diy'er that had already written the firmware and solved the usb protocol.

i.imgur.com/1fG7G59.png