Arduino Encoder Programming: Troubleshooting Missed Pulses with Profi-360-06-AABBZZ Encoder

Hello,

I decided to test the encoder I purchased today. . After connecting the encoder to it, the arduino reads the pulses, but has a tendency to miss them. What could be causing them?

The encoder used for work: http://sklep.cncprofi.com/enkoder-profi-360-06-aabbzz.html
Connection: Straight to Arduino Vcc-5V, Gnd-Gnd, Pin A to Pin 2 and Pin B to Pin 3 (with 300 Ohm resistors).
Code: from the arduino playground website


Greetings,
TraCerT

Resistors should be 10k.
Download the Rotary library, you have ready and precise encoder support, either in interrupt or normally, of your choice.

Greetings

@TraCerT It's hard for him not to miss pulses if you don't check the encoder line status all the time the serial is sending data, and these can be milliseconds. In this case, the encoder operation should be based on interrupts.

[syntax=c]

#include

Rotary r = Rotary(2, 3);

void setup() {
Serial.begin(9600);
PCICR |= (1

@DarkMajster The same error, and even worse - the time-consuming function of sending data via UART you put in interrupts. Additionally, the comparison of result == DIR_NONE does not make sense, since the {} clause is empty.
It is also worth adding that the solution which is to connect the encoder outputs to the pin interrupts is ok in this case, but only because we have an optical encoder that does not generate vibrations. It wouldn't be a good solution for a mechanical encoder.

I can see that my colleague DarkMajster put in an example from the library I recommend, but I recommend the pooling mode because it is not always possible to use interrupt pins that are not there too much, and the service in this mode also works very well on "regular" pins. Of course, provided that you do not pack your code with delays.

Greetings

rs6000 wrote:

I can see that my colleague DarkMajster put in an example from the library I recommend, but I recommend the pooling mode because it is not always possible to use interrupt pins that are not there too much, and the service in this mode also works very well on "regular" pins. Of course, provided that you do not pack your code with delays.

Greetings

Pooling is the worst possible solution. Due to the unpredictability of the digestion time of the main loop of the program, you will miss pulses from the encoder. Normally the encoder is handled on the timer interrupt - just fire it from at least 2xf the encoder to recreate its signal. As a result, we have a constant, predictable CPU load, without losing pulses.

tmf wrote:

@DarkMajster The same error, and even worse - the time-consuming function of sending data via UART you put in interrupts. Additionally, the comparison of result == DIR_NONE does not make sense, since the {} clause is empty.
It is also worth adding that the solution which is to connect the encoder outputs to the pin interrupts is ok in this case, but only because we have an optical encoder that does not generate vibrations. It wouldn't be a good solution for a mechanical encoder.

Of course I did, I just put an example from the library

Hello and thanks for any tips

Overall, I changed the resistance to 10k Ohm and wrote a program in interrupts. I don't really need serial functions, because I check the angle with the stabilization of the inverse pendulum (so you can see that when it's around 180, the motors should stand still). Unfortunately, this happens only at the beginning for about 2-3 seconds, and then the stabilization is not assumed where it is needed (e.g. the required stabilization angle of 180 is after some time at the angle of 175). It turns out that the encoder is still losing steps. So I would like to ask for advice (preferably step by step as you can describe, because at the moment I am green: /). I don't know if this error exists in the program, or maybe in some settings or maybe it just should be like that - hysteresis?

Here I will present all the code used to stabilize the pendulum


greetings
TraCerT

First of all, what I wrote to you before - the encoder encodes the position in the Gray code. So in order to get information about the change of the encoder position, you have to decode the signal. Needless to say, you are doing it wrong. Another thing - you need to atomically access the variable position0encoder - volatile does not do everything. Access to this variable from the level of the main loop of the program must be included in atomic blocks (of course as short as possible, so as not to miss interrupts from the encoder).

In an incremental encoder there is a position encoded in Gray code ???

TraCerT wrote:

In an incremental encoder there is a position encoded in Gray code ???

How else would the information about the direction of rotation be sent? You have signals A and B that need to be decoded. In yours you also have a Z signal informing about the absolute position of the encoder shaft, which would also be worth using.

Quote:

In an incremental encoder there is a position encoded in Gray code ???

Probably the question was that the position is not coded, but the increment.

tmf wrote:

TraCerT wrote:

In an incremental encoder there is a position encoded in Gray code ???

How else would the information about the direction of rotation be sent? You have signals A and B that need to be decoded. In yours you also have a Z signal informing about the absolute position of the encoder shaft, which would also be worth using.

Then I have to read a bit about decoding ... And is the direct connection (Vcc-5V, Gnd-Gnd, Pins 2 and 4 respectively with A and B with 10k Ohm resistors) correct, or can it have an influence on it?

This method of connection is OK. However, the encoder used offers differential signals, so in an environment with mega noises it can also be used.