> So yes, buffer clearing is a good idea, but how long would one wait? SWS has a default of 200 ms timeout, plus the time a command takes on OnStep. It varies. Maybe 250 ms minimum timeout is safe? I don't know.
For network (CONNECTION_TCP) specifically, It's (like everything should be) detected on startup. I've got it set to 2 seconds, otherwise 100ms if wired. Messages in the INFO log (ie displayed for users) should be:
* Network based connection, detection timeouts set to 2 seconds
* Non-Network based connection, detection timeouts set to 0.1 seconds
As of the latest version, which I don't think I uploaded to github quite yet, run about 9 hours, I see 29 times the buffer gets flushed, actually just checked a bit later, and it's now 32, with 33 events indicating a read error of some type. So at least with my network that's about 3-4 an hour. Sometimes in batches, sometimes, alone.
One example (flushIO error type = 0 indicates it read something, -4 indicates it timed out (this is expected if we have no data for it to clear. In playing around I increased it to 10ms) In this :GX95# is correct and you see the 2 second timeout on the RES to GX96, which it then returns from in ReadScopeStatus so things like the focusers don't get checked. You see the next :GU# get called. (I have a really low polling interval, 50 ms, which is why it might look like it goes immediately to :GU#.)
"
[2021-11-25T03:30:24.163 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GX95#> "
[2021-11-25T03:30:24.163 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] flushIO "
[2021-11-25T03:30:24.173 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] flushIO: error_type = -4 "
[2021-11-25T03:30:24.182 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2021-11-25T03:30:24.182 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GX96#> "
[2021-11-25T03:30:24.182 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] flushIO "
[2021-11-25T03:30:24.192 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] flushIO: error_type = -4 "
[2021-11-25T03:30:26.194 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <> "
[2021-11-25T03:30:26.195 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] Error -4 "
[2021-11-25T03:30:26.196 CST INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[ERROR] Communication error on Preferred Pier Side (:GX96#), this update aborted, will try again... "
[2021-11-25T03:30:26.196 CST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Idle" to "Error"
[2021-11-25T03:30:26.245 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] flushIO "
[2021-11-25T03:30:26.245 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] flushIO: error_type = 0 "
[2021-11-25T03:30:26.245 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GU#> "
[2021-11-25T03:30:26.245 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] flushIO "
[2021-11-25T03:30:26.255 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] flushIO: error_type = -4 "
[2021-11-25T03:30:26.263 CST DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <nNp/EW057> "
One thing I don't like and I may change the behavior of is that returning false from the function sets the state to ERROR. Which per docs is technically correct. However, practically isn't entirely correct. Yes, communication error, but with the bounds checking in there now, and bailing, I'm not sure I'd say that the telescope is in an error state, and I worry about things bailing out. I may also change the Communication errors from LOG_ERROR to LOG_WARN (Still would show up for users). Anyone's thoughts on either of those changes?
Actually a quick check in KStars, I'm going to change that, because there are a couple of places it bails out if that changes that it won't restart jobs. (Slewing is one, I'm not completely sure about it's effect on imaging.)