πŸ‡ΊπŸ‡¦ We stand with Ukraine! πŸ‡ΊπŸ‡¦

False "print exceeds bed size" warnings on Prusa i3 mk3

Hello everyone, I'm back in OctoPrint after purchasing, building, and calibrating a Prusa i3 MK3. Gotta say - this is one hell of a great printer. Compared with my old FlashForge Creator Pro, the MK3 has been much more reliable and has produced prints with much better quality (and I haven't even tried the high-detail setting yet).

I've also completed a transition to OctoPrint, and it's working great - with one small issue: the bed size warning is occurring with nearly every print. This is odd because I'm using the PrusaPrint image, which of course is preloaded with MK3-specific settings; I'm slicing and G-Coding with the version of Slic3r right from Prusa; and I'm printing small, typical things that take up the middle 1/9th of the bed and aren't more than 10cm tall.

I see that the "bed size warning" feature is listed as beta. I'm interested in helping to debug by providing diagnostic info, but I'm not sure how to access any diagnostic info for this particular feature. If someone can point me in the right direction, I'll provide some data after the next warning.

A lot of the time it's because the printer moves to a negative value to wipe or purge the nozzle. I'm pretty sure prusa's move to like -something and do a purge line, that puts the "model" size at larger than the bed, octoprint doesn't know the difference between a purge and a printed wall. So while the build volume might be say 200x200 (yes I know they're bigger than 200x200, just go with it), that negative space it uses is reserved in the firmware so your actual build volume is more like 220x200.

Hello @sfsdfd,

note that the size detection is still BETA status. It can result in errors with some models. You can switch it off:

And here are the settings of my MK2.5:

1 Like

Looks like it was also asked on 3d.stackexchange and an answer was accepted:

First, I just thought I'd mention (for the sake of exact-string google searches) that the error in the UI is "Object doesn't fit print volume"

Or, as a more complete example:

Object doesn't fit print volume

Object in [something].gcode exceeds the print volume of the currently selected printer profile, be careful when printing this.

More

Object exceeds print volume in depth.
Object's bounding box: (0.00, -3.00, 0.00) Γ— (137.87, 167.86, 4.50)
Print volume: (0.00, 0.00, 0.00) Γ— (250.00, 210.00, 210.00)

Second, it seems to me that the relevant bits of gcode are these lines -- particularly the first one:

G1 Y-3.0 F1000.0 ; go outside print area
G92 E0.0
G1 X60.0 E9.0 F1000.0 ; intro line
G1 X100.0 E12.5 F1000.0 ; intro line
G92 E0.0

Next, the code that generates the error is in the evaluatePrintDimensions function within static/js/app/viewmodels/files.js (line 994, in the copy I have).

That, in turn, references data["gcodeAnalysis"]["printingArea"]... which derives from filemanager/analysis.py (line 487), which gets its data, in turn, from analysis["printing_area"], which in turn appears to get its data by running:

python -m octoprint analysis gcode [...etc...]

(ibid, line 423). Digging further, I see util/gcodeInterpreter.py is where this comes from, and [skipping some steps], in particular it comes from the analysis done in the loop at line 278, more specifically recording the value at line 393.

Now, my first thought was to suggest is that, up around line 350 (where y gets set from the data in the gcode), perhaps we could special-case a tweak of the y value? More specifically, it occurs to me that a naΓ―ve solution might be something like adding a test a few lines after that y gets set that does something like:

# integer of 10x to eliminate possibility of false float inequality
if y and int(10*y) == -30 and comment == "go outside print area":
    y = 0.0 # cheat y inside print area for nozzle cleaning run.

Such a solution does in fact get rid of the error. So does a workaround from another answer in the stackexchange question linked by @tedder42, which changes the dimensions of the print bed to include Y=-3.

However, both of these still consider that initial strip to effectively be part of the print, which it really isn't (it's part of the preamble in the slicer, not part of the model output, per se), so... Perhaps something more comprehensive is in order? I'm not entirely sure the best way to do things... but... well...

Here's a diff/patch of what I did for myself; feel free to incorporate this, or use it as a model for a better version, or whatever (a few more thoughts after the patch):

--- octoprint/util/gcodeInterpreter.py.orig	2021-02-24 17:43:06.202647542 -0800
+++ octoprint/util/gcodeInterpreter.py	2021-02-24 21:49:40.781844790 -0800
@@ -275,12 +275,32 @@
         if len(offsets) < max_extruders:
             offsets += [(0, 0)] * (max_extruders - len(offsets))
 
+        in_skip_zone = False
+
         for line in gcodeFile:
             if self._abort:
                 raise AnalysisAborted(reenqueue=self._reenqueue)
             lineNo += 1
             readBytes += len(line.encode("utf-8"))
 
+            # there are a few very specific lines we wish to ignore for
+            # our purposes, as they're just the printer doing an initial
+            # extrusion line to get the filament flowing, and thus are
+            # not usefully part of the "model" -- so we don't want this
+            # to show up in the "printing_area":
+            if line.strip() == "G80 ; mesh bed leveling":
+                in_skip_zone = True
+            elif in_skip_zone and (
+                    # first line, gets us outside:
+                    "; go outside print area" in line or
+                    # 3rd and 4th lines, extrudes a bit:
+                    "; intro line" in line or
+                    # 2nd and 5th lines, stopping extruder:
+                    line.strip() == "G92 E0.0"):
+                continue
+            else:
+                in_skip_zone = False
+
             if isinstance(gcodeFile, (io.IOBase, codecs.StreamReaderWriter)):
                 percentage = float(readBytes) / float(self._fileSize)
             elif isinstance(gcodeFile, (list)):

Using this version, not only is the error not presented, but the dimensions calculated for the model (as reported by gcodeInterpreter.gcode().load(...).get_result()['printing_area']) reflect the dimensions without that initial "intro line".

Alas, apparently this also gets calculated somewhere else, because it isn't reflected in the GCode Viewer ("Model size" under "Model info") β€” that still gives me dimensions with the stripe included. So... I guess there's more to be done.

Also, if the preamble comes in any different form from the slicer, this code likely won't catch it. A more comprehensive solution might be to detect discontinuities and check them against certain parameters β€” if they're one-line stripes along one axis that fall on layer zero, ignore them? β€” or at least have a sub-option to ignore them (without entirely disabling the warning), or.... I don't know.

Anyway, this does the trick well enough to at least get rid of the error, so... I hereby submit it to the community, in hopes that others may also find it useful. :slight_smile: If/when I come up with something that'll also update the "Model size" under "Model info" in the GCode Viewer, I'll be sure to share.

This is kind of what the custom bounding box is for, this exact situation, setting it to -3 also stops the error occuring.

3 Likes

This is true! However, that solution still gives a potentially-unrealistic report of the size of the print. It would be nice if a preamble line could be treated separately from the core print -- so e.g. if you have a 10x10mm print in the middle of a 200x300mm print bed, it says it's 10x10mm, instead of 155x108mm. Not critical, it would simply be nice.

It is not just Prusa printers that potentially trigger "print exceeds bed size".

My LulzBot TAZ 6 print volume is 280 x 280 x 250mm but requires a bounding box of -20,300 x -20,300 x 0,260 because it has a wiper pad next to the bed and auto leveling points on the corner washers holding the bed down.

That bounding box doesn't cause OctoPrint's GCode Viewer to report an unrealistic size of the print. A 3DBenchy sliced and ready to print (including wiping the nozzle and auto leveling) shows "Model size: 59.86mm Γ— 30.50mm Γ— 47.50mm" (with the .stl file dimensions of 60mm x 31mm x 48mm).