Filament Odometer/Manage all your filaments
-
IIRC there once was a filament odometer suggested i.e. a figure what length of filament was extruded since the machine first went online/the last reset.
While thats kinda neat, I'd find another one really amazing:We already have "Filament" config files vor loading and unloading (iirc we also had a "config.g" file per filament but I cant find that anymore), what if we could have an odometer for every spool?
We'd need to have a config file for every color/spool that specifies filament diameter, etc. maybe like this;fil_type = PETG ;fil_manufacturer = XXXX ;fil_color = Blue transparent ;fil_dia = 1.75 ;fil_density = 1.29 ;fil_amount = 800 ;cost = XX.XX
maybe we could even add
;fil_loadtemp = 230 ;fil_unloadtemp = 200
and ditch the load.g and unload.g macros for each filament with one that specifies wait times, amount of filament extruded etc.
or maybe a .csv that acts as a "database".
as long and you'd use the load and unload function in DWC the firmware could keep track of how much filament was used for each color/roll of filament.This would enable having a vage idea how much filament is left on your spool and maybe a warning if you are low on filament/do not have enough for your print.
Having diameter, amount of filament, density and cost in there would also enable accurate weight and cost per part as long as filament usage metadata is accurate.
These values could be displayed under "Job Information" in DWC.Thoughts or suggestions?
Or is this a dumb idea/way too much work?-JV
-
When I start a new spool of filament I weigh it and mark the empty spool weight on the spool. When I'm going to start a print and it isn't obvious that there's enough filament on the spool, I weigh it again and subtract the empty spool weight. It works every time. I haven't run out of filament during a print in years.
Descriptions like "blue transparent" are nice, but you'll need a more positive identifier than that. What if you have more than one spool of "blue transparent" filament? I'd assign a serial number to each spool so I can be sure exactly which spool I'm looking at in the controller.
It would be much better to integrate filament accounting into the slicer so it can warn you that there isn't enough filament left on that spool to finish the print.
Maybe you could put the spool inside a cartridge and have the printer read/write a chip... oh wait...
-
When I start a new spool of filament I weigh it and mark the empty spool weight on the spool. When I'm going to start a print and it isn't obvious that there's enough filament on the spool, I weigh it again and subtract the empty spool weight. It works every time. I haven't run out of filament during a print in years.
I'm aware that's possible, I just think having an estimate of the amount of filament left on my spools would be neat, what if I'm not in the mood to break out a scale and my calculator?
Descriptions like "blue transparent" are nice, but you'll need a more positive identifier than that. What if you have more than one spool of "blue transparent" filament? I'd assign a serial number to each spool so I can be sure exactly which spool I'm looking at in the controller.
That's true, but I'd wager most people dont have multiple partly used spools of the same material, manufacturer and color in use at one time. Adding an ID for each spool could easily solve that but only an ID would be to cumbersome IMO.
It would be much better to integrate filament accounting into the slicer so it can warn you that there isn't enough filament left on that spool to finish the print.
I'd rather have that on my printer as I'm frequently switching slicers or device the slicer runs on, but not my printer. I think most people use multiple slicers/slice on different machines and not one slicer on one machine for multiple printers. Even IF I'd be only using 1 slicer I don't want to update a database on multipe machines everytime i slice a model.
Also what if I just slice a file and dont print it? what if I print the same gcode twice? what if a print fails and i have to restart it?
Only way that would make sense if you had a machine dedicated for sending out the gcode to the controller of your machine(sounds a bit like my Duet )
Implementing this in the Duet FW rather than a slicer makes way more sense IMO.
Also, IIRC this is the duet forums not the forum for some random slicer?