Random bad reading of limit pins

[Avataar120]

Controller Board

Own design Limit pin goes through a 100ohm resistor 100nF capacitor in parallel

Help From Board Vendor

• [ ] Yes
• [ ] No
• [X] Not Applicable

Machine Description

Test setup (4 steppers with end switch on an acrylic sheet)

Configuration file

name: K40_AvaShield
board: 4_Test_Ava_Shield_7.x_XYZ

kinematics:
  Cartesian:

stepping:
  engine: I2S_STREAM
  idle_ms: 255
  dir_delay_us: 1
  pulse_us: 4
  disable_delay_us: 0

axes:
  shared_stepper_disable_pin: NO_PIN

  x:
    steps_per_mm: 78.74
    max_rate_mm_per_min: 20000.000
    acceleration_mm_per_sec2: 2000.000
    max_travel_mm: 310.000
    soft_limits: false
    homing:
      cycle: 1
      positive_direction: false
      mpos_mm: 5.000
      feed_mm_per_min: 200.000
      seek_mm_per_min: 2500.000
      settle_ms: 250.000
      seek_scaler: 1.500
      feed_scaler: 5.000

    motor0:
      limit_neg_pin: gpio.39:low
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 5.000
      stepstick:
        ms3_pin: I2SO.3
        step_pin: I2SO.2
        direction_pin: I2SO.1
        disable_pin: I2SO.0


  y:
    steps_per_mm: 78.74
    max_rate_mm_per_min: 20000.000
    acceleration_mm_per_sec2: 2000.000
    max_travel_mm: 210.000
    soft_limits: false
    homing:
      cycle: 1
      positive_direction: false
      mpos_mm: 5.000
      feed_mm_per_min: 200.000
      seek_mm_per_min: 2500.000
      settle_ms: 250.000
      seek_scaler: 1.500
      feed_scaler: 5.000

    motor0:
      limit_neg_pin: gpio.34:low
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 5.000
      stepstick:
        ms3_pin: I2SO.7
        step_pin: I2SO.6
        direction_pin: I2SO.5:low
        disable_pin: I2SO.4

  z:
    steps_per_mm: 1000.000
    max_rate_mm_per_min: 400.000
    acceleration_mm_per_sec2: 2000.000
    max_travel_mm: 20.000
    soft_limits: false
    homing:
      cycle: 2
      positive_direction: true
      mpos_mm: 0.500
      feed_mm_per_min: 100.000
      seek_mm_per_min: 100.000
      settle_ms: 250.000
      seek_scaler: 1.500
      feed_scaler: 5.000

    motor0:
      limit_neg_pin: gpio.35:low
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 0.500
      stepstick:
        ms3_pin: I2SO.11
        step_pin: I2SO.10
        direction_pin: I2SO.9:low
        disable_pin: I2SO.8
    motor1:
      null_motor:

i2so:
  bck_pin: gpio.22
  data_pin: gpio.21
  ws_pin: gpio.17

spi:
  miso_pin: gpio.19
  mosi_pin: gpio.23
  sck_pin: gpio.18

sdcard:
  cs_pin: gpio.5

control:
  safety_door_pin: gpio.27:low:pu
  reset_pin: gpio.12:low:pu
  feed_hold_pin: gpio.14:low:pu
  cycle_start_pin: gpio.13:low:pu

coolant:
  mist_pin: gpio.4
  delay_ms: 50.000

probe:
  pin: gpio.36:low
  check_mode_start: false

macros:
  startup_line0: 
  startup_line1: 
  macro0: 
  macro1: 
  macro2: 
  macro3: 

start:
  must_home: true
  check_limits: true
  deactivate_parking: false

user_outputs:

laser:
  tool_num: 0
  speed_map: 0=0.0% 1000=100.0%
  output_pin: gpio.15
  enable_pin: gpio.16:low
  disable_with_s0: true
  s0_with_disable: false
  pwm_hz: 15000

arc_tolerance_mm: 0.002
junction_deviation_mm: 0.010
verbose_errors: false
report_inches: false
enable_parking_override_control: false
use_line_numbers: false

Startup Messages

[MSG:INFO: FluidNC v3.5.1-pre]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.1-1-gb8050b365e]
[MSG:INFO: Local filesystem type is SPIFFS]
[MSG:INFO: Configuration file:config.yaml]
[MSG:DBG: Running after-parse tasks]
[MSG:DBG: Checking configuration]
[MSG:INFO: Machine K40_AvaShield]
[MSG:INFO: Board 4_Test_Ava_Shield_7.x_XYZ]
[MSG:INFO: I2SO BCK:gpio.22 WS:gpio.17 DATA:gpio.21]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cs_pin:gpio.5 detect:NO_PIN]
[MSG:INFO: Stepping:I2S_stream Pulse:4us Dsbl Delay:0us Dir Delay:1us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Axis X (5.000,315.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     stepstick Step:I2SO.2 Dir:I2SO.1 Disable:I2SO.0]
[MSG:INFO:     Neg Limit gpio.39:low]
[MSG:INFO: Axis Y (5.000,215.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     stepstick Step:I2SO.6 Dir:I2SO.5:low Disable:I2SO.4]
[MSG:INFO:     Neg Limit gpio.34:low]
[MSG:INFO: Axis Z (-19.500,0.500)]
[MSG:INFO:   Motor0]
[MSG:INFO:     stepstick Step:I2SO.10 Dir:I2SO.9:low Disable:I2SO.8]
[MSG:INFO:     Neg Limit gpio.35:low]
[MSG:INFO:   Motor1]
[MSG:INFO: safety_door_pin gpio.27:low:pu]
[MSG:INFO: reset_pin gpio.12:low:pu]
[MSG:INFO: feed_hold_pin gpio.14:low:pu]
[MSG:INFO: cycle_start_pin gpio.13:low:pu]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: Laser Spindle Ena:gpio.16:low Out:gpio.15 Freq:15000Hz Res:12bits Laser mode:On]
[MSG:INFO: Using spindle Laser]
[MSG:INFO: Mist coolant gpio.4]
[MSG:INFO: Probe Pin: gpio.36:low]
[MSG:INFO: Connecting to STA SSID:MySSID]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connecting...]
[MSG:INFO: Connected - IP is 192.168.x.xxx]
[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]

User Interface Software

Fluidterm or Lightburn

What happened?

I trigger several HOME with lightburn button or by issuing $H in Fluidterm Once out of 15/20 tries, I got an home error message :

[MSG:DBG: Homing XY] [MSG:DBG: PrePulloff] [MSG:DBG: Fast approach] [MSG:DBG: X target -465.000 rate 2500.000] [MSG:DBG: Y target -315.000 rate 2500.000] [MSG:DBG: Pulloff0] [MSG:DBG: X target 5.000 rate 200.000] [MSG:DBG: Y target 5.000 rate 200.000] [MSG:ERR: Homing fail] ALARM:8 Homing fail. Cycle failed to clear limit switch when pulling off. Try increasing pull-off setting or check wiring. ok Grbl 3.5 [FluidNC v3.5.1-pre (wifi) '$' for help] [MSG:INFO: '$H'|'$X' to unlock]

If I issue ? command, I get :

? <Alarm|MPos:5.004,5.004,0.500|FS:0,0|Pn:X|WCO:5.004,5.004,5.200> ok ? <Alarm|MPos:5.004,5.004,0.500|FS:0,0|Pn:X|Ov:100,100,100> ok ? <Alarm|MPos:5.004,5.004,0.500|FS:0,0|Pn:X> ok ?

However, limit switch is not activated (please have a look to my attached video) It occurs on all 4 limit switchs randomly.

Other Information

https://user-images.githubusercontent.com/12379002/181906198-1c8c9867-ec86-4145-838e-f1e2390bb375.mp4

[MitchBradley]

Do you have pullup resistors on the limit pins?

[Avataar120]

Yes, my schematic is below :

[Avataar120]

I have made some scope traces ... I didn't notice any difference between what is working, what is not. Below image of Y input on ESP32 pin when 1) not working 2) working

Note : I have to trigger manually the switch in order to unblock the situation (therefore triggering ESP32 to 0V) In other words, input is read as 1 until I trigger manually the swicth.

[MitchBradley]

What does the rising edge look like?

[Avataar120]

[Avataar120]

Any clue on what could cause this issue ?

[Avataar120]

Hi, I have changed a little bit my input layout in order to have a clean edge either for rising edge, either for falling edge. Now, both of them are perfect without any spike, bounce, ...

However, I still have the issue. It's very easy to reproduce, just playing with the limit switch until FluidNC freezes with X limit switch detection for instance ... It tools only 10-15 times to reproduce it

Any clue on that issue ? With same hardware, GRBL ESP32 does not have this issue

[Avataar120]

Made some tests by instrumentating LimitPin.cpp (void IRAM_ATTR LimitPin::read() function)

When reading is OK,

• I have one interrupt for falling edge and reading is logic 1 -> OK
• I have one interrupt for rising edge and reading is logic 0 -> OK

When reading if NOK,

• I have one interrupt for falling edge and reading is logic 1 -> OK
• I have one interrupt for rising edge and reading is logic 1 -> NOK

Looks like interrupt is triggered on one input level, and reading is not exactly at the same level

I postponed by 10us the reading in the interrupt (I know it's bad) -> no more issue Perhaps my RC is a little bit too slow ? driving interrupt and reading to be inconsistent ? What do you think ?

Thanks

[MitchBradley]

Okay, that is good information. The interrupt detector may have a separate threshold circuit from the read circuit, with a slightly different threshold value for the interrupt. The delay will probably work for now; I will try some alternative fixes too.

[AdamKrovina]

I believe I have experienced this problem yesterday. I'm trying to adopt the fluidnc and the 6-pack controller to my cnc router. What happened was I got the same message after failed pulloff - the machine was showing X and Y sensors are active. None of those was. I tried acitvating the Y sensor by hand and the controller finally registered it. The X signal was still indicated as positive. After a $bye the machine has detected also the X signal correctly. I am using inductive sensors. Sorry for not sharing all the details required for an issue. I am using the latest release, 1950bd0, no radio.

[mac7988]

This problem started after version v3.4.4. In this version the problem is not there. FYI

[MitchBradley]

Yes we know about it.

[mac7988]

I should have read the "Issues" I spent two days thinking it's my board. I must have soldered on so many filtering caps. I am a dummy lol.

[MitchBradley]

Caps actually make it worse, by slowing down the edges. Slow edges increase the chance that the change detection interrupt will fire before the pin read circuit has detected the new value.

[mac7988]

I noticed that. I am aslo trying to solving this without a scope.

Thank you for the prompt reply

[MitchBradley]

Apparently it is not a signal quality problem, but rather an artifact of the way the ESP32's input hardware is designed. I made what I thought was an improvement to the way that pin value changes are detected, but tripped over that artifact.

[mac7988]

Do you have a way to test it? I can help my board seems to be prone to this problem.

[MitchBradley]

https://github.com/bdring/FluidNC/releases/tag/EventQueueTest

[mac7988]

Hi Mitch, this seems to fix it. I will do more testing and let you know.

[MitchBradley]

I think we have fixed it.