Encoder stops working when enabling REPRAPWORLD_KEYPAD (Marlin 2.0.9.2)

Hi all,

Recently I upgraded to 2.0.9.2 and added a 2004 character LCD display and a reprapworld_keypad to one of my printers. As controller board I'm using a Megatronics V3.3 .

The LCD and encoder (with switch) are working correctly if I'm enable ULTIPANEL in the configuration file:

#define ULTIPANEL

However, when I also enable REPRAPWORLD_KEYPAD the encoder (and switch) stops working:

#define REPRAPWORLD_KEYPAD
#define REPRAPWORLD_KEYPAD_MOVE_STEP 10.0 // (mm) Distance to move per key-press

So somehow enabling REPRAPWORLD_KEYPAD disables the encoder and switch. I cannot figure out what's wrong. Anybody Ideas?


What I've done to further debug:
- Swapped the keypad with the keypad of another printer running 1.X firmware. Everything works fine then.
- I used an oscilloscope to check the signal levels on the keypad. There also everything seems to be ok.
- I used M43 to check if changes are detected on the encoder pins (BTN_EN1, BTN_EN2, BTN_ENC). That was all ok.

I've attached my configuration files to this post (Configuration.h, Configuration_adv.h)

So, my assumption is that something in the firmware changes between 1.X and 2.0.9.2 that disables the encoder. But I cannot locate it. There are too many changes between 1.X and 2.0.9.2.

Any help would be appreciated!

@bbg

It says on the product page for that keypad
Not compatible with Megatronics 3.2, so it is very likely it is not compatible with Megatronics 3.3 as well.

Edited 1 time(s). Last edit at 12/29/2021 06:05AM by Dust.

@Dust

Sharp! However, the keypad is compatible with Megatronics 3.3. In Megatronics 3.2 they changed the pin-out of headers (always a bad idea) causing that specific version to be incompatible with the keypad. In version 3.3 they reverted back to the old pin-out before V3.2 (but did rotate the header 180 degrees wrt V3.1) . So the keypad is specifically not compatible with 3.2 but it is compatible with 3.3.

I also checked the connections using an oscilloscope and with M43 in Marlin. No strange things there, all as expected

I still suspect the "define REPRAPWORLD_KEYPAD" directive is "throwing out" the code that is reading the encoder (BTN_EN1, BTN_EN2, BTN_ENC). However, I cannot locate that piece of code in the source. I'll do some more searching but it is hard to understand as I'm not familiar with the Marlin code. So I anybody knows where that piece of code is locate, the would be helpful

I think I found the problem (and think it is a bug in Marlin).

In the file "buttons.h" BUTTON_CLICK is defined when IS_RRW_KEYPAD (lines 71-75):

  #ifdef EN_C
    #define BUTTON_CLICK() ((buttons & EN_C) || RRK(EN_KEYPAD_MIDDLE))
  #else
    #define BUTTON_CLICK() RRK(EN_KEYPAD_MIDDLE)
  #endif

where EN_C is the bitmask associated with the encoder switch. I think the idea is that clicks can come from either the encoder switch (EN_C defined) as from the middle button of the keypad.

However, EN_C is only defined later (line 90, when HAS_DIGITAL_BUTTONS). Therefore the second define will always be used. And that explains the behaviour what I saw: When enabling REPRAPWORLD_KEYPAD the encoder switch is not working anymore.

To (quick) fix it I've added the following directly under the definition of EN_C (lines 93-96):

  //bbg
  #if IS_RRW_KEYPAD
	#define BUTTON_CLICK() ((buttons & EN_C) || RRK(EN_KEYPAD_MIDDLE))
  #endif

With this addition the keypad is working as I was expected. I've attached the modified file for any one who can use it.

I do believe this is a bug in Marlin and will file a bug report (but I might be wrong).


Maybe a little unrelated, but just to make a note of it. In my search I found the place where the buttons are updated. That's actually done in void MarlinUI::update_buttons()
(file marlinui.cpp). This method is invoked from an interrupt context. Processing of the buttons is done outside of the interrupt. Hence the volatile variables.

I agree this is a bug

Can you test PR [github.com]
This should fix this

Edited 1 time(s). Last edit at 12/30/2021 12:10AM by Dust.

It has already been merged into bugfix...

I did try the bugfix-2.0.X this morning and can confirm it solves the problem for reprapworld_keypad with Megatronics 3.3.

Thanks!