Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug?] Incomplete file analysis #1685

derpicknicker1 opened this issue Jan 4, 2017 · 3 comments


None yet
2 participants
Copy link

commented Jan 4, 2017

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 added a commit to fabianonline/OctoPrint-Telegram that referenced this issue Jan 9, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 10, 2017

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

foosel added a commit that referenced this issue Jan 11, 2017

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


This comment has been minimized.

Copy link

commented Jan 11, 2017

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


This comment has been minimized.

Copy link

commented Jan 25, 2017

Part of 1.3.1 which has just been released.

@foosel foosel closed this Jan 25, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.