Great, thanks.

I hope the rotator polling cures the 30+ second delays I was seeing. Polling is always dicey - I have sometimes used
a voting scheme. Three times failed and the object is turned off or we throw a fatal error.

Thanks again.
Jack

There's not really any way around polling, as OnStep only responds to commands. It doesn't send a status update constantly.

More or less that's the reason for the connect delay. On Startup, It polls things like the Focusers, PEC and Rotator (others I'm not recalling atm?), If it doesn't get a response indicating they are there from OnStep the driver doesn't check them again.

Based on your logs, it was hitting the LX200's 5 sec limit 5 times, so 25 seconds.

A repoll could be added, but I don't see the point. Disconnect/Reconnect will do that, if maybe take a few seconds. Maybe someone else does?

Looking at changing the lx200driver to 1 second does change the connect time from 18 seconds down to 6. With everything turned off (so it's likely hitting 2-3 of the 5 second timeouts) I'll check more, but my keyboard is fritzing out in ways that are being really annoying (probably needs to be replaced), and I don't really want to introduce typos, so I'll look at it later.

James,

I experience the same delays, in the average it it more than 5 to 6 seconds between an action is taken from Kstars, Ekos or control panel and execution of the command.
I was first suspecting my latest pull request but it is not.
I did not identify the cause yet but it is definitively the case only for OnStep. When running indi_lx200_TeenAstro or even indi_lx200classic everything is reacting in a reasonable time.
Since my configuration does not have a second focuser, any wheather sensors nor de-rotator I guess there must be some aditional delay due to polling non existing things ...
I will continue to search on my side.

James,

The code from a couple hours ago seems to be problematic. It doesn't seem to want to go form Park to tracking.
I am including the log file.

Thanks,
Jack 

@azwing: I did find with 0 focusers, and with one, that somehow OSFocuser2 seems to be non-zero. I've made changes, but before it's only been set to false in the .h and true if detected (by :fA) (Same as OSFocuser1) I've added explicit assignments  to False for it now.

So that might fix your problem.

@jackbak

I generally don't park my scope so I'm less familiar with the process.

In trying to reproduce, I haven't been able to. What I see in your logs I am not sure I understand completely. The UnPark() command & the message that it's already unparked gets called from the base indi telescope class. I can't reproduce it, BUT it looks like something changed so I've made the Trackstate explicitly Parked (in addition to a function call which did it before, and doesn't seem to now.)

Can you see if you can still reproduce it off my repository?

I pulled your last changes and yes it solves the lag issues.
I have practically same response time as before all the last week changes.
I tested the following:
- Parking
- Unparking
- slewing
- focuser
- guiding
- Focuser1
All seems to work with reasonable timing.

In my opinion since OnStep is going to be a very complex and multipurpose controller we will encounter this knd of timing issues soon or later so conditional configuration and scheduled polling would become necessary.
e.g. in the polling loop we could use semaphores to have high priority for telescope movements and lower priorities for focuser weather and so on. Why poll temperature every second when once a minute is largely sufficient?

Maybe also we could fork the driver to cope with OnStepX new features leaving the current driver for people having older hardware.
I know, ideas are easy, time to implement is another topic. I was believeing I would have more time after retirement .... it is the contrary, my boss is now behind me 24h a day

James,

Thank you for your work on this.

I'm sure I have made a mistake somewhere in my testing but I don't understand your comment about not using park.
When one powers off OnStep whether it has been sent to a park position or not doesn't it come up in a Park state?
Then you would have to unpark it in Ekos before you would be able to slew. That is all I was trying to do in the
last log I sent you.

Anyway, I like azwing think that with the added complexity of the future OnStepX leaving the older driver as is -- call
it OnStep_Classic (old soft drink reference, sorry), and forking to a more complex OnStepX driver would be a good idea.

For those clamoring for the driver to handle both focusers I'm thinking they can use the Android app. Usually (I think) only one
focuser is used frequently during an imaging session - that's how I use it anyway, everybody is different I guess.

Thanks again,
Jack

@Jack

Parking is a feature where one can choose a convenient (arbitrary) position to move the telescope (or observatory) when session is finished.
When parking occurs telescope moves to this predefined position and everything is at rest (motors not powered ....).
When in this position before any movement / action can be taken a "unpark" command must be issued, which just put the telescope in ready to operate state (tracking is started).

Thanks Alain,

That is my understanding of Park as well.

Jack

So would you say the focuser is a bit out of "scope"? 
 

Parking seems only to be for the pointing.

I had thought it saved PEC position, but that doesn't appear to be the case. (Or if it does, it appears to do it before a move which... doesn't really work for saving the position.)

As far as the OnStep vs OnStepX. Right now I think there's 0 point. Or maybe 0.002 sec of a point (how long it takes to probe for the focusers on a mega, sans stupid programming mistakes by someone. Theoretically it's 0.0026 sec, but rounding errors, and batched serial communication over USB) There's still a lot that the INDI driver doesn't support, or needs to be looked at: PEC, Outputs, Weather, etc.

But we've got issues with the compatibility, like (and I don't mean this to be any slight at @azwing, I just looked at it most recently) the outputs for example, there's two commands :SXX____ for the current stuff (currently implemented, for some outputs) and :SXG____ for things older than ~Oct 2020 (Currently not implemented. I didn't narrow the date down too much) Which gives rise to what we want to support. Do we want to have that fall back to the old command? Another recent example is the High precision location, which I do have it falling back, and that's a change that's < 1 year old. The fallback there was easy. Should we add the :SXG commands as a fallback? Which I think would require rewriting the detection function or just go: "Upgrade!"

Which kind of gives us a dilemma on what we should consider for the INDI driver, for any changes in a project which can be easily downloaded and reloaded onto the microcontroller? Thoughts on maintaining compatibility with old versions? Which is in some ways necessary with commercial stuff (*insert flashbacks of aggravation in trying to re-flash Meade controllers*) due to difficulty (or impossibility) of flashing newer versions. (Though they are starting to get their act together with regards to that.) as opposed to something where to even have it work it has to have an easy path to flashing.

It'd be nice but somewhat impractical, if OnStep just stored config.h and could spit that out. It's 26KB alone, at least on my machine and while I've added a little, I strongly suspect it's less than 1KB. Though that might be something on large flash sized controllers like the ESP32.

Somewhat philosophical questions aside, looking at the outputs, It seems like it'd be better to do it via separate handlers for each type because of the differences, and simply display them on the OUTPUTS tab, rename to FEATURES or leave as OUTPUTS?

Current list from constants, and some documenting for reference later.
#define SWITCH                      1
#define ANALOG_OUTPUT               2
#define ANALOG_OUT                  2
#define DEW_HEATER                  3
#define INTERVALOMETER              4
#define SWITCH_UNPARKED             5

SWITCH is an output switch (might be named digital_output to be a bit less confusing, as that seems to imply you can trigger it, but anyway)
Format :SXX_,V_#
First _ is output number 1-8
Second _ is value 0 or 1
If the pin is assigned to a DS2413, it will turn the sensor on or off.

ANALOG_OUTPUT is an pwm output
Format :SXX_,V_#
First _ is output number 1-8
Second _ is value 0-255 which is passed to AnalogWrite (see arduino for details)

DEW_HEATER is a  heater output
Format :SXX_,?_#
First _ is output number 1-8
The ? and second _ depend (Only 1 can be used at one time, so to set all 3 you'd need to make 3 calls):
V_ : 0 = Off, 1 = On
Z_: -5.0 to 20, "Zero"
S_: -5.0 to 20, "Span"

(I would need to look into Zero and Span, as Dew Heaters haven't been a huge priority of mine.)

INTERVALOMETER is a camera trigger output, holds the output high while an exposure is going on.
Format :SXX_,?_#
First _ is output number 1-8
The ? and second _ depend (Again Only 1 can be used at one time, so to set all 3 you'd need to make 3 calls):
V_ : 0 = Off, 1 = On (I believe this starts it)
E_: 0.0-3600.0 Exposure length
D_: 0.0-3600.0 Delay (I presume between pictures)
C_:0-255 Count

SWITCH_UNPARKED is a switch tied to if the mount is parked/unparked. It can be called as a switch, but will return nothing and possibly cause a 5 sec timeout, if not implemented well.

I'd suggest that we look at doing those as separate interfaces, if detected. (With the :GNY, it should give use the values, which the current code adds onto the end.)

(The intervolometer would be great for some of my cameras which don't support bulb mode (Nikon D5100, D3200) if tied in with the gphoto photo port trigger. Though that needs modification in OnStep for IR (which is how I use it, via another arduino with an IR led and the Arduino NikonRemote program, or my phone.)) Anyway this post is already way too long.

 

Still in the process of getting the outputs done.

I went hunting a little, and found a few things that could be improved. They are now in main repository. (There was a timeout after tracking On/Off, Parking?, The OnStepX focuser type checks had an issue on V3, so I fixed that as well, it'll timeout once there.)

There may be more, I need to look at some of the replies, the main issue is the use of some of the lx200 functions which expect a # string, and OnStep returns either a single character vs a # terminated string, or in some cases times out. I think I've gotten most of them, with V3 to V5.

I also changed the high precision to be off, and implemented the most basic version checking. It will turn on High precision on connect if it sees OnStep, or On-Step and V4 or V5 or in the case of OnStepX. Otherwise it's off with no timeout caused. If you are using an old version of V4/V5 it might not support that in which case it will cause a timeout (once, effectively the same behavior before the changes).

Timeouts that I don't see a way around:
TMC_SPI detection currently is 2 seconds to check for it's presence and a timeout if not present. (This actually will likely go up, as it appears that TMC_SPI which used to be RA+DEC Both or None is per axis now) 


Copying my old todo:
1. Changing the MaxRate replacement (degrees per sec)
2. Intervolometer support
3. Focuser Changes
4. Dew heater
5. Weather support. (Read BME280/etc)
6. Tangent arm support (Plate solve then adjust?)
7. Check backlash values (Changed to allowed to 3600)
8. DC Focuser support (Not sure if that works already or not?) Might need someone who has one to help with this.
9. TMC_SPI reporting support. (I got one for testing, and finally went to put it in on this cloudy night. I unfortunately missed the: You have to have both axis be SPI if one is, so this will be working at some point, but when is a big question. Oops.)
10. Equivalent of MoveAxis support to allow for following satellites. (Kstars issue more likely than OnStep directly, as the custom rates are added in, but Kstars doesn't have a way to send the rates/information, AFAIK)
11. PEC Import/Export
12. Check uses of getCommandString and replace any which might not return with the replacements (getCommandSingleCharResponse/getCommandSingleCharErrorOrLongResponse)
13. Implement checksum for packets See: onstep.groups.io/g/main/topic/27153325

Also, @Jack I just was able to duplicate and found the cause of the Unparking issue, and submitted another pull request a minute ago. It had been set to only read it from a clean state only from when it first connected. After that it would read only specific things depending on the state. (I suspect an artifact from a long time ago, maybe before :GU# had everything including Park status?) I got rid of the conditionals (there is no extra scope communication) so it updates it every update. (Which also isn't perfect (there was/is? a timing bug with KStars on alignment, if it sees a move start, but the status updates), but eh.)

In that case, dome lock was on, so the unlock would fail, but the state would get set to not parked (don't recall what it was, and doesn't matter) but that was/is tracked in the telescope class so it'd go: Hey, you are already unparked. I'll look into it a bit more, in case it's a problem for someone else.