Automaticly chose the right spool by a filament specific start G-Code

[JoschaMiddendorf]

In the most slicers a filament specific start G-Code can be defined.

Would it be possible to make the plugin chose the right spool automatically, by adding a Spool indicating comment to the G-Code?

In that way it could also be determined if filament of different spools will be used in multi material prints or after m600 filament changes.

[JoschaMiddendorf]

Slic3r even adds a line with the Filament ID automatically. By maintaining the naming scheme between the slicer and OctoPrint-FilamentManager maybe even this indication would be enough.

; filament_settings_id = "My Black Prusament PETG"

[malnvenshorn]

Possible? Yes. But whats the benefit? You're shifting the selection of the filament from the UI to the slicer. Even when you only want to print with a different color you have to slice your model again. This is completely the opposite what other users want, see #142 for example.

I also think that this could lead to some issues, because it would be still possible to change the filament in the user interface.

[JoschaMiddendorf]

There are many settings that need to be tuned for each filament separately, so I would never print a gcode with a filament that it hasn't been sliced for. But if it would still be possible to change the filament in the user interface, the users don't caring for detailed filament tuning, could still override the filament specified in gcode, or in addition to that don't even specify a filament specific start gcode. You could also make the automatic selection of filament, based on gcode (start-gcode-comment or filament_settings_id) optional, by adding a check mark in the settings.

The huge benefit would be that you cannot forget to select the right spool when you start a print and therefor eliminating the risk to mess up your filament counters by printing with a wrong spool selected.

Furthermore, it would give the OctoPrint-CostEstimation plugin the opportunity to calculate the cost prior to printing and to display the costs in Files section. For me, that would be a game changer because i regularly need to determine costs prior to a print for quotations.

https://github.com/malnvenshorn/OctoPrint-CostEstimation/issues/6

[malnvenshorn]

Yes you are absolutely right you cannot always reuse a filament profile, but usually I don't have to tweak anything when taking a different color of the same material from the same vendor. But this shouldn't be the topic here.

The huge benefit would be that you cannot forget to select the right spool when you start a print and therefor eliminating the risk to mess up your filament counters by printing with a wrong spool selected.

Imagine the following situation. You have a new filament spool and you forgot to set the custom gcode. A different filament is still selected in the FilamentManager. When you start a print the wrong filament will be used.

For such cases you can enable the confirmation dialog, but I don't see the benefit of the 'auto-selection' of the filament compared to the manual selection.

Furthermore, it would give the OctoPrint-CostEstimation plugin the opportunity to calculate the cost prior to printing and to display the costs in Files section. For me, that would be a game changer because i regularly need to determine costs prior to a print for quotations.

For this use case the estimated costs have to be stored in the database or all files need to be parsed every time OctoPrint starts. To be honest I don't like both solutions. Besides that you can already see the estimated cost before the print after OctoPrint has finished analyzing the file.

Also it is not sufficient to specify the filament name as a comment in the gcode file, because you could have multiple spools of the same filament in stock, therefore you need the IDs.

Another thing that comes to my mind. If you configured spool A in the gcode, but this spool has not sufficient filament for the print you still have to select spool B (same filament as spool A) manually. Automatically selecting the filament via gcode comments looks quite inflexible to me.

[JoschaMiddendorf]

Yes you are absolutely right you cannot always reuse a filament profile, but usually I don't have to tweak anything when taking a different color of the same material from the same vendor. But this shouldn't be the topic here.

Here you are absolutely right

Imagine the following situation. You have a new filament spool and you forgot to set the custom gcode. A different filament is still selected in the FilamentManager. When you start a print the wrong filament will be used. For such cases you can enable the confirmation dialog, but I don't see the benefit of the 'auto-selection' of the filament compared to the manual selection.

Didn't know about that setting, just checked the box. But the confirmation could also be invoked if there is no spool specified in gcode. And if it is it wouldn't be necessary to choose a spool manually. My idea isn't to replace the manual selection, but maybe just to enhance it by providing a predefined suggestion. The feature could also be manually selectable in the settings, so that people who prefer not to parameterize the workflow, could still do everything manually.

For this use case the estimated costs have to be stored in the database or all files need to be parsed every time OctoPrint starts. To be honest I don't like both solutions.

What's the issue with storing one extra value in the database. If it's absolutely impossible to add a value to the database, a separate statefile could be a workaround. Or in my case, I would also tick a box to reprocess everything or maybe a specifiable number of recently uploaded gcodes on every reboot. Or just place a "calculate price now" button on every gcode in files section.

Besides that you can already see the estimated cost before the print after OctoPrint has finished analyzing the file.

Where can I see that and how can I make Octoprint analyze the file? Can I also do that while the printer is busy with another print job?

Also it is not sufficient to specify the filament name as a comment in the gcode file, because you could have multiple spools of the same filament in stock, therefore you need the IDs.

In that case you could again display the confirmation dialog. Just see the gcode specified filament as a filter for those in FilamentManager. If filter results to 1 spool, take that. If it results to 0 spools matching, show full confirmation dialog. If it results to multiple spools of maybe the same filament, show confirmation dialog with only matching spools.

There could also be 3 fields to filter. Name | Material | Lieferant Possible relating gcode lines: ; FilamentManager_Name = "Black Prusament PETG" ; FilamentManager_Material = "PETG" ; FilamentManager_Supplier = "Prusament" or similar, provided by the slicer.

In that way you could also just filter the filament compatibility of the gcode by material and still have the ability to choose another i.e. roll of PLA.

[malnvenshorn]

Where can I see that and how can I make Octoprint analyze the file? Can I also do that while the printer is busy with another print job?

Every new gcode file will be analyzed automatically. Usually it's finished when you can see the amount of filament in the sidebar. Because it needs a lot of processing power the process is suspended if a print job is running.

If you're interested you could take a look at my MetadataPreprocessor plugin.

[JoschaMiddendorf]

Every new gcode file will be analyzed automatically. Usually it's finished when you can see the amount of filament in the sidebar. Because it needs a lot of processing power the process is suspended if a print job is running.

I can see the amount of filament in the sidebar, but no estimated cost so far. Processing power isn't an issue for me, as my Octoprint instances are running in Docker containers on an Intel Xeon based Application server. Hopefully the suspension features aren't always on. But that's off topic I think.

How do you think about the idea to filter spools?

[JoschaMiddendorf]

By the way Repetier Sever handles that cost calculation thing also very well, by making a spool select able in advance on a per gcode file basis.

[malnvenshorn]

Sorry, but I still don't see the benefit if it comes down to manually selecting the filament anyway.

Everything regarding the cost estimation should be discussed in the corresponding repository.

[Ravnecks]

I would also love an automatic spool choice by G-Code. With slic3r you can automatically start the print after uploading the gcode. When I use this option I am not able to select the right filament in filament manager because I won't open Octoprint before the print starts.

[josephduchesne]

Sorry, but I still don't see the benefit if it comes down to manually selecting the filament anyway.

The Slic3r / Slicer Prusa Edition workflow that I normally use is:

• Open Slicer Prusa Edition
• Select the filament that I'm using in the slicer's filament manager
• Lay out the print
• Slice
• Send Gcode w/ Start printing after upload checked
• Print starts

It's semi-regular that I swap filament types, slice the correct filament, then one or more prints take place with the wrong numbers. This makes the plugin pretty hard to use since the only way to reconcile this is basically to go through and weight every roll of filament that I have, weigh empty spools from that brand or google the empty weight, and do a bunch of math. Until then the entire plugin is useless.

Another way to resolve this would be to have a log of each print, with the type of filament used editable.

To highlight how requested a solution to this is, I've briefly skimmed through all open and closed tickets:

20 #34 #20 #36 #123 #143 #147 #150 #156 #160, #174 #196 and #200 are also trying to figure out a way to resolve this problem.

It's pretty clear that there's a usability problem here that the community is interested in.

I think the filament challenge is that the amount of filament used is not a scalar value, it's a ledger.

If the backend stored the amount of filament in the spool, the logged a new entry each time there was a debit from this total, the calculated sums (remaining) could be easily fixed when a ledger entry was changed.

It would just take a simple table containing

• some uuid
• a timestamp for sorting
• the print name
• usage type (e.g. initial used amount, print, manual offset, spool replacement additional filament)
• the selected filament id
• the amount used

The existing filament remaining (used column) could remain as it is, but in the event of a change, it would be a simple matter of taking the original weight, and subtracting the sum of all credits/debits from the ledger. If performance ever became a problem there could be an option to compact ledger entries older than a certain date into a single value.

Once added, this backend could support the ability to do a host of nice-to-have things, including a quick way to reassign the last print, an audit trail of "where did I use this filament", and the ability to retroactively fix several prints done with the wrong filament type selected.

[DaStivi]

is this really still true that you have to choose the spool manually before each print?? make the whole "zero-touch" print start right away kinda pointless, that octoprint should give ... 🤔