Why don't you use Cura slicer?
-
David can confirm but I think that the latest beta of RRF has some fix for pressure advance related to the smoothness of extrusion rates in curves.
-
OK, I'll look into what it will take to be able to specify settings for overhangs. A relatively easy solution would be to use the bridge settings for walls whose overhang angle is less than some threshold. Would that be acceptable?
Yes I think that would work well. Overhangs and bridging are pretty similar in their requirements for slow speeds and lots of cooling so they stay in place. This one change alone would make Cura more usable for me.
One thing that Slic3r also has is an extrusion multiplier specifically for bridges, with the logic being that since you're extruding into thin air, you want a thinner extrudate so that it gets pulled taught, and there is less plastic, and therefore, less thermal mass so that it cools faster. I've found this very useful when printing with larger nozzle diameters.
I would also say that being able to look ahead and detect a bridge is about to begin and slowing down before leaving the edge of the supporting layer so that it has a chance to anchor itself. I notice that Slic3r will slow down a little too late and the extrudate will break or disconnect.
Also, I've just been looking into the variable layer height plugin and it looks really good. The manual GUI from Slic3r PE is a bit weird and fiddly to use. The 1.3 dev branch of Slic3r has an automatic function which obeys a full steps/mm value you specify which is a much better way to do it. I hope the Cura version is similar.
https://community.ultimaker.com/topic/20451-cura-variable-layer-heigth/ -
One thing that Slic3r also has is an extrusion multiplier specifically for bridges, with the logic being that since you're extruding into thin air, you want a thinner extrudate so that it gets pulled taught, and there is less plastic, and therefore, less thermal mass so that it cools faster. I've found this very useful when printing with larger nozzle diameters.
I would also say that being able to look ahead and detect a bridge is about to begin and slowing down before leaving the edge of the supporting layer so that it has a chance to anchor itself. I notice that Slic3r will slow down a little too late and the extrudate will break or disconnect.
Also, I've just been looking into the variable layer height plugin and it looks really good. The manual GUI from Slic3r PE is a bit weird and fiddly to use. The 1.3 dev branch of Slic3r has an automatic function which obeys a full steps/mm value you specify which is a much better way to do it. I hope the Cura version is similar.
https://community.ultimaker.com/topic/20451-cura-variable-layer-heigth/Yes, I have a bridge flow setting which does the same as the slic3r extrusion multiplier.
What I have implemented is that the bridged region of walls extends a little onto the solid regions that support the bridge so that the bridge settings come into action just before the air below starts and finish just after the next solid region is encountered.
I am not involved in the variable layer height stuff other than I made some small contribution to speed up their implementation.
-
Your implementation sounds great. Can't wait to try it out.
-
As far as the seg faults under linux go, I had another great one on a clean install. I want to add my K8400 dual nozzle. Can't.
I can add the single nozzle variant no problem. Try and add the second nozzle. Boom! Just dies.
Raised on it github. Discover it's an old bug that's still there after many months. Means it's impossible to add a dual nozzle printer. Again it's one of those annoying python gui issues that's causing it. So frustrating, both for users and the developers I imagine.
This is under the latest LTS version of Ubuntu.
-
Here's an example of bridge settings being used in overhang regions. There is a setting to control how much overhang is needed to use the bridge settings rather than the normal settings.
The Cura devs are not very quick at testing/merging PRs so it will take quite a while before this (or similar) appears in a release.
-
Here's a question - how do the other slicers handle the combination of bridges and support? Is bridging disabled when supports are in use?
-
In Slic3r there is a checkbox toggle to ignore supporting bridges. Just like there is for support on build plate only.
-
OK, thanks. Do you know what happens if both are enabled? WIll slic3r still print using bridge settings even when there is support below?
At the moment, my cura implementation has a switch to enable/disable the bridge settings (and, of course it has the on/off for the support as well) but if both the bridge settings and support are enabled, it will use both. It's actually quite a lot of effort (I think) to detect if an area has support under it so that the bridging can automatically be turned off so I wasn't going to do that.
-
As far as I know, even with support turned on for bridges, it will still use the modified speed settings for the bridging sections. I'm not at my printer right now so I can't verify.
But I do have access to slic3r right now. I made a simple STL to test. https://www.tinkercad.com/things/gXWCAMR5SEE
It looks like for some reason even with support for bridging turned off it still adds a support for the outermost wall. I've never noticed that before. With Don't support bridges checked, and only on build plate unchecked, it will add supports on both outer walls, but not under the bridge. With only on build plate checked, it will add support for just the outer wall over the build plate.
It might be easiest to download Slic3r PE and see how it behaves rather than me describing it.
-
As far as I know, even with support turned on for bridges, it will still use the modified speed settings for the bridging sections. I'm not at my printer right now so I can't verify.
But I do have access to slic3r right now. I made a simple STL to test. https://www.tinkercad.com/things/gXWCAMR5SEE
It looks like for some reason even with support for bridging turned off it still adds a support for the outermost wall. I've never noticed that before. With Don't support bridges checked, and only on build plate unchecked, it will add supports on both outer walls, but not under the bridge. With only on build plate checked, it will add support for just the outer wall over the build plate.
It might be easiest to download Slic3r PE and see how it behaves rather than me describing it.
Also, I should say that Slic3r may not be doing it the best way either. The only thing it had going for it in my books was cooling control during bridges and speed control for more corner cases.
-
Cura is in my opinion slightly better than Simplify3d. The biggest problems are the lack of custom support placement and the lack of simple things like temp and fan settings per layer numbers. There is a ton of adjustments that could be replaced by simpler ones, especially what comes to cooling. At my customer I print mainly with UMs and there is no way to poke around with thw exported gcode afterwards to set these things like "turn the fan on 70% from layer a to b".
-
+1 for custom support placement / removal in cura. Surely has to be the no. 1 feature request.
-
I try to use cura last week. A nigthmare to setting the machine and print settings for finally not have z offset option.
-
Maybe this is a bit unfair as I just tested cura right now for the first time (because of this thread) coming from s3d.
Parts layout is not very nice. I could not find any way to drop the part to the bed and had to resort to rotating and translating manually. This is way to clumsy. A basic drop face to bed needs to be implemented. Auto arrange placed parts outside the build volume
In the gcode preview I accidentally moved a model which wiped out the gcode I was reviewing.
No manual supports (yes I knew that, this is why I really didn't bother with it until today), and I do not se that i have any additional control over supports to make up for it. I use manual supports in 90% of my models (Most of the rest need no supports). I had to go hunting in the menus to actually get any semblance of controls to be visible. The usual problem I use manual support to solve is that I have parts with gaps that are too cramped to be able to extract supports from but can be bridged or can tolerate a little drooping, while I have other areas that needs the support. Hence the lack of control of the support is pretty much a dealbreaker.
I could not find any way to save the print settings changes I did as a profile. I guess there is a way, but it is not obvious. Clicking the create button in manage materials (which is where I thought it would be) does not appear to do anything.
-
I would like to use Cura, but it crashes under linux.
That's been my experience, too. Like you, I'm using Ubuntu 16.04. (With the latest kernel, or at least close to it, as provided by Canonical.) Worse, Cura not only crashes, it hangs the X GUI, and sometimes even hangs the whole computer! Those are impressive feats for any Linux program, and not in a good way. Because the computer I generally use for slicing is my main workstation, with dozens of programs open at any time and, typically, an uptime measured in weeks if not months (it's currently 25 days), I'm very reluctant to experiment with new versions of Cura in the hopes that this problem has been fixed, or to explore Cura more fully to determine if it might have features I'd find useful. (The latest version I've tried is 3.0.4; I see that 3.2.0 is now available.)
Beyond that, Cura is slow as a sloth. It takes longer to start up (I just timed it – 55 seconds; Slic3r and ideaMaker both take 2 seconds) than any other slicer I've tried. I don't recall the details, but it's pretty sluggish to actually slice models once it's running, too. I have other, more minor, qualms with it, but they're nothing compared to crashing my computer, which is inexcusable.
I use either Slic3r or ideaMaker for most of my slicing. Between the two, they get the job done. Slic3r's strengths include a UI that, although a little hard to understand at first, is very intuitive once you get going; and good options for infill and top/bottom layer patterns. Its weaknesses include sluggish performance and a tendency to crash (but without taking anything else with it). IdeaMaker is very fast and reliable, in my experience. It also provides manual support structures, which is a must-have feature for some prints. On the down side, ideaMaker doesn't explicitly support delta configurations (there are workarounds, but the slicer thinks the delta's bed is square), and I had to tweak my startup g-code a bit more than usual to get it to work with my Duet-based delta printer. Until recently, infill options were limited, but the latest version (3.1.0) adds hexagonal and triangular infill.
Slic3r is fully open source and is available in Ubuntu's repositories, which is a plus for an Ubuntu user. IdeaMaker is not open source, but it is available as a native Linux application in a Debian package, so it installs pretty easily. Cura is the worst of these from a Linux package management point of view (although it is open source, and so could easily qualify for packaging); AFAIK, it comes only as a platform-independent .AppImage file. This distribution format has its advantages for a software developer, but when an OS provides high-level package management tools (as almost all Linux distributions do), not using them is a drawback for the user.
-
Cura built from source runs very reliably under Linux so the problem must be some incompatibility or defect in their packaged releases or your system. It would help everyone if you could post an issue with as much debug info (cura.log, stderr, stdout, etc.) as possible at https://github.com/Ultimaker/Cura/issues.
-
I didn't have any crash with Cura (using .app), neither with Slic3r. And I'm running a debian sid (unstable)! If both crash on Ubuntu, this is a Ubuntu issue.
-
I could not find any way to drop the part to the bed and had to resort to rotating and translating manually. This is way to clumsy. A basic drop face to bed needs to be implemented.
It's there as standard and (AFIK) enabled by default (you found the app preferences menu yesno?)
Auto arrange placed parts outside the build volume
I'd forgotten about that gem; yes, autoarrange appears to totally ignore the build area. And will happily move parts from a printable position to one outside the bed. It's very randomly too; there is no coherent logic I can ever see in the decisions auto-arrange makes.
-
I would like to use Cura, but it crashes under linux.
That's been my experience, too. Like you, I'm using Ubuntu 16.04.
Upgrade; you are 18 months out of date in a fast-moving world. Appimage/QT has matured a lot over that time.
@srs5694:Cura is the worst of these from a Linux package management point of view (although it is open source, and so could easily qualify for packaging); AFAIK, it comes only as a platform-independent .AppImage file.
Appimage IS packaging. Distribution independent code containerization.
@srs5694:This distribution format has its advantages for a software developer, but when an OS provides high-level package management tools (as almost all Linux distributions do), not using them is a drawback for the user.
I'd argue it is so simple to use (download, make executable, run) that making the user install a package (open software centre, find, click, supply password, install, close software centre, find app and run; or sudo dnf/yum/apt install <must know="" the="" exact="" package="" name="" here="">) is not really that much simpler; just more familiar.
[VERY TL;DR]
Add the fact that each of these distribution-specific packages needs to be properly maintained; tracking every OS /and/ packages update. It's a lot of effort for the Buildmasters and devops guys to keep up with; appimages give a single solution across a huge number of target platforms and distros; they are the future.- I say this as someone who currently makes his money doing cloud application packaging/building into RPM's for 'traditional' software deployment; and who looks as appimages as the best replacement tech for application distribution (but emphatically not OS or System components) to come along so far.
They also have a HUGE disadvantage; and I think this will kill them over time/ or force some sort of update/patch system to be added.. Since all the libraries they use are pre-packaged there is no possibility of retroactively upgrading individual items.
For instance; if you bundle LibreSSLv1.2.3, you are stuck with it.. if it is found vulnerable at some future time you will need to make a whole new appimage to bundle the newer libs. Fine if the project is very agile and quickly updates; but a nightmare for other scenarios, or those who are slow to upgrade.- But, this is not a unique problem. I also see many traditionally packaged apps that statically link crucial libraries to make life easier for developers (part of my job involves re-engineering CentOS rpm's for our internal purposes; I read a lot of %build sections in rpm specfiles; this happens far more often than I would like. I think I can argue that appimages are in one sense better than other packages since there is no pretense that they use libraries outside their domain.</must>
