[QUESTION] BLTouch fails to detect on homing, M48 Works

[timeburn]

Bug Description

When homing with the BLTouch, the pin is not detected. The Z axis keeps moving, driving the nozzle into the bed.

Even repeatedly moving the pin by hand fails to trigger. The pin does not redeploy when pushed in.

M48 works correctly, probe is detected and redeploys the pin correctly.

My Configurations

Creator Pro retrofit with SKR 1.3, 2208s, Genuine BLTouch. Configs.zip

Steps to Reproduce

1. Initiate homing from LCD
2. X/Y home correctly
3. Effector moves probe to bed center
4. BLTouch pin deploys
5. Bed moves up, pushes pin in, keeps going.

Expected behavior: Bed stops moving when pin is triggered

Actual behavior: Pin goes in, but endstop is not triggered. Z keeps moving.

Additional Information

Pin can be pushed in via bed or manually, with no change.
Pin does not snap like it is supposed to when pushed in.

M119 causes touch pin to deploy. If pushed in at this point, it snaps in, then immediately redeploys. M48 test works properly. Pin deploys, snaps in when triggered, redeploys.

Genuine "Smart" BLTouch. ( i think it's a 3.1) Same behavior with a 3dTouch.

If I connect a regular endstop switch and trigger that by hand, it works.

[timeburn]

Not a Delta. Flashforge Creator Pro. Improved clone of the original Replicator Dual The config is adapted from the example provided in the Marlin sources.

The coordinates are all correct; as a dual extruder, the effector travel area is larger than the bed. All the coordinates work fine when just using a Z min endstop and manually leveling the bed. The only thing I changed was to enable bltouch, and use it in place of the original z-min switch. (well, and enabled UBL and associated menu options)

When it runs the homing cycle, the sensor is correctly moved to the center of the bed before moving Z. It just doesn't trigger when it should.

Line 2206 was an error; it is not enabled in the actual firmware image in use. I had made that edit thinking it might make a difference, but have not yet tried it; it doesn't look like the bltouch code usese it.

[timeburn]

just for grins, I put the z-min endstop back in, and swapped the probe to use the z-max pin instead. Now homing works fine with the endstop... and UBL works, probing the bed just as one would expect.

So the bltouch part works fine. Except when used for homing on the z-min pin. Wat?

So the previously posted config fails... but this works.zip

[boelle]

@timeburn still an issue?

[timeburn]

haven't seen any related updates since the last time I tried it. The bltouch works as long as it's not for z-homing. If I try to use it to home z, it fails.

[Vertabreak]

Is it defined as the z endstop?

[timeburn]

In the first config set, the touch sensor is connected to z-min and defined as the endstop, yes.

the the second, there's a mechanical endstop connected to the z-min pin, probe is on z-max, mapped as the probe pin in the pins file.

that's the only change. The second set works, the touch probe does ubl just fine, once it's homed with the limit switch. But if I put it back, try to home with the bltouch as the endstop, it won't trigger.

[boelle]

try and post config as they are now

[boelle]

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

[timeburn]

Ok, new info. it appears to be something to do with the physical pin selection.

\ configs_pins.zip

In the attached configs, bltouch is enabled, on z-min pin, with

define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

enabled.

Z-min pin is the board default of P1_25.

In this conifg, homing fails. the probe trigger is not detected.

but if I swap the z min and max pins in pins_BTT_SKR_V1_3.h:

define Z_MIN_PIN P1_24 // Z_MAX (free)

define Z_MAX_PIN P1_25 // Z_MIN

and connect the bltouch to z-max pin P1_24, homing works normally.

The only change made was swapping the Z-min pin from P1_25 to P1_24

[thinkyhead]

Try enabling PINS_DEBUGGING and then use M43 to get a pins report. This will tell you if any pins are conflicting or assigned to the same plug. You can also do live endstop testing with M43 E or M43 W where you watch a pin or a range of pins for changes. See https://marlinfw.org/docs/gcode/M043.html

Does this probe work okay with min pin P1_25 if you use an earlier version of Marlin?

[thinkyhead]

With the SKR boards you also want to make sure that the DIAG pins from the stepper drivers (for stallGuard sensorless homing) are not connected to the endstops by jumpers or any other means, and that there are no shorts to that pin.

[timeburn]

I don't have an older snapshot of 2.0 to work from unfortunately, I could not say. It gets stranger, though.

When I try to print with the above config, the printer stops moving right after homing. like, it still receives commands and Octoprint thinks it's moving, but the carriage never moves out of the z-homing position.
Shortly after reaching temp;, the screen shows "STOPPED" at the bottom and the temps drop again, but Octoprint thinks it's printing. so weird.

I have not yet tested it with SD printing, nor set up pins debugging; hopefully I have time to play with it some this evening.

[timeburn]

This appears to have been a hardware failure.

The board was not able to read an external sd card, so it was replaced with an SKR 1.4 Turbo, and all is working correctly now.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.