Re:Driver OnStep (LX200 like) for INDI

@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.

Anyone else facing issues with the latest packages from Jasem's repository?

I got this a week ago: indi-bin 1.7.7~201904141646~ubuntu18.04.1

When using OnStep as the driver, the refresh on KStars and CdC is very sluggish (lags by 5 seconds or so).

When I change the driver to LX200 Basic, everything works fine.

Any ideas what changed?

kbahey wrote: Anyone else facing issues with the latest packages from Jasem's repository?

I got this a week ago: indi-bin 1.7.7~201904141646~ubuntu18.04.1

When using OnStep as the driver, the refresh on KStars and CdC is very sluggish (lags by 5 seconds or so).

Found the problem.

This is a process trace of the INDI driver.

You can see that the :GXEA and :GXE9 commands above are timing out, after 5 seconds each.

They are for getting minutes past meridian east and west.

This configuration is for a fork mount, and the INDI driver requests this information regardless of the mount type.

So, the driver must check GU's output and only do these commands if there is an E in it, otherwise, these commands should not be issued at all.

Hi All,

I implemented a new feature in INDI driver: support for driving output ports.
It adds a new tab "Outputs" which allows entering values for 10 outputs.
Both binary and analog values can be passed to Onstep controller.
Onstep will interpret the values accordingly:

• if output is binary, then any value above 0 will toggle the output to high
• if output is analogy, the analog output will be set per the input value

With my RAMPS based Onstep I can toggle output 6 as binary and set values between 0 and 255 on port 7.
This code intentionally does not impose any validations on values, passed to Onstep in order to support future enhancements in Onstep, e.g. implement more than 8-bit resolution.

I see that someone already started working on a similar concept, which introduces a couple of toggle switches, but looks like it is not finished. I used the same tab in INDI UI for my feature.

Here is a pull request for this change:
github.com/indilib/indi/pull/926

Please review, test and merge.

Alex