Rotary encoder - pulser - is an excellent input device for controlling e.g. menus in the device interface. In the following tutorial, we will describe how to use a typical pulser in conjunction with the Arduino module.
Step 1. Watch the movie
If you do not want to read the entire text below, and the English language is not a problem for you, watch the video below - it will certainly help you understand how to connect the pulser and program the Arduino so that the whole thing works together.
Such an encoder is an electromechanical device that translates the angular position or rotation of an axis into a digital or analog output signal. There are two types of rotary encoders:
1) Absolute - The output state of this encoder corresponds exactly to the absolute position of the axis. Thus it is an angle converter. 2) Incremental - the signals at the output of this encoder correspond to the axis movements, so the position calculated on their basis is relative. Processing these signals into data on position, rotational speed, etc. is always carried out remotely.
Step 3. What is an incremental rotary encoder
The incremental encoder gives information about changing the position and its direction (clockwise and counterclockwise rotation). In many applications this functionality is essential, however, this element does not track the absolute position. Therefore, in some encoder applications, it may be necessary to initialize the encoder by moving it to a known, fixed position.
Step 4. Construction and principle of operation
An exemplary encoder that we will use in the tutorial has all the necessary resistors that pull the I / O lines. This element has five output pins:
Clock, Data, Switch, Vcc, GND.
The knob we turn is internally connected to the disk inside the encoder. It will move clockwise or counterclockwise, just like the knob that the user turns. On the surface of this disk there are fields connected to the power line. The remainder of the disk is at ground potential. Above the disk there are two contacts shifted relative to each other by a certain distance - these are the outputs of the Clock and Data.
Principle of operation
When we turn the encoder, the state of the outputs will change with the position of the disk in the encoder. In such a situation, we can observe sequences of impulses on the Clock and Data outputs.
If we look at these impulses, we can see that they are out of phase by 90 degrees. If the encoder turns clockwise, the clock output pulses will be first, and if the encoder turns counter-clockwise, the first pulse will be shown at the data output.
By analyzing the state change on these two outputs, you can immediately judge which direction the encoder knob is turning. Now let's try to implement this analysis programmatically in Arduino.
Step 5. Software
Example 1: (Counter.ino)
Log in, to see the code
In this example the clock pin is connected to pin 3 and the data pin is connected to pin 4. We have connected a switch to pin 5 which activates when we press the encoder.
In the above program, we first defined a series of variables and set the pins to which the encoder was connected as input pins. Finally, a serial port was launched, which we will use for communication and data transmission.
Then the main program loop is started. This is where we read the state of the encoder inputs. The current state is written to the variable state. If state! = State in any iteration, it means the encoder has turned. Then if data! = State it means the encoder turned clockwise and vice versa if the variables are equal. These encoder pulses will increment and decrement the counter accordingly.
The current counter value is then transferred via the serial interface. If the button is pressed, the counter will be reset and the new value will also be sent via the serial port.
At the end of the loop, the new state is written to the variable state and the cycle can start all over again.
Example 2: (LEDBrightness.ino)
Log in, to see the code
In this case, being a modification of the first program, the counter value is used to control the brightness of the LED via PWM. The counter value is directed to the analogWrite function instead of the UART interface. You should only limit the value of the counter to a value from 0 to 255, because such values are taken by the variable controlling the PWM filling.
And that's all you need to easily handle the rotary encoder - the pulser in our device. Do you use such an element in your projects? Show off your implementations and devices, not necessarily based on Arduino modules.
The examples from the first post should be moved to the "How not to write programs" section. The program will work relatively correctly at a low uC clock frequency (no elimination of contact tremors) or when the main loop will be running for a long time. As @ rs6000 wrote, the encoder is best to handle on interrupts.
Incremental encoder, this is an incremental encoder in Polish, what did everyone insist on this encoder type?
The original text is written in Polish as the teacher speaks English , besides, there are errors in it (eg in the names of variables in relation to the program code). It would be preferable for the translator not to translate into a dump, but to make a substantive correction and check whether everything is correct, because yes, his work loses its value and still inexperienced readers are misled.
These algorithms from the article, unfortunately, are bad and would turn out to be a fraction of what's below ... In my project in C on Atmega32 clocked at 16MHz as of today (because the project is being developed all the time) it supports: - 2x 1600imp / rev encoder with a speed of max 15 rev / s, - 2x encoder 10imp / rev with vmax 10000 rev / min, - 1x encoder 25imp / rev with vmax 1000 rev / min, - two programmable independently regulated pulse generators, - buttons, Plus a lot of math operations, adc reading, lcd buffer support, etc. Nothing is lost, nothing is cut, everything counts ... Libraries, of course, their own. This is how the device looks and works There is a chance that I will describe the whole thing in DIY soon
Atmega32 clocked at 16MHz today (because the project is under development all the time)
I have been using the library from Sylwek for a long time, of course the old one, probably one of the first versions. This is a great piece of code. I also use STM, because why not I used to try to lose pulses with an optical encoder 365 imp / rev, using some simple gear, but failed so in my humble opinion I confirm that it is quite good. Sylwek, be sure to publish the latest version, and it's a breeze!
Encoder read only by pooling. For the simple reason that it is deterministic. In the case of vibrating contacts on the interrupts, you suddenly get 10x this frequency of calling the function.
I have a servo motor in one machine, which I control by impulse and read the position with an encoder. During the movement, there are about 20-30 thousand pulses from the encoder per second. I set the pooling frequency slightly below the maximum performance of this AVR, taking into account the rest of the things it does. As a result, the machine can walk all day without missing a single impulse. I can't imagine how this can be achieved with such interrupt predictability.
So correctly: - we choose the timer that has the highest priority in the interrupt table - we set the appropriate frequency for this timer - in its handling procedure, we include a code that increases or decreases the value of a global variable representing the position of the encoder
Whatever else we do elsewhere in the program (main loop, other timer), we do it based on the value of this global variable. This ensures that the encoder reading has the highest priority and always works the same.
In professional devices, a preliminary filter is often used to remove the effects of vibration of the rotary encoder contacts, e.g. something like this:
The circuit shown above was applied to each encoder in the circuit, and each four encoders were read by the HCT165 parallel-serial register, i.e. by polling. In addition, the device also detected the mere touch of the metallized encoder knob, which resulted in the highlighting of the changed size on the screen.
Depending on the type of encoder used in the circuit, only the values of the filtering capacitors C1 and C2 (from 1n to 10n) changed.
I don't know how often these encoders were polled, but probably 20-30 times per second (the encoders were of the 24 pulses per revolution type).
Any system with capacitors at the encoder is lost at the start for me, because it limits the speed of its reading. Maybe in less demanding applications it works well, but certainly not in PROFESSIONAL ones. Often in popular electronics and household appliances you can find an encoder covered with filters, which works properly only with slow rotation. It may even be a well-known and popular company, but there is nothing to say about professionalism. I can assure you that you can make a small and relatively quick program that will be great for vibrating contacts
Nevertheless, handling with capacitors, where the software part is usually neglected, irritates me, because it is enough to wear the encoder a little or a little dirt (which increases the vibrations of the contacts) and it is practically impossible to use it. My algorithm compensates for vibrations in real time and will stop counting when the mechanical damage is really serious.
I looked at your links and I did not find it, but I admit that I did not search too intensively, I found the ripples but I am not interested in it because I do not duplicate someone's ideas, if I'm already looking for inspiration.
Added after 1 [minutes]:
I've done it before ... Google blocked you?
And google is a huge dumpster, I don't have time to rummage there.