"Spoofing" multible tools in RRF.
-
So short story long, multi part object (different colors) on a single extruder machine AKA manual filament/color changes
😅
.I've been doing this for a while allready now by just having an "physical printer" in PrusaSlicer that's a clone of my standard printer, except having 5 tools.
- I add and delgate tools / filaments to the specific parts like the machine was a true multi tool machine.
- In the Output options I use regex to remove every
T
command other thanT0
. - Rename every
G10 P1-3
toG10 P0
for temperature handeling. - And add
M600
as "Custom G-code > Tool change G-code".
This works "ok" except I would much rather handle this in RRF (if possible in an elegant way). So I can remove those G-code subsitutions from the slicer profile.
And also gain back all the "Preview features" in PrusaSlicer, since the whole preview turns into the same color/tool with everything else thanT0
remvoed. Making it harder to spot potential issues with the sliced job.
I've thought about having RRF handle this since the day i first set it up the way it currently is, but have put it off in favour of other more "pressing" projects.
But after seeing @marvineer's thread it got me thinking down the road of trying to find a solution for this by deploying parts of the code talked about there.
But rather than actually doing a tool change, it will trigger a filament change and deploy the settings called for in the (lets say a
T0
toT2
) tool change.
I haven't started writing any code yet, and thought i should "wave a flag" to see if anyone have a more elegant solution for this problem, or see any big pitfalls in my proposed way of approaching this in RRF.
-
@Exerqtor yes that sounds possible. You could use M291 to pop up a message such as "Please load white filament, press OK when done" in the tpost#.g file.
-
@dc42
Yeah i have thought about maybe finding a way to output the color from the slicer to be prompted as part of the specific color change, i'm pretty sure it's a placeholder for it in prusaslicer.Anyways i would have to get the other parts working first lol.
I don't think i got it across in the initial post that i DON'T want it to be more than 1 tool in the printer/dwc just to underscore that.
The machine only have
T0
and that's whats always "deployed" on startup etc, Only when a job calls for a toolchange RRF sees that and pretty much handles it in the same manner as I've done with the G-code subsitution.This all depends on the "tool macro fallbacks" being implementet first ofcourse.
Or won't this work unless the tool that gets called out have been created? (don't want to clutter DWC & PD with alot of "virtual" tools).