[BFW-5841] [BUG] Prusa XL false modular bed error 17255 due to high nozzle temperature

[rrsawant1]

Printer type - XL 5T

Printer firmware version - 5.1.0-alpha2

Original or Custom firmware - Original

Describe the bug Summary: A false positive 17255 modular bed error is triggered due to the printing conditions when all heatbed tiles are working properly.

Cause: When materials with greater printing temperatures and low bed temperatures are printed such as Polymaker PA612-CF, the nozzle heat leaks into the heatbed triggering error 17255. This occurs during the first layer of a model with large surface area on the bed. The greater surface area allows more time for the nozzle to leak heat into the heatbed tile. Since there is a large temperature delta between the nozzle and heatbed tile, it triggers the error quickly.

How to reproduce Print high melting temp, low bed temp filament with a large bottom surface area fully covering a tile. A thin rectangular prism spanning one entire tile is sufficient.

Expected behavior During the first layer, the printer will crash with error code 17255 for that tile. This phenomenon may also occur with certain filaments that have a high bed temperature (Prusament PA11) if the first layer is printed slowly enough for heat to absorb into the tile.

Possible solutions In firmware, detect when the nozzle temperature is high and it will be moving over a heatbed tile slowly. In this case, increase the tolerance for 17255 to be triggered.

Don't detect the high nozzle temp and simply increase the tolerance for all prints.

Slicer settings and GCode Version 2.7.0-beta1 Debree Bucket PA612_0.6n_0.25mm_PA,PLA_XL_6h14m.zip

[hardiebotha]

I am having the exact same issue printing the same material - PA6-CF at 290C with the bed at 50C.

I was getting an error on tile 3, and per the knowledge base, I swapped the connector to tile 4, at which point the error moved to tile 4. I suspected the error was triggered by heat injected from the print, and moved the printed part. I am now getting the error on tile 10, where the part is now centered.

I've never had bed heating issues before, and do not believe the issue to be with the modular bed elements or thermistors. I suspect the thermistor is detecting an increase in temperature due to heat from the printed part even when heating is switched off for the module, triggering this error.

A possible avenue to resolution is to allow the bed module to rise in temperature, even above the set temp as long it is being printed on. Once the head moves away for more than 10? seconds, the temperature should no longer rise. If it keeps rising, it may indicate thermal runaway conditions.

Firmware | 5.1.2+13478 PrusaSlicer Version 2.7.1+win64

[czei]

I am having the same issue, but with regular ABS and PETG. Any model printed in the middle of the bed fails with a 17255 error. I can print ABS if the model is tiny and it's only on Tile 1, but pieces that are larger and use most of the bed fail.

Even if I try to print a benchy in the middle of the bed fails with a 17255 error.

Oddly enough the Tile number remains the same even if that tile is replaced, or swapped or the cables swapped.

[hardiebotha]

If you swap cables and the tile number remains the same in the error message, the problem is most likely the cable. Does the reported tile number change if you move the model around on the print bed in the slicer?

On Sat, 27 Jan 2024 at 09:19, czei @.***> wrote:

I am having the same issue, but with regular ABS and PETG. Any model printed in the middle of the bed fails with a 17255 error. I can print ABS if the model is tiny and it's only on Tile 1, but pieces that are larger and use most of the bed fail.

Even if I try to print a benchy in the middle of the bed fails with a 17255 error.

Oddly enough the Tile number remains the same even if that tile is replaced, or swapped or the cables swapped.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3484#issuecomment-1913184916, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVFVFYZ5MGNYFRV4J62YBDYQULIRAVCNFSM6AAAAAA7QCEG4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGE4DIOJRGY . You are receiving this because you commented.Message ID: @.***>

[czei]

I don't quite get that logic. If you completely swap out a cable, and the cable is bad, then the reported Tile number of the error would change.

For example, if you have a bad cable connected to Tile #1, and you completely swap that cable with Tile #2, you'd then have a bad cable on Tile #2, and the reported error would be on Tile #2.

In any event the reported Tile number of the error stays the same no matter what model is being printed, and in any location on the bed. In this case the error is on Tile #15, and that cable was completely replaced with a new one. But I decided to try swapping cables just to make sure, and now I can't get it to fail. This probably indicates the cable wasn't plugged in completely, but that cable had been unplugged and plugged many times, as well as swapped. At least everything's working now though!

[dhyananbho]

I get the same error in a slightly different but similar situation:

XL • Printing TPU (Extrudr Flex SemiSoft) • Modular Bed Error Tile No. 11

I wanted to print a large lid with TPU (Extrudr Flex SemiSoft clear) that would fill almost the entire bed. During the first layer, when tile 11 was mostly covered, the "Modular Bed Error" for tile 11 occurred, resulting in a first restart of the printer due to the error indication and a second restart of the printer after pressing the button. This process resulted in the hot nozzle staying very close above the print sheet in the same position for a long time with no possibility for user intervention. I tried the same print a second time with exactly the same result. I then swapped tiles 10 and 11, including the cables, and tried a third time, again with exactly the same result. This means that it is not a hardware error, but that the software parameters are too tight / too strict for checking this error.

—> Why two reboots in the event of an error? —> Why is the bed not moved away fron the hot nozzle in the event of an error? —> The software parameters for checking this error are too norrow / too strict. Please widen these parameters.

—> This bug is very annoying because it prevents me from printing the desired object and I cannot fix it myself. I need a solution very urgently. —> Is there a possibility for me as an experienced user to temporarily disable this check?

After further research and I found the following:

I still think that the test values of the "Modular Bed Error" are too strict, because no such error should occur during normal printing, but only when there is a real danger. Apart from that, I have found out why the error occurs with extrudr FLEX SemiSoft (and Hard) but not with PETG. The reason is obvious: In the configurations of all extrudr FLEX, the component cooling is turned off completely. This means that less heat is dissipated and the error occurs. But when using a 1.0 mm high flow nozzle with 0.5 mm layer height and an automatic cooling of 60-80 %, the error still occurs (at 0.3 mm layer height it does not). The test values are definitely too strict.

XL Firmware Version 5.1.2+13478 PrusaSlicer Version 2.7.1+MacOS-arm64

Sortbox Hüllendeckel 6x4.3mf.zip

[hardiebotha]

I don't quite get that logic. If you completely swap out a cable, and the cable is bad, then the reported Tile number of the error would change.

For example, if you have a bad cable connected to Tile #1, and you completely swap that cable with Tile #2, you'd then have a bad cable on Tile #2, and the reported error would be on Tile #2.

In any event the reported Tile number of the error stays the same no matter what model is being printed, and in any location on the bed. In this case the error is on Tile #15, and that cable was completely replaced with a new one. But I decided to try swapping cables just to make sure, and now I can't get it to fail. This probably indicates the cable wasn't plugged in completely, but that cable had been unplugged and plugged many times, as well as swapped. At least everything's working now though!

Gotcha - I thought you were just swapping cables on the heatbed side, did not realize it was a complete replacement. My bad, I didn't quite understand what you were doing.

[Skaronator]

I also ran into error 17255 as well, but always late (5 hours) into the print. I tried to print basically the same model twice, but I sliced it two times with different settings. I always had Tile 15 which is the top right tile which shouldn't even heat up:

First Print

Second Print

[hardiebotha]

I managed to get around the issue by printing without heating the bed, which probably means it was not being monitored for thermal runaway any more as no power is supplied for heating. Not all filaments re this forgiving, so it is not an appropriate way to address the issue, but it was a good way for me to confirm some suspicions on this issue.

[MooseOnTehLoose]

I am also seeing this issue and I am not sure at which point it was introduced, but have done the following troubleshooting steps:

1. Switch the cables for tile 6 and tile 7 - FAIL

2. Switch the physical location of tile 6 and 7 - FAIL

3. Try Prusaslicer 2.7.2 and 2.7.3 - FAIL

4. Upgrade from fw 5.1.2+13478 to 6.0.0-alpha+14120 - FAIL

5. Move the print directly to the edge of the print bed, over the tile reporting the error - SUCCESS

6. Move the print slightly, now reports a completely different tile - FAIL

Some weird stuff happened to the error report after upgrading to 6.0.0 as you can see in the images below, the tile number implies my Prusa XL is more like an XXXXXXXXXL:

I have a .gcode file for 0.4 nozzle ASA that can reproduce the issue but can't upload it to github.

[TouchMonkey]

I am also hitting this when printing a roughly tile-sized object using PA6-CF at 290C with a bed temp of 50C. Would love the logic to be updated, or a way to disable this check for a print.

[gladrusskamrad]

The problem when printing is with the table temperature above 100°C. Errors on different tiles are constantly introduced. Replacing the cable with new ones does nothing. And Prusa apparently can't solve this problem.

[czei]

4. Upgrade from fw 5.1.2+13478 to 6.0.0-alpha+14120 - FAIL

Thank you for reporting everything you've tried! I was able to try the alpha firmware and now won't bother.

I am also getting a Tile #15 "unexpected temperature peak" error on every single print under identical conditions to yours. This is a bummer as I've got product to ship and had sold a couple of MK3's to make room for this printer and now it's just sitting there. The printer does work with PLA and PETG, but everything I sell is ABS.

It definitely seems to be a firmware problem on the tile temperature sensor. I've tried swapping out whole tiles, cables, and the heated controller board, and nothing has worked.

It really would be nice to get an acknowledgment of the issue from Prusa and some sort of timeline for a fix. Does anyone know how to escalate this bug? My PrusaXL has been basically a brick for months, not to mention so many wasted hours trying to troubleshoot the issue.

[rob-miller]

Does anyone know how to escalate this bug? My PrusaXL has been basically a brick for months, not to mention so many wasted hours trying to troubleshoot the issue.

I believe if you raise it with info@prusa.com it will at least go into their issue tracker, and you may get some suggestions.

[czei]

Does anyone know how to escalate this bug? My PrusaXL has been basically a brick for months, not to mention so many wasted hours trying to troubleshoot the issue.

I believe if you raise it with info@prusa.com it will at least go into their issue tracker, and you may get some suggestions.

I was working with Prusa for months with no luck. Luckily the problem just went away when I went from a single head to 5 head machine.

[MooseOnTehLoose]

Just an update here - I was able to work around this by just heating the entire bed.

For everybody reading this I want to also give you a heads up that you probably got here after having failures printing ASA, and if you have enclosed your XL to print ASA.... Prepare for meltdown. You need to start reprinting all the extruder parts in ASA NOW. You also need to reprint the belt holder for the x and y axis thats mounted to the front of the toolchanger. The printer is going to fail slowly and all the PETG held under tension won't stay under tension for long.

Works great now that I've done that and also switch to 5mm OD 3mm ID ptfe tubing and fittings.

[Prusa-Support]

Thanks for reporting. I'm under the impression that there have been no new reports since mid-April when FW 6.0.0 (final) was released. That would mean the issue is potentially addressed in the most recent firmware release, and I'd like you to try and confirm.

• In the past, a few false modular bed errors would be potentially possible due to heated magnetic field inconsistencies. This was addressed in production with complementary controls, plus, an additional "shield" for the modular bed's board. This shield is not really necessary but you may want to check if your printer is missing it. https://help.prusa3d.com/guide/how-to-fix-modular-bed-error-hw-solution_512077
• In other cases, the issue is most likely caused by a damaged board/socket or a pulled wire (no longer firmly crimped).
• Last but not least, there have been a few unconfirmed cases where the problem was caused by air pockets between the sheet and module bed due to debris stuck between them.

Please test the most recent firmware and, with a reminder that in most cases the problem is caused by hardware problems, please consider contacting Customer Support for troubleshooting. https://help.prusa3d.com/article/customer-support_2287

Michele Moramarco Prusa Research

[rob-miller]

Thanks for reporting. I'm under the impression that there have been no new reports since mid-April when FW 6.0.0 (final) was released. That would mean the issue is potentially addressed in the most recent firmware release, and I'd like you to try and confirm.

In fact I only found this problem when starting to print ABS in an enclosure after installing FW 6.0.1. This was for a small test cube, and I could change the error tile by changing the tile I was printing on. I initially also tried swapping cables as suggested on the support pages. I eventually found a spot on a tile that did not trigger the error.

[czei]

Thanks for reporting. I'm under the impression that there have been no new reports since mid-April when FW 6.0.0 (final) was released. That would mean the issue is potentially addressed in the most recent firmware release, and I'd like you to try and confirm.

In fact I only found this problem when starting to print ABS in an enclosure after installing FW 6.0.1. This was for a small test cube, and I could change the error tile by changing the tile I was printing on. I initially also tried swapping cables as suggested on the support pages. I eventually found a spot on a tile that did not trigger the error.

FYI, my identical problem was also triggered by ABS in an enclosure. I worked around the problem by switching to PETG, but have been running tests for the past 24 hours with ABS and haven't triggered the issue. I also upgraded from a single-head to 5-head system, so that may have also had something to do with it.

[MooseOnTehLoose]

This problem still exists for me on 6.0.1 and is easily reproducible with the right STL file, but I will upgrade to 6.0.2 and confirm its still a problem. I have already verified there's nothing wrong with my bed hardware.

[tg73]

This bug is still ruining people's days in 6.0.3.

Wow, I hate this bug. Had the error at first layer in an ABS print, found this issue report, so tried again with the enclosure a bit open. It was going well, 8 hours or so in. I had to be in the room briefly so closed the enclosure door, 3 minutes later - off goes this damn error. Urgh. I really loath it when a "smart" system is exceedingly dumb because of its broken smartness. Dear devs, please fix this. @Prusa-Support - here's a nice new report for you, please exit denial mode.

Dayspring baffles and holders.zip

[czei]

This bug is still ruining people's days in 6.0.3.

I'm still getting this error regularly. There doesn't seem to be any rhyme or reason to it. I've got $500 worth of ABS rolls to print and have had to switch to PETG just to get product out the door. It's definitely triggered by prints that need high bed temperatures, though.

I also have swapped in brand new tiles, new cables, and even paid for a brand new bed controller board. It doesn't seem to be hardware related at all since all of us are getting an error on the same Tile number, which would be exceedingly remote.

[tg73]

I managed to get the print to complete on the 3rd try by 1) aligning all the parts to the centre of the bed rather than front left; 2) heating the whole bed and 3) leaving one enclosure door slightly open (see enXLosure on printables). Maybe I didn't need to leave the enclosure door open, but I didn't want to jinx it - I just wanted it to work. I'm building my RatRig VC4 at the moment, which will be a petg-parts-free ABS/ASA monster.

[TouchMonkey]

This issue caused so many failures when printing objects with large bed-contact area in PA6-CF at 290 that I made a custom firmware.

NOTE: Before going down this route, MAKE SURE you don't have a hardware issue. Follow the instructions on the error page.

The temperature check is in the function CheckTemperaturePeak in src\puppy\modularbed\control\StateLogic.cpp. By default, the function looks for a temperature reading >(SetTemp+3) for 60 seconds. Possible fixes would be to change the number of degrees by changing TEMPERATURE_PEAK_THRESHOLD_DEGREES, or the number of seconds by changing TEMPERATURE_PEAK_THRESHOLD_SECONDS.

Anther option would be to scale the threshold based on nozzle temperature, so that higher print temperatures have more wiggle-room to account for the extra heat-soak.

I went the easier-but-less-safe route of setting the threshold to BED_MAXTEMP, which is 120 for the XL. The max-temp value is defined in include\marlin\Configuration_XL.h, which isn't actually included by StateLogic.cpp so I hard-coded it. Personally, I don't care how hot the bed gets as long as it doesn't get hot enough to damage anything. There's also BED_MAXTEMP_SAFETY_MARGIN defined as 5, so a slightly-more-safe option might be 120-5=115.

The screenshot below shows the change I made. I combined the two checks because TEMPERATURE_PEAK_AMBIENT_DEGREES is 50, and since 120 > 50 there's no point in doing both.

Again, I'd recommend something less aggressive unless you understand the risks, especially since using a custom firmware requires voiding your electronics warranty.

[danopernis]

Hi folks, thank you for reporting. I have created an internal ticket BFW-5841 and we will be working on fixing this issue. I can't give you an estimate as to when the fix will be available. We are going to relax the conditions leading to red screen being shown, similar to what @TouchMonkey is proposing.

[raymondagena]

Thank you. I have 1200 print hours on my XL and I just ran into this bug. This was printing TPU and it seems to fail over the exact same spot every time.

[Mr3Deee]

Over the past months I have seen this problem twice:

First time 17. July - tile no. 15 Second time 2. Sept - tile no. 9

It appears to show up only when printing PETG (which is the material with the highest temperatures)

Looking at this article from Prusa, I can see that there is a solution - however - I cannot see the parts which should get printed to resolve this.

Reading now this thread it sounds like that there will be a firmware update soon?

[danopernis]

Just to give you an update, we still don't have a solution to this, but we have some pretty good reproducers and this is also manifesting on the iX printers (part of the AFS project) which are also using modular bed system. The original idea to just relax the conditions was rejected, as this is an important safety feature and we need to gather more data to judge how to solve this properly.