Request for Filament Tweaks

garethky

I have 2 asks:

Can we get a nextFilament variable in the object model? This would mirror how tool changes work with nextTool and currentTool. Two reasons for this:
1. When scripting in load.g it would help if we didn't have to repeat the filament name in the script. Writing a single unified load macro is within reach if the Object Model has this for loading.
2. When changing filament it would be great if the unload.g script could tell if another filament was about to be loaded, then it could decide to shut the heater off or leave it on for the next load operation.
Can we allow filament changes to the same filament that is already loaded and allow multiple tools to have the same filament loaded? I use a lot of PETG but its in different colors, or maybe the roll just ran out and I need to change it. Unloading and loading the same filament type is more common than switching types for me. The current functionality is clever, but maybe too clever.

garethky

For #2: this is the line that does the exclusions in the Duet Web Control: https://github.com/Duet3D/DuetWebControl/blob/master/src/components/dialogs/FilamentDialog.vue#L67
A helpful comment notes:
// Exclude filaments that are already loaded (RRF does not allow loading the same filament into multiple tools)

I don't understand why that is but the next step is to find where in the firmware the limitation is enforced.

garethky

This seems to be the only place that it is actually used: https://github.com/Duet3D/RepRapFirmware/blob/7c571137d68a1a2de0d79e2dc1741793a96c7279/src/GCodes/GCodes.cpp#L4628

So its use is only to enforce this limitation not to stop something else in the firmware from breaking. Please feel free to tell me what I'm missing. I don't understand the reason for this limitation.

I don't think you expect users to create a Filament for every individual roll of filament they physically have. Nor does it make sense to have N copies of every filament so a machine with N tools can load N of the same filament. Nor does it makes sense on a single tool machine to stop the user from unloading one color of PLA and then loading another color of PLA (Change Filament doesn't work because PLA Filament is in use, technically it would work because its unloaded as part of the change but the GUI blocks it from showing up in the selection dialog).

Most users are creating 1 filament per type of filament they have: PLA, PETG, ASA, Nylon, PC etc.

If I submit a PR removing this check and the IsInUse function from the filament model would I get that merged? @chrishamm or @dc42

garethky

No one replied and I'm not keen on wasting my time building and testing a change that the maintainers will not accept because it conflicts with your future plans for the software.

Going by whats written there: https://duet3d.dozuki.com/Wiki/Filaments#Section_Loading_filaments

". You can only load one filament at once. The current filament mechanism is intended to reflect your spools and the underlying mechanism will be likely enhanced to include some usage statistics as well."

My PR would be to expressly remove this idea. If you want to track filament usage per-spool then you should add that as a separate feature for spool tracking. I don't think the two ideas are incompatible, If you add spool tracking as an extension to filaments you can make the individual spool the thing that can only be loaded into 1 extruder. But we don't have that yet, and even if we did, I don't see why I would copy my filament config for every spool of filament that I buy. Nor would I want the filament selection menu cluttered with dozens of spools of filament. Config for a filament type and tracking data for an individual spool are two different concepts.

You can keep a file for spools in the filament directory with per-spool statistics. Making a new spool of PETG wouldn't require copying a filament, its just a new line in the stats file. After you select a filament you can then, optionally, select an individual spool if you want to do spool tracking. This de-clutters the main selection menu.

Can I get a response so I can move forward on this @dc42 or @chrishamm?

T3P3Tony

I have flagged this up to @chrishamm.

chrishamm

@garethky Apologies for the late response, I've been thinking about this for quite some time.

In general I'm up for the idea to allow the same filament for multiple extruders. Decoupling this wouldn't take much effort and it's been requested for quite a while. How spool tracking could be implemented is another topic but I doubt we'll find time for this particular feature in the near future. In any case that could be implemented as a plugin once v3.3 is released.

Please note that your requested change would require two PRs, one for RRF and another one for DWC. I'll check if there are extra implications in DSF but I doubt that.

garethky

@chrishamm awesome! I will make both PRs. I don't think its very complicated at all, and from what I read in the C code there wont be any side effects. It doesn't cause a memory leak or anything like that.