Rotary encoder directional mismatch

[Drmaestro]

Hi,
I have inverted the rotary encoder in config, so that clockwise motion goes downward in the LCD menu, however when I try to change numerical values, counter-clockwise increases them, insted of clockwise. Is there a separate option for numerical values?

Thanks

[Roxy-3D]

I noticed that also. I was (forced to) help my brother bring up his printer, and he complained about the dial going the 'wrong' way on the menu. So I told him not to worry, we can flip it and we did. But now the numbers move in a counter intuitive direction.

We definitely don't want to mess with this in the Release Candidate. But this would be worth considering doing in a development branch as soon as our Release Candidate goes Golden.

[Blue-Marlin]

Is there a separate option for numerical values?

No - not directly. Change the pins (BTN_EN1 <-> BTN_EN2) - then use 'REVERSE_MENU_DIRECTION'.

[thinkyhead]

I have inverted the rotary encoder in config

Before we can answer this well… Which option(s) did you use to do that?

[Drmaestro]

First, I've uploaded the firmware without changing any options related to the direction of the encoder. Turning counter-clockwise moved the cursor (and the numbers) downwards, so I've used the REVERSE_MENU_DIRECTION option. This fixed the clockwise issue for the menu items but it persisted for the numerical values. I was about to change the pins also after Blue-Marlin's suggestion to see what will happen but didn't do it yet.

[thinkyhead]

This fixed the clockwise issue for the menu items but it persisted for the numerical values.

But wait. You said:

Turning counter-clockwise moved … the numbers … downwards.

That sounds like what you would want. And REVERSE_MENU_DIRECTION should not affect that.

[Drmaestro]

Sorry, I mixed things up. The change I've mentioned above (REVERSE_MENU_DIRECTION) causes the following behaviour:

• Turning clockwise in menu items moves the cursor downwards (this is what I want, so no problem here)
• Turning clockwise in numerical items decreases the value (this is not what I want, I need this to be corrected, so that when I turn clockwise, numerical values should increase)

Also, I have another question: In the previous version of Marlin, I was able to increase some numerical values as high as I wanted, as fast as I wanted. For example, to check if my extruder was calibrated, I could give a move command for the extruder using the LCD menu item (move 100 mm using the move 1 mm command) to extrude 100 mm. Now, I can only give that command for a very short distance (a few milimeters) and then I have to wait for the movement to happen before I can give another command. Seems like a safety feature to prevent unintended extrusions or long distance moves but I don't know if it can be disabled..

[thinkyhead]

@Drmaestro Aha. In that case, you should just switch the values of the pins BTN_EN1 and BTN_EN2, but don't enable REVERSE_MENU_DIRECTION (because it should already be reversed by this change).

For reference, here's how your controller behaves in all cases:

• Your default: CW moves upwards (bad!) and values decrease (bad!).
• With REVERSE_MENU_DIRECTION: CW moves down (good!) and values decrease (bad!).
• Switching the pins: CW moves downwards (good!) and values decrease (good!).
• Both changes: CW moves upward (bad!) and values increase (good!)

In the previous version of Marlin, I was able to increase some numerical values as high as I wanted, as fast as I wanted. … I have to wait for the movement to happen before I can give another command….

The move functions were tweaked to prevent movements from piling up, but it has that side-effect. There's a PR in the queue that will help with that. #3110 handles axis movement in a separate function, and with some adjustment I hope it will also help to prevent long movements being queued and blocking your ability to switch direction for too long. It also adds a 1/2 second delay before starting a move.

[notoriousbdg]

I'm so glad I found this. I was having same issue, and REVERSE_MENU_DIRECTION didn't work. It would be helpful if the comments in Configuration.hnear //#define REVERSE_MENU_DIRECTION mentioned pin swapping as an additional method to fix the problem.

[thinkyhead]

I've added a new option, REVERSE_ENCODER_DIRECTION to deal with encoders like these, and to remove the need to swap the pin definitions around. #3739 Enable this to reverse the encoder direction everywhere. If needed afterward, enable REVERSE_MENU_DIRECTION to switch the direction just in the menus.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.