[Bug?] Incomplete file analysis #1685

derpicknicker1 opened this Issue Jan 4, 2017 · 2 comments


None yet

2 participants

derpicknicker1 commented Jan 4, 2017 edited

What were you doing?

I sliced a *.stl file with the bundled slicer plugin.

What did you expect to happen?

I expected that a complete file analysis will happen after slicing

What happened instead?

The metadata of the file will not include filament usage as they would when a analysis on uploaded gcode is done.

Branch & Commit or Version of OctoPrint

Version: 1.3.0 (master branch)

Printer model & used firmware incl. version

Eustathios Printer with Marlin 1.0.2

Browser and Version of Browser, Operating System running Browser

Chrome Version 55.0.2883.87 m (64-bit) on WIN10

Link to octoprint.log

No output

Link to contents of terminal tab or serial.log

No output

Link to contents of Javascript console in the browser

No output

Screenshot(s) showing the problem:

Metadata of sliced file:

    estimatedPrintTime: 5816
      tool0: {}
      tool1: {}
  hash: 45698ee20bf37128dab8fbf5e499083a491852ee
  - hash: 666c9407805911c4aeb264fa57f24f98cb3d3451
    name: lego_deckel.stl
    rel: model

See also: kennethjiang/OctoPrint-Slicer#24
I have read the FAQ.

@derpicknicker1 derpicknicker1 referenced this issue in kennethjiang/OctoPrint-Slicer Jan 4, 2017

No file analysis after slicing #24

@derpicknicker1 derpicknicker1 added a commit to fabianonline/OctoPrint-Telegram that referenced this issue Jan 9, 2017
@derpicknicker1 derpicknicker1 Solved issue in file hash usage and parsing file details
* Internal OctoPrint file hashes are calculated by file data. If you
slice same stl with same settings multiple times and save the result in
different named files, the files will have the same hash. The plugin
uses these hashes for file browsing. Now The plugin generates its own
unique hashes.
See also: foosel/OctoPrint#1684
* When slicing with the bundled slicer, there seems to be something
wrong with file analysis of created gecode. No length filed for filament
usage is provided. Plugin can now handle this situation.
See also: foosel/OctoPrint#1685

After some investigation, i did a pull request to fix this issue.

@foosel foosel added a commit that referenced this issue Jan 11, 2017
@derpicknicker1 @foosel derpicknicker1 + Fix issue in getting file metadata after slicing
This fixes the issue that there were no informations about filament
usage in metadata after slicing with cura plugin. Trying to call
profile.get_float("filament_diameter") ended in en exception with
message " 'module' object has no attribute 'get_float' ". So i defined
profile before using profile and now it works.
See issue #1685
Also inserted a check to determine if filament usage is > 0 to exclude
tools with no filament usage in metadata.

(cherry picked from commit c9b38bd)
@foosel foosel added this to the 1.3.1 milestone Jan 11, 2017
foosel commented Jan 11, 2017

Fixed with your PR in maintenance and also devel, will be released with 1.3.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment