Is it just me, or is LCD menu navigation backwards?

[ntoff]

You scroll down the list by turning the wheel "up" (my encoder is on the side). Increasing values of variables is fine and dandy, you turn the wheel "up" to increase, but menu navigation itself seems reversed.

It's been like this for ages, so I don't know if it's something that can be changed (maybe a user selectable variable?)

[nophead]

It's been mentioned before but for most of us increasing is the same as moving forward in the menu, so clockwise is correct for both.

Other people seem to perceive a mechanical connection between the wheel and the menu and then it depends where the wheel is.

[ntoff]

Yeah it depends where the encoder is physically. On my Mendel it's on the front so it's not quite as odd, but for the LCD I have that's on the side it's really strange. I'm also one of those weirdos with an inverted mouse in video games :p

So is there any way I can change it just for myself? I've taken a look but I don't know which part of the code actually handles navigation, and if there's even a separate handler for navigation and settings changes. Should I be looking in ultralcd.cpp?

[nophead]

Yes, but good luck with changing it as the code is truly horrible.

[ntoff]

I wouldn't know horrible from good, I have no idea what I'm doing when it comes to code. Took me ages to figure out how to add a simple feature to Pronterface.

[nophead]

This is the relevant line: https://github.com/MarlinFirmware/Marlin/blob/Development/Marlin/ultralcd.cpp#L133

[ntoff]

yep, I was afraid of that (that's the part I was looking at earlier)

[thinkyhead]

@ntoff Here's what needs to be done.

1. Create a new variable bool encoder_is_editing = false; which will be set whenever the menu is inside an editing function as opposed to a navigable menu. The lcd_goto_menu function is a good place to clear this flag, and the macro that creates the edit functions (_menu_action_setting_edit_ ## _name) is a good place to set it.
2. Add code to Line 1353 so that it subtracts whenever that flag is false, but adds when it is true.

[oysteinkrog]

I have this same "problem", I fixed it by switching the pins (for ramps I think it was switch 31/33), you can probably find the commit in my fork.

[thinkyhead]

@oysteinkrog @ntoff Switching the pins will reverse the behavior of the controller knob everywhere, including when editing numeric values in the menu. One of these days I'll implement the method I described as a switchable feature.

[ntoff]

Yeah it reverses it everywhere. I added the feature to my own Marlin last night but for some reason it doesn't apply to the "Move Axis" menu, though it seems to work everywhere else. Or maybe I'm just crazy.

I don't even know what I'm doing with C++ so having to take a crash course in it (google)

@thinkyhead don't go to too much trouble right now. I'd rather not tie up the bug fixing with more feature requests. Like nophead said, it depends on how you perceive the knob to function, whether it's a "physical" connection or not, and also its location as on my Mendel90 the navigate + reversed direction for editing feel very natural since the wheel is on the front. It's just my other panel where the encoder is on the side that feels wrong.

[TechMasterJoe]

Is it not fast to just swap the count routine by swapping the + and - in the ISR at lines 1519 to 1532 Just a thought

[AnHardt]

@TechMasterJoe
There are several easy ways to change the encoder direction - like swapping the pins.
But to make the behavior of editing values and moving in menus different is the problem her.

[nophead]

Yes the issue is psychological. Everybody seems to agree clockwise should increase values, most people expect it to move forwards through the menu as well, but a few people think it should go up the menus when the button is arranged to the left of the screen.

[thinkyhead]

Yep, if you look closer you'll see that my approach would work just fine. The only thing you want to alter is menu navigation, and the only way to alter that is to understand that the (stupid?) thing uses the encoder value directly. You could imagine using the inverse or the reciprocal of encoderPosition in the menu navigation, but in fact that doesn't do it either. The simplest way is to simply set a flag when menu navigation is active, clear it otherwise, and only reverse the encoder direction in software (in the manner that @TechMasterJoe and I point out) when that flag is set. There are a few convenient spots to set and clear such a flag, within the menu macros or the menu handlers. I'll mess around with it at some point, I'm sure, if no one else does.

[boelle]

So since we can partly agree that this is psycological related and not a software problem should we not close this one?

[AnHardt]

@boelle
No. We should make this configurable. This problem will pop up over and over again.

[dEDshort]

I usually turn a volume knob clockwise to increase.
That's why I found it strange with controlling knob on LCD Displays.
Actually almost got use to it. Uncomment line 539 and enter -1 for value
//#define ENCODER_PULSES_PER_STEP 1 // Increase if you have a high resolution encoder
Ie_#define ENCODER_PULSES_PER_STEP -1 // Increase if you have a high resolution encoder
I have had no other issues and the knob works clockwise on both navigation and values.

[thinkyhead]

@dEDshort How does that affect editing of values, changing feedrate, etc.? Does it do just what you want everywhere?

[dEDshort]

Yes I believe it works for all adjustments the control knob on the LCD Display is used for.This has been tried with reprap discount displays 2004 and Full 12864 both types on a Ramps 1.4. This is just the encoder logic and should have no changes with anything else. Perhaps just editing comment line in config file would explain changing.

[thinkyhead]

@dEDshort Sounds like for your controller changing the pulses per step is sufficient. For some controllers, we may need to reverse only the menu navigation (so clockwise = up or minus) and not the changing of values (keep clockwise = plus). The ENCODER_PULSES_PER_STEP solution unfortunately doesn't allow the independent reversal of these two functions, but always affects both. So, we still need to add an ENCODER_REVERSED_MENUS option.

[thinkyhead]

Well that didn't take me too long. #3114 adds an option to reverse the direction of the click-wheel, in menus and SD card listings only.

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