Closed Avataar120 closed 2 years ago
Do you have pullup resistors on the limit pins?
Yes, my schematic is below :
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.
1)
2)
What does the rising edge look like?
Any clue on what could cause this issue ?
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
Made some tests by instrumentating LimitPin.cpp (void IRAM_ATTR LimitPin::read() function)
When reading is OK,
When reading if 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
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.
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.
This problem started after version v3.4.4. In this version the problem is not there. FYI
Yes we know about it.
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.
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.
I noticed that. I am aslo trying to solving this without a scope.
Thank you for the prompt reply
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.
Do you have a way to test it? I can help my board seems to be prone to this problem.
Hi Mitch, this seems to fix it. I will do more testing and let you know.
I think we have fixed it.
Controller Board
Own design Limit pin goes through a 100ohm resistor 100nF capacitor in parallel
Help From Board Vendor
Machine Description
Test setup (4 steppers with end switch on an acrylic sheet)
Configuration file
Startup Messages
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