Well, that took longer than I would have liked but today I created the Feature Request for this https://github.com/prusa3d/PrusaSlicer/issues/9852. I will look for input and feedback from the community before implementing and generating a PR. Please add your ideas and comments accordingly.
Cheers,
mak3r
Well, that took longer than I would have liked but today I created the Feature Request for this https://github.com/prusa3d/PrusaSlicer/issues/9852. I will look for input and feedback from the community before implementing and generating a PR. Please add your ideas and comments accordingly.
Cheers,
mak3r
@T3P3Tony said in making the most of /filaments/<filament>/..:
M106 S{global.currentToolFanSpeed}
Or even
global.currentToolFanBridgeSpeed
global.currentToolFanPerimiterSpeed
Etc
Yes, this is what I'm thinking. If I modify the slicer to output the variables instead of the specific values, this should work. PrusaSlicer already has the code to vary fan speeds based on small layer times, bridging, etc.
I am going to look into this. It should not be too difficult to implement and also to add a checkbox in the UI indicating to output variable names instead of values.
@chrishamm thank you for the insights. I have briefly looked at your revo macro plugin and I will take a closer look when I have more time. I am working toward a more stateless model like yours and am hopeful that the arrays coming in RRF v3.5 will provide some useful data structures for encoding filament specific configurations.
I'm still not quite sure how to resolve the fans issue. I would rather not do gcode post processing but ideally I do need some way to adjust the M106 S<speed> values after gcode is output. I have considered patching PrusaSlicer with code that would at least give me more external control after the gcode file is created and possibly could output a macro command instead. I'd be curious about your thoughts on this approach? My hesitancy is of course maintenance over time of my patches. Since Prusa a planning for a TC model, it may prove valuable to them in time anyway.
I have read the docs on the use of the filament configurations and I have searched for "filament config.g" and come up with over 1600 entries on the forum which is proving too much to read through. Please do point me at existing discussions or move this to the appropriate sub as necessary.
tl;dr; Is there a future for filament configs that truly isolates filament configuration from the motion system? Or should I go back to hardcoding filament detail in my slicer?
I have been using the filament configurations capability for some time. I use PrusaSlicer and I am able to get generally decent gcode for mult-material printing. I got to a point where I thought that if I could isolate the materials for ideal printing on a given tool, I would have a nice system for swapping materials and re-using sliced models to great effect. For example printing in cheaper materials like PLA/PETG as I test features and moving to more expensive materials like Nylon and Carbon filled material simply by swapping material on the tool.
I print in a variety of materials including PLA, PETG, Nylon and TPU. I tend to label my printable files using the tool numbers as part of the file name so that, in theory, I could re-run the print just by knowing which tools are going to be used. So for example PartName_T023_FWR.gcode indicates to me that the part will print using tools 0, 2 and 3. FWR (firmware) is a replacement label for the filament type that PrusaSlicer enables. It's not a perfect naming convention, for example, I may also need to know if tools should be feeding support material or which color should be perimeters or infill.
What I'm finding is that this model actually falls short in other ways because, for example, there is no facility to adjust fan speeds dynamically on a per filament basis. I discovered this when I tried to use Nylon where I had originally configured for PETG. In PrusaSlicer, I had selected PETG for slicing which setup various PWM fan speeds however this causes all sorts of issues when printing nylon. So basically, I need to go back to the slicer and setup for Nylon. Which should be fairly easy but it changes my process quite a bit.
I am beginning to think that I'm fighting the system instead of working within it's best parameters. I have read that the filament configurations are really only designed for assisting with loading and unloading. Is this true? Are there plans to truly isolate filament configuration from motion system?
If you are not using filament configs and instead slicing for each material change, how do you organize your .amf/3mf files accordingly.
And if there is an ongoing discussion or effort to make changes in the direction I've described, please let me know. I'd love to be a part of it.
My Duet3D setup
Duet v3.4.5
Toolchanger with 4 tools
T0: Zesty Nimble v3 with E3D v6 hotend
T1: Zesty Nimble v3 with E3D v6 hotend
T2: Zesty Nimble v3 with E3D volcano hotend
T3: E3D Hemera direct drive for TC
Duet 2 board with Ethernet
If you would like to see my configuration files, you can view them on github github.com/mak3r/toolchanger. The filament configs are in flux, as tools have changed I have not updated all configs - that is the procedure I am currently undertaking.
--
Mak3r
Toolchanger
MK3S (MMU2S)
Monoprice MPIII
Lulzbot Mini
Frankenstein (originally a Printrbot simple)
