From a glance it seems like it's going to cause extra state changes on certain codes with regard to parking (calling setParked(x) results in a change to either PARKED or IDLE, and a variable IsParked being set (accessible through isParked()) and I think that's changed in the past.

Issues with what you've got:
F shouldn't change TrackState. (Park failed, but the state should be processed via n/N )
p and nN only, if it's pn, it'll produce TRACKING when it should be IDLE (here again state should be processed via n/N)
Not sure why the myTrackState?

That own-goto branch of mine, I didn't handle it right, either, when I looked at your code: (F, I and p should be moved in my code before the n/N/P processing, because of the potential call to setParked(false) in them, which could result in an idle state.) Basically moving up the ==parkdata== / ==end...== section should have fixed that issue. (I have pushed the branch, but not tested it, as I need to get away from the computer for a bit, as I keep looking and running through the same logic and questioning it, so I'm going to stop and come back in a while so I don't break anything too badly.)

Please have a look though: github.com/james-lan/indi/blob/own-goto/...ope/lx200_OnStep.cpp (Note it doesn't include IsNewSwitch() settings which can change it.)

Note the multi unparked in ( indilib.org/forum/development/1406-drive...html?start=660#73262 ) should be resolved in the current version, as each call will set status, but will only correct the internal parked variable when needed. (That I have tested some, and so far I haven't had issues with it.)

Issues/TrackState manipulation remaining with mine:
Scope may get set for a split second to TrackState=SCOPE_IDLE when unparking, but that will be correct shortly thereafter within the function. due to the call to set IsParked
Same with parking (but to the correct TrackState=SCOPE_PARKED) so non issue

One thing that could be done is skip the OSStat == OldOSStat check. That would resolve the sync issue and why when you start/stop tracking it gets corrected. (With the isParked() guards around it shouldn't cause any issues for the correct things to be set with regards to TrackState, not sure about the rest of it.) So we'd need to make sure things don't cause issues like messing with TrackState can, but that I think is probably the best case. But it could mask TrackState and other issues as well.

Alright, I'm off, let me know what you all think. (Apologies, I left this up last night, but aside from me being less tired everything else should be the same.)

Read More...