Knowing the Turning Direction of a Rotary Switch (NOT encoder)

I am using a 4 way rotary swich, break before make. Each output is connected to a separate digital input on the arduino

All 4 positions will bring a separate input LOW

I am trying to achieve the following and wondering if there is a way without creating many variabbles and constant;y resetting them depending on each switch position.

Positions are Program - Stop - Run - Pause

i need to be able to control the following 2 functions:

1) Whilst in the Run section of the program, the program pauses waiting for a user confirmation. This confirmation will be Switch goes FROM Run TO Pause and then Back to Run. The program will then continue.

2) From the Run position, IF the switch is turned to Stop and they try to Run it again, I will not allow the program to Run, Instead they will have to go from Run to Stop THEN to Program before trying to Run the program again.


A classical state machine. Google for that term.

Interesting, but I'm not certain how I can use it for what I need? Namely to monitor the input states as opposed to output states.

Forget about input or output states. You have some input and depending on what your current state is (so what happened previously) you react differently on the new input.

So when your machine is in idle state you might get a "run" event which lets the state change to "wait_for_confirmation". In this state you accept input from "pause" and "stop". If you get a "pause" event, the state changes to "confirmed_wait_for_run" where you accept input from "run" and "stop". If you get a "run" event, the state changes to "turned_on". And so on. You have to differentiate between (input) events, (output) actions and states.

As far as reading the inputs goes, I suggest you write a function which reads the state of the relevent inputs and returns the identity of the currently-selected input. For example you could return a number in the range 0 .. 3 (or whatever) to indicate which position the switch is currently in. This functions is where you'd put the debounce logic too. A very simple way to implement this is to define a static variable to record the current position of the switch, and update that whenever you found the switch in a different position. This would suit the 'break-before-make' behaviour of your switch.

For controlling the expected sequence of input positions, I'd use a state machine implemented as a switch statement (switching on the current state), with each case containing code to test for the events applicable to the corresponding state.