Problem: Inverting probe pin stopped working after 3.7.12 about fluidnc HOT 12 CLOSED

I think that I've tracked down the commit that is causing these problems:
7cf191e

Edit: I compiled and tested each commit up to this and the probing stopped working.

I found that this function never got triggered when an probe input was triggered:

If I triggered the probe then a limit pin the status report was updated correctly with the probe status.

from fluidnc.

I have a fix that needs testing. I will PR it as time permits. I am traveling so my development time is limited for a few days.

from fluidnc.

My fix has the good side effect of allowing probes to be remoted over I/O expanders. I suspect that the fix will have similar or perhaps even better latency than the gpio-only status quo but it needs to be tested in real world situations on hardware that I do not have with me away from the office.

from fluidnc.

Excellent, and no stress!

I have seen questions about this starting to popup in different forums so I gave it a shot figure out the problem. But I am unfamiliar with the code, have no debugging capabilities and my time to spend on this ran out...

Once you have a branch up I can give it a quick test as well.

from fluidnc.

PR #1181

from fluidnc.

Thanks, I've given it a try and it seems to work better now.

It was never an issue with probe pin being inverted like the title of the issue said, but I tried a couple of those scenarios as well and it is also working as it should.

Here it is doing a XYZ corner probe:
fncprobe.webm

I did notice one detail which is different compared with version 3.7.12. If I use a switch (normally open) connecting to GND with config gpio.32:low:pu and do a cold start of the controller it will report the probe pin as active. If I trigger the probe once it will then display the correct state.

from fluidnc.

Try it now. The pin state was not being initialized properly.

from fluidnc.

That didn't make any difference, still get the probe input on a cold boot. Ignore the Y limit switch, it has always behaved this way.

Grbl 3.7 [FluidNC v3.7.16 (EventProbe-8c25da95) (wifi) '$' for help]
[MSG:WARN: Active limit switch on Y axis motor 0]
[MSG:INFO: ALARM: Unhomed]
ALARM:14
<Alarm|MPos:0.000,0.000,0.000|FS:0,0|Pn:PY|WCO:-214.904,78.375,-28.889>

I don't know how much time we should put on this as it only occurs if I leave the input floating (using the internal pull up) and it doesn't effect the usability of the machine. I only reacted to this as it was a new behavior. It could lead to questions from other users, but could be solved with some documentation.

from fluidnc.

I would like to understand why it happens. Can you show the indications that it occurred? All I see is the Y thing that you said to ignore.

from fluidnc.

I tried simplifying how to reproduce the problem by just connecting to a stand alone ESP module and could no longer reproduce it. So the problem with it reporting inputs as active is only present when the ESP32 is on the controller board. Not sure why it behaves like this looking through the schematics of the board (https://github.com/bdring/Grbl_ESP32_Development_Controller/blob/master/docs/V4p1/esp32_cnc_test_v4.1_schm.pdf).

I am also not sure why the behavior is different in version 3.7.12. 🤷🏻‍♂️

But this is good enough for me and from my end this issue is resolved, thanks Mitch!

from fluidnc.

I’m seing the same symptoms probe not working with pullup and inverted added. Tried with different ports on both 6x board as well as a wemos D1 with same result.

Used both 3.7.15 and 3.7.16 releases during my tests.

Happy to run additional tests if needed.

Thanks/Per.

from fluidnc.

@lytke create a new issue, using your 6x config. give details on the probe type too.

from fluidnc.