[BFW-5513] gui: Add custom filament temperature settings

[bkerler]

Refers to issues #3643, #2210, #3633, #3589, #3667, #3786 and for sure even more.
As many users requested to add custom filament settings for PHA, NGEN etc. and it is forseeable that many more filament types will appear, it does make sense to add custom modifiable filament temperature settings.

Here's an example of the implementation:

It was fully tested to be GUI conform on the MK4 and Mini. It also compiled without issues on the XL.

The 4 custom filament slots can be set via "prusa_printer_settings.ini", for example:

[custom_filament_1]
name=PCTG
nozzle_preheat=170
nozzle=260
heatbed=100

[custom_filament_2]
name=PHA
nozzle_preheat=170
nozzle=210
heatbed=0

[custom_filament_3]
name=NGEN
nozzle_preheat=170
nozzle=240
heatbed=90

[custom_filament_4]
name=CPE
nozzle_preheat=275
nozzle=210
heatbed=90

Copy the prusa_printer_settings.ini to usb stick, then load via "Settings->System->Load settings from file" and it will be available immediately on the printer.

[bkerler]

Rebased to v5.1.2 as requested

[FVerbaas]

The above procedure would yield 'anonymous' filament names, and post-it notices on the printer. Sequence number for a filament will be different for each printer.
I have no deep insight in the things yet, but the printer does throw warnings if the filament type loaded does not match the filament type specified for the BGCODE files, so there must be a way to identify a material. I suggest to let the printer accept filament type name and temperature for bed and hotend as specified in the BGCODE, and on encounter add the option to add this to the list.
Multiple 'new' materials could be added in one go with a single GCODE file in which a dummy object is printed with a layer in each material.

[bkerler]

What do you mean by sequence number ? The filament can be identified and set using the filament name, in this case "CUSTOM_1" for Slot 1 instead of "PLA". Of course an additional gcode could be added to set the Slots using serial port / Prusa Slicer if needed, but that is out of the scope for this PR as it would introduce a lot of issues and even more testing. There aren't unlimited slots as the firmware has a limit of a max of 4 slots (due to the menu structure limiting to a max. of 16 items). It might be possible to assign a name for each slot if needed, but that is also right now out of the scope.

[FVerbaas]

By sequence number I mean the number behind the "CUSTOM" string.
I was not aware there is a limit in number of slots. Anyway 4 strikes as a bit low in this respect, but admitted one can jot the local mapping on a post-it.
Also not sure if the approach now painted avoids the warning by the printer that the filament currently loaded is not the one specified in the GCODE. Of course the warning could be suppressed when the current material is one of the 'CUSTOM' slots, but not sure if that is a desirable situation because this is exactly the situation when such a verification and warning can be useful.

I do not understand why you say extra gcodes would be neded. The present GCODE files already contain all the necessary info.

; generated by PrusaSlicer 2.7.1+win64


; printer_model = MK4IS
; filament_type = PETG                 <====
; nozzle_diameter = 0.4
; bed_temperature = 90               <====
; brim_width = 0
; fill_density = 15%
; layer_height = 0.2
; temperature = 245                    <====
; ironing = 0
; support_material = 0
; extruder_colour = ""
; max_layer_z = 2.00
; filament used [mm] = 200.92
; filament used [g] = 0.61
; filament cost = 0.02
; filament used [cm3] = 0.48
; total filament used for wipe tower [g] = 0.00
; estimated printing time (normal mode) = 2m 28s
    

In short I suggest the printer takes these data for material, hotend temp and bed temp and stores this in the 'custom' slot indicated by the user, to be used like any other material from that moment on.
I imagine that for practical purposes the slots get a name like 'CUSTOM_PCGT'.

Another question while I am 'at it' Does the info in these custom slots survive a firmware update?

[bkerler]

The sequential number you are refering to is the slot number. It's not possible to give custom slot names such as "CUSTOM_PCGT" as the main issue is, that these values have to be stored in the eeprom as well and the variable needs to be in a hardcoded array that is being stored in the eeprom. It would be possible to store a name for the slot, but still PrusaSlicer would have to configure a slot, as the names are hardcoded in the firmware. I don't see any easy way to change that behaviour without changing huge portions of the firmware, sorry :(

Of course you could also save the custom name to the slots in the eeprom and compare against the filament_type in the gcode, but that would require a lot of eeprom space as you would need to reserve a fixed space like 16 chars for each slot (4) and also the user would need to enter the name manually into the printer, which I haven't seen a functionality in the printer to do that so far. Would be doable, but would also take a lot of time and testing (and also might not be possible for the mini printer).

4 Slots are the max limit due to a max of 16 items on the screen, and 12 menu items are already hardcoded. Changing that limit might cause big trouble for the mini printer fw due to hw restrictions and does also mean huge changes to the current firmware as far as I could see so far.

[FVerbaas]

Thank you Björn for the extensive answer. I understand the issue better now. The LCD screen thing is not just a monitor and peripheral for the buddy board. This may be explained from a historical background but too bad a new printer type launched less than a year ago now already runs into such limitations.
I see that on the short term the proposed patch solution will probably be the best one feasible.
At present there is a comparison between the material name specified in the GCODE and the material saved in the printer as 'currently loaded'. If there is a discrepancy the printer issues a warning. If the currently loaded material is one of the 'custom' types, could one avoid that warning by editing the name of the material in the GCODE, so replace the string 'PCTG' by 'CUSTOM_1'?

[bkerler]

I will seek into that, but not sure if there will be an easy way to do that, @FVerbass :D

[FVerbaas]

I just defined custom material CUSTOM_1 in Prusaslicer (saved a copy of Fiberlogy PCGT) and made a GCODE file with that material type. I attached a zipped copy.
I do hope this would pass the printer's checks without complaints. It is just up to me to keep that Post-it on my printer to remind me that my CUSTOM_1 material is PCGT. ;-)

Shape-Box_0.4n_0.15mm_CUSTOM_1_MK4IS_29m.zip

[bkerler]

Thanks, will try the gcode on the simulator :)

[bkerler]

Seems there is an issue as the gcode preview does truncate the filament type to "CUSTOM_", missing the slot. Gonna need to have a look if CUSTOM_1 needs to be replaced by "CUST_1" or if the length can be increased.

[bkerler]

indeed, there is a limitation in filament_buff to have a max size of 8 chars

[bkerler]

I've solved it now by increasing the char buffer size to 9 :) Tested and it seems to work fine printing your gcode @FVerbaas.

[FVerbaas]

Excellent! The actual name is immaterial of course, as long as it can be read and lines up with what is hardcoded. Thanks and regards, Frans Op za 13 jan. 2024 23:55 schreef Bjoern Kerler ***@***.***>:

…

I've solved it now by increasing the char buffer size to 9 :) Tested and it seems to work fine printing your gcode @FVerbaas <https://github.com/FVerbaas>. — Reply to this email directly, view it on GitHub <#3657 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANPPP5NODLZI4CHSETCR553YOMGERAVCNFSM6AAAAABBKMJQACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQG44DOOJTHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bkerler]

Frans, yes, having the filament name instead of "CUSTOM_1" would be great, but I don't see any easy way to set a custom name via the user interface right now, except we introduce a new gcode to allow setting custom names.But that wouldn't be very userfriendly and may introduce security issues. Guess I need to discuss that with the prusa guys, maybe it can be added to the web interface.

[FVerbaas]

There is a workaround for the short term but yes if you have the channels please raise it with them. To me it came as a disappointment. One buys a 1000+EURO printer; the launched less than a year ago top line model of a top notch manufacturer, and then one has to go exploiting loopholes in the manufacturer's own slicer app (writing in what appears to be intended a pure drop-down selection box) to make a clone of a known material definition only to give it a special name so it can be recognized by the printer.
But solving that is up to them, of course. If they have questions they know where to find me.
Thank you for your responsiveness. Who knows our routes will cross again some day. For now take care.

[bkerler]

I had a chat with the devs and there is currently a development for text entry. So I will prepare the commit for adding custom names to the slot, then the user shouldn't have to remember custom names ;)

[FVerbaas]

Great! Thx. Op di 16 jan. 2024 09:18 schreef Bjoern Kerler ***@***.***>:

…

I had a chat with the devs and there is currently a development for text entry. So I will prepare the commit for adding custom names to the slot, then the user shouldn't have to remember custom names ;) — Reply to this email directly, view it on GitHub <#3657 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANPPP5NAIOAS33SWZ3U2P5TYOYZTXAVCNFSM6AAAAABBKMJQACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJTGI2TKNRTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bkerler]

@FVerbaas, it has now option to change names and filament temperatures using prusa_printer_settings.ini, so you don't have to remember what CUSTOM_1 etc. was :)

[FVerbaas]

Great! Thanks for letting me know. Frans Op zo 21 jan. 2024 16:48 schreef Bjoern Kerler ***@***.***>:

…

@FVerbaas <https://github.com/FVerbaas>, it has now option to change names of the filament using M703 command, so you don't have to remember what CUSTOM_1 etc. was :) — Reply to this email directly, view it on GitHub <#3657 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANPPP5KO64ET7OZ4JUWVENTYPU2DLAVCNFSM6AAAAABBKMJQACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGY3TMMJSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[KlausKraemer]

I just loaded Willowflex filament into my XL. Recommended nozzle temperature is from 180°C to 200°C.

Closest filament to load Willowflex is PLA with 215°C. At this temperature, Willowflex is nearly flowing through the nozzle by itself. Way too liquid. 215°C ist too hot for Willowflex.

I expect problems when unloading, as retraction leads a still overheated filament back to the extruder.

We really need common filament settings! The sooner, the better! And please reconsider to place these custom settings editable in a file on the USB Stick. I wouldn't like to fiddle around with the printer display.

[CZDanol]

Internal ticket for this feature: BFW-5513

[CZDanol]

There are some conceptual changes that we want to do to prevent this change introducing more technical debt - for example not using responses in the preheat menu: Yep, any ideas for that ?

Yes, I do. But those changes need to be implemented internally after discussion with the whole team and such. Not suitable for an external PR, sorry. I will push for doing it.

[FVerbaas]

An intermediate solution would be to work from the settings in the GCODE file that is to be printed. The header of the file, at least those generated by PrusaSlicer, contain the printing temperature. The printer could use that for loading filament.
I do not know how standard this is, so it may not work for all GCODE files, but if it at least works with PrusaSlicer, the current (embarassing) gap between the slicer and the printer would be closed. A stand-alone loading sequence for a specific material can be defined in a GCODE file.

[bkerler]

thx @CZDanol. Highly appreciated.

[muesli]

Now that we even have official Prusa filament with a recommended temperature below 200C, I really hope this becomes a priority.

[bryn51]

Its great to see this is progressing. Several times I have used unusual filaments but found it a pain having to mess around with temps or compromise "similar" filament type selections in the slicer and during load/unload. Better to identify the material correctly.

May I suggest the Prusa Connect folks might need to have a look at this too, because the statistics screen identifies filaments by type.

[CZDanol]

@bryn51 we are coordinating with the Connect guys, but it will probably be first implemented on the printers and then receive full Connect support some time later.

[FVerbaas]

Good to hear this now gets attention. It really is a shame that we have to use all these tricks to fool the printer and the software, even for filament sold by Prusa themselves. Op vr 26 jul. 2024 08:37 schreef Danol (Daniel Čejchan) < ***@***.***>:

…

@bryn51 <https://github.com/bryn51> we are coordinating with the Connect guys, but it will probably be first implemented on the printers and then receive full Connect support some time later. — Reply to this email directly, view it on GitHub <#3657 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANPPP5MTFI54G5CTOD53E7DZOHVCNAVCNFSM6AAAAABBKMJQACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJSGA3TGNZUG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Lyude]

There are some conceptual changes that we want to do to prevent this change introducing more technical debt - for example not using responses in the preheat menu: Yep, any ideas for that ?

Yes, I do. But those changes need to be implemented internally after discussion with the whole team and such. Not suitable for an external PR, sorry. I will push for doing it.

????
Could there be more explanation on this? I have to assume I'm missing some context here, maybe this is something that needs to happen internally due to safety certification requirements or something that just needs to happen in sync with services that Prusa hosts like PrusaConnect?

[CZDanol]

There are some conceptual changes that we want to do to prevent this change introducing more technical debt - for example not using responses in the preheat menu: Yep, any ideas for that ?

Yes, I do. But those changes need to be implemented internally after discussion with the whole team and such. Not suitable for an external PR, sorry. I will push for doing it.

???? Could there be more explanation on this? I have to assume I'm missing some context here, maybe this is something that needs to happen internally due to safety certification requirements or something that just needs to happen in sync with services that Prusa hosts like PrusaConnect?

Yes, you are correct. Filament type support is definitely something that needs to be consulted with the Connect, and the Slicer teams. I've mentioned that two comments above yours :)

I was also responding to "for example not using responses in the preheat menu" - and that is a very technical thing. Basically, that is a rather large conceptual change in the codebase that requires consultations across the dev team, so it's not something that can be just handed to us by an external developer. We would need to integrate him in the team deeply and well, then he wouldn't be external anymore.

[Lyude]

There are some conceptual changes that we want to do to prevent this change introducing more technical debt - for example not using responses in the preheat menu: Yep, any ideas for that ?

Yes, I do. But those changes need to be implemented internally after discussion with the whole team and such. Not suitable for an external PR, sorry. I will push for doing it.

???? Could there be more explanation on this? I have to assume I'm missing some context here, maybe this is something that needs to happen internally due to safety certification requirements or something that just needs to happen in sync with services that Prusa hosts like PrusaConnect?

Yes, you are correct. Filament type support is definitely something that needs to be consulted with the Connect, and the Slicer teams. I've mentioned that two comments above yours :)

I was also responding to "for example not using responses in the preheat menu" - and that is a very technical thing. Basically, that is a rather large conceptual change in the codebase that requires consultations across the dev team, so it's not something that can be just handed to us by an external developer. We would need to integrate him in the team deeply and well, then he wouldn't be external anymore.

Ah, apologies I missed that comment above - thank you for the clarification! My main reason for asking was because I (and almost everyone I've talked to) bought into Prusa's ecosystem to help support open source development. This being said - an easy solution to the problems described here (I mean, except for PrusaConnect of course) would simply be to default to having discussions around this kind of design in the open wherever possible - as doing so dramatically reduces the complexity in working across teams with outside contributors and makes this sort of thing a non-issue. It's also kind of the standard in FOSS

Would a compromise of some sort here be acceptable in the mean time? Even being able to only configure a custom temperature through an ini file would be quite useful, and seeing as prusaslicer is open source and on github already this seems like something that would be pretty easy to coordinate. Functionality that Prusa in the GUI that prusa wants to keep in sync with services like PrusaConnect could certainly come later and I think a lot of people would still be pretty happy with that. This is also basically the way that Wi-Fi passwords were handled in Prusa's firmware up until the most recent firmware updates, and that didn't seem to be too much of an issue for most users.

[CZDanol]

@Lyude No need for compromises :) We've just released a 6.2.0 alpha1 FW with a fully featured user material support :) https://github.com/prusa3d/Prusa-Firmware-Buddy/releases/tag/v6.2.0-alpha1

Closing this PR.

[bryn51]

• Please advise what is related ticket number on Prusa Slicer. Will change releases be coordinated ?

[CZDanol]

@bryn51 There are no changes needed on the PrusaSlicer side. Everything should work out of the box.

[Ro3Deee]

@bryn51 , the filament settings in the printer are for loading/unloading filament. The filament settings in the slicer ar for actual printing

[CZDanol]

[CZDanol]

Oh, actually, I forgot - yes, there will be some small changes in the Slicer. They will be adding fields to configure filament abrasivity and extruder hardened/high flow nozzles

[bryn51]

@bryn51 There are no changes needed on the PrusaSlicer side. Everything should work out of the box.

Thanks for your response, but it begs the question:
Apropos PS generates gcode that includes short mnemonic generic recognition code of filament, seen in dropdown list on PS filament profile you depicted, and this is (I believe) used on printer firmware to alert the user when filament loaded does not match the gcode. It's part of default filename too. The filament code also finds its way to Prusa Connect, and used for statistical purpose and in a couple of other places.
So on PS, the expected change would be to add several "custom" filament codes into the dropdown list.
Ideally the filament type recorded in Connect would be an mnemonic of the material not "custom_1" etc.
Thus changes, albeit small ones, might be expected on both Connect and PS.
That said the ability to have custom type added to the printer simplifying filament load will be a significant improvement by itself, so long as unexpected errors or behaviors do not occur. I guess that must be a part of testing regime.
I'm wondering if I should perhaps bring my own experience to bear on this (normally I steer clear of test versions). I'm definitely interested in the outcome.

[CZDanol]

@bryn51

• The idea is not that you use "CUSTOM1" for your custom filaments, but rather the mnemonic for it. For example "PCTG".
• In PrusaSlicer, you are not limited to the options in the dropdown, you can enter any string you want (as demonstrated in the screenshot above).
• So for example, you add a custom profile for "PCTG" in the printer, you set up a PCTG filament profile in the slicer, and everything will work.
• Connect should be able to crunch your custom mnemonics as well, though they won't be in the preheat menu list, at least for now.
• The same goes if you have say glow in the dark PLA. You'd simply create something like "GLPLA"

[bryn51]

Oh, actually, I forgot - yes, there will be some small changes in the Slicer. They will be adding fields to configure filament abrasivity and extruder hardened/high flow nozzles

Thats also a big deal and welcome. unclear what behavior change on PS or the printer might occur, but speculatively one might expect it to influence maximum Flow rate and motion speed.(for CHT).

[CZDanol]

Thats also a big deal and welcome. unclear what behavior change on PS or the printer might occur, but speculatively one might expect it to influence maximum Flow rate and motion speed.(for CHT).

Flow rate and motion speed is determined by the printer profile in the slicer. These fields will be intended for compatibility checks.

[bryn51]

@bryn51

• The idea is not that you use "CUSTOM1" for your custom filaments, but rather the mnemonic for it. For example "PCTG".

• In PrusaSlicer, you are not limited to the options in the dropdown, you can enter any string you want (as demonstrated in the screenshot above).

• So for example, you add a custom profile for "PCTG" in the printer, you set up a PCTG filament profile in the slicer, and everything will work.

• Connect should be able to crunch your custom mnemonics as well, though they won't be in the preheat menu list, at least for now.

• The same goes if you have say glow in the dark PLA. You'd simply create something like "GLPLA"

I get it. So "custom_x" just used as example. makes sense.

[CZDanol]

@bryn51 the CUSTOM_X was used as an example for this PR - but this PR was not merged, we implemented the things differently. So the demo image you see on the top has nothing to do with how things work on the printer.

[bkerler]

Yeah, custom_1 .. custom_4 was just at the beginning of the PR, but it was modified to use any filament name instead afterwards. Prusa has even added more functionality and so far I'm pretty happy about it (it looks pretty familiar to what I did) :D

[KlausKraemer]

@bkerler Thank you for all the energy, you invested to create a solution!