How to set heaters temp from prusaslicer in start.g

[achrn]

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

[jay_s_uk]

@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

[deckingman]

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

[jens55]

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!

[deckingman]

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

[jens55]

@deckingman, thank you !

[deckingman]

@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).

[achrn]

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

[Phaedrux]

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

[Sindarius]

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

[deckingman]

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

[achrn]

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

[Alex.cr]

@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!