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

slic3r.pl works, but in octoprint doesn't #38

Open
ChristophSchranz opened this issue Jul 11, 2018 · 7 comments
Open

slic3r.pl works, but in octoprint doesn't #38

ChristophSchranz opened this issue Jul 11, 2018 · 7 comments

Comments

@ChristophSchranz
Copy link

I followed the instructions on https://github.com/OctoPrint/OctoPrint-Slic3r/wiki/How-to-install-Slic3r-on-RPi
I couldn't find the tests to verify via the ctest command.

Locally, slicing works well:
image
...perl local and timezone warnings
image

However on Octoprint, i verified the path, used the default profile from Slic3r desktop edition and this error occurs:
image

I couldn't find any help in the internet before. Is anyone familiar with the error responses?

Cheers,
Chris

@eyal0
Copy link
Collaborator

eyal0 commented Jul 12, 2018

First, I'm glad that you were able to compile. That is usually the hardest part!

Open up the settings in OctoPrint (wrench icon) and the click on logging and then look for the log called "plugin_slic3r_engine.log" and download it using the download button on the right. Open up that file and see if you can make sense of the error from those messages.

If you can't make sense of the error, post it here and I'll take a look.

@ChristophSchranz
Copy link
Author

ChristophSchranz commented Jul 12, 2018

Thanks for the answer.
I checked the log and indeed it helped me further!
image
It seems that the profile i used is wrong.

Edit:
However, when I select profiles in the GUI, which work in the cli, they will fail with octoprint too.
As seen in the first picture, Octoprint uses a profile from the /tmp directory. However, my uploaded and working profiles are stored in .octoprint/slicingProfiles/slic3r/
I'm just wondering why octoprint uses the stl from the upload folder, but the profile from /tmp.
Is it possible that this bug has been already fixed somewhere?

Edit:
In the slicer window: When I select a print for slicing, this message appears:
2018-07-12 11:13:05,470 - tornado.access - WARNING - 409 POST /api/files/local/arms2_single.stl (127.0.0.1) 35.49ms
2018-07-12 11:13:08,400 - tornado.access - WARNING - 409 POST /api/files/local/arms2_single.stl (127.0.0.1) 35.38ms
I've also seen that it comes along the warnings from the slicer. Maybe that's the origin from the bug.

@eyal0
Copy link
Collaborator

eyal0 commented Jul 13, 2018

The profile is copied into tmp because the profile that is stored in OctoPrint is in a different format from that of what Slic3r expects. OctoPrint reads in the profile, converts it to a different format, ans then Dave's it. In order to recreate the original, it reads the stored format, converts that into the original, and saved that into tmp. It's the same technique that the cura plugin uses. All the converting doesn't have much purpose so maybe I should get rid of that. I but haven't gotten complaints about it so I never changed that.

@eyal0
Copy link
Collaborator

eyal0 commented Jul 13, 2018

Also, don't use export config bundle. Use export config. We don't support bundles.

You can see the slicing profile as it is stored in the directory .octoprint/slicingprofiles/slic3r .octoprint/slicin

@ChristophSchranz
Copy link
Author

ChristophSchranz commented Jul 13, 2018

Ok I've figured out the problem:
The ini-file is transformed into a profile-file.
If it loads the ini-file, it works,
pi@octopi:~ $ ./Slic3r/slic3r.pl --load Downloads/myprofile2.profile Downloads/arms2_single.stl

However, with the automatically generated profile-file it stucks:
pi@octopi:~ $ ./Slic3r/slic3r.pl --load .octoprint/slicingProfiles/slic3r/myprofile2.profile Downloads/arms2_single.stl
Invalid value for support_material_extruder

The solution was to delete the lines "support_material_extruder" and "support_material_interface_extruder" in the profile-file. Now it works fine! :D

Thank you eyal0 for the help!

Edit:
In case someone is facing the same problem, here is a working profile for the Prusa i3 MK3:
i3_0mm10_none.profile.txt

@eyal0
Copy link
Collaborator

eyal0 commented Jul 13, 2018

Great!

How did those lines about support material extruder get in there? We're they in the uploaded file?

I'd like to make it so that future users won't have this bug. Or at least make it easier to diagnose.

As you noticed, the profile that OctoPrint stores is a slightly transformed version of the input ini file. OctoPrint stores profiles as python dictionaries so that they can potentially be merged. But it can cause confusion when converting back and forth.

@ChristophSchranz
Copy link
Author

I've seen that in the profile.py this could be implemented quite fast.

To reproduce this error:

  • I exported the config on the Slic3r desktop version (Version 1.40.1-beta-linux64)
    orig_i3_0mm1_none.ini.txt (without the .txt, I just used it to upload that file)

  • Then upload the ini with the Plugin

  • While Slicing, i got this error:
    image

However, the one in my last comment works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants