| Age | Commit message (Collapse) | Author |
|---|
|
[CURA-9085] Unretracted moves on top layer of top skin.
|
|
Co-authored-by: Casper Lamboo <c.lamboo@ultimaker.com>
|
|
|
|
Ultimaker/CURA-8708_remove_travel_acceleration_jerk
Implement option to add or remove acceleration or jerk command specific to travels
|
|
when using CombingMode::NO_OUTER_SURFACES.
The top_most_surface_fill polygon being used for the combing boundary was defined incorrectly.
skin_part.top_most_surface_fill = skin_part.skin_fill.difference(no_air_above);
The skin_part.skin_fill was empty on the surface skin layers. Causing this statement to return an empty polygon for combing.
This is because the skin_fill is the fill for the bottom skin rather than the top.
This fix is to use roofing_fill, which has the correct polygon for the top surface skin fill.
CURA-9083
|
|
This was some repeating code that was both duplicate and inefficient.
Contributes to issue CURA-8708.
|
|
The same way as acceleration_travel_enabled.
Contributes to issue CURA-8708.
|
|
Unless there is no next layer, of course. Or if the next layer has no extrusion moves at all.
That last case is technically a bug, but I call it a feature. If there are a bunch of empty layers halfway through the print, this means that the last travel move before those empty layers uses the acceleration and jerk of the extrusion move before it, instead of of the first extrusion move after all of those empty layers. But looking that far ahead of all of these layers is architecturally very hard.
Contributes to issue CURA-8078.
|
|
The case of having a travel move at the end of the layer isn't properly handled yet. We can't easily look into the layer afterwards to know the acceleration rate of the first extrusion move of that layer.
Contributes to issue CURA-8708.
|
|
[CURA-9293] Define 'too long' line segments as twice the length of smallest.
|
|
Should fix microsegemtns for occurrences of 'line segments slightly longer than the minimum' and 'small line segments but longer than 5 micron' occurring together often. Which in turn should fix those microsegments that still cause blobs at least on UM printers.
|
|
Don't use zig-zag endpieces when using gradual infill
|
|
The endpieces will connect the endpoint of the zigzag pattern up to the last real line along the edge, but this causes massive overlaps when the pattern is used at different densities next to each other for gradual infill.
|
|
|
|
It's the first release in 2022.
|
|
|
|
CURA-9163 - 🏃♀️ Travels through model with printing PVA
|
|
... and why we might decide to keep them instead of deleting them outright.
part of CURA-9163
|
|
We _do_ want to enable this however there is a bug in the current implementation. It is checking _all_ the extruders and if `travel_avoid_supports` is enabled on one of the extruders then this feature is enabled for all combing.
This introduces problems for PVA support. If `travel_avoid_supports` is disabled for the PLA extruder but disabled for the PVA extruder the `model_boundary` will contain the boundary for support. As there are many travel moves within/through this model boundary with support area's included there will be many retractions. This is the main cause for https://ultimaker.atlassian.net/browse/CURA-9163.
Note that `model_boundary` is only used in a very specific case where combing fails to travel via the outside of the travel-avoid distance (see https://github.com/Ultimaker/CuraEngine/pull/1626)
CURA-9163
|
|
CURA-9163
|
|
match line_width in ironing_config instead of here.
CURA-9158
|
|
CURA-9158
|
|
Not really part of the ticket, but this was clearly intented behaviour
CURA-9158
|
|
Retracted unnecessary travel moves
|
|
[CURA-9206] Fix error slicing with 5.0
|
|
CURA-9206
|
|
boundary"
This reverts commit ade72656ec16931fd750759ce39203b03d5ea19f.
|
|
[CURA-9158] All ironing lines should be ironing_line_spacing apart.
|
|
Since we are using infill code to calculate this, we were offseting the concertric polygons by infill_line_width - line_distance.
In the case of ironing we should have infill_line_width == line_distance == ironing_line_spacing
This way our paths are always ironing_line_spacing apart.
This bug was caused by the offset being too large because we were passing in the line_width (0.4) to infill_line_width while
our line_distance was our ironing_line_spacing (0.1) . This caused the insets to be offset by an extra 0.3 (line_width - ironing_line_spacing)
CURA-9158
|
|
5.0
|
|
Cura 9128 outer wall extruder crash
|
|
part of code review for CURA-9128
|
|
part of code review for CURA-9128
|
|
Fixes CURA-9128 Outer wall extruder crash
|
|
Ultimaker/CURA-9159_alternate_fix_thread_tree_crash
[CURA-9159] Alternate fix crash/deadlocks/threading Tree-support
|
|
Print wall_toolpaths_here, which has the thin toolpaths of support
|
|
There occurred a crash when using a different outer wall extruder.
This happend because the switching in iteration direction was done
"old skool"-style. Values like start en end inset where uninitialized
constructed. And the if-construct to set the values was overly complex
with cases which could never occur. Why are people so afraid of
`auto` and `for ()` and other standard algorithms?
Since we are still on C++17 I had to use a template helper function
to switch between forward begin()...end() and rbegin()...rend()
iterators. I can't wait till we support C++20 with ranges and views.
The crash is fixed atm but I'm still figuring out the offsets in the
iterators for when we use multiple extruders.
CURA-9128 [Exploratory]Outer wall extruder crash
|
|
Other fix could still crash and deadlock. Could have probably made it work, but the critical section using 'volumes_' within the scope of the parallel for can be very small, since the access to the tree envelope cash ('volumes_') occurs twice in quick succession. Much easier to make it its own little critical section and not worry about making that entire class thread-safe. That takes care of the crash. During investigation it was found that, since it had multiple critical sections in the loop, handled by the same mutex, _and_ a seprate atomic that was then accessed _inside_ one of the critical sections (what was I thinking...) it could deadlock or at the very least report the wrong progress (causing that part of the front-end to hang). Fixed that as well.
part of CURA-9159
|
|
This reverts commit 550d807b383104c29776f609fbe55df5ac915142.
|
|
It was re-printing the same thing that was already printed earlier: wall_toolpaths. In this code block it was checking if wall_toolpaths_here was empty and then proceeded to print wall_toolpaths (not _here) if it wasn't. That was clearly a mistake.
Also fixed some spelling mistakes in the other file since I noticed them. Just in documentation.
Contributes to issue CURA-9077.
|
|
Ultimaker/CURA-9096_Tree_Support_branches_not_being_generated_
[Cura] 9096 - Tree Support branches not being generated
|
|
|
|
Co-authored-by: Jelle Spijker <j.spijker@ultimaker.com>
|
|
Co-authored-by: Jelle Spijker <j.spijker@ultimaker.com>
|
|
CURA-9096
|
|
|
|
In multi-layer infill, it added these end pieces properly, but not in single-layer infill. They should be added, because not adding them leaves loose endpoints for the infill which are a weak point. This is especially visible in 100% density since it leaves gaps then if the infill is slightly too thin to add another line.
I believe this was correct before, so I think a recent refactor accidentally set this to False.
Contributes to issue CURA-9077.
|
|
In multi-layer infill, it added these end pieces properly, but not in single-layer infill. They should be added, because not adding them leaves loose endpoints for the infill which are a weak point. This is especially visible in 100% density since it leaves gaps then if the infill is slightly too thin to add another line.
I believe this was correct before, so I think a recent refactor accidentally set this to False.
Contributes to issue CURA-9077.
|
|
[CURA-9159] Fix occasional crash due to unsafe threading in tree support.
|
|
CURA-9096_Tree_Support_branches_not_being_generated_
|
