| Age | Commit message (Collapse) | Author |
|---|
|
[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
|
|
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.
|
|
[CURA-9159] Fix occasional crash due to unsafe threading in tree support.
|
|
CURA-9096_Tree_Support_branches_not_being_generated_
|
|
CURA-9159
|
|
CURA-9096
|
|
Contributes to CURA-8640
|
|
Contributes to CURA-8640
|
|
Contributes to CURA-8640
|
|
A container is no longer needed. We can build
directly on the VM since it is the same ubuntu
version as our container.
Build script will first install conan
and then pull the repositories.
Including arcus for which I added a Conan
package to the ultimaker remote artifactory.
These dependencies will in all likelyhood be
recompiled at each run. Normally you would
upload the build conan artifacts but the
current artifactory server is still a test
server.
I also still need to fix the Conan target
naming for the GTest.
Contributes to CURA-8640
|
|
Contributes to CURA-8640
|
|
Cura 8640 PyQt6 upgrade
|
|
CURA-9088
|
|
|
|
Add missing parameter to infill constructor
|
|
|
|
CURA-8640_PyQt6_upgrade
|
|
Ultimaker/CURA-8694_Retracted_unnecessary_travel_moves_part_II_return_of_the_comb
[CURA-8694] retracted unnecessary travel moves part ii return of the comb
|
