STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt - awesome .... super slicer and prusa slicer 2.3.3 here. Just re read @deckingman post above too and he described how to do as such.

I will give this a try and see if it sorts my drama.

TY fellas

Feel free to get back to me if you need more info.

Frederick

[SputnikOC3d]

@fcwilt - more questions. Ive seemed to have opened a can of worms onto meeeself ...

Whats the purpose of this ? set global.print_end_retract = 0.5 ;

Now i need to try and sortcreating and passing needed var's around - havent fiddled with that much coding in decades ... like Allaires ColdFusion decade LOL

Is the advantage of your print begin macros to remove the slicers quirks from the equation and have the vast majority of all things dealt with via your script and duet/rrf3 ?

This approach will require a complete rethinking of how I start and end my printing routines/jobs, which is fine, and due to this current issue with added junk code - I see the clear benefits. However; is there more to gain ?

Sounds like I just need to convert the code I have embedded in my slicer's custom code / start.g section into a revised macro housed in my own fw file structure and remove slicer / super slicer / ideamaker / s3d et al ... from that domain.

[dc42]

@sputnikoc3d if you were getting CAN error messages then those are most likely to be caused either by running different firmware versions on the main board and tool board, or because you don't have a G4 delay command in config.g to give the tool board time to start up before the first command in config.g that refers to the tool board. So check both firmware versions using M115 and M115 B# where # is the CAN address of the tool board, and check that you have a G4 S2 command near the start of config.g.

[SputnikOC3d]

@dc42 said in [ snipped out ]

Yes sir will do ... I only seem to recall getting these errors when I had this G10/M116 issue.

More to follow

Had G4 S1 !!! changed to 4 seconds as advised. TY

1LC - rrf3.3 beta 2+2
Duet 3 mini - rrf 3.3

Duet TOOL1LC firmware version 3.3beta2+2 (2021-04-16 13:48:06)

FIRMWARE_NAME: RepRapFirmware for Duet 3 Mini 5+ FIRMWARE_VERSION: 3.3 ELECTRONICS: Duet 3 Mini5plus Ethernet FIRMWARE_DATE: 2021-06-15 21:46:20

[SputnikOC3d]

@fcwilt - my first stab at this- isnt going so well ...

I did a slice after creating a Print Start Macro - essentially putting my custom start.g routine into it. Did similar with a Print End.g - just used my custom End script to lift nozz and move head to a safe location for print removal.

Went thru an existing PLA filament config.g and updated it ti be more robust based up on this thread. Was just setting retraction and pressure advance before.

M221 S0.94 D121.0					; set extrusion multiplier
M207 S0.4 F2100 T1500 Z0			; FW retraction settngs | distance .4 | Speed - F | deRetract Speed - T
G10 P0 S215 R175                    ; set extruder temps
;M568 P0 R175 S215 A1				; Sets Tool0 / S-Nozz 1st layer Temp / R-Standby Temps | A1-Sets Tool0 to Standby Temp
M140 S65 R0                         ; set bed temps
M572 D0 S0.05						; Pressure Advance Settings S = distance .05 is median

Wasnt sure if there was a reason to set Nozz temps via G10 vs. M68 like I was in the start.g previously.

I did not set any var's ... not sure how yet.

Ran a slice and ... no appended junk G10/M116 combos - but no print to look at either. All gcode for the extruder is E0.00000's - entire print. So obvi Im doing something significantly errant.

Also - it just dawned on me .. for this approach to work successfully - I MUST have the proper filament selected via the DWC Load filament interface.

Starting to question my sanity of embarking on this approach ... with 3 different printers and 3 duet boards - one with different sized nozzles / brass and hardened steel / nozzle X and different hotends and bed type - I can see this getting unmanageable in a jiffy. If printer A with the hard steel nozz i usually use for PC and CF happens to be printing PLA - it needs to run about 10C hotter than the brass nozz printer next to it which may be occupied with a current job/plate full of parts that will take 8 hrs.

Not to digress too far off the prior issue at hand ... Im not sure I want to make THAT many Filament config.g combos ... [ lets address this sidebar another time ] I do need to get this new duet 3 Voron 2.4 printing reliably for now - deciding the best way to organize a plethora of print heads nozzles and gfilaments can come later after It actually works ... one way or another .

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt - more questions. Ive seemed to have opened a can of worms onto meeeself ...

Whats the purpose of this ? set global.print_end_retract = 0.5 ;

Now i need to try and sortcreating and passing needed var's around - havent fiddled with that much coding in decades ... like Allaires ColdFusion decade LOL

The purpose of using the global variables is there is other code I didn't post that use them to control extruder priming and retraction. Different filament types sometimes benefit from different values.

Is the advantage of your print begin macros to remove the slicers quirks from the equation and have the vast majority of all things dealt with via your script and duet/rrf3 ?

The goal was to allow using different slicers with the minimum amount of code in the slicer.

Generally I can slice a model in Cura, Prusa, Simplify3D or most recently ideaMaker and print it with different filament types just by selecting the desired filament type in the DWC.

Frederick

[engikeneer]

@sputnikoc3d looks like your toolboard firmware is still a beta, so might be that mismatch causing your issue like DC42 suggested...?

For the different temps for different machines, it might be a headache now, but it means your steel nozzle printer temps will always be right etc. You should also be able to send the same gcode to different printers. You just need to name the filaments the same on the different printers. You then just say which filament to call in the slicer (can't remember what the gcode is...)

Also, if you're still struggling with the slicer spitting out temp commands you dont want, you can use a python post-processing script to remove them or comment those lines out (thats what I do to help handle multi tool bits for mine). PrusaSlicer has a feature to run this when it slices a file

Finally M568 is the way to go over G10. G10 is being deprecated

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt - my first stab at this- isnt going so well ...

I did a slice after creating a Print Start Macro - essentially putting my custom start.g routine into it. Did similar with a Print End.g - just used my custom End script to lift nozz and move head to a safe location for print removal.

Went thru an existing PLA filament config.g and updated it ti be more robust based up on this thread. Was just setting retraction and pressure advance before.

M221 S0.94 D121.0					; set extrusion multiplier
M207 S0.4 F2100 T1500 Z0			; FW retraction settngs | distance .4 | Speed - F | deRetract Speed - T
G10 P0 S215 R175                    ; set extruder temps
;M568 P0 R175 S215 A1				; Sets Tool0 / S-Nozz 1st layer Temp / R-Standby Temps | A1-Sets Tool0 to Standby Temp
M140 S65 R0                         ; set bed temps
M572 D0 S0.05						; Pressure Advance Settings S = distance .05 is median

Wasnt sure if there was a reason to set Nozz temps via G10 vs. M68 like I was in the start.g previously.

I did not set any var's ... not sure how yet.

Ran a slice and ... no appended junk G10/M116 combos - but no print to look at either. All gcode for the extruder is E0.00000's - entire print. So obvi Im doing something significantly errant.

Did you remember that you needed to have in your print start code the M703?

Also - it just dawned on me .. for this approach to work successfully - I MUST have the proper filament selected via the DWC Load filament interface.

I didn't post all of my code that I run start print start - see below.

I do some "sanity checks" to insure things are correct - such as filament selected and needed commands in the filament config file.

Then you can see where I use the global variables. Using them is strictly optional.

; select tool and configure based on filament selected

T0                              ; select tool 0 so extruder commands below will work
M703                            ; configure selected filament (sets bed/extruder temps, extrusion multiplier)

; check for selected filament

if move.extruders[0].filament = ""
  M291 R"No Filament Selected" P"Cannot Continue" S2 T0
  abort

; check bed heater active temp setting

if heat.heaters[0].active = 0 
  M291 R"Bed Heater Active Temp = 0" P"Cannot Continue" S2 T0
  abort

; check extruder heater active temp setting

if heat.heaters[1].active = 0 
  M291 R"Extruder Heater Active Temp = 0" P"Cannot Continue" S2 T0
  abort

; check if homed - allows homing (OK button) or canceling (CLOSE button)

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  M291 R"Printer has not been homed" P"Home and Continue?" S3 T0
  G28

; setup to print

M291 R"Preparing to print" P"Please wait..." T0

M106 P2 S255                    ; lights on
M106 P3 S255                    ; lights on
M106 P4 S255                    ; lights on

G90                             ; absolute moves
G1 Z100     F1200               ; position for cleaning
G1 X0 Y-145 F6000               ; position for cleaning

M291 R"Heating Extruder & Bed" P"Please wait..." T0

M116                            ; wait for temps to reach set points

M291 R"Priming Extruder" P"Please wait..." T0

M83                                 ; insure extruder relative mode
G92 E0                              ; reset the extruder logical position
G1 E{global.g_print_beg_prime} F120 ; prime the extruder
M400                                ; wait for extruding to finish
G92 E0                              ; reset the extruder logical position

M98 P"beep_alert_1.g"               ; beep paneldue

M291 R"Clean Nozzle and Bed" P"Click OK to begin printing" S3 T0

G1 E{-global.g_print_beg_retract} F120 ; retract to control oosing
M400                                   ; wait for extruding to finish
G92 E0                                 ; reset the extruder logical position

M98 P"mesh_load.g"                     ; load height map as needed

Starting to question my sanity of embarking on this approach ... with 3 different printers and 3 duet boards - one with different sized nozzles / brass and hardened steel / nozzle X and different hotends and bed type - I can see this getting unmanageable in a jiffy. If printer A with the hard steel nozz i usually use for PC and CF happens to be printing PLA - it needs to run about 10C hotter than the brass nozz printer next to it which may be occupied with a current job/plate full of parts that will take 8 hrs.

Not to digress too far off the prior issue at hand ... Im not sure I want to make THAT many Filament config.g combos ... [ lets address this sidebar another time ] I do need to get this new duet 3 Voron 2.4 printing reliably for now - deciding the best way to organize a plethora of print heads nozzles and gfilaments can come later after It actually works ... one way or another .

Whatever approach you use the information needs to be somewhere.

I wanted to be able to use different slicers with a minimum of information duplicated in each slicer, such as temp settings.

I have been using this approach since the v3 firmware came out and have expanded it as things like variables became available.

I have four printers, all different. I simply use an FTP client to download all of the filament files from the "master" printer and upload them to the remaining printers.

I have found no reason (yet) to not use this approach.

But everyone is different - you need to use whatever approach suits you best.

Frederick

[SputnikOC3d]

@fcwilt - awesome.

Ok so it is manageable. This further info posted from your start print macro is helpful. The conditional code - solves several concerns - wasnt thinking of that flexibility being availed in rrf3.x but its there now.

Yes T0 and M703 are the 1st two lines in my start macro, but Im sure it was my lack of passing temps for nozz and bed thru variables to the slicer somehow that cause it to emit junk gcode.

I did find a hack for the superslicer G10/M116 issue - and that is - it and prusa slicer will not emit "safeguard" gcode into the mix if you stuff a M104 / M190 at the front of your custom start.g in the slicer.

I switched over to M568 ... and neither slicer jived with that; hence it stuffed a G10 P0 S215 and a M116 - to safeguard me from myself.

2 am now ... lots to ponder and fix. off to bed for a short bit then back at it fresh in the a.m.

thanks again for all your help.

[SputnikOC3d]

@engikeneer

Thank you sir. I will see about trying to update flash the 1LC in the am.

Ive been pouring over github issues on superslicer to try and track this down - its a common issue. To protect me from myself - prusa / super slicer has built in code generation that if it doesnt see M190 / M104 in a start.g routine - its going to produce a sequence of heater starts and M116 waits to make sure "safety" happens.

SuperMerrill indicates in a issue on git that theres an option to supress auto generated gcode, but i cant locate it anywhere in the application.

Another hack is to add a phantom useless M104 / M190 set of commands and that actually does work [ i tested ] SuperSlicer does not append the offending G10 P0 S215 and M116.

fun times - switching over to M568 has done my head in on this new voron for the last 3 days tracking this down to cause and solution.

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

To protect me from myself - prusa / super slicer has built in code generation that if it doesnt see M190 / M104

; PrusaSlicer (RepRapflavor - no temps) generates the following code
;M107                           ; fan off (should be M106 S0)
;M98 P"print_begin.g"           ; invokes my code
;G21                            ; set units to millimeters
;G90                            ; absolute XYZ moves
;M83                            ; relative E moves

This is what Prusa 2.3.3 generates for me. Nothing there that causes any problems.

Frederick

[SputnikOC3d]

@fcwilt

https://github.com/prusa3d/PrusaSlicer/issues/6726

theres 25 other posted issue across superslicer git issue forum and prusa slicer ive read nearly 1000 posts in threads on the issue.

Both slicers will add G10 / M116 or G10 P0 [ prusa slicer ] / M116 [ sslicer ]

Here the dev of superslicer indicates you can turn the autogenerated gcode behavior off - but I cant seem to sort out how

https://github.com/supermerill/SuperSlicer/issues/645

broncosis created this issue in prusa3d/PrusaSlicer

closed Start gcode not the real start Gcode #6726

Tinchus2009 created this issue in supermerill/SuperSlicer

closed Bug in start gcode #645

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt

https://github.com/prusa3d/PrusaSlicer/issues/6726

theres 25 other posted issue across superslicer git issue forum and prusa slicer ive read nearly 1000 posts in threads on the issue.

Both slicers will add G10 / M116 or G10 P0 [ prusa slicer ] / M116 [ sslicer ]

Here the dev of superslicer indicates you can turn the autogenerated gcode behavior off - but I cant seem to sort out how

https://github.com/supermerill/SuperSlicer/issues/645

Here is the start code from my install of Prusa 2.3.3.

This is with extruder/bed temps set to some typical values:

M107
M190 S60 ; set bed temperature and wait for it to be reached
G10 S200 ; set temperature
M98 P"print_begin.g"
G10 S200 ; set temperature
M116 ; wait for temperature to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0```

This is with extruder/bed temps set to zero:

M107
M98 P"print_begin.g"
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0

As you can clearly see you only get the G10/M116 commands when extruder/bed temps are set.

Perhaps this behavior is only true for version 2.3.3 - but that is the version I have.

Frederick

[SputnikOC3d]

@fcwilt

with temps set in slicer 2.3.3

M73 P0 R65
M107
G10 S215 ; set temperature
;TYPE:Custom
;==========================================
;Start GCode DasVoron2.4 - as of 8-30-2021
;Print Area is X10 Y10 to X285 Y285
;==========================================

G21												; set units to millimeters
G90												; use absolute positioning
M83												; relative extrusion mode
M140 S65				; set bed H0 temp
T0												; set Tool 0 to proper tool to get this started
M568 P0 R175 S215 A1	; Sets Tool0 /Nozz/ 1st layer Temp / Standby Temps | Sets Tool0 to Standby
M561											; Disable ANY and ALL Mesh Bed Level Compensation
G28												; home X / Y / Z  w/out mesh bed level
G29 S1 P"/sys/heightmap.csv"					; Load and use latest heightmap for Mesh Bed Compensation | heightmap.csv is Default/latest 
G92 E0.0										; reset extruder distance position
G1 X5 Y5 Z20 F5000								; go to Steve's Dribble Zone and wait
M190 S65				; wait for bed temp
M116 H0 S12										; RRF3 - Waits for H0/Bed to get within 12*C | S5 Param | of Set Temp Above
M568 P0 S215 A2			; Sets Tool0  /Nozz/  | S - to 1st layer Temp | A-Sets Tool0 to Active /0-1-2/ 
M116 P0 H1										; Waits for Tool0 / H1 Heater 1  Nozz  to get to get to Print temps in M568 above
G1 Z0.24 F3000					; drop to 0.24 print height
G1 X5 Y5 F3000									; move to purge strip start position
G1 E10.0 F140									; puddle from Tilley Test
G1 Y60.0 E9.0 F1000.0							; intro line 1 from Tilley Test
G1 Y100.0 E12.5 F1000.0							; intro line 2 from Tilley Test
G92 E0.0										; reset extruder distance position
G10 S215 ; set temperature
M116 ; wait for temperature to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
M572 D0 S0.06



G1 F2400.000
G1 X139.381 Y130.088 E0.04073
G1 X140.090 Y129.928 E0.02459
G1 X140.820 Y129.869 E0.02478
G1 X159.131 Y129.869 E0.61939
G1 X160.056 Y129.953 E0.03144
G1 X160.957 Y130.202 E0.03163
G1 X161.800 Y130.608 E0.03163
G1 X162.551 Y131.154 E0.03144

without temps set / using custom start.g code from before

M73 P0 R65
M107
;TYPE:Custom
;==========================================
;Start GCode DasVoron2.4 - as of 8-30-2021
;Print Area is X10 Y10 to X285 Y285
;==========================================

G21												; set units to millimeters
G90												; use absolute positioning
M83												; relative extrusion mode
M140 S0				; set bed H0 temp
T0												; set Tool 0 to proper tool to get this started
M568 P0 R175 S0 A1	; Sets Tool0 /Nozz/ 1st layer Temp / Standby Temps | Sets Tool0 to Standby
M561											; Disable ANY and ALL Mesh Bed Level Compensation
G28												; home X / Y / Z  w/out mesh bed level
G29 S1 P"/sys/heightmap.csv"					; Load and use latest heightmap for Mesh Bed Compensation | heightmap.csv is Default/latest 
G92 E0.0										; reset extruder distance position
G1 X5 Y5 Z20 F5000								; go to Steve's Dribble Zone and wait
M190 S0				; wait for bed temp
M116 H0 S12										; RRF3 - Waits for H0/Bed to get within 12*C | S5 Param | of Set Temp Above
M568 P0 S0 A2			; Sets Tool0  /Nozz/  | S - to 1st layer Temp | A-Sets Tool0 to Active /0-1-2/ 
M116 P0 H1										; Waits for Tool0 / H1 Heater 1  Nozz  to get to get to Print temps in M568 above
G1 Z0.24 F3000					; drop to 0.24 print height
G1 X5 Y5 F3000									; move to purge strip start position
G1 E10.0 F140									; puddle from Tilley Test
G1 Y60.0 E9.0 F1000.0							; intro line 1 from Tilley Test
G1 Y100.0 E12.5 F1000.0							; intro line 2 from Tilley Test
G92 E0.0										; reset extruder distance position
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
M572 D0 S0.06
;LAYER_CHANGE
;Z:0.24
;HEIGHT:0.24
M73 P0 R64
G1 Z0.240 F12000.000
G10 ; retract
G1 X138.275 Y130.564
G11 ; unretract
;TYPE:Skirt
;WIDTH:0.42
G1 F2400.000
G1 X139.381 Y130.088 E0.04073
G1 X140.090 Y129.928 E0.02459
G1 X140.820 Y129.869 E0.02478
G1 X159.131 Y129.869 E0.61939
G1 X160.056 Y129.953 E0.03144
G1 X160.957 Y130.202 E0.03163
G1 X161.800 Y130.608 E0.03163
G1 X162.551 Y131.154 E0.03144

with zero temps set in filaments / using a print start macro in slicer's custom start.g section
*** of note - it now generate E0.xxxx filament extrusion values. First time I tried it did not - odd

; generated by PrusaSlicer 2.3.3+win64 on 2021-09-04 at 18:18:14 UTC

; 

; external perimeters extrusion width = 0.45mm
; perimeters extrusion width = 0.45mm
; infill extrusion width = 0.45mm
; solid infill extrusion width = 0.45mm
; top infill extrusion width = 0.40mm
; first layer extrusion width = 0.42mm

M73 P0 R64
M107
;TYPE:Custom
M98 P"Print_Start.g"

G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
M703                ; Use / Engage Firmware retraction | Make sure this filament is in Duet w / filament / config..g
;M572 D0 S0.05      ; This should be in filaments / config..g
;LAYER_CHANGE
;Z:0.24
;HEIGHT:0.24
G10 ; retract
G1 Z0.240 F12000.000
G1 X138.275 Y130.564
G11 ; unretract
;TYPE:Skirt
;WIDTH:0.42
G1 F2400.000
G1 X139.381 Y130.088 E0.04162
G1 X140.090 Y129.928 E0.02512
G1 X140.820 Y129.869 E0.02532
G1 X159.131 Y129.869 E0.63285
G1 X160.056 Y129.953 E0.03212
G1 X160.957 Y130.202 E0.03231

So three slices - different approaches .... still odd behaviors

[fcwilt]

@sputnikoc3d

What "flavor" of gcode have you selected in Prusa ?

Frederick

[SputnikOC3d]

@fcwilt

RepRap ... for these examples. reprap / sprinter exhibits same issues tho.

got the error again too

Warning Discarded std reply src=121 RID=4094 exp 206""

Separate issue:

Error: in file macro line 1 M221 Parameter 'D' too high

filament config.g error
M221 S0.94 D121.0 ; set extrusion multiplier

Seems I do not address the E0 toolboard extruder via the 121 prefix. ; super noob

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt

RepRap ... for these examples. reprap / sprinter exhibits same issues tho.

Odd.

got the error again too

Warning Discarded std reply src=121 RID=4094 exp 206""

Error: in file macro line 1 M221 Parameter 'D' too high

Well that should be an easy error to find and fix.

---

How about exporting from Prusa the config bundle with printers and post it here. I will import it into my Prusa install and see if I can find what you are doing that I am not doing which is causing the differences we are seeing.

Frederick

[SputnikOC3d]

@fcwilt

well as much as I appreciate that ... I think Id be wasting your time brother.

Im heading towards your macro methodology. I think long term it will serve me better. Prusa Slicer keeps driving more and more prusa centric interface and stuff into their fork, and Superslicer dev[s] seem agnostic to reprap and lean towards klipper. Being slicer agnostic and having more control over my well being seems prudent. Leaving the slicer to just handle basic slicing and pathing etc and besides Ive been looking closely recently at iDeaMaker. Super Slicer seems pretty nice and familiar as well. The devil I DO know sort of thing.

It seems a small price to pay to merely have to stuff a pair of M codes into the start.g if I still use that - but I think the /macro/Print_Start.g approach is where its at. Id rather spend time ironing out the details of getting that working and porting my filament profiles into that ... Seems like its working that way ... by passing my old way in start.g and using a macro to set all my environment and safeguards myself.

[SputnikOC3d]

@fcwilt my last code example above that uses the M98 P"Print_Start.g" - seems to have worked and generated some proper gcode.

I just need to get a good Print_Start.g macro written

that said - Im trying to get my head round my filaments config.g. So far here's what I think I need to have in each one.

M221 - extrusion multiplier
M207 - retraction / de retraction / speeds and distances
M568 - nozzle print and standby temps
M140 - bed temps
M572 - Pressure Advance

uncertain items
Input shaping settings ? have no idea how that works yet

Global Var's - not sure what needs to be set and where else they will be used.

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt my last code example above that uses the M98 P"Print_Start.g" - seems to have worked and generated some proper gcode.

I just need to get a good Print_Start.g macro written

that said - Im trying to get my head round my filaments config.g. So far here's what I think I need to have in each one.

M221 - extrusion multiplier
M207 - retraction / de retraction / speeds and distances
M568 - nozzle print and standby temps
M140 - bed temps
M572 - Pressure Advance

uncertain items
Input shaping settings ? have no idea how that works yet

Global Var's - not sure what needs to be set and where else they will be used.

Well I think I posted most of my print_begin.g file - didn't I?

And the global variables are something that can be used or not. Nothing special about them. In my case it just allowed me to change certain priming/retract settings as needed by different filaments, in the filament config.g file and later use them in the print_begin.g file.

Frederick