Closed Myles512 closed 7 months ago
Update: it seems to only happen when the area being supported is further back on the bed than the front of the object. I've included a project file with geometry demonstrating a plate that works fine, and a plate that demonstrates the issue.
Additionally, normal brims seem to work fine, but when I run a "Max Flow Rate" calibration, it runs over the purge line a little bit.
brim and support are not objects, it will be tricky and confusing to label them. You probably can consider using adaptive_bed_mesh_min/max to decide the purge line position: https://github.com/SoftFever/OrcaSlicer/wiki/adaptive-bed-mesh
You probably can consider using adaptive_bed_mesh_min/max to decide the purge line position: https://github.com/SoftFever/OrcaSlicer/wiki/adaptive-bed-mesh
I use auto brim, but sometime the brim width value is very large, almost 20mm. So should I set the mesh margin to 20mm to avoid collision? Or can i reference brim width value in adaptive bed mesh options to dodge the purge line?
Is there an existing issue for this problem?
OrcaSlicer Version
2.0.0-beta
Operating System (OS)
Windows
OS Version
Windows 10
Additional system information
No response
Printer
Voron 2.4 r2 with Klipper and KAMP
How to reproduce
On a printer using Klipper with Klipper Adaptive Meshing Purging, slice something that needs supports in front of it or a large brim all the way around. If your start gcode has a KAMP line purge, the supports will be written overtop of the line purge. I believe the same happens with brims.
Actual results
supports/brims are not included in the labelling, so the printer doesn't know there is something to be printed where the supports are located on the bed.
Expected results
Support and brim toolpaths should be included in object labeling.
Project file & Debug log uploads
Checklist of files to include
Anything else?
May be related to https://github.com/SoftFever/OrcaSlicer/issues/3557