May be you were an idiot, I'm still one
You really do a nice job.
It is now three times I try to pull request just a little change and cannot because I am lost in all the git labyrinth!
Hope the last try is the good one.

James good work, no crash.

I got tired of waiting for your changes to percolate through to git hub so I pulled them from git.hub/james-lan

No more crashing seems to work but ... the communications back to Ekos is slow as molasses. If I tell it to slew or park for that matter
the scope starts (a tad slower than what I remember) but once started it moves fine gets to its position and we wait like 30 seconds for Ekos
to register anything - like the red bulls eye on a star or the Red Park label.

Thanks for your work, really appreciated.

Jack

Git is both wonderful and the worst part of most projects if you do something wrong, or there are commits to the same file in the relative area. (Then if when going through to fix it, you miss a section.) These examples are not pulled from the past week (not at all) /s

That looks good. I started to work a little on it, after someone else contributed it. Unfortunately, I got distracted, so there are a few functions OSEnableOutput & Disable which are placeholders. The one that's not is OSGetOutput state, though it's working on different variables. That should probably be merged and/or removed.

One question though, why not do it starting from 1 instead of 0, leaving the 0th always unconfigured?

Not to worry James,

I went back to the lx200_onstep.cpp and lx200_onstep.h from last week and polluted my git pull directory with those versions
then rebuilt and all is working. I'm sure there is a reference to rev 1.10 that should be 1.9 or some such - oh well, it works.

Thanks for looking into this for us.

Jack

So for this. Can you run a full log and get everything between :GR# and :GR# ?

That will at least show me where the issue is occurring. Because I can't reproduce it on a mega. (It takes about 200msec for it to pull an update (+ polling time which starts after that completes.)) 

Or if you can find what it is, ex: (This is the polling at 300ms)

[2021-05-29T07:24:21.242 CDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:fG#> "
[2021-05-29T07:24:21.250 CDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <136> "
[2021-05-29T07:24:21.250 CDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Fa#> "
[2021-05-29T07:24:21.254 CDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <1> "
[2021-05-29T07:24:21.254 CDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] :Fa# return: 1 "
[2021-05-29T07:24:21.554 CDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2021-05-29T07:24:21.565 CDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <15:17:31> "
[2021-05-29T07:24:21.565 CDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] VAL [15.2919] "

Ok, lets see if I get these log files attached.

The procedure was,
    - Start up devices in Ekos
    - Unpark
    - Slew to AZ = 180 (due South), ALT = 27
    - Wait for arrival via Bullseye
    - Park
    - Wait for Red Parked label
    - Shutdown

The file labeled old_drivers is last weeks working code
The file labelled new_drives is the new non-working code.

Thanks,
JackOk, lets see if I get these log files attached.

The procedure was,
    - Start up devices in Ekos
    - Unpark
    - Slew to AZ = 180 (due South), ALT = 27
    - Wait for arrival via Bullseye
    - Park
    - Wait for Red Parked label
    - Shutdown

The file labeled old_drivers is last weeks working code
The file labelled new_drives is the new non-working code.

Thanks,
Jack
  
 

Ok, I left the rotator checking code on, which is causing a delay.

So I've gone through and checked that on initialization. If a rotator is not detected it will not poll it, which will eliminate the time you were seeing. Additionally, and I may apply this to the focuser in the future, it will not show the rotator control panel.

Additionally, I lowered the delay from 3 to 1 second (minimum) on timeout for some functions called. Which honestly is still too long for OnStep. (There are some further up lx200 calls, which have a timeout of 5 seconds, this won't affect them, to change that would require a global change for the lx200, or modifying about every other function in lx200driver.cpp to add a timeout calling parameter (and all of the ~20 lx200 drivers which use it))

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?