Re:Driver OnStep (LX200 like) for INDI

Just for reference, Jasem's statement about this : github.com/indilib/indi/pull/859

So if I understand well there is a "sync" command in Indi to say the focuser is at a certain value.
I don't see a way to sync in OnStep firmware, is there one except the "zero"?

If I follow Blueshaw, an offset of max/2 would solve this issue.
Just for info, here my focuser set-up (than explains why I don't need the negative value or offset)
#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 whith this set-up I have 38000 steps to travel these 38mm with 0 fully retracted. (48 step motor, and approx 20,8/1 gear)
When I start I set the focuser mechanically to zero (0), initialize the focuser to Zero and from then travel to approx half travel where my focus usually is and I'm done.

May be James has some ideas.

azwing wrote: Just for reference, Jasem's statement about this : github.com/indilib/indi/pull/859

So if I understand well there is a "sync" command in Indi to say the focuser is at a certain value.
I don't see a way to sync in OnStep firmware, is there one except the "zero"?

If I follow Blueshaw, an offset of max/2 would solve this issue.
Just for info, here my focuser set-up (than explains why I don't need the negative value or offset)
#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 whith this set-up I have 38000 steps to travel these 38mm with 0 fully retracted. (48 step motor, and approx 20,8/1 gear)
When I start I set the focuser mechanically to zero (0), initialize the focuser to Zero and from then travel to approx half travel where my focus usually is and I'm done.

May be James has some ideas.

After some review in Onstep firmware I think there is no way to sync the focuser in a arbitrary position without modifying Onstep firmware.
All the Onstep Focuser1 commands are here (Driver supported):
=====================================================
// :FA# Active?
// :FAn# Select focuser 1 or 2
// :F+# Move focuser in (toward objective)
// :F-# Move focuser out (away from objective)
// :FQ# Stop the focuser
// :FG# Get focuser current position (in microns)
// :FI# Get full in position (in microns)
// :FM# Get max position (in microns)
// :FT# get status
// :FZ# Set focuser position as zero
// :FH# Set focuser position as half-travel
// :FF# Set focuser for fast motion (1mm/s)
// :FP# Get focuser DC Motor Power Level (in %)
// :FPnnn# Set focuser DC Motor Power Level (in %)
// :Fp# Check for focuser pseudo absolute mode
// :FRsnnn# Set focuser target position relative (in microns)
// :FS# Set focuser for slow motion (0.01mm/s)
// :FSsnnn# Set focuser target position (in microns)
// :Fn# Movement rate, 1=finest, 2=0.01mm/second, 3=0.1mm/second, 4=1mm/second
=====================================================
Set an arbitrary position without moving the focuser:
With OnStep we can only set to 0 (:FZ) or half-travel (:FH) but not any other position.
If we would want to add SyncFocuser Onstep firmware should be modified.
Should we ask to Howard for a change?

Use relative negative movements: // :FSsnnn# Set focuser target position (in microns)
As per Jasem's answer this would break Indi/Ekos since all setpoints for movement / position are defined as (unint), see Focuser Interface
I would be possible to calculate an offset if the returned range (:FI and :FM return values ) is -25000 to + 25000 and present a 0 to 50000 to Indi but this would create even more confusion.
I still don't see a solution here.

Set focuser Speed:
This could be supported by SetFocuserSpeed I presume provided we override the function to deduce the :Fn# arguments (1, 2, 3, 4) from a 0/100% saying 0-25 = 1, 26 to 50= 2 51 to 75=3 and 76 to 100=4 for example.

The major issue comes in when someone, like me, goes, I'll set min/max to +/- 50000 Which seems reasonable.

:FH and :FZ both initialize to 0, which requires human intervention/uploading the firmware. I can probably shift it (now that I've realized it's IMO unwisely uint), but that means any problems with OnStep, will have a different number than is in the hardware.

I'll as noted in the pull request submit an issue, followed by a pull request, to change it from uint32, to int32, because the restriction seems contrary to the INDI protocol (the one focuser actually shows a negative position.) I'm going to be honest, after looking through 13 of the 21 drivers that do absolute focusing, yikes. I have found exactly one that uses unsigned for how it deals with the uint32_t. Well, 3 I guess if you count Hex. There's no reason at all for it to be a positive number at all. I suspect it was just how some focusers work, and it got based off of that.

Nothing so far that I've looked at uses more than 20 bits. There would only be a few driver changes required. Also, as far as I can tell, OnStep has greater ability to handle ranges, but with the timing, heh! But at 1 millisecond (default is 8 ) 20 bits of change would take 17+ minutes. (Depending on hardware it may use a 4-byte float/double, or an 8-byte double) Anything above that I think is kinda silly, unless you've got some amazing measuring equipment and are down in the nanometer range. (SEMs for telescope alignment?)


Ironically, at least one I looked at briefly last night (not in the 13 I've looked at), there was one also work with negative numbers via treating the uint as int, and enforcing the greater than 0 will actually break that one.

@James,

I remember when I started testing my stepper focuser with Onstep (before I had a self built DC type), I started with default settings (-25 .. + 25) and it was working with Indi but I changed during tests because I never was able to set my origin so I chose to use 0 .. 38 instead. (Just to say the reason was not software, just simple mechanical fact)

By the way, what means IMO?

Nevertheless, there must be an objective reason why Howard did set the default to -25 .. +25, so we should find a solution.
So I decided to change my set-up again to relative (-19 .. +19) to fit with my 38mm stroke to be in position to test this with Indi again

Seems we have other issues too. I made many tests yeasterday and dis the mistake to upgrade OnStep to last Alpha.
At a fist glace everything seemed working fine and then I discovered that Speed adjust :FS# :FF# and :Fn# do not work anymore.

I asked also on Onstep Forum wait and see

IMO ~= à mon avis
We all value your opinion greatly @James_Lan. I read through the git discussion also.
Sync - (I knew it had a name ;-P)

tl;dr I think it's more of a machine thing than a program thing.

Very interesting discussion. One side effect of programming in short pants(opensource) is that it can be like herding cats when so many different bits of hardware come together. I'm not surprised there's already a negative going focus driver as it does seem likely to happen in normal use due to system startup favoring 0 unless an offset specifically loaded, but it tends to leave you with an unknown index. Some focuser developers may not have been working with repeatable indexes in mind, especially the DC motor ones.
In industrial robots, we "home" a traverse/arm/spindle etc. to get a calibrated position. "home" is always a 0 or 0,0 and locked to physical encoder indexes or mechanical/hall effect limit switches. Only robots that zero at a midpoint use negative numbers. Our gem mounts are one example of the latter, and we all know how picky alignment is from that variable location(viva la platesolving). Onstep is ahead of the curve on this btw, having inputs available for homing switches; nice touch Howard.
I see Jasem's point about setting this arbitrary home position(all the way in) at 0 because this means your known locations are always going to be "out/positive" from there. This gives you a repeatable and locked "home" point with which to base your movements and then all offsets are positive from there.

@KNRO: Storing the previous session's focus position to XML might be a nice option.

Hope this makes it easier.
Cheers,
Ray

@ Blueshawk,

Thanks for your input ... especially for the IMO ... I have really problems with acronyms also in French!

More seriously, I asked also Howard about the -/+ and the here the answer .

There is also support in the interface to store settings to file, just a matter of thinking about what needs to be stored.
I really would like to work on both sides, Firmware modification to allow Sync, Reverse, Speed control as well as stting saving.
But to reach the goal I must be sure both Sides are happy whith the modifications.
Seems on Howward side there is agrreement on that.

A propos Focuser speed control, did somebody experience with that?

Posted the suggested change here as an issue: github.com/indilib/indi/issues/866 (And I'm about 50% done with the pull request)

The takeaway from reading through all the things that implement focuserinterface and the focuserinterface is that, 20 bits is all that's used aside from OnStep and OnFocus and to go through that, even at 1 step/millisecond and 20 bits is a 17 minute focus!

Also, everything communicates with the mount as if it's already a signed integer, fixing it to actually act like the documentation would be more issues than the reverse. (gcc, which is almost certainly the compiler used for INDI, will let you call printf(%d) with an unsigned integer, not give you a warning, and output it as a signed integer, which is part of why everything works for me. Actually, based on a quick look, so will Microsoft's compiler. There is only a single driver that actually treats it with the proper %u, and that's only for warnings not for output to the focuser.)

Internally, focuserinterface actually uses signed integers in it's calculations.

Most drivers also represent it internally as well, and I'd say that aside from one using an unsigned short (16-bit), and a few using uint32_t, most use signed doubles. Our current implementation relies alone on the FocuserInterface, and the INDI number variables are doubles. (Frankly I see a lot of unnecessary code in many many drivers. ie, lots of bounds checking, and because I looked at other drivers initially, I did that too.)

FocuserInterface also needs to have support for more than 1 focuser, but that's a separate issue. (And it should be pretty simple to handle, now that I've gone through things.) There's also the rotator interface, which can be used for OnStep.

----

As far as speed control: That isn't something that's going to matter for Absolute positioning.

A brief overview as to why that exists, and why I ignored it:

LX200 was designed when there were only DC motors, so you'd have a speed + time + direction. You can see this still reflected in www.indilib.org/api/classINDI_1_1FocuserInterface.html with MoveFocuser, which gives you reasonable control over DC, and you REALLY need to be able to control the speed for fine vs coarse focusing. The methodology aside from computers was a hand controller with a few speeds and buttons for each direction.

This translates into the LX200 commands, which were the only ones for a while: In, Out, Halt, Fast, Slow, %speed www.meade.com/support/LX200CommandSet.pdf Looking at the newer protocol specification, www.meade.com/support/TelescopeProtocol_2010-10.pdf added some more like time for pulse and such.

However, OnStep uses steppers, with given positions. So instead of trying to use the above, there are more useful commands, where we can tell the focuser go to position X, and barring mechanical or electrical interference/problems it will. There's no need to go at 1mm go for 5 ms In/Out. When you can go: Make 2 steps. It is limited by the rate specified per axis (default is 8ms/step at least on Megas, probably lower on others) (Ok, it's actually defined as micrometers theoretically, along with a conversion factor between steps and physical motion. I personally just set that to 1 micrometer/step, as trying to calculate that on at least one of my setups was probably inaccurate and would require disassembly of the focuser (again). I'd say that's the best method, unless for some reason you know the proper physical conversion and want it to be stored like in the FITS header, I don't see much of a point.)

So I have left speed out of the implementation, because IMO it's useless for anything from within INDI. It might not be for a hand controller (I know some people have SHCs with focusing. Frankly there I'd use absolute.) Frankly, if allowed, I wouldn't have done anything with MoveFocuser, if it weren't a required function. (I used relative movement, ignoring speed, and using the duration as ticks) same as MoveRelFocuser). Relative moves update the Abs position in OnStep, so there's no issue.

So unless you have a reason to want to implement focuser speeds (and I honestly can't think of any good reason, unless you want compatibility with really old lx200 software, but that wouldn't be going through INDI) I would just ignore them completely.

Hi James,

I agree from a technical standpoint, speed control is not necessary.
But soon or later one will come and ask why it is not feasible since OnStep allows it!
And now that DC motor is supported I am pretty sure many people will go for that since it far cheaper, and does the job (I went to stepper because OnStep didn't support DC!)

At least the situation where we are now allows anybody to use the focuser within Ekos and that is the most important.

As we say ... Rome wasn't built in one day!

@all

It is abit complicated for me to follow and keep track in an efficient manner of all the reports and suggestions concerning the Driver.
Using Indi's GitHub issues was an option but I think we shoudnn't use it for "loud thoughts".
So finally I beleive the " OnStep Fork " is the right place to use since it will use only OnStep user's time.

@James,
I believe your Focuser Interface is at the right place since it is more indi related than pure OnStep, but leave up to you to open an issue as reference.

Regards

Hello everyone !

Thank you again for the great job you all did on the indi_onstep driver!
Bravo, without you we never had a driver for indi !!!!

I come to solicit you again to create a new driver that will be a copy of the driver indi_onstep but slightly modified.
The goal would be to create the indi_teenastro driver!

The developer is ready to help and then to maintain it.

Unfortunately I can not help because I already develop the "NAFABox": github.com/Patrick-81/NAFABox

The project teenastro is a project of simplification and personalization of Onstep to make it accessible to the greatest number.
link: github.com/charleslemaire0/TeenAstro

@Dragonlost,

looks a nice project too.
Unfortunately I am still busy with my observatory, still not motorized ...
An many other things on the fire (Retired people never have time
I will take a look on Teenastro at least to see how it is similar in terms of protocol.

Regards

dragonlost wrote: I come to solicit you again to create a new driver that will be a copy of the driver indi_onstep but slightly modified.
The goal would be to create the indi_teenastro driver!

The developer is ready to help and then to maintain it.

Unfortunately I can not help because I already develop the "NAFABox": github.com/Patrick-81/NAFABox

The project teenastro is a project of simplification and personalization of Onstep to make it accessible to the greatest number.
link: github.com/charleslemaire0/TeenAstro

I personally think that instead of effectively forking OnStep into many projects and many drivers, it is better for us to convince Howard to move OnStep to a more friendly and simpler configuration. I wrote the Online Configuration Generator as one way to avoid editing the files. Me, as well as Charles, have advocated for this.

For example, instead of compile time values, we should have things that are run time (e.g. mount type: GEM, Alt-Az, Fork, ...etc.; motor steps per rotation, GR1, GR2, worm wheel steps per rotation). Using a USB tool (a Python program on the desktop, or the SHC), these values are configured, and Steps Per Degree, ...etc. are all calculated internally).

Charles even wrote a Teensy program loader.

Howard so far has been reluctant to entertain the idea. However, with enough voices calling for these changes, perhaps he will be convinced.

If we have this, we can have one universal binary for each MCU architecture and users will not even have to install the Arduino IDE at all.

Instead of addressing the symptom, let us go for the root cause.