Req Example of debounce about core HOT 7 CLOSED

Which driver version? Please post the $I response.

When using wait_on_input() for anything else than immediate mode then a reasonable timeout has to be provided. If wait_on_input() times out it returns -1, you will have to test for that.

In plugin code you may consider registering an interrupt handler instead, support for this has recently been added to a number of drivers. The function pointer is non-zero if registering is supported.

Note that there is no debounce performed on aux inputs.

from core.

[VER:1.1f.20210629:]
[OPT:VNMZHS2,35,1024,3,0]
[NEWOPT:ENUMS,RT+,HOME,ES,TC]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FRAM]
[DRIVER:iMXRT1062]
[DRIVER VERSION:210703]
[DRIVER OPTIONS:USB.2]
[BOARD:GRBLHAL2000 - PRINTNC]
[AUX IO:4,0,0,0]
[PLUGIN:RGB Indicator Lights v0.4]

Ah, so I need to implement debounce regardless of the method, that is what I needed to know.

from core.

Ideally I would like to trigger on low or falling but the board becomes inaccessible if I use them.

It crashes or hangs for the duration of the wait? wait_on_input() with timeout > 0 blocks until the event or the timeout expires.

Ah, so I need to implement debounce regardless of the method

Yes, if you really need debounce. Currently the best method will be to register an interrupt handler, when called deregister it and delay, then read the input in immediate mode (and take the neccesary action) and reregister the handler. You may also set a flag instead of deregister/reregister, this to ignore further calls to the handler and/or check the input in your real time handler (IIRC you subscribe to the on_execute_realtime event).

A delay (or any code that takes a long time to process) should not be executed in an interrupt handler, use protocol_enqueue_rt_command() to register a function to be executed (once) from the foreground process instead.

from core.

Great, thank you. Very helpful.

from core.

i'd like to add an aux-input for my tool setter over travel alarm line. I haven't been able to find an example of aux-in being used for a signal like this in any other plugins, is there an example you can point me to? I want to assert ALARM/ESTOP in the event this signal is tripped.

from core.

If you register an interrupt handler for the input pin then set the relevant signal when asserted and call hal.control.interrupt_callback.

If you want status report to show the correct status hook your code into hal.control.get_state . Save away the original fn pointer first (e.g to get_state_org as in the example below).

In your replacement read the original status and "or" the input with the original.

control_signals_t get state (void):
{
    control_signals_t signals = get_state_org();

    signals.e_stop |= (hal.port.wait_on_input(true, <port>, WaitMode_Immediate, 0.0f)  == 1);

    return signals;
}

<port> is the port id you want to use.

The Bluetooth plugin uses interrupt for an aux input pin and may serve as an example for how to do that.

from core.

Terje,

I was able to address my situation with just a simple check of the pin during the loop, as all I want to do is to switch a light on when a button is pressed. It doesn't require interrupt level urgency, it's just for improved visibility and I don't perceive any delay when using it.

It will appear in a pending up date to the RGB plugin.

from core.