MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.29k stars 19.24k forks source link

[BUG] Probe Constantly Fails #18480

Closed RNewDeal closed 4 years ago

RNewDeal commented 4 years ago

Bug Description

Probe constantly fails whether it is homing Z or leveling. Occasionally when it actually starts leveling it will "skip" a spot, immediately moving upwards and going to a new spot

My Configurations

configs.zip

Steps to Reproduce

  1. Have a Sidewinder with a BLTouch attached with the waggster mod.
  2. Attempted to level or home Z

Expected behavior: A z home or bed leveling

Actual behavior: Either the probe prematurely triggers without hitting anything

Additional Information

Sidewinder X1 V4 with an SKR 1.4 Turbo board, TMC 2209s, sensorless homing enabled.

https://cdn.discordapp.com/attachments/491165528295997450/727453478095552532/video0.mov https://cdn.discordapp.com/attachments/491165528295997450/727453479676674081/video1.mov https://cdn.discordapp.com/attachments/491165528295997450/727453481249538118/video2.mov https://cdn.discordapp.com/attachments/491165528295997450/727453482508091422/video3.mov

Probe has had connectors replaced, and multiple M43 S checks have passed, did a dozen in a row with a single noise failure.

ellensp commented 4 years ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

RNewDeal commented 4 years ago

abl runs.txt Ctrl + F for First Run, Second Run, and Third Run First Run Probe Failure Immediately on first ABL Second Run Did not trigger on a few probes Third Run Same issue as above. If needed I'll also do 3 more runs and record the runs in a video.

RNewDeal commented 4 years ago

@ellensp Updated

ellensp commented 4 years ago

"SLOW Probe fail! - Triggered early." is your issue.

Quoting @sjasonsmith

"This is related to a sanity check that is a 'recent' addition to Marlin. It attempts to detect unexpected early probes, and fails probing to avoid damaging your printer."

"The behavior of this sanity check is influenced by Z_CLEARANCE_BETWEEN_PROBES . You could try increasing that value (perhaps from 5 to 10), to see if it makes your issues go away"

sjasonsmith commented 4 years ago

If that does make the issue go away, we should explore further to determine whether that check is misbehaving.

RNewDeal commented 4 years ago

I've had a pretty odd issue. So if the printer is dead cold, ABL works fine. Even for the first print with the heaters on, the BLTouch works fine. However trying to home and ABL with the printer even a bit warm after seems to cause premature triggering, even when the printer is cooling down and the heaters are off. I did increase Z_CLEARANCE

thinkyhead commented 4 years ago

Does the PROBING_HEATERS_OFF option make any difference?

RNewDeal commented 4 years ago

I'll try enabling it, but as said when I do the first print off a cold printer the probe works fine, but on a warm printer with heaters off it fails until I wait for it to be dead cold. I'll do a log of a successful run and a warm unsuccessful run.

sjasonsmith commented 4 years ago

@RNewDeal it might also be significant whether you have power-cycled your printer. If your "warm" probing is not the first G29 after boot it might make a difference.

It should not make a difference, but it is one more thing to pay attention to while debugging.

RNewDeal commented 4 years ago

@sjasonsmith Printer is getting fixed right now as the thermistor wire broke when fixing the results of a sock slipping over the nozzle. I'll pay more attention to when I power cycle. A print had somehow bent the BLTouch pin despite having a BLTouch shield, and after fixing it leveled warm the one time I've leveled after. I'll update you once I fix the printer.

Dracrius commented 4 years ago

@RNewDeal Pull Request #18637 is more then likely the solution to your issues. Correction maybe a similar pull request is needed!

The problem is made far worse with ADAPTIVE_STEP_SMOOTHING enabled as it is in your configs as ADAPTIVE_STEP_SMOOTHING currently can occupy 100% processor power for the stepper-interrupt alone by stepping at the wrong speed. This is not the main issue but another that makes things worse the pull request fixes the Servo Pin priority which prevents ADAPTIVE_STEP_SMOOTHING misbehavior from causing probing interference. A separate fix for ADAPTIVE_STEP_SMOOTHING is also in the works.

sjasonsmith commented 4 years ago

@Dracrius this won't be immediately fixed by my PR, because their board uses the LPC1768 HAL, and my fix only applies to the STM32F1 HAL.

There might be a related root-cause, but it would require a unique fix. Disabling ADAPTIVE_STEP_SMOOTHING may help improve behavior in the meantime.

Dracrius commented 4 years ago

Oh my bad Ill edit that! I got carried away trying to help I forgot to check the listed board.

RNewDeal commented 4 years ago

@Dracrius So should I disable adaptive step smoothing or just do what I'm doing now, waiting for my printer to cool, power cycling, and praying as I level the bed.

Dracrius commented 4 years ago

@Dracrius So should I disable adaptive step smoothing or just do what I'm doing now, waiting for my printer to cool, power cycling, and praying as I level the bed.

Haha ya disabling Adaptive Step Smooting should work! It did for me even without the patch for my mainboard

RNewDeal commented 4 years ago

@sjasonsmith After multiple successive prints with abl not missing a beat, it's clear to me the issue is adaptive step smoothing causing issues.

sjasonsmith commented 4 years ago

I suspect this is related to software-PWM interrupt priority issues that I fixed on STM32F1 boards. I've adjusted labels on this issue to scope it to BLTouch and LPC176x, which may need some similar changes.

RNewDeal commented 4 years ago

Ok, so I now have a bizarre issue. I pulled adaptive step smoothing, and the printer ran fine for a few days. Suddenly I started getting M999 errors. The BLTouch passes all tests and commands, and only fails when I ask to home z or level, then it repeatedly deploys and retracts and gives M999 errors. After reconnecting the endstop and verifying that the board was working still, the BLTouch started acting normally again when I swapped back and enabled adaptive step smoothing again. A day later more M999s. All connectors have been swapped, and double checked.

github-actions[bot] commented 4 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

github-actions[bot] commented 4 years ago

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.