Core One L Nozzle Scraping / Crashing Into Bed#15141
Core One L Nozzle Scraping / Crashing Into Bed#15141avirtuos wants to merge 1 commit intoprusa3d:masterfrom
Conversation
|
So just to clarify, you changed the one line in the start gcode for the C1L printer profiles from g28 Q to just G28? I have a similar issue I'm waiting on a mysterious cable for from support. But its only impacting my C1L when I use the hardened steel nozzle. It fails the clean and gouges the bed. If i swap to brass, it works normally. They had me test setting the heater to 240 and off, and we got it to work when set to 240. |
|
Yes, just the 1 line. A good way to "test" if this issue is affecting you - though its not a perfect test - is to restart your printer. If that 1st print after restart rarely (ideally never) has the issue, then its a great sign your hitting the Z-axis homing drift problem I'm describing here. Without the above change the printer will only home z on start up meaning the actual Z can drift which is why bed leveling or nozzle cleaning inexplicably crashes / scrapes the bed as if it forgot its actual z height. Obviously some of the above is just a "theory" based on the behaviors I'm seeing and the characteristics of the fix I'm proposing here. Someone with deeper knowledge of the firmware will likely comment with a more authoritative view on the issue / fix described here. |
Sure enough just had it happen with my brass nozzle and power cycling 'fixed' it. |
|
Did you try applying the start gcode fix listed in this PR? if so, did it work for you? |
|
Juts, thank you for sending here from the Prusa Forums. Avirtuos, please take a look at this thread. I can make this condition repeat. Been in contact with Prusa support 4 times, the last time 1/18/26, since I could prove this issues is a firmware bug, they agreed with what they were seeing and how I could make it repeat the failure, they had no answers, and basically blew me off. Said to contact them if it happened again, I can make it happen endlessly. |
|
Did you try the fix proposed here @ruebarb ? if so, did it resolve your issue? I didn't see a clear answer to these questions in your post of the linked forum thread. |
|
There is a firmware update just released that prusa support tells me should fix this issue - |
|
You didn't miss anything, Prusa had no answers. More of I can prove the issues exists, it is repeatable. I haven't tried your G code edit yet. |
|
Can confirm that this happens after doing two or more prints without power cycle. Core one L smashed the nozzle into the print sheet leaving scrapes and nozzle imprints on the build plate. |
|
How do we get Prusa to actually do something to fix thier bug, thier CS gaslights everything I bring to them. |
|
Yea, I am fairly disappointed no one from Prusa has at least triaged this PR in the few weeks that it has been open. Thankfully you can fix this yourself easily by applying the one line change to your start gcode. |
|
Here is another with a similar Z loss, same nozzle crash. |
I recently got a new Core One L and noticed that the more prints I run without restarting the printer or taking an action that forces a full homing of all 3 axis the more often my nozzle cleaning or mesh leveling would fail. I spent hours trying to figure out if I was imagining things and then I started recording the first few minutes of each print and I noticed that my Core One's initial homing / probing procedure is different from the Core One L. The Core One will do a full homing (G28) at the start of each print, which results in the x/y bumping but also a single point probe of the bed (z-axis). I think I tracked the difference down to the line I've edited in this PR. Without this change I can reliable get the nozzle to start scraping the bed during nozzle clean / mesh leveling after a few prints to the point where it will fail. With this change I am no longer able to reproduce this failure mode after dozens of prints.
It is unclear to me (a) why the Core One L switch to G28 Q (and we didn't update the Core One) but also (b) why G28 Q doesn't probe the z-axis as the documentation I was able to find for G28 indicates that G28 Q should home ALL axis. Maybe this is a bigger bug in the firmware's implementation of G28 Q but this fix seems faster to release to customers and without drawback so an investigation of possible firmware issues related to G28 can likely happen independent of this pull request.
The diff looks worse than it is, only the following part of the start-gcode was edited in both profiles
Before
G28 Q ;home all without mesh bed levelAfter
G28 ; home all without mesh bed levelTested on firmware 6.5.1+12574 with a Core One L manufactured in Dec 2025.