Informational: Encoder counter roll over to zero

[mfarabee]

I used this library to create a DRO (Digital Readout ) for a lathe. It worked great, but I ran into one problem and wanted to share this in hopes of saving people debug time. It might be good to mention this in the library documentation.

I was using a 600 step rotary encoder in quad mode. This produced 2400 steps per revolution. As my lathe bed has about 36" of travel, I would have many revolutions of the encoder from one end to the other. I ran into the problem that as I was moving, my DRO would reset to zero. I finally tracked this down to the encoder output. The library uses a 32 bit signed integer and this can overflow (sort of). When the encoder count reaches the max positive or negative number it rolls to zero. I had to add a function in my code to count the roll overs so that I could keep my position accurate.

/The encoder will rollover to zero and continue in positive or negative direction
-> 0, 1, ... 32766, 0, 1, ...
-> 0, -1, ... -32767, 0, -1,...

Great library!

[madhephaestus]

there is a wrapping system built in, can you check the latest to see it it still wraps?

[mfarabee]

Awesome, I see that you changed from int32 to int64. That should fix it for me as I will not roll over with a int64.

I did not notice that you had roll over built in. It looks like I would check if "attachedInterrupt" turns true?
If I understand what is going on:

• The problem is the the pulse counter module (pcnt) uses int16. This limits the max count.
• The getCountRaw will now return a int64, but is still only a 16 bit number (from pcnt).
• getCount DOES take into account the roll over. Previously it supported a number up to 32bit, but now you have increased this to a 64 bit number. This should fix my problem as I will be within that max count.
• If you are using getCount and the number exceeds 64 bit, you will need to handle this outside the encoder library.
• It looks like the "attachedInterupt" variable does not get reset. If I am checking this and find it 'true', will I need to reset it after processing the count in my code. Is this correct?

I am looking forward to seeing an example on how to use the overflow. I might be using the encoder differently from others, as I am trying to determine the exact location, so I need a linear increment. I set the count to zero then if the count overflows (previous count >30k, current count <1k), I then increment a multiplier that I use to calculate the actual count. Obviously I do additional checking if it rolls over negatively.

I assume I would still need to track the count and if I detect a roll over (interrupt turns true) I would add/subtract the max value? How will I know if I hit a roll over from negative or positive? To use this interrupt flag, it might be better to have an ENUM instead of a bool (LOW_OVERFLOW, HIGH_OVERFLOW, NO_OVERFLOW).

I will try and test tis out in the next few weeks, I only have the one encoder and I am using my lathe a lot and do not want to lose my DRO :-)

Thanks for all of your hard work. I really like the library!

[madhephaestus]

you shouldn't need to do any juggling if you use getCount()

The issue you had is that you were using getCountRaw() at all. I think i should make it private now that i think of it.

[madhephaestus]

the PCNT module has an interrupt that detects rollover case, and calls an interrupt service routine when it rolls over. This library attaches its own ISR and checks all PCNT modules for rollover, checks if its upper or lower limit, and adds the limit (upper or lower) to the total count. WHen you read the encoder, this count is added to the institainious reading from the PCNT module for the most accurate current count.