Conversation
|
@KuzuriAo |
|
@zackaree-shen I know you all are really busy, I totally understand. Launching something like the U1 and Snorca is no small undertaking. I figure if it's something that's causing me problems, it's probably doing the same for others (based on the Snorca/Orca issues, it seems to be the case). So, when I have time I try and solve the problem for myself and when successful, I open a PR. |
…-793 fix(print): sequential clearance Kahn sort + above-rod Y extent (Snapmaker#630, Snapmaker#793)
Replace the object-list-order sort in Print::sequential_print_clearance_valid with a search for a valid print order: a topological sort over the "must print before" constraints implied by extruder_clearance_height_to_rod and extruder_clearance_height_to_lid. If a valid order exists it is used; if none exists (a genuine, unavoidable collision) the original object-list order is kept so the existing error is still reported. Same change as Snapmaker#630 (and OrcaSlicer#14987). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…the rod The X rod sits extruder_clearance_height_to_rod above the nozzle and spans the whole X axis, so the only part of an already-printed instance it can hit while a later instance prints is the part that reaches above that height. The check used each instance's whole footprint for the Y-overlap test, which turns a 145 mm deep assembly with a 16 mm tip above the rod into a 145 mm wide obstacle. Compute, per instance, the Y extent of its geometry above the rod height (any triangle with a vertex above the rod contributes all three vertices; modifiers, blockers and negative volumes are skipped) and use that extent, instead of the full footprint, both when building the print-order constraints and in the final vertical clearance check. "Tall" becomes "reaches above the rod", which is the same thing for objects on the bed and correct for objects sunk into it. The later instance keeps its full footprint plus the radius/2 reach, the lid rule and the horizontal clearance check are unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ebdb36d to
c3edc7d
Compare
|
@zackaree-shen Quick heads up: I force pushed this branch, and it should be a lot easier to look at now. The problem was on my end. I had branched off the I rebased onto current Nothing about the code changed in the rebase, only the base it sits on. The two commits are the same as before:
Since #630 is still open, that first commit is included here as well. If #630 lands first, this will rebase down to just the second commit. One more thing that might help: I wrote unit tests for Happy to add them to this PR, to #630, or to open them separately, whichever is easiest for you. Just let me know. |
|
@KuzuriAo Maybe you can rebase to this branch and then create a PR to here. |
|
@zackaree-shen Sounds good, that works for me. I rebased both commits onto One request before you pull it in. That branch is currently 25 commits behind
Once the branch is current I will send the tests straight after. In all it's four scenarios, built from the existing 20mm test cube so there are no new test assets, covering both cases these commits fix and the two that must still fail. Separately, while I have you: #839 has not had any eyes on it yet, and it is unrelated to this work. It fixes two bugs that together mean Snapmaker Orca's CLI cannot slice anything at all. It rejects effectively every project file on a version check that compares against a legacy BambuStudio constant, and with that bypassed it segfaults in GUI code that assumes an application object exists. The practical effect is that anyone automating around the U1, a print farm or a model site generating print statistics, has to use upstream OrcaSlicer rather than yours. It is small and self-contained, and I do not think it belongs on the by-object branch. Would you be able to take it straight to Last thing, on process. My default going forward will be to use a topic branch like this one when a change is part of a bigger arc, and send small standalone fixes straight at |
|
|
@KuzuriAo It's updated now |
|
Thanks, that is everything I needed. I rebased onto the updated base and added the tests to zackaree-shen#10, so it is now three commits: the two Print.cpp fixes and the test coverage. All four scenarios pass on the current base, 10 assertions in 4 test cases. The tests are a separate commit if you would rather not carry them over. |
2 participants
@zackaree-shen
Stacked on #630. The first commit in this PR is #630 unchanged; the second is this change. It builds on the constraint graph #630 introduces, so it can't land before it.
The practical result: with #630 and this change together, the plates that started this whole thread, the ones that sliced and printed fine on my X1C but were "too tall" on the U1 no matter how I arranged them, now slice and print on the U1. Objects or assemblies usually need to move a little, but only a little: no splitting assemblies and repacking them by hand, no rotating, no bumping height-to-rod. #630 finds the print order; this change stops counting material the rod can't reach. Those two are the slicer-check half. The physical half is #532, the toolchange G-code that lifts the head over already-printed objects, which is merged but not yet in a release; my prints were done with it in place. Each piece alone helps; all three together turn print-by-object on the U1 from something I fought with on every multi-part model into something that just works.
What this changes
Print::sequential_print_clearance_valid()decides which already-printed objects the X rod could hit while a later object prints by testing whether the objects overlap in Y. Today it uses each object's whole footprint for that test. But the rod sitsextruder_clearance_height_to_rodabove the nozzle, so the only material it can physically touch is the part of an object that reaches above that height. This PR computes that above-the-rod Y extent per instance and uses it, instead of the full footprint, for the object that could be hit. The later object (the one being printed, i.e. everywhere the nozzle can be) keeps its full footprint plus theextruder_clearance_radius / 2reach, exactly as before.In the same function:
above_rod_min_y / above_rod_max_yis computed from the transformed mesh (any triangle with a vertex above the rod contributes all three vertices, so it's conservative; modifiers, support blockers and negative volumes are skipped because they aren't printed);Nothing else moves: the ±radius/2 reach of the rod is unchanged (still symmetric, still conservative), the height-to-lid rule is unchanged, the toolhead-radius "too close" check is unchanged.
Why
I measured my U1's actual nozzle-to-rod clearance with a printed gauge (details in #630): the rod's underside is 27.2 to 27.4 mm above the nozzle tip, so the profile's 27.5 is right. That also means the rod only ever meets the top few millimeters of a 30 mm object, and with most real models that is a small fraction of the footprint. Pulled from my own files:
With the current rule those last two need 321 mm of front-to-back space in separate bands on a 262 mm bed: impossible, and the only ways out were rotating them or splitting the assembly and repacking its parts by hand. With this rule the same plate slices after moving the 145 mm assembly 66 mm forward, no rotation, no splitting. The Squirtle plate's three tall objects go from needing 238 mm of Y to 138 mm.
What it does not do
Cost
This runs in
Print::validate(), the check that fires when an object is moved or a setting changes (it's what draws the red "too tall" plane) and once more when you press Slice. It never runs inside the slicing pipeline itself. What it adds is one extra pass over each printed instance's mesh (a transform per vertex, a comparison per triangle). The check already walks the same meshes to build the convex hulls, so this at most doubles a cost that isn't noticeable today. I haven't profiled it, but I ran every plate in the testing section below on both this build and the official 2.3.6, moving objects around and slicing, and if there is a difference it isn't noticeable by eye.Testing
Built on Snapmaker Orca
v2.3.6+ #630, macOS Apple Silicon.aboverod_test.3mf.zip
aboverod_test.3mf(attached above): two 40 x 30 x 2 mm slabs 25 mm apart in Y, each with one 32 mm fin on the edge facing away from the other. Stock 2.3.6 refuses it ("A back-fin plate is too tall": two tall objects whose footprints overlap in Y). This build slices it with the objects untouched, and it printed on the U1 with no contact. Minimal reproduction, ~8 g of filament.Here is the aboverod_test.3mf loaded in Snapmaker Orca v2.3.6 (official):
Here is the aboverod_test.3mf loaded in Snapmaker Orca v2.3.6 (compiled with #630 and this height-to-rod patch):
Here is the video of aboverod_test.3mf successfully printing with the above patches:
https://photos.app.goo.gl/VGWgU8iyUwxpffFD8
rod_gauge.3mf,rod_gauge_low.3mf) slice clean, as before.None of this is U1-specific; the check reads the same three profile values for every printer.
Related