[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.

[bkerler]

Currently broken as v6.0 seems to have missing merged 474a274

[bkerler]

Should work with v6 again :)

[muesli]

Just to chime in how badly this is needed. There's a whole range of filaments below 200C that are currently unsupported by the firmware.

[CZDanol]

This is not mergeable, sorry. While this would possibly work, it introduces a code that is quite hard to manage.

• Heavy code repetition
• This needs to be coordinated with the Slicer team for filament type checks and such
• 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
• The UI design for this feature is possibly worth revising as well

We do want to have this feature, don't take me wrong.

[KlausKraemer]

I still see the necessity of a possibility to add new filaments. Some actually need temperatures way off the included filament choice.

Before that will be implemented: How about at least a possibility to simply tell the printer "Hey, I loaded filament pretending, it's PETG. But it's really PLA". That way changing filaments with different melting points could be way easier and effective, because a second unload/load cycle could be avoided.

[CZDanol]

@KlausKraemer discussion here is meant to be only about this PR. Please re-post it in some of the github issues, or create a new one.

That being said, I unfortunately don't understand your request, please try rephrasing it a little.

[bkerler]

This is not mergeable, sorry. While this would possibly work, it introduces a code that is quite hard to manage.

* Heavy code repetition

* This needs to be coordinated with the Slicer team for filament type checks and such

* 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

* The UI design for this feature is possibly worth revising as well

We do want to have this feature, don't take me wrong.

@CZDanol

Thx for the feedback. Regarding your points:

• Heavy code repetition: Yes, I also was quite unhappy, so I restructured the code. Let me know anything else that you think should be optimized / handled differently.

• This needs to be coordinated with the Slicer team for filament type checks and such: This shouldn't be needed as it doesn't interfer with the Slicer but instead uses the values that the Slicer is setting in the gcode

• 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 ?

• The UI design for this feature is possibly worth revising as well: If you are referring to the XL, yes indeed, there are already many issues regarding the footer and status design

[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.