How to set heaters temp from prusaslicer in start.g
-
Hello,
I want to use the heaters temperatures values set in prusaslicer to heat bed and nozzle in start.g.If somebody know how to do it. I interrested !
Thanks for your help -
start.g runs before the print file starts. Because of this you can't do exactly what you asked but you can do something close.
I created another file called startprint.g. Inside this file I placed most of what would go in my start Gcode in my slicer. I then set up variables in the start code in prusaslicer to set the variables and call startprint.g at the appropriate time.
Startprint.g:
;slicer variables in set start code M207 P0 S{global.varRetractAmt} R0.0 F{global.varRetractSpeed} Z{global.varZhop}; firmware retract defaults M572 D0 S{global.varPressureAdv} ;pressure advance for tool 0 M104 S180 M190 S{global.varBedTemp} G32 ; home and level gantry G10 P0 S{global.varNozzleTemp} R180; M116 ; wait for tool temp M98 P"/macros/print_scripts/nozzle_purge_wipe.g" G01 X325 Y320 Z5 F12000 M98 P"homez.g" ; home Z using the home Z file M291 P"Cycle Start" S1 T30 G29 S1 ; load bed map G1 X175 Y175 Z10 F20000
The start code in prusa slicer (and similar for my cura/simplify3d) looks like this:
G10 P0 S[temperature] R180 M140 S[first_layer_bed_temperature] set global.varPressureAdv = 0.04 set global.varRetractAmt = 0.6 set global.varRetractSpeed = 3600 set global.varZhop = 1.0 set global.varNozzleTemp = [temperature] set global.varBedTemp = [first_layer_bed_temperature] M98 P"startprint.g" ; start code on print
Side note you need to place the G10/M140 or similar commands in your start code for prusaslicer/superslicer or it will try and add them itself and cause all sorts of havoc.
And the last bit of code needed to make this work is in config.g where you delcare the variables.
;presets for slicer variables in start code global varPressureAdv = 0.04 global varRetractAmt = 0.6 global varRetractSpeed = 3600 global varZhop = 1.0 global varNozzleTemp = 240 global varBedTemp = 105
Hope this makes sense!
Edit: spelling
-
@Alex-cr
Amazing job ! Tanks for your help ! I'll try to make a similar code for my config. If I have any difficulties I will contact you in pv. -
@Rodrigue-Richalland I long ago stopped using the start and end codes built into the slicer and instead have a single M98 call to a "pre print" macro similar to @Alex-cr. The main advantage is that it gives much more control over what happens and when. For example, one can pre-heat the bed, then when it reaches a set point, change the set point to the desired print temperature and while it's heating, start heating the hot end, then while that's happening, home all axes. If you get the timings right, you can be ready to print in the time it takes to heat the bed. Essentially one can do things consecutively rather than sequentially.
-
@deckingman said in How to set heaters temp from prusaslicer in start.g:
The main advantage is that it gives much more control over what happens and when. For example, one can pre-heat the bed, then when it reaches a set point, change the set point to the desired print temperature and while it's heating, start heating the hot end, then while that's happening, home all axes.
Why can you not put that in the slicer startup gcode? It's easier to tailor to nozzle and material there (I find) - the slicer has profiles for every material and nozzle size on every printer I have, so any of those things can be simply different. Using a single file on the printer I need to do workarounds with things like macros writing config-override.g so it sets global variables so the printer knows how it is configured next time it powers on, so it does the right preheat and and prime dance.
-
@Alex-cr theres no need to create variables like you have to pass information to a start macro.
You can pass things as parameters from the slicer. e.g.M98 P"start_print.g" A{first_layer_bed_temperature} B"{filament_type}" C{first_layer_temperature} D{nozzle_diameter}
in the start gcode you can then use that information
; When using a macro as custom gcode, do not use G, M, N or T as parameters in a custom 'G' gcode file ; param.A is the first layer bed temperature ; param.B is filament type ; param.c is first layer temperature ; param.D is the nozzle diameter the model was sliced for M190 S{param.A} ; set G28 ; home the printer G32 ; level the gantry G29 S1 ; load the height map M568 P0 S{param.C} A2 ; set hotend Temperature to whatever is set in M116 P0 ; wait for this temperature to be reached
-
@achrn said in How to set heaters temp from prusaslicer in start.g:
@deckingman said in How to set heaters temp from prusaslicer in start.g:
The main advantage is that it gives much more control over what happens and when. For example, one can pre-heat the bed, then when it reaches a set point, change the set point to the desired print temperature and while it's heating, start heating the hot end, then while that's happening, home all axes.
Why can you not put that in the slicer startup gcode? It's easier to tailor to nozzle and material there (I find) - the slicer has profiles for every material and nozzle size on every printer I have, so any of those things can be simply different. Using a single file on the printer I need to do workarounds with things like macros writing config-override.g so it sets global variables so the printer knows how it is configured next time it powers on, so it does the right preheat and and prime dance.
Each to their own but I have found that most slicers do not use conditional gcode. They tend to use the older commands like M109, M190, M140. These are OK to some extend but for my use case inappropriate. For example, I use the nozzle as probe therefore I need to heat it to soften any blobs of plastic that might have formed. But I don't care what the temperature is as long as it's above about 140 deg C or so. But using M109 if the hot end is already heated to a higher temperature, it will wait for it to cool. Whereas I use a while loop to wait for the the temperature to be above 120 so it doesn't have to wait for the nozzle to cool, only to heat if it's cool. Similarly the bed when changing from a higher temperature to a lower temperature. I prefer to do things while it's cooling and only wait at the end. For sure one could do this by calling a number of different macros from the slicer start code but I prefer to wrap everything in a single macro.
I use a naming system for my gcode files which identifies the nozzle size, filament type and speed that it was sliced at.
I do however have different pre-print macros for each filament type so for example "prePrintABS will set different hot end and bed temperatures than say "prePrintPETG". But these macro calls are embedded in the filaments section of the slicer. The advantage for me is that if I want to print the same object using a different filament, all I have to do is edit the M98 in the gcode file to call a different pre-print macro. Personally, I don't use config-override nor do I mess with changing global variable values. To my mind, if one is constantly changing such things, it simply negates the reason for having them.
But each to their own. I have my machine set up so that I can simply turn it on, pick which file I want to print, select it and walk away. I might log into into DWC now and again to check on progress if it's a long print but otherwise I just leave it to "do its thing". So it all works the way I want it. If others want to do things differently, that's fine and I'm not going to argue about it.
-
This is a very interesting discussion - I really appreciate that this came up. I had not realized that all these options/possibilities existed. Thank you everybody for that mini education!
-
@jens55 said in How to set heaters temp from prusaslicer in start.g:
This is a very interesting discussion - I really appreciate that this came up. I had not realized that all these options/possibilities existed. Thank you everybody for that mini education!
If you are interested, my slicer profile for ABS just has a single line which is M98 P"PrePrintABS.g".
That macro looks like this..........
; Pre-print gcode 90 deg bed, 255 hot end using tool 1 ; start by setting the tool temperatures as they will get set to zero at the end of a print M98 P"0:/macros/Set Tool Temperatures.g" ; Set initial temperatures. T0 P0; slect a tool - don't run macros - start with tool 0 M140 S80; start heating bed to 80 but wait for it to reach 75 G4 S2 ; now wait for bed to be at or above 75 ; this works better than using M190 because the bed might already be above 70 so it won't wait for it to cool while sensors.analog[0].lastReading < 75 ; M291 P"Waiting for bed to pre-heat to 75" R"Pre-Print Macro" echo "Bed", sensors.analog[0].lastReading G4 S5 G10 P0 S120:120; start heating hot end to 120 M140 S85; start heating bed to 85 ; set to 85 but wait for it to reach 80 M291 P"Pre Heating Bed and Hot End " R"Pre-Print Macro" S1 T5 G4 S2 ; now wait for hot end to be at or above 120 ; this works better than using M109 because the hot end might already be above 120 so it won't wait for it to cool while sensors.analog[1].lastReading < 120 M291 P"Waiting for bed and hot end to pre-heat" R"Pre-Print Macro" echo "Bed", sensors.analog[0].lastReading echo "Hot end", sensors.analog[1].lastReading G4 S5 ; now wait for bed to be at or above 80 ; this works better than using M190 because the bed might already be above 40 so it won't wait for it to cool while sensors.analog[0].lastReading < 80 M291 P"Waiting for bed and hot end to pre-heat" R"Pre-Print Macro" echo "Bed", sensors.analog[0].lastReading echo "Hot end", sensors.analog[1].lastReading G4 S5 M291 P"Homing all axes" R"Pre-Print" S1 T10 M140 S90; Now start to heat bed to 90 but don't wait M98 P"0:/macros/PrePrintHome.g" ; home all axes (at high temp) M400 ; wait for any moves to finish T1 P0; change to tool 1 which is ABS - this should change it's temperature but not run any macros G1 X{global.left} U{global.left} Y{global.rear} V{global.rear} F12000 M83; M291 P"Waiting for heaters to reach active temperatures" R"Pre-Print Macro" S1 T10 M116 ; wait for all temps including hot end M291 P"Purging nozzle" R"Pre-Print" S1 T5 M98 P"0:/macros/SinglePurge.g" ; run purge M291 P"Wiping nozzle" R"Pre-Print" S1 T5 M98 P"0:/macros/Nozzle wipe" M400 ; wait for any moves to finish (shouldn't be any) M584 P5 ; use P5 to make all visible
The Pre-Print macros for other filaments are just copies of this one but with different temperature settings.
As you can see, it calls other macros which deal with "universal" things like homing, purging and wiping the nozzle.
-
@deckingman, thank you !
-
@jens55 Oh, that's the easy bit! To complicate matters further, I swap between 5 different hot ends - 6 input multi material, 6 input mixing, 4 input mixing, dual input and single input. So my "root" config.g uses M505 to change the .sys path and there are copies of each of these pre-print macros in each .sys folder. But they are slightly different from one configuration to the next. For example, the 6 input multi material config uses tool1 for ABS but I can't use tool 1 on the single input hot end which only has tool 0.
But as far as the sliced gcode files are concerned, they work on any machine configuration because the PrePrint macros reside in the .sys folder(s). So that M98 which calls PrePrintABS, will get redirected to use a different PrePrintABS file depending on the hot end configuration. That is to say, I can print the same gcode file on any hot end without making any changes to that file. And if I want to print it using a different filament, all I have to do is edit that one M98 at the start of the file to use a different "PrePrint" macro (which will be redirected to the correct version for the particular hot end in use).
-
@deckingman said in How to set heaters temp from prusaslicer in start.g:
Each to their own but I have found that most slicers do not use conditional gcode. They tend to use the older commands like M109, M190, M140. These are OK to some extend but for my use case inappropriate.
I don't understand this explanation about conditional gcode - I think that anything that can be in a macro can be written into a gcode file by the slicer, can't it? The slicer doesn't need to be able to parse or execute what it's putting in the sliced file. The Duet interprets conditional (or meta-) gcode in a model file the same as in a macro file, I think. I'm interested if there's something that doesn't work like that.
-
@achrn I use multiple slicers, so I'd rather keep as much as possible custom on the Duet side and as generic as possible on the slicer side so that I don't have to make changes in multiple slicers.
-
I highly recommend going the route @jay_s_uk calls out using parameters when calling macros. Params tend to be safer in the long run because a global variable could unintentionally carry a value you did not mean to carry over like accidentally setting a bad feed rate etc.
The bonus to params is you can always set a default value in your macro to deal with items that are left off or do not need to change often and you can give the param a meaningful name in the macro.
Very simple example
var bedTemp = 60 if exists(param.B) set var.bedTemp = param.B
-
@achrn said in How to set heaters temp from prusaslicer in start.g:
@deckingman said in How to set heaters temp from prusaslicer in start.g:
Each to their own but I have found that most slicers do not use conditional gcode. They tend to use the older commands like M109, M190, M140. These are OK to some extend but for my use case inappropriate.
I don't understand this explanation about conditional gcode - I think that anything that can be in a macro can be written into a gcode file by the slicer, can't it? The slicer doesn't need to be able to parse or execute what it's putting in the sliced file. The Duet interprets conditional (or meta-) gcode in a model file the same as in a macro file, I think. I'm interested if there's something that doesn't work like that.
You do what you want pal. I merely stated what I do and why I do it. The most important thing for me is that I can use any sliced gcode file with any multi tool hot end configuration (as long as the nozzle size is the same) without changing the file itself. And if I want to print the same file with a different filament, I don't need to re-slice it. If you want to do things differently, that's fine - there is no right or wrong in any of this. I know you just like to argue, but I'm really not going to take your bait this time.
-
@deckingman said in How to set heaters temp from prusaslicer in start.g:
@achrn said in How to set heaters temp from prusaslicer in start.g:
@deckingman said in How to set heaters temp from prusaslicer in start.g:
Each to their own but I have found that most slicers do not use conditional gcode. They tend to use the older commands like M109, M190, M140. These are OK to some extend but for my use case inappropriate.
I don't understand this explanation about conditional gcode - I think that anything that can be in a macro can be written into a gcode file by the slicer, can't it? The slicer doesn't need to be able to parse or execute what it's putting in the sliced file. The Duet interprets conditional (or meta-) gcode in a model file the same as in a macro file, I think. I'm interested if there's something that doesn't work like that.
You do what you want pal. I merely stated what I do and why I do it.
It's the why you do it that I'm interested in, because if I've 'missed a trick' about what can or cannot be in macro files or gcode job files, or if there's some facility that is easier with a particular approach, then I'd like to understand it.
If the why is only whim or preference, I've obviously got no objection to how you do anything, but if the why is for some reason that I could benefit from I'd like to know what it is.
Phraedux highlights using multiple slicers, which is valid but not relevant to me (because I prefer to be familiar with only one), but I do use conditional gcode quite frequently, so I'm interested in that.
I'm genuinely sorry that asking you why you adopt a particular approach has annoyed you, it certainly wasn't intended.
-
@jay_s_uk said in How to set heaters temp from prusaslicer in start.g:
@Alex-cr theres no need to create variables like you have to pass information to a start macro.
You can pass things as parameters from the slicer. e.g.Yes that's another good idea!
-