GCODE Analysis rarely includes the "printingArea" dict

Get Help
1

What is the problem?
I'm wondering why the printingArea and dimensions dicts from the GCODE Analysis of a gcode file is calculated so rarely. When looking in localhost/api/files it only appears in one out of my 10 gcode files.

I noticed that the size of the file where the dimensions and printing area has been analyzed is considerably smaller than the ones where it hasn't calculated it, so I'm guessing there's an undocumented limit to the filesize, if you want a proper GCODE analysis.

(the "large" files being 106.1KB, small file 28.16KB)

Is there way to bypass this limit? I'm simply just interested in knowing whether the file exceeds the bed.

Logs
Not that I think they're really needed, but here are the logs;
https://www.dropbox.com/sh/qo4jjhi7e738oj8/AACraaHaTDi9IcDgFVehbSAga?dl=0

Additional information about your setup

  • Octoprint version: 1.3.12 running on OctoPi 0.15.1
2

I still haven't figured out why or exactly when the metadata analysis skips the printingArea and dimensions calculations, but I've made a plugin that uses the octoprint.filemanager.analysis.QueueEntry class to re-evaluate the file with high_priority set to True. The plugin does this automatically when it gets a MetadataAnalysisFinished event that doesn't contain the printingArea dict. The new analysis starts just fine, but the result I get is a dict filled with null values.

The re-calculated gcodeAnalysis I get now looks like this;

gcodeAnalysis: {
  dimensions: {
    depth: 0,
    height: 0,
    width: 0
  },
  estimatedPrintTime: 0.5344246021308753,
  filament: {
    tool0: {
      length: 0,
      volume: 0
    }
  },
  printingArea: {
    maxX: null,
    maxY: null,
    maxZ: null,
    minX: null,
    minY: null,
    minZ: null
  }
},

Even before I do the high priority analysis, the meta data analysis that doesn't contain the printing area or dimensions all have values set to 0.

Is there a way to make the calculations more reliable? The QueueEntry() function returns true even though it seems it failed to get any of the values (sometimes it manages to calculate the estimated print time).

Is this function just not reliable enough to always give you data?

3

If it analyses the print job (and is actually allowed to finish) it should provide data. If it doesn't that's a bug that should be reported and looked into (preferably with GCODE files to reproduce because otherwise it might get tricky - I've never seen this behaviour on my own instances as far as I know, regardless of GCODE size).

Could be something simple as some GCODE properties causing stuff to not be calculated properly.

4

Some more quick info:
My files shown in the API; https://pastebin.com/raw/8v5sCgtB
image

This only really seem to happen to files that are sliced through the Octoprint Cura (legacy) slicer. When dragging a file directly into the octoprint UI that has been sliced in Simplify3D, it calculates everything just fine, but when slicing through octoprint (also if I download the sliced gcode file and re-upload it), it gives the empty data - sometimes with missing dicts.

The files can be found here; https://www.dropbox.com/sh/laff90yt39j3gad/AABJdwlpRbbn_FRQLLccaM6Pa?dl=0

  • "wire-rail.gcode" is sliced manually using Simplify3D
  • "soundbar-spacer.gco" is sliced with Cura through the "Cura Legacy" slicer plugin
  • "soundbar-spacer-stl" (self explanatory)
  • "cura-test-profile.ini" is the profile used to slice with cura in Octoprint

It seems that Cura or the way Octoprint uses it that results in meta data not being calculated properly.

I can open a Github issue if you'd like,

5

Please do. Otherwise chances are high it'll get lost before I find the time to actually look at it.

1 Like
6

Issue created; https://github.com/foosel/OctoPrint/issues/3387

1 Like