Closed RNewDeal closed 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:
bugfix-2.0.x
to test with the latest code.DEBUG_LEVELING_FEATURE
and M114_DETAIL
and re-flash the firmware.M502
and M500
to ensure your Configurations are applied.M111 S247
to enable maximum logging.G28
to do your standard homing procedure.G29
to probe the bed. This will also enable bed leveling.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.
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.
@ellensp Updated
"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"
If that does make the issue go away, we should explore further to determine whether that check is misbehaving.
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
Does the PROBING_HEATERS_OFF
option make any difference?
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.
@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.
@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.
@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 A separate fix for ADAPTIVE_STEP_SMOOTHING
misbehavior from causing probing interference.ADAPTIVE_STEP_SMOOTHING
is also in the works.
@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.
Oh my bad Ill edit that! I got carried away trying to help I forgot to check the listed board.
@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 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
@sjasonsmith After multiple successive prints with abl not missing a beat, it's clear to me the issue is adaptive step smoothing causing issues.
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.
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.
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.
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.
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
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.