Open agravelot opened 1 year ago
This is some good ideas :)
I'm not really setting filament specific parameters when I'm 3d-printing. Perhaps you can help me by providing a conclusive list of parameters that would be good to have? We already have extruder and bed temp today.
Sadly, we cannot provide magic number since it's specific for each printer and filament.
Linked to https://github.com/Donkie/Spoolman/issues/20 & https://github.com/Donkie/Spoolman/issues/10
I didn't ask for any specific numbers, I'm interesting in knowing what filament-specific parameters there are. Currently Spoolman supports bed and extruder temperature. What more should be there?
Created a mockup of a new system I had in mind, you can see it in #20 , would this be suitable?
I think it'd be easiest if Spoolman hooks into Moonraker and overrides the gcode there, instead of hooking into the slicers. What do you think?
One thing which can be even different from spool to spool would be "pressure advance" which a lot of people (me to) set in the custom gcode filament settings.
To be honest I dont see this as a needed function in spoolman itself - but it would be very handy in the app discussed in #142
Created a mockup of a new system I had in mind, you can see it in #20 , would this be suitable?
I think it'd be easiest if Spoolman hooks into Moonraker and overrides the gcode there, instead of hooking into the slicers. What do you think?
That would work well for things that affect only the printer, but are not controlled by the slicer. Not so well for things that must, by nature, be (also) considered by the slicer. And that's most.
Cooling comes to mind. Filament matters big-deal for cooling (think ABS/PLA), so it's definitely a Spoolmanager thing in my book. But there's obviously no way that "always the same cooling for this filament" is correct. It's rather a "Slicer takes base material data from Spoolmanager and modifies it with smart decisions, several times per layer".
Good luck with slicer developers on getting that working ... :-/ And good luck with me if you override my carefully determined slicer settings with trivial default values ;-)
So: bed temperature, nozzle temperature, both for first-layer and remaining, cooling data (my slicer has 12 settings ...), filament density, cost, diameter, extrusion multiplier, spool weight .... just look through a slicer's material data, you probably want everything there. After all, why should a slicer keep a material database when there is Spoolman? (yes, that's rhethorical)
Pressure Advance may work well indeed, simply because hardly any (any at all??) slicers actually use Klipper PA. They rather do their own thing, and only their own thing, and we switch it off immediately anyway. On the other hand, PA depends on filament AND PRINTER ... if you're actually managing the same spools for multiple printers, that would be a hard and immediate nogo.
For me even a "basic data import" would be a help. Basic would be all information, that can come from the filament producer. And my "dream" is, that there will be an industry standard for filament-basic-informations, that can be imported from the producers homepage and are linked to an ID, you just scan from your filament.
I would like to outsource the (basic) filament mangement outside the slicer and get it via API/.ini into the slicer. So i have a seperate managementsystem for my filaments (like spoolman). Then later on, i can add slicing and printer specifics either in spoolman myself, or in the slicer, but that would be the second step.
Don´t know, if that is one goal of this project, so just my 2cents.
Before going any further, I'd like to thank you for this project. It's been on my mind for a long time, but never came to fruition.
Having the ability to retrieve the entire Spoolman filament in your slicer could be useful.
Ideally, we could synchronize from the slicer GUI, but this would require extensive development of slicer parts and as most slicers are managed by major brands, it will be a long road.
Another solution would be to download filament profiles and import them into the slicer. This would require a specific export format for each slicer, as it is not standardized.
Perhaps storing additional information such as extrusion multiplier, cooling, custom g-code could be handy (PA, for example).