slic3r.pl works, but in octoprint doesn't

[ChristophSchranz]

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: ...perl local and timezone warnings

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

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

Cheers, Chris

[eyal0]

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]

Thanks for the answer. I checked the log and indeed it helped me further! 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]

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]

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]

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]

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]

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:

However, the one in my last comment works.