Problem: Inverting probe pin stopped working after 3.7.12

[breiler]

Wiki Search Terms

N/A

Controller Board

ESP32 CNC Dev Controller v4.1

Machine Description

Just the control board with a switch to the probe input

Input Circuits

Switch (NO) acting as probe connected to GPIO.32 and GND

Configuration file

name: New configuration
axes:
  x:
    steps_per_mm: 800
    max_rate_mm_per_min: 1200
    acceleration_mm_per_sec2: 15
    max_travel_mm: 1000
    homing:
      cycle: 2
    motor0:
      limit_all_pin: gpio.17:pu:low
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 2
      standard_stepper:
        step_pin: gpio.12
        direction_pin: gpio.14:low
        disable_pin: NO_PIN
  y:
    steps_per_mm: 800
    max_rate_mm_per_min: 1200
    acceleration_mm_per_sec2: 15
    max_travel_mm: 1000
    homing:
      cycle: 2
      positive_direction: false
    motor0:
      limit_all_pin: gpio.4:pu:low
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 2
      standard_stepper:
        step_pin: gpio.26
        direction_pin: gpio.15
        disable_pin: NO_PIN
  shared_stepper_disable_pin: gpio.13
  shared_stepper_reset_pin: NO_PIN
  z:
    steps_per_mm: 800
    max_rate_mm_per_min: 1200
    acceleration_mm_per_sec2: 15
    max_travel_mm: 1000
    homing:
      cycle: 1
    motor0:
      limit_all_pin: gpio.16:pu:low
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 1
      standard_stepper:
        step_pin: gpio.27
        direction_pin: gpio.33:low
        disable_pin: NO_PIN
probe:
  pin: gpio.32:low:pu
  toolsetter_pin: NO_PIN
  check_mode_start: false
stepping:
  engine: RMT
  idle_ms: 250
  pulse_us: 4
  dir_delay_us: 0
  disable_delay_us: 0
PWM:
  output_pin: gpio.2
  enable_pin: gpio.22
  direction_pin: NO_PIN
  speed_map: 0=0% 12000=100%
  s0_with_disable: true
  disable_with_s0: false

Startup Messages

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13220
ho 0 tail 12 room 4
load:0x40080400,len:3028
entry 0x400805e4
[MSG:INFO: uart_channel0 created]
[MSG:RST]
[MSG:INFO: FluidNC 3.7.13 https://github.com/bdring/FluidNC]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]
[MSG:INFO: Local filesystem type is littlefs]
[MSG:INFO: Configuration file:config.yaml]
[MSG:INFO: Machine New configuration]
[MSG:INFO: Board None]
[MSG:INFO: Stepping:RMT Pulse:4us Dsbl Delay:0us Dir Delay:0us Idle Delay:250ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Shared stepper disable gpio.13]
[MSG:INFO: Axis X (-1000.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.12 Dir:gpio.14:low Disable:NO_PIN]
[MSG:INFO:  X All Limit gpio.17:low:pu]
[MSG:INFO: Axis Y (0.000,1000.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.26 Dir:gpio.15 Disable:NO_PIN]
[MSG:INFO:  Y All Limit gpio.4:low:pu]
[MSG:INFO: Axis Z (-1000.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.27 Dir:gpio.33:low Disable:NO_PIN]
[MSG:INFO:  Z All Limit gpio.16:low:pu]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: PWM Spindle Ena:gpio.22 Out:gpio.2 Dir:NO_PIN Freq:5000Hz Period:8191]
[MSG:INFO: Using spindle PWM]
[MSG:INFO: Probe Pin: gpio.32:low:pu]
[MSG:INFO: Connecting to STA SSID:---]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connecting...]
[MSG:INFO: Connecting....]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connected - IP is XXXXX]
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://fluidnc.local/]
[MSG:INFO: SSDP Started]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]

Grbl 3.7 [FluidNC 3.7.13 (wifi) '$' for help]
[MSG:INFO: ALARM: Unhomed]

User Interface Software

UGS and FluidNC Web Installer terminal

What happened?

With versions up to 3.7.12 the following works. I have a button that is normally open and connects to GND with this configuration: gpio.32:low:pu. When I press the button it will report the probe in the status report:

> ?
<Idle|MPos:0.000,0.000,0.000|FS:0,0|Pn:P>

With the same configuration on versions after it will not register the probe input. The behaviour only effects the probe functionality. If I instead configure this pin as a limit switch to gpio.32:low:pu it will correctly register the limit switch input.

I have not studied the details in #1169 and #1125 but they could be related.

GCode File

No response

Other Information

No response

[breiler]

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:

FluidNC/FluidNC/src/Machine/EventPin.cpp

Line 10 in 7cf191e

log_debug(_legend << " " << active);

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

[MitchBradley]

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.

[MitchBradley]

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.

[breiler]

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.

[MitchBradley]

PR #1181

[breiler]

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.

[MitchBradley]

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

[breiler]

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.

[MitchBradley]

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.

[breiler]

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!

[lytke]

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.

[bdring]

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