burtoogle
-
Posts
1,529 -
Joined
-
Last visited
-
Days Won
19
Content Type
Forums
Events
3D Prints
Posts posted by burtoogle
-
-
When there are a lot of unnecessary moves, retractions and extra time spent on a layer there is more stress on the printer and more inconsistency in filament deposition and failed prints.
I agree even though I normally only print small parts. For someone printing parts that can take 10s of hours, the time savings can be substantial. Also, cutting down on travel really does help with ooze!
With the announcement of Cura v3, It would be great to see this issue finally put to rest and help to make Cura the market leader that I know it can be.Hmm, well, we shall see. I'm afraid I'm too cynical to really believe that but I'll keep on fixing the stuff that could (IMHO) be better done.
-
Nope.
Expect some embarrassing breakage then. It's code, it will be buggy, be realistic.
-
I think that if there was some way of tracking down who had corrected the code for the top and bottom surfaces, we might politely ask them to do the same for the infill patterns ;c)
Well, I had a hand in that and I have looked at if doing the same helps the infill and I am not convinced it is right there. But I have been busy working on a PR that stops the disconnected pairs of lines being output like you see in your example.
https://github.com/Ultimaker/CuraEngine/pull/613
The code it modifies is used a lot (infill, skin, support, raft, etc.) so the PR will need a lot of testing before it could be accepted into Cura but we may as well set the ball rolling.
-
1
-
-
Hi shadowfiend, yes I completely agree with you. That rectangle on layer 5 gets infilled in a totally bizarre order. I'm not familiar with the detail of the infill code so I can't immediately think of where to look to improve this. I will investigate when time allows.
-
The last version of Cura should print the skin of a simple part (like a rectangle or circle) from corner to corner thus avoiding extra seams. It should no longer start the skin area "in the middle". Obviously, if the part contains holes or has a non-trivial outline then skin areas cannot be printed as a single piece and seams will be required. If you have a specific example of Cura 2.7 not getting that right, please post a link to the gcode.
-
How about making all the settings visible and then looking to see if any have a red background?
-
-
Thanks for the gcode - I've found the bug (it's not one of mine!), it's triggered by the combination of retract before outer wall and outer wall printed before inner walls both being enabled and the end of one layer being some distance away from the start of the new layer. I will submit a PR that should fix the problem to the Cura devs.
-
Could please post a link to the gcode so I can have nose around, thanks.
-
All that being said; I think it's smart to consider having LTS (Long time support) versions.
I think that would be very good. With, say, 2 years between LTS releases and only major bug fixes triggering sub-releases, users would benefit from the stability while those who like to live more dangerously could use the non-LTS releases. Even they don't need to be more frequent than 2 per year (IMHO).
-
2
-
-
This function looks awesome!
Are there any nightly builds so people without coding knowledge (like me) can test it?
Sorry, you will have to wait until a beta of the next release is produced. Hopefully, this new feature will be merged by then.
-
Next Beta ?
We'll see, it all depends on whether the PRs are acceptable to the Cura guardians or not. Even if they are basically in favour, changes always seem to be required. Chill.
-
2
-
-
I think what google does having devel, beta and stable versions of chrome is good because then those people who want to live on the bleeding edge can and by the time the stable release is updated, there's a good chance that most of the worst bugs have been spotted.
As a contributer to Cura, I think one of the most difficult aspects is getting any new code or even bug fixes sufficiently well tested before it gets exposed to the masses. A real difficulty is that slicers are expected to cope with a very wide range of input due to the many different models/setting/etc. that users throw at it. Personally speaking I simply cannot test the stuff I produce against a wide enough range of inputs to be confident that it will work correctly for everyone. That is why it would be very good if development builds where made available on a regular basis because then the developers would get some feedback before it gets to the major release stage which is what happens now. So, for example, 2.7 has some fresh bugs (not mine, honest) that weren't spotted before the release. They probably would have been spotted if they had been incubated for a month or two in devel and beta releases (that assumes that brave people would actually try those early releases).
The bottom line is really that people have to test the fuck out of any beta release to catch regressions and other problems. If the testing doesn't happen, the bugs will get through.
Well, that's my take on it.
-
2
-
-
Hi, I have found retraction when printing TPU/TPE not to be a problem. Very little stringing occurs.
-
Here's a few seconds of video that shows an example of the optimizer's ordering of the walls. The part has 3 holes and is being printed with 3 walls. The walls start to be printed 5 seconds in.
-
2
-
-
Instead of starting in one corner and filling in in one go to the opposite corner Cura leaves a triangle behind, fills in to the far end then comes back to fill in the triangle.
This behaviour has been fixed and I thought that 2.7 incorporated the changes, could you please post a link to the gcode?
-
Hopefully, you won't be waiting much longer to try it out, there should be a Beta of the next release available within a week or 2.
-
2
-
-
I mostly understand the behaviour and the constraints. I was just hoping there was a simple setting i could flip to make it better. But i guess not.
But on the optimize code. Wouldnt it be pretty easy to just add a quick code that treats things seperated by a gap as its own item.
Like when you add a bunch of models on a plate it will print one at a time, so add a code tweak so where anything printed on a layer that is seperated by a gap is treated as its own item (even if it is physically the same model). It may not be perfect, but i think that alone would get rid of so many back and fourth movements.
Well, the're all simple settings to be flipped but, unfortunately, the setting you crave hasn't yet been created. However, what you mention later about treating items that have a gap between them as separate is indeed how Cura currently works. When I referred to a "part" above, what I mean is the Cura notion of a part which is basically an island of plastic separated from other islands by air. When you slice a model you get 1 or more parts depending on the shape of the model. If the model has bumps then at some point those bumps will get separated by air and they become individual "parts". Each part is printed completely separately to the others so all the walls and infill for that part will get printed before the printer moves on to the next part.
-
2
-
-
It could be that the object has sunk into the build plate and so the bottom is not printed. Check that the z offset for the part is 0 and not negative.
-
For each part, Cura prints the walls and then the infill (there is an option to swap the order so it prints the infill first). The walls are printed grouped by level which means that within a part it can do quite a lot of travelling if there are many holes each with several walls. Doing it that way can involve lots of travelling but it does provide some guarantee of quality of finish as that is influenced by the order in which walls are printed. One of the challenges of creating the optimizer has been to reduce the travel moves while still observing the constraints regarding the order in which the walls should be printed in a particular region. The new optimization code groups the walls together so that it will try to print all of the walls around each hole together as a group so as to minimize travel. The optimizer only alters the printing order of the walls, it doesn't change the order in which the infill is processed. That remains a future task.
-
1
-
-
Hi, the next release of Cura is likely to include an option to optimize the order in which wall lines are printed. If you are willing to share your model, I could slice it with the optimization enabled and let you know if that will improve things for you.
-
3
-
-
You mean like this:
Set Retraction Minimum Travel to a small amount (e.g. 1mm).
-
Good, but remember, the model is badly broken. You need to fix it to be able to reliably print from it.
-
Thanks for your suggestion. That works well for top layers.
I would like to see bottom layers only at Z=0 level (printed on the printable). At higher Z levels I do not want to see bottom layers printed on horizontal areas. However Cura prints them as bottom layers too. And with zero infill below this will result in problems.
Sorry, I don't understand what you mean, could you please provide an image of the layer view that shows these bottom layers you are referring to?
Obviously, when you spiralize, the model cannot have any areas whose slope is less than approx 45 deg because otherwise the layer above would not have a layer below to rest on and you would get holes appearing. But apart from the layers that start at the build plate you should not get any other skin layers.
Unwanted prime blob custom FDM dual extruder
in UltiMaker Cura
Posted
Hi. I don't use multiple extruders so I have no experience in this area but if you want to be able to disable the prime blob I think your machine definition needs to have this in the overrides section to make that setting visible:
"prime_blob_enable": { "enabled": true },See ultimaker3.def.json for an example...