making the most of /filaments/<filament>/..
-
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 TCDuet 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.
--
Mak3rToolchanger
MK3S (MMU2S)
Monoprice MPIII
Lulzbot Mini
Frankenstein (originally a Printrbot simple) -
@mak3r I use per-filament settings to
- set the extrusion multiplier
- apply different firmware retraction settings
- set different pressure advance parameters
From your filaments structure I see you have different profiles for each tool. It's probably simpler to use a single filament config per filament and evaluate
state.currentToolfor each one. Note that a tool must be selected anyway before you can useM703(which I generally put in my tpost*.g macros). Also, you can set a global variable to match your selected filament type. I have different brands of filament requiring slightly different settings, but the print settings in PrusaSlicer generally remain the same.You can find some examples in the README of my own E3D Revo macro plugin.
-
@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.
-
@mak3r said in making the most of /filaments/<filament>/..:
I'm still not quite sure how to resolve the fans issue.
Talking about fan speeds: The part cooling fan is controlled by the slicer for obvious reasons. Only the slicer ‘knows’ where to enforce cooling, be it for bridging or overhangs.
However, you can provide a custom per filament config.g. Within this, you might be able to re-define the minimum and maximum fan speed with
M106. With the L and X parameters, you set the operating range for the percentage (from 0-100%) the slicer demands. -
@mak3r as @infiniteloop already said, using the min/max values for the fans gets you part of the way there.
Ideally slicers would allow for variables in their generated gcode:
M106 S{global.currentToolFanSpeed}
Or even
global.currentToolFanBridgeSpeed
global.currentToolFanPerimiterSpeedEtc
Would allow you to define these on a per filament, per tool etc basis is your filament config or tool change files (or by using a series of multipliers, then based on both the tool and the filament).
Until slicers have this, then I tend to manage all the filament related settings in the slicer. If you have to choose between one or the other then the slicer has more information (currently) about the particular bit of the print. Better labelled gcode would also help.
-
@T3P3Tony said in making the most of /filaments/<filament>/..:
M106 S{global.currentToolFanSpeed}
Or even
global.currentToolFanBridgeSpeed
global.currentToolFanPerimiterSpeed
EtcYes, 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.
-
@mak3r that would be nice. If possible would you do the work in the way that a PR can be submitted back to PrusaSlicer to make this a core option at sometime in the future.
-
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
