Quote Originally Posted by tonyfoale View Post
I was about to reply almost the same, even with the stepper motor analogy.
I cannot see that the state simulator does anything that you cannot do in the base software. It can only be reflecting the commands that you send out.
You cannot replace a missing real-world feedback loop with a virtual perfect feedback loop. Going with the stepper analogy, you command it to move 3 steps, the state simulator can only return that it moved 3 steps, but how many did the motor move. You gain no value by being told that it was 3.
Tony,

The strategy is that the user simply says what state they want to get to and the driver with its state machine figures out how to get there. By having all users pass their requests through the same high-level driver, I am able to prevent a user from changing the hardware and not updating the state machine.

The intent was never to simulate the position on an output shaft. It is to control a RunCam2 camera. The low-level driver accepts a shutter-button push command or a mode-button push command and sends 80 ms pulses to the camera. These commands are meaningless without knowing the current state of the camera. I get that from the high-level driver which contains the state machine including the current (assumed) state of the camera. The user then just tells the high-level driver what they want to do and the high-level driver sends a series of low-level commands to the low-level driver to get there. All the while, it is updating its state machine to reflect what should be the current state of the camera.

I'm not sure this is any clearer. I can say that this is not theory, I have fully tested these drivers and it works as expected.

Rick