Failing to read QR code is unrecoverable: Bed ends up too low (nozzle too high)

[GuzziRaz]

Bambu Studio Version

1.8.2.56

Where is the application from?

Bambu Lab github releases

OS version

macoS Sonoma 14.2.1

Additional system information

X1C firmware 01.07.01.00

Printer

X1C

How to reproduce

1. Install a Smooth PEI or Cold Plate in the printer, with a piece of tape covering the QR code.
2. Ensure "Enable build plate detection" is turned on.
3. Slice a small test print for the installed plate, and print it.
4. When printer says it can't read the QR code, just resume.

Actual results

The first layer fails spectacularly because the nozzle is WAY too high. It's so high you can easily spot it when watching the flow calibration, priming and printing (it starts to fail on the flow calibration already).

Expected results

It should work just fine - the expected plate was installed.

Project file & Debug log uploads

I saw this happen a few times over the last months without realizing it was a bug so I'm not quite sure when the problem was introduced. It might have been present in August already, when I got this printer. After reproducing several times over this weekend I am now pretty sure it is an actual bug, either in firmware, software or G-code.

Here are variations of this bug:

1. Slicing for the Cold Plate but using the Smooth PEI. When printer complains about incorrect plate, resume and manually increase temperature to 55°C. This should work just fine, right? Well it doesn't - nozzle ends up too high.
2. Using a Lightyear G10 plate with an incorrectly placed QR code. Slicing for the Smooth PEI (which is correct). When printer complains about unreadable QR, just resume. This should work fine but nozzle ends up too high.
3. I'm pretty sure I've seen this also with a 3rd party Textured PEI lacking any QR code. When printer complained about unreadable QR, I just resumed because it was the correct plate, I did slice for it. But again, nozzle ended up too high.
4. Flow calibration enabled or not, doesn't matter.
5. Bed levelling enabled or not, doesn't matter.

In all of these cases, if "Enable build plate detection" is turned off, it works just fine. But if it's turned on, complains - and is resumed, the nozzle ends up too high.

Checklist of files to include

• [ ] Log file
• [ ] Project file

[mateuszdrab]

I think this is actually a printer FW issue or gcode because I was struggling with the same exact issue past few days with a custom plate.

The nozzle was too high and the filament was being dropped on the plate. The distance was about 2mm.

This was happening even if reprinting from cached file but seems resolved the moment I put a QR code sticker on the plate.

[GuzziRaz]

Hey @QingZhangBambu this is definitely a firmware problem and it leads to a lot of confusion! Often it's not immediately attreibuted to the QR. Here's just an example: https://forum.bambulab.com/t/x1c-bed-leveling-problem-after-motor-noise-cancellation-fw/49923/1

I am pretty sure many problems seen on reddit and forums are actually caused by this, while the users don't associate it with QR so don't even mention it (adding even more to the confusion). This is bound to give your support staff a hard time.

[GuzziRaz]

I re-verified that this happens every single time.

With correct plate loaded and QR enabled and found: Z ends up correct. With correct plate loaded and QR disabled: Z ends up correct. With correct plate loaded and QR is enabled but no QR found (or plate mismatch), then resumed: Regardless of ABL(!), Z height will end up too large (nozzle is high a.k.a. bed is low) by about 0.07-0.08 mm - and the print will invariably fail immediately. Even when there is a full ABL after resuming!

I did see a bit of oozing during bed levelling after resume, but I can’t see it being the reason - because even with ABL turned off, Z ends up with wrong height after a resume.

[GuzziRaz]

Forgot to switch plate so got an IRL test just now. I installed the correct plate and resumed. I did see some oozing but the nozzle was 140°C so it (being PETG) was punched to abidance at first knock. At least that is what I thought.

However, this time the ABL acted up weirdly: It normally probes all 36 spots exactly 3 times. This time it probed between 3 and I believe over 20 (!) times at each spot - as if it saw variations or couldn’t believe the result so kept on drumming until it got a consistent measure. So I soon cancelled the print job to look for debris under the plate but even though the job cancelled allright, the ABL continued until completion. It took quite some time and I think it did more probes on the right side. Anyway after it finally stopped I removed the plate but couldn’t see any debris or other problem. So I restarted the same job with the correct plate but this time I covered the QR causing it to fail, but resumed it immediately. This time there were no ooze but again it probed up to over 20 times on each spot. And then it produced a Perfect First Layer Failure™.

Cancelled the job, restarted without messing with the QR and it rendered a normal ABL and perfect full print.

I still think there was some debris under the plate, I just couldn’t find it. Never saw this ABL behavior before.

[svdb99]

+1

I bought a Lightyear G10 build plate which has an incorrectly places QR code. Hence the printer doesn't detect it.

When I dismiss the error message and tell the printer to continue, the printer lowers the bed by 1 or 2 layer heights, which causes the first layer to not stick and fails the print.

[GuzziRaz]

I just confirmed I can reproduce this bug using latest fw 1.7.3.5.

I can't fathom why you are not fixing this in THIS NEXT firmware release. A whole lot of people are affected by it and many of them never understands it's about the failed QR unless someone tells them. I have given the advice to people on reddit, on forums, IRL and every single time they come back later and report that disabling the QR check made the problem go away.

[Flyrian]

Can confirm the issue is still present for FW 01.08.00.00

[wineBambu]

@GuzziRaz pls upload one tikect to us and we will fix it as soon as possilble. thanks~

[Flyrian]

@wineBambu I would have a unanswered Ticket open for this if it helps US240514817001

[GuzziRaz]

Great, I assume I don’t need to open a similar one then.

[GuzziRaz]

Edit: NVM, we haven't got any later fw yet 🤣

@Flyrian do you know if this was fixed with latest firmware? I haven't had time to try it yet. Bambu never seem to update/close tickets.

[gaolegao-lx]

Please upload log through Handy APP, and give us your ticket number

---

Upload log files through Bambu Handy Log files from the Bambu printer can be uploaded via Bambu Handy over the network, with an upload speed of around 150 kbps under optimal network conditions. When uploading logs, you have the option to select a specific time frame, allowing you to reduce the volume of logs transmitted and shorten the upload duration. To upload files, go to Me → Support Tickets → Choose the ticket for log upload and proceed with the operation.

[GuzziRaz]

I opened ticket US240418890001 several months ago, with logs, with att @chuan.yang (on request) and support staff replied they had forwarded the info.