[BUG] nozzle touches bed: ARC_SUPPORT + bed leveling
#25095
Comments
|
Hello @Roxy-3D , I can confirm that it still occurs in bugfix-2.1.x as of 7c0b465 (Fri Feb 3 06:06:11 2023 +0000). How to reproduce:
That means it is not a bug in G26 (Mesh Validation Pattern). |
|
Here a concise procedure how to reproduce the behaviour:
; ----- reset flash -----
M502 ; factory reset
M500 ; save settings
M501 ; restore settings
; ----- probe bed, create mesh and store to flash -----
G29 P1 ; UBL, all points are on bed, no interpolation needed
G29 P3 ; optional: "fill unpopulated regions"; all moves of G2/G3 in the subsequent examples are within the probed points;
; no extrapolation is required;
; makes no difference in subsequent steps, if `G29 P3` is left out or executed
G29 S0 ; store mesh to 1st slot
G29 L0 ; load mesh from 1st slot
; ----- home all and place the nozzle above the suspected area -----
G28 ; home all
G90 ; absolute pos.
G0 Z10 ; go to safe Z pos. of 10mm
G91 ; relative pos.
G0 X110 ; place nozzle above the suspected area
; ----- examples -----
; example 1 - erroneous: current Z-height within Z-fade height + compensation enabled
M420 Z11 ; set Z-fade height to 11mm (above current Z=10mm)
M420 S1 ; enable bed compensation
G2 I-10 J-10 ; move a full circle: reproduces unexpected Z move behaviour
; example 2 - OK: current Z-height within Z-fade height + compensation disabled
M420 Z11 ; set Z-fade height to 11mm (above current Z=10mm)
M420 S0 ; disable bed compensation
G2 I-10 J-10 ; move a full circle: no unexpected Z move (as expected)
; example 3 - OK: current Z-height above Z-fade height + compensation enabled
M420 Z9 ; set z-fade height to 9mm (below current Z=10)
M420 S1 ; enable bed compensation
G2 I-10 J-10 ; move a full circle: no unexpected Z move (as expected)
; ----- end -----
Observations:
I can confirm that it still occurs in bugfix-2.1.x as of ef3f484 (Thu Feb 9 06:33:20 2023 +0000). |
|
Observed same behaviour also with G5 (Bézier cubic spline). Additional examples to the afore mentioned ones: ; example 4 (Bézier G5) - erroneous: current Z-height within Z-fade height + compensation enabled
M420 Z11 ; set Z-fade height to 11mm (above current Z=10mm)
M420 S1 ; enable bed compensation
G5 F50 P0 Q-5 X-40 Y-40 ; move Bézier curve: reproduces unexpected Z move behaviour
G5 F50 P0 Q-5 X+40 Y+40 ; move Bézier curve: reproduces unexpected Z move behaviour
; example 5 (linear move G0/G1) - OK: current Z-height within Z-fade height + compensation enabled
M420 Z11 ; set Z-fade height to 11mm (above current Z=10mm)
M420 S1 ; enable bed compensation
G0 F2000 X-40 ; move linear: no unexpected Z move (as expected)
G0 F2000 X+40 ; move linear: no unexpected Z move (as expected)
G1 F2000 X-40 ; move linear: no unexpected Z move (as expected)
G1 F2000 X+40 ; move linear: no unexpected Z move (as expected) |
|
May be due to this #25453, as it appears to be occuring beyond X pos of 255mm. |
|
#25453 has been merged, so please download |
|
I tried to test the firmware as of 16bd900 (31.03.2023) which contains the fix #25453 and also the related refactoring. Unfortunately there is some other issue, which prevents me to test if the afore mentioned erratic behaviour has disappeared. What happens now is that while UBL
My printer has BL Touch installed. The normal behaviour (i.e. with ef3f484) is:
The current behaviour with 16bd900 is:
An example mesh result of Apart of this I observe a varying latency in between the time when the probe tip is touched and the bed stops moving. Sometimes the bed stops immediately, sometimes it moves about 3mm beyond the touching point until it stops. In contrast, with the firmware as of 09.02.2023 (ef3f484), when the probe is touched the bed always stops immediately. I can exclude cabling issues because the probe errors are reproduce-able with the newer firmware, but disappear with the older. I cannot find (but also not exclude) configuration errors. Configurations: configs.zip I have to postpone the test of the originally reported issue and switch back to the firmware as of 09.02.2023 because the recent one (31.03.2023) is unusable for me. |
|
It may be worth trying commit a8ac83b, as some changes to probe appear to have been committed a couple of days ago. |
|
The BLTouch/probe behavior change is new/unrelated to why this issue was originally opened. There have been several updates to the probe code the past few weeks that is causing extra (or no) moves. See the following issues for more info: |
|
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. |
Did you test the latest
bugfix-2.1.xcode?Yes, and the problem still exists.
Bug Description
When printing an initial layer or the mesh validation pattern with
G26, the nozzle unexpectedly lowers down towards the bed and touches the build plate. This seem to happen only withARC_SUPPORTenabled (on arc or circle move) and only on some areas on the bed.Video: https://user-images.githubusercontent.com/7566204/207461198-bec9cb37-b2f4-4f7b-bc10-29418ba84d75.mp4
Example with
G26:Bug Timeline
No response
Expected behavior
With
ARC_SUPPORTenabled: when printing the initial layer (I use arc-welder) or the mesh validation pattern withG26, the nozzle shall not rub the build plate.Actual behavior
When circles/arcs of the mesh validation pattern are printed, on the two right-most columns the following happens:
I observed similar behaviour while printing the initial layer of arbitrary 3D models (sliced with Cura + arc-welder). At the moment I cannot tell if this happens at subsequent layers too (at least I didn't observe it so far).
Steps to Reproduce
Version of Marlin Firmware
bugfix-2.1.x as of 314e52b
Printer model
Creality Ender 5 Plus
Electronics
BTT SKR Pro v1.2
Add-ons
No response
Bed Leveling
UBL Bilinear meshAUTO_BED_LEVELING_UBLYour Slicer
Cura
Host Software
OctoPrint
Don't forget to include
Configuration.handConfiguration_adv.h.Additional information & file uploads
Configuration
configuration.zip
Detailed steps with
ARC_SUPPORTenabledDetailed steps with
ARC_SUPPORTdisabledReported printer capabilities
The text was updated successfully, but these errors were encountered: