Limit switch is ignored if already triggered at time of homing #618

I would like to see the circuit for your limit switches. Something strange is happening that I am having trouble reproducing,

Using 3.5.1-pre1-FS on a laser gantry with dual motors and dual negative limit switches, squared homing is flawless. If a switch is tripped when I issue $HY, the first move is a pulloff, then the homing cycle proceeds as expected.

Same problem to me. Only Firmware 3.4.4 works flawless. Firmware 3.5.1-pre1-FS have the same problem.

Same problem here (please see my last comment in #602 when I reopened it)

I would like to see the circuit for your limit switches. Something strange is happening that I am having trouble reproducing,

So why is :pd enabled for such switches? pd effectively connects a resistor across the transistor, making it appear to be always on.

I can imagine why it used to “work”. Since some versions of FluidNC had the bug of always enabling pullups, even when you did not ask for them, thus the :pu would turn into :pu + :pd. The combination of pu and pd creates a voltage divider that sets the transistor-off-state voltage at some intermediate value that just happens to be above the input threshold, albeit with a narrow noise margin.

So why is :pd enabled for such switches? pd effectively connects a resistor across the transistor, making it appear to be always on.

From what I recall, I tried the correct solution, but it wasn’t behaving as expected, but I’ll try it again (using 3.6.1-pre1-FS) and see what TF goes on.

I don’t see a schematic for v2.5 of DLC32 on the MKS github. The closest I can find is v2.1. It shows the circuits for X-, Y-, Z- (GPIO 36, 35, 34) but does not show the values of the pullup and series resistors in those circuits. Lacking those values, it is impossible to calculate the voltages when :pd is active. But I can say for sure that :pd is not helpful for those cases.

For GPIO 18 (Z limit_neg_pin) AKA LCD_SCK, :pd is definitely wrong, and there is no pullup at all. So that pin will never go high. You really should add an external pullup as the internal ones on ESP32 are too weak to give decent noise margin even if you say :pu

GPIO 23 – same comments as for GPIO 18 – omit :pd and add external pullup of say 10K. A 0.1uF cap to ground wouldn’t hurt either.

V2.5 is my file version. The DLC32 is v2.1 rev1

GPIO 23 – same comments as for GPIO 18 – omit :pd and add external pullup of say 10K. A 0.1uF cap to ground wouldn’t hurt either.

Sure. I’ll make those changes tonight.

So should I remove :pd from the 3 built-in limit inputs?

The only case where :pd would be useful would be a high-side switch – connected between V+ and the input. Even then, it would be better to use an external pulldown resistor. The internal resistors on ESP32 are really intended to keep the inputs from floating to an indeterminate state. They are too weak for signals going off-board.

I’ve noticed this a few times with homing. My pulloff_mm setting was 1.500 mm and i changed it to 2.000 mm. But it could be that i’m thinking too simple. But at this moment is is working again.

Have you measured the voltage at the gpio pin with the switch in both positions?

Not to sound snarky, but should it matter? The $limits test indicates it is working correctly.
Is there something I need to know about the limits test?

Also, it homes perfectly well if the limit is not triggered at the time homing starts.

Okay, so there’s a problem here. I changed limit_neg_pin: gpio.18:high to limit_neg_pin: gpio.18 and $limits still performs the exact same way. I believe it should be reporting the opposite, right?

Right, so even after changing from :high, I still get the same failure.

No high is the default. You should switch to :low

Changed to :low, now it tries to home and just keeps jamming against the top of the limit. This time is doesn’t stop after 3 seconds and show error 8.

They are NC switches through an optocoupler, so in the non-triggered state, the IR LED is on and the pin is pulled to ground by the phototransistor.

Both my Z- and Y- pins are showing their states as inverted without using :high

OK, that active state change was your idea. You were just doing it wrong.

Set $message/level=debug and reply with the debug text during a Z homing.

Grbl 3.6 [FluidNC v3.6.3 (wifi) ‘$’ for help]
$message/level=debug
ok
$h
[MSG:DBG: Homing Cycle Z]
[MSG:DBG: Starting from 0.000,0.000,0.000]
[MSG:DBG: Planned move to 0.000,0.000,1.000 @ 20.000]
[MSG:DBG: CycleStop PrePulloff]
ALARM:8
ok

Ahh, so it’s trying to pulling off in the wrong direction, I guess.

Paste you Z axis config. Use the yaml code block formatting.

Updated first post.

I think it should be a limit_pos_pin:

I’m happy to change it. Any idea why the problem doesn’t occur if PrePulloff doesn’t need to be called?
Can I assume that the homing cycle is looking for any limit switch on the axis it’s homing, not specifically the limit switch in the direction it’s moving? And if so, is that the best way to handle it?

I think it should be a limit_pos_pin:

Argh. Right, this was the solution all along. 🤦‍♂️

It needs to know which way to pull_off from a stuck limit switch. If it is touching a negative switch it knows it must move in the positive direction. If it is a limit_all_switch: it will just Alarm right away with a stuck limit switch.