Re: Stable Slic3r builds
1.31.2 is awesome when it comes to support 🙂 Thank you!
Re: Stable Slic3r builds
I have one question though. When I go layer by layer in the gcode viewer at http://gcode.ws/ I see an interleaving pattern between three different type of layers - "support only", "support and model", "model only". I hope this is visible on the attached pictures. The issue is that the "model only" layers accumulate faster than the layers with support. As a result after some time the PINDA probe crashes against the model while making a support only layer (my PINDA probe is about 1.5mm higher than the nozzle). It looks to me a as a problem during support slicing, but I don't have an algorithm to prove this in the gcode. Can anyone help with this?
Re: Stable Slic3r builds
I am attaching the compressed gcode for analysis.
Re: Stable Slic3r builds
Slic3r generates the support layers at a Z spacing independent from the model layers with the wish to make the support layers thicker, therefore printing faster. In the future this behavior will be configurable, also due to the color switching of our multi-material rig.
But frankly I don't understand why the PINDA probe should crash into the supports due to the different layering of an object and supports, as long as the total height is correct. And we are testing the Slic3r supports in house without such an effect.
Vojtech
Re: Stable Slic3r builds
We have a new build, mostly fixing some issues introduced in the 1.31.2 build.
https://github.com/prusa3d/Slic3r/releases
Also this build fixes some hang-ups on Windows 64bit, namely the hang ups at auto placement of models on the print bed and on sequential printing.
Re: Stable Slic3r builds
Since there are not Linux builds from Prusa, I'm using the Slic3r version (1.2.9) that comes packaged in Fedora 24 plus the settings extracted from the OSX build . Other than been slightly outdated, is there any reason why I should switch (building from source) to the Prusa one?
Thanks!
P.S: Extracting the settings from the zip is not that hard but I was wondering if there is a reason (other than the extra work) for no keeping this settings in a Github repo.
Another Fedora user -
I have been able to compile from Master (1.30.0-dev) using the guide for Linux builds. However, the release will not compile. They apparently changed the wx code to use version 3.0 libraries which as funky on Fedora. the maintainer did not want to upgrade the 2.8 libraries as it would break too many things so they installed them as gtk3+ rather than gtk2+. At least that appears to be the root of the issue.
So I am having to use wine to run Cura 2.x for much of my slicing as slic3r 1.30 leaves major gaps on slopes. BTW, the setting are in a separate github repo.
Re: Stable Slic3r builds
@Vojtech, I am not quite sure I understand what's happening too. But it seems to be absolutely reproducible as I am getting the same error three times out of three trials with the same gcode. During printing of the support the PINDA crashes against the edge of the model which prevents the nozzle to move further in direction positive X and as a result I get an offset in the X-axis. Always on the same place 4 to 5 hours of printing. You can try to reproduce it with the previously attached gcode. I will slice again with 1.31.3 and look for differences.
But you are absolutely right, the total height seems to be correct. I'm starting to wonder if it is some thermal effect that leads to deformation of the edge of the model, the one close to the support. But I won't expect this to be happening with PLA.
Re: Stable Slic3r builds
@Vojtech, I am not quite sure I understand what's happening too. But it seems to be absolutely reproducible as I am getting the same error three times out of three trials with the same gcode. During printing of the support the PINDA crashes against the edge of the model which prevents the nozzle to move further in direction positive X and as a result I get an offset in the X-axis. Always on the same place 4 to 5 hours of printing. You can try to reproduce it with the previously attached gcode. I will slice again with 1.31.3 and look for differences.
But you are absolutely right, the total height seems to be correct. I'm starting to wonder if it is some thermal effect that leads to deformation of the edge of the model, the one close to the support. But I won't expect this to be happening with PLA.
I have a couple of questions for you: 1. Does Calibrate XYZ say your printer is "perpendicular", and 2. What is the value of your Live Z Adjust?
Re: Stable Slic3r builds
BTW, the setting are in a separate github repo.
Ugh! My bad. 😳
Thanks tom.s for pointing the obvious.
Re: Stable Slic3r builds
> I have a couple of questions for you:
> 1. Does Calibrate XYZ say your printer is "perpendicular"
The printers coming out of our production have to pass the "perfectly perpendicular" or "slightly skewed" criteria. I would say it is 50:50.
> 2. What is the value of your Live Z Adjust?
roughly -0.7, but I don't think this is critical. It has to be negative.
Vojtech
Re: Stable Slic3r builds
> I have a couple of questions for you:
> 1. Does Calibrate XYZ say your printer is "perpendicular"
The printers coming out of our production have to pass the "perfectly perpendicular" or "slightly skewed" criteria. I would say it is 50:50.
> 2. What is the value of your Live Z Adjust?
roughly -0.7, but I don't think this is critical. It has to be negative.
Vojtech
I have found people that have a very large negative Live Z adjust tend to have the PINDA probe drag on their prints. From some of the people I talk to that fine tune their printers, -0.200 to -0.400 is a really good Live Z adjust value to have. I find it is rare to have someone with a Live Z adjust value between 0.000 and -0.200. But I've also discovered that these low of Live Z adjust values require Calibrate XYZ to report "perfectly perpendicular".
Re: Stable Slic3r builds
> But you are absolutely right, the total height seems to be correct. I'm starting to wonder if it is some thermal effect that leads to deformation of the edge of the model, the one close to the support. But I won't expect this to be happening with PLA.
I think the problem is, that the object does not stick to the supports well enough. When using supports with this version of Slic3r, you should enable "detect bridging perimeters". This makes the perimeters over supports thicker. You may also try to make the gap between the support and the print small, maybe zero. The object will not lift then, but the supports will be hard to remove.
Re: Stable Slic3r builds
I've noticed on the lastest stable build, 1.31.3, the "Support on buildplate only" option is placing supports inside of objects. I've enclosed a screenshot of the plate preview, along with the print settings. This is the one thing that keeps me going back to Cura, as it handles the supports only on the buildplate issue well.
Great work on all of this, I really appreciate the effort you all put forth!
Chief
Re: Stable Slic3r builds
Actually we provide a Slic3r build for 64bit linux, built on some Ubuntu linux I think.
https://github.com/prusa3d/Slic3r/releases
The problem with Linux is, the "DLL hell" for binary distributions is even worse than with Windows.
Please let me know whether this binary distribution of Slic3r works and / or which library needs to be fixed.
Thanks, Vojtech
I've tried both the .2 and .3 releases, Command line appears to work, no GUI. I notice that there are broken links in the bin directory. Those libraries are not available on Fedora (similar, but different naming scheme and compile options apparently). I could probably run slic3r with a local copy of the libwx files in Slic3r/bin if I had the ones you compiled with. Compiling from source does not seem to work on Fedora after 1.30-DEV or whenever you went to the 3.0 branch of the wx libraries.
Re: Stable Slic3r builds
> I've tried both the .2 and .3 releases, Command line appears to work, no GUI. I notice that there are broken links in the bin directory. Those libraries are not available on Fedora (similar, but different naming scheme and compile options apparently). I could probably run slic3r with a local copy of the libwx files in Slic3r/bin if I had the ones you compiled with. Compiling from source does not seem to work on Fedora after 1.30-DEV or whenever you went to the 3.0 branch of the wx libraries.
Our Linux builds are built on
Linux BuildBot 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64 GNU/Linux
with a non-system perl installed through a perlbrew.
The following libraries are required by the Slic3r:
/lib64/ld-linux-x86-64.so.2
libatk-1.0.so.0
libcairo.so.2
libc.so.6
libdatrie.so.1
libdl.so.2
libdrm.so.2
libexpat.so.1
libffi.so.6
libfontconfig.so.1
libfreetype.so.6
libgcc_s.so.1
libgdk_pixbuf-2.0.so.0
libgdk-x11-2.0.so.0
libgio-2.0.so.0
libglapi.so.0
libglib-2.0.so.0
libGL.so.1
libGLU.so.1
libglut.so.3
libgmodule-2.0.so.0
libgobject-2.0.so.0
libgraphite2.so.3
libgthread-2.0.so.0
libgtk-x11-2.0.so.0
libharfbuzz.so.0
libICE.so.6
libm.so.6
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpcre.so.3
libpixman-1.so.0
libpng12.so.0
libpthread.so.0
libresolv.so.2
librt.so.1
libselinux.so.1
libSM.so.6
libstdc++.so.6
libthai.so.0
libuuid.so.1
libwx_baseu-3.0.so.0
libwx_gtk2u_adv-3.0.so.0
libwx_gtk2u_core-3.0.so.0
libwx_gtk2u_gl-3.0.so.0
libwx_gtk2u_html-3.0.so.0
libX11.so.6
libX11-xcb.so.1
libXau.so.6
libxcb-dri2.so.0
libxcb-dri3.so.0
libxcb-glx.so.0
libxcb-present.so.0
libxcb-render.so.0
libxcb-shm.so.0
libxcb.so.1
libxcb-sync.so.1
libXcomposite.so.1
libXcursor.so.1
libXdamage.so.1
libXdmcp.so.6
libXext.so.6
libXfixes.so.3
libXinerama.so.1
libXi.so.6
libXmu.so.6
libXrandr.so.2
libXrender.so.1
libxshmfence.so.1
libXt.so.6
libXxf86vm.so.1
libz.so.1
linux-vdso.so.1
Which ones are you missing?
I am quite reluctant to pack half the Linux distribution with the Slic3r binaries to get it running. Are you able to compile Slic3r on your Linux box?
https://github.com/alexrj/Slic3r/wiki/Running-Slic3r-from-git-on-GNU-Linux
Thanks, Vojtech
Re: Stable Slic3r builds
The libwx_gtk2u* files are not available on Fedora in that version.
After 2.8 fedora changed the library names to libwx-gtk3u* to prevent issues with software requiring 2.8, and the maintainer was unwilling to upgrade. Another individual stepped in and it was agreed to change the library name. I have looked through the slic3r source, but have been unable to determine where the calls to link those files are. Placing renamed file in the 'slic3r/bin' directory did not work as there are missing values. Apparently Fedora compiled with different flags.
I notice that there are links in the Slic3r/bin directory for these libraries, but no library files for them to link to. If I had the libraries (libwx*) that you built against I would have a chance that it would compile. Slic3r itself compiles, but when evoked as 'slic3r --gui' it fails to compile. Being in the RPM world, I can not install the .DEB files, but I would be willing to try running those libraries locally, but really don't want to have to try to compile the libraries myself and match the Debian ones.
/* UPDATE */ I went to the WXwidgets site and they had fedora binaries available which I placed in the /slic3r/bin directory and the GUI now starts. by opening the rpm in the archive manager, i was able to extract just the library files needed. I needed files from three RPMs:
wx-base-unicode-3.0.2-1.x86_64.rpm,
wx-gtk2-unicode-3.0.2-1.x86_64.rpm, and
wx-gtk2-unicode-gl-3.0.2-1.x86_64.rpm
Re: Stable Slic3r builds
Would you please try the following Linux wx-gtk2 libs?
Re: Stable Slic3r builds
Would you please try the following Linux wx-gtk2 libs?
Missing the libwx-baseu-3.0.so.0.2.0 library, but with that added it works. I added a file, sliced it and saved the gcode.
Re: Stable Slic3r builds
> Missing the libwx-baseu-3.0.so.0.2.0 library, but with that added it works. I added a file, sliced it and saved the gcode.
ok, thanks, I will add these files into our linux builds.
Re: Stable Slic3r builds
I have posted a new Slic3r build
https://github.com/prusa3d/Slic3r/releases/tag/version_1.31.6
There is a Linux package, which I have tested on Ubuntu 16.04.1 Desktop (needs to install freeglut3), Fedora 24 Workstation and Arch Linux (needs to install gtk2, glu, glut) with success.
Also there is an initial Debian package prepared by Chow Loong Jin.
[0] https://ftp-master.debian.org/new.html
[1] https://anonscm.debian.org/git/3dprinter/packages/slic3r-prusa.git
Vojtech