Marlin: Viki panel problematic with button reads on 1.1.0-RC3

[bryanboettcher]

Possible duplicate of https://github.com/MarlinFirmware/Marlin/issues/2681, although I implemented the fixes proposed and I'm still experiencing the issue.

The encoder works fine, but the main button in the middle of the Viki 'wheel' is sluggish to respond, and immediately selects the next menu option once it's visible. If I "race" it and spin the wheel as the menu is rendering, sometimes I can get it to stay on the next page. Youtube video of behavior shown:
https://www.youtube.com/watch?v=wrIqe1lumpM (give the white-balance a few seconds...)

_I am willing to send a Viki to any Marlin dev who reasonably thinks they can tackle this, but needs hardware_

[Roxy-3D]

Is it Viki's that are having a problem? Or is it Viki-II's that are sick?

[Blue-Marlin]

The video shows a 20x4 character display. A VIKI2 is full graphic.

[thinkyhead]

Is it still acting up with the current RCBugFix code? Also, have you played with the ENCODER_PULSES_PER_STEP and ENCODER_STEPS_PER_MENU_ITEM values to see if you can minimize the issue? If you've already been through all that, we shall move on to looking into a possible code issue. Of course be sure to tighten all the cables, again…

[bryanboettcher]

@thinkyhead: still broken on the latest RCBugFix as of today. Behavior is unchanged. I downloaded a fresh ZIP, unpacked it, set the board and enabled VIKI. That's all I did, and the buggy behavior is still there.

The encoder itself is behaving fine, I can move through menu items no problem once I get there. The behavior is in the button-press code, which changed from the (working) 1.0.x by adding the LCD_HAS_SLOW_BUTTONS stuff, due to doing I2C reads differently now.

What's next?

[thinkyhead]

I think I might have found a small bug, but I don't know if it will have any effect on this. Try this and see if it does anything at all. Find these lines in ultralcd.cpp around line 1923:

#if BTN_ENC > 0
  if (now > next_button_update_ms && READ(BTN_ENC) == 0) newbutton |= EN_C;
#endif

Change them to:

#if BTN_ENC > 0
  if (now > next_button_update_ms && READ(BTN_ENC) == 0) {
    newbutton |= EN_C;
    next_button_update_ms = now + 300;
  }
#endif

[bryanboettcher]

It had no effect, positive or negative. Is there anything I can do to help you debug this more easily?

[thinkyhead]

What happens if you simply comment out the lines #define LCD_HAS_SLOW_BUTTONS to prevent slow buttons from being used?

[Hidden-Dragone]

Have you found the issue yet? I'm having the same problem, uploaded RC4 but still doesn't work properly. Even tried commenting out #define LCD_HAS_SLOW_BUTTONS but that stops it from working altogether.

[Blue-Marlin]

I guess the former position of lcd_implementation_read_slow_buttons() was not so bad. Please try:
in ultralcd.cpp

@@ -1858,17 +1858,17 @@ void lcd_update() {
       lcd_sd_status = sd_status;
     }

   #endif //SDSUPPORT && SD_DETECT_PIN

+  #if ENABLED(LCD_HAS_SLOW_BUTTONS)
+    slow_buttons = lcd_implementation_read_slow_buttons(); // buttons which take too long to read in interrupt context
+  #endif
+
   millis_t ms = millis();
   if (ms > next_lcd_update_ms) {

-    #if ENABLED(LCD_HAS_SLOW_BUTTONS)
-      slow_buttons = lcd_implementation_read_slow_buttons(); // buttons which take too long to read in interrupt context
-    #endif
-
     #if ENABLED(ULTIPANEL)

       #if ENABLED(REPRAPWORLD_KEYPAD)
         if (REPRAPWORLD_KEYPAD_MOVE_Z_UP)     reprapworld_keypad_move_z_up();
         if (REPRAPWORLD_KEYPAD_MOVE_Z_DOWN)   reprapworld_keypad_move_z_down();

[thinkyhead]

Based on the fix proposed by @Blue-Marlin, #3308 is queued up in case we need it.

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

[3dfab]

Guys, with the latest bugfix release im having this issue. Is there anything that i can try?

[thinkyhead]

Still looking for a cause. These Viki panels are temperamental. I've been working with a client whose encoder button simply doesn't work at all, and that appears to be totally due to the panel. Have you found it to work if you install Repetier Firmware, for example?

[3dfab]

Ok, how can i help?

On Mon, Sep 12, 2016 at 8:06 PM, Scott Lahteine [email protected]
wrote:

Still looking for a cause. These Viki panels are temperamental.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3007#issuecomment-246523654,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFPy8QVex-l5MUkEqQsgIittEFxSxKmHks5qpdrxgaJpZM4HdcCf
.

[bryanboettcher]

The offer to ship a Viki board to a dev still stands, by the way.

On Mon, Sep 12, 2016 at 7:34 PM, 3Dfab.ar [email protected] wrote:

Ok, how can i help?

On Mon, Sep 12, 2016 at 8:06 PM, Scott Lahteine [email protected]
wrote:

Still looking for a cause. These Viki panels are temperamental.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
3007#issuecomment-246523654>,
or mute the thread
l5MUkEqQsgIittEFxSxKmHks5qpdrxgaJpZM4HdcCf>

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3007#issuecomment-246538328,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA--064PioqAThuwkQRPY3o3wi9x_i3Zks5qpe9_gaJpZM4HdcCf
.

[thinkyhead]

Ok, how can i help?

Install Repetier Firmware and confirm that the panel works. If all is well, then we can take a look and see what Repetier might be doing differently.

[thinkyhead]

The offer to ship a Viki board to a dev still stands, by the way.

I would totally take you up on that offer, but I'm in Austin, Texas and away from my machines for the next couple of weeks. I do have several RAMPS-based boards to test with here, however, so… I dunno. Maybe!

[3dfab]

With older versions and with repetier it works. If I turn the encoder
really fast after pressing it I can, sometimes, get into the menus.

On Sep 13, 2016 5:37 AM, "Scott Lahteine" [email protected] wrote:

The offer to ship a Viki board to a dev still stands, by the way.

I would totally take you up on that offer, but I'm in Austin, Texas and
away from my machines. I do have boards to test with here, however, so… I
dunno. Maybe!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3007#issuecomment-246613804,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFPy8SgmPr0IZACDuf4__nzzVkrbBPjRks5qpmDUgaJpZM4HdcCf
.

[thinkyhead]

Hmm. I suspect the "debouncer" might have issues with this particular display. See if adding #define LCD_HAS_SLOW_BUTTONS to your configuration makes any difference. Meanwhile, I will take a look at the debounce code and see what's changed since 1.0.2-1.

[3dfab]

I added that to the bugfix version and it's the same.

[thinkyhead]

I see the difference between the old and new code. Previously (in 1.0.2) when a button was pressed resulting in a "click" sound we set a half-second timer and ignored button presses until it expired. So if a button was continually sending presses (or if it registered as "click" on both the button press and release) then it wouldn't have this effect.

So, I'll try that approach and post a branch for you to test shortly.

[thinkyhead]

Actually, I see we do still set the 1/2 second timer, but there might still be some tweaks I can make to ensure the button value isn't left in a stale state (i.e., still pressed).

[thinkyhead]

Try this, for a start, and see if it's enough to make a difference:

  void lcd_quick_feedback() {
    lcdDrawUpdate = LCDVIEW_CLEAR_CALL_REDRAW;
+   buttons = 0;
    next_button_update_ms = millis() + 500;

    // Buzz and wait. The delay is needed for buttons to settle!
    lcd_buzz(LCD_FEEDBACK_FREQUENCY_DURATION_MS, LCD_FEEDBACK_FREQUENCY_HZ);
    #if ENABLED(LCD_USE_I2C_BUZZER)
      delay(10);
    #elif PIN_EXISTS(BEEPER)
      for (int8_t i = 5; i--;) { buzzer.tick(); delay(2); }
    #endif
  }

[3dfab]

Where should I make the changes?, will test it in 4 hours!

[thinkyhead]

Where…?

See above.

[3dfab]

I just uploaded your rc_lcd_button_fix branch. It woks.

I love you.

Will test it further later, time to feed the kids now.

thanks!

[boelle]

@thinkyhead @jbrazio @Roxy-3D thinks this one is solved?

[3dfab]

From my side, it is, been using it since and its all good.

On Sep 20, 2016 7:16 AM, "Bo Herrmannsen" [email protected] wrote:

@thinkyhead https://github.com/thinkyhead @jbrazio
https://github.com/jbrazio @Roxy-3D https://github.com/Roxy-3D thinks
this one is solved?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3007#issuecomment-248260901,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFPy8bOsA8mzumd8F0U5085YseQLebzGks5qr7KJgaJpZM4HdcCf
.

[bryanboettcher]

Can confirm it's been good for me as well -- sorry for the silence.