Slowing Marlin rotary encoder

My encoder for my Ultipanel type controller on Marlin has defined 'clicks' when you turn it. However it seems to be giving out 4 pulses for each of those clicks. This makes it hard to input numbers for setting the bed temp (for example) as the encoder wants to stop on one of those clicks.

I noticed that the ultrapanel.cpp has a define of ENCODER_STEPS_PER_MENU_ITEM 5 which makes the menu jump only on the click (there about's, I haven't changed the number to reflect my encoder yet as I have only just found it ). I Was wondering if anyone knew where I could change the input routine for the encoder to divide all the pulses by 4 so that it only ever advances on the click of the wheel and not have these intermediate steps.

In ultralcd.pde you will find the commands for each individual menu entry and they include the size of the increment.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Sublime, I think he's trying to adjust the "touchiness" of the encoder.

I know myself, that when I want to set the speed back to 100%, sometimes I have to play with the encoder because if keeps jumping between 99% and 101%. I have to turn the wheel very slowly and it seems too touchy. I hadn't even considered that the encoder resolution was set with a #define, but based on the name mentioned above, I would bet that's the ticket.

I'd say give it a shot - it's just software. You won't break anything, and if it doesn't work, it's easy enough to revert.

I'd be interested in what you learn.

@jbernardis

That is exactly what I mean. It is a pain that each click is subdivided into 4 pulses when trying to set variables. I too have the LCD jump between 98-101%.

I have found two sections in the code (ultralcd.cpp)

        if (encoderDiff)
        {
            lcdDrawUpdate = 1;
            encoderPosition += encoderDiff;
            encoderDiff = 0;
            timeoutToStatus = millis() + LCD_TIMEOUT_TO_STATUS;
        }

and

//manage encoder rotation
    uint8_t enc=0;
    if(buttons&EN_A)
        enc|=(1<<0);
    if(buttons&EN_
        enc|=(1<<1);
    if(enc != lastEncoderBits)
    {
        switch(enc)
        {
        case encrot0:
            if(lastEncoderBits==encrot3)
                encoderDiff++;
            else if(lastEncoderBits==encrot1)
                encoderDiff--;
            break;
        case encrot1:
            if(lastEncoderBits==encrot0)
                encoderDiff++;
            else if(lastEncoderBits==encrot2)
                encoderDiff--;
            break;
        case encrot2:
            if(lastEncoderBits==encrot1)
                encoderDiff++;
            else if(lastEncoderBits==encrot3)
                encoderDiff--;
            break;
        case encrot3:
            if(lastEncoderBits==encrot2)
                encoderDiff++;
            else if(lastEncoderBits==encrot0)
                encoderDiff--;
            break;
        }
    }
    lastEncoderBits = enc;

I have been playing but while I can make basic Arduino programs I am in no where near the leage of the guys doing Marlin! I have tried removing the if statements in encrot1-3, in an effort to make it update only once per 4 pulses, but it led to very unpredictable behaviour (jumping the numbers by a large amount intermittently).

I feel that it is in the last code that something needs to happen. In my mind I have this idea it would count 4 pulses before returning a positive or negative update. Just not sure how to do that. I'll keep playing!

Just change

encoderPosition += encoderDiff;

to

encoderPosition += encoderDiff / 4;

---

[www.hydraraptor.blogspot.com]

I had previously tried that but unless it received at least 4 pulse per interrupt it didn't register any change however think I have it now though (using an extension on that idea) change:

if (encoderDiff)
        {
            lcdDrawUpdate = 1;
            encoderPosition += encoderDiff;
            encoderDiff = 0;
            timeoutToStatus = millis() + LCD_TIMEOUT_TO_STATUS;
        }

to

if (encoderDiff % 4 == 0)
        {
            lcdDrawUpdate = 1;
            encoderPosition += encoderDiff / 4;
            encoderDiff = 0;
            timeoutToStatus = millis() + LCD_TIMEOUT_TO_STATUS;
        }

this way it only goes when the encoderDiff is divisible by 4.

It isn't perfect, you don't get the immediacy that the old way offered on the LCD display when you turn the dial quickly, it can lag a little at times. But it is easier to input numbers when you turn slower.

In my setup I have now changed the 4 in that code to "ENCODER_JITTER_CORRECTION" and added a #define under #define ENCODER_STEPS_PER_MENU_ITEM (which I changed to 1 or you end up having to turn the encoder 5 times for each menu item!)

Actually scrap all of that, it does work, but the lag is too annoying!

smartroad

You gave up just a tad bit too early. I changed one line of your code and it works quick as lightning. (well as fast as I have ever seen it! :-) )

in addition to all your code changes just change

if (encoderDiff % 4 == 0)

to

if (abs(encoderDiff) >= 4 )

This updates more rapidly than when you cooincidentally fall on an even 4 tick boundary while not updating untill you have a minimum change of 4 in either direction.

Thanks for your hard work. Now how does this get into future martin code?

Merged.

[github.com]

I'm using a Chinese clone of the rep-rap-discount 20x4 line LCD panel. I think the knob is turning in the wrong direction (ie: counter clockwise to increase or scroll down). The first click of the encoder is lost going though a menu. I think my encoder generates 4 transitions per detent. Each click does move the menu cursor only one step, however on the prepare->move axis-> command each click moves the setting by 4 (If I slowly turn the knob between detents it will generate single counts).

ENCODER_PULSES_PER_STEP is set for 4, which seems right for the menu, but yet I still get 4 clicks on the counts.
ENCODER_STEPS_PER_MENU_ITEM is set to 1. This seems backwards from what is actually happening.

Any ideas?

Edited 1 time(s). Last edit at 06/14/2014 04:30PM by kscharf.