Feature request: scrolling in LCD

[batata004]

Hi,

today I almost destroyed again my printer (it has probably 7 lives) because I thought I had clicked in BED LEVELING but some other thing was clicked and I went to the bathroom, when I came back the Y motor was with very strange sound so I disconnected everyting frmo the power.

The problem is this: sometimes I am spinning the knob in my LCD screen and if I find some option that I want to click I click (of course). BUT sometimes right in the moment that I click the knob spins a little bit and the wrong option is seleted in the screen without I even realized that.

I think this is not complicated to fix! My idea would be this: if the click event was fired X milliseconds before scrolling DO NOTHING. For example, if the click is sensed by arduino right after the user is scrolling (for example, 100ms) then do nothing! Cause this is probably some undesired option click cause no user is so agile and precise when choosing an option using LCD, I doubt in 100ms you can finish scrolling and click in some option!

[Tannoo]

Scroll debouncing?

[Tannoo]

Tune these:

//
// ENCODER SETTINGS
//
// This option overrides the default number of encoder pulses needed to
// produce one step. Should be increased for high-resolution encoders.
//
//#define ENCODER_PULSES_PER_STEP 1

//
// Use this option to override the number of step signals required to
// move between next/prev menu items.
//
//#define ENCODER_STEPS_PER_MENU_ITEM 5

[batata004]

I already tuned that and It is working perfeclty. What I repórted is not a debouncing, it's com.pletely differe t. I think It wiuld be pretty usefull tô have this feafure implemented

Em 12 de mai de 2017 10:12 PM, "Tannoo" notifications@github.com escreveu:

Tune these:

// // ENCODER SETTINGS // // This option overrides the default number of encoder pulses needed to // produce one step. Should be increased for high-resolution encoders. // //#define ENCODER_PULSES_PER_STEP 1

// // Use this option to override the number of step signals required to // move between next/prev menu items. // //#define ENCODER_STEPS_PER_MENU_ITEM 5

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

[batata004]

This is not a support question, maybe a feature request.

[Roxy-3D]

This is not a support question, maybe a feature request.

Well actually... I would argue if something is not working correctly, it is not a feature request. It is a feature that needs to be fixed so a 'Bug Report' is probably most accurate.

I think I've seen the LCD Menu jump lines. I'm not sure about that. But I've been paying much closer attention to that question ever since I read your description up above.

[batata004]

@Roxy-3D I totally agree with you, when I said that at least this thread should be marked as a feature request was in response to someone had marked it as "Support: LCD & Controllers".

It's not a support question: it's a bug OR it's feature requsest, depending what you are facing. If you are having this problem too ofter you should mark it as a bug BUT if you (as me) sometimes is scrolling and click in some option and the option opened is the wrong option, so it should mark as feature request.

@Roxy-3D understand this, please: if there were 2 different buttons in my LCD (one to scrolling and another to click) this problem would never happen! This problem only happens cause sometimes when I click the button, without any intention, I spin juuuust a little bit the knob and it makes my click to happen in sibbling menu.

I think the best way to solve this would be:

1) discard any scrolling that happened 100ms (for example) before a click, undoing the scrolling that would happen; OR; 2) discacard the click that happened only 100ms (for example) after the last scrolling call.

I think the second option is easier to implement and intuitive and you could even make a beep (in the buzzer) when such a click is invalidated, so the user knows what is going on.

Since I got your attention and you look very inteliggent and know a lot about marlin, could you please answer a side question? Sometimes I click PRINT FROM SD and choose some file to print and I hear a beep (very short). Sometimes I hear a beep that is longer, at least twice longer. In practice it looks like everything is the same, but should I worry when this longer beep happens?

[github-actions[bot]]

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.