Marlin: Rotary encoder directional mismatch

Created on 8 May 2016  Â·  9Comments  Â·  Source: MarlinFirmware/Marlin

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

Question

Most helpful comment

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.

All 9 comments

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.

Is there a separate option for numerical values?

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

I have inverted the rotary encoder in config

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

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.

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.

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..

@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.

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

W8KDB picture W8KDB  Â·  4Comments

pubalan12 picture pubalan12  Â·  4Comments

ShadowOfTheDamn picture ShadowOfTheDamn  Â·  3Comments

Anion-anion picture Anion-anion  Â·  3Comments

Glod76 picture Glod76  Â·  3Comments