PanelDu debouncing ideas

[mikeabuilder]

I have a clone PanelDu 7
connected to a Duet2 wifi
running RRF 3.5

I'm having occasions where it seems like I'm getting multiple instances of a macro running on a single intended touch of the screen. It's like the touch property is not getting de-bounced. I've only noticed on macros I've written but I haven't tried to test other buttons.

I have a couple of questions.

1. Is there any user control of de-bouncing that happens with PanelDu touches? I assume PanelDu uses sw de-bouncing, not HW.

2. Are there any recommendations for de-bouncing in macro launches? I've been thinking I might test and set a global variable at the beginning of the macro (I'd create it at machine startup). Something like

if global.this_macro_already_running
  M99
set global.this_macro_already_running = true
 
; rest of macro
 

Then as the last command I'd set the value to false

set global.this_macro_already_running = false

What I don't understand is how multiple macros are queued and started in RRF. Is it possible that a second instance of the same macro initiated from PanelDu would either start before I get the global set from the first instance? And is it possible the second instance could start before the last command resets the variable in the object model? Should I insert a short pause (say 200msec) after the last command?

Or maybe there are other better ways to handle this?

[dc42]

@mikeabuilder bouncing is not normally a problem with PanelDue so perhaps something is wrong with the touch membrane. Maybe your enclosure is pressing against it enough to increase its sensitivity but it enough to cause a permanent trigger.

BTW the most precise way to touch the PanelDue buttons is to use the tip of your fingernail, not the pad of your finger.

The buttons auto-repeat if you maintain the pressure.

[mikeabuilder]

@dc42 - thanks for the info. Leaning on the button is certainly a possibility here.

I was curious about how fast a macro could repeat so I did a quick test with a macro that appends state.upTime to a file, then kept my finger on the touch screen button. I got 10 entries per second, so I'll assume the touch does a 100msec debounce - or that's the round trip time to read and execute the macro.

Then I wrote a macro with my logic above and again held down the macro button. I proved to myself that the slow-finger would end up with the macro queued multiple times, not run simultaneously. Nothing surprising to you, but I'm happy to prove it to myself.

To avoid my problem of the slow-finger, I now have a global variable holding state.upTime that I set when the macro ends. At the start of the macro, I test whether the current upTime is "long enough" after the saved upTime (I picked 5 seconds for my case), and only proceed with the rest of the macro if it's been long enough.