help with optimizing heater temperature

fcwilt

@jltx said in help with optimizing heater temperature:

@fcwilt Wow, now it's getting ridiculous. I thought you had it. I used the double variable and the original value still passes through, and I tried more than one. I also tried with and without {}. I tried integer and fixed point literal. The numeric expression just does not evaluate it seems. I have used math in other places successfully. There must be something super simple I'm overlooking.

I assume you tried hard-coding the values like S100 or whatever?

Frederick

infiniteloop

@jltx Here's some brain food. Wanted to figure out the persistence of a calculated value when passing this as a parameter to a second macro. You have to create the files "test1" and "test2" (did this in the /sys directory).

test1:

; Test macro with optional parameter B
; calls the macro test2 which requires an S parameter

var temp_1 = 100
if exists(param.B)
	set var.temp_1 = {param.B}
var temp_2 = {var.temp_1 - 10}
M98 P"test2 " ^ S{var.temp_2}

echo var.temp_2

test2:

; Macro test2, requires an S parameter (defaults to 0)

var my_s = 0
if exists(param.S)
	set var.my_s = param.S

echo var.my_s

Call this from the command prompt with
M98 P"test1"
or
M98 P"test1" B<your number here>

Hope this helps.

dc42

@jltx said in help with optimizing heater temperature:

I am trying to optimize my print start times by kicking off some prep work just prior to the bed reaching temperature (the long pole).

I pass the bed temp as param.B and use an expression to subtract 5 degrees. I wait for that to reach the then set final bed temp and nozzle temp without waiting, and kick off bed leveling, etc while those finish.

However, this does not work. It just heats up the bed to full temp every time before anything else. So either the expression does not work here or I don't understand how heater requests are queued by the firmware. Any help? This is 3.6 but behaved the same on 3.5.
; set bed and hotend temps
M190 S{param.B-5} ; set bed up to last 10 degress
M568 P0 R170 S{param.A} ; set nozzle to first layer temp

M140 S{param.B} ; finish bed to first layer temp
T0  ; select tool 0

...

That should work, unless either your tpre0.g or tpost0.g file waits for heating to finish. Do they?

Another trick you can do to speed up hot end heating is to set the hot end standby temperature to the active temperature minus e.g. 50C (low enough to avoid oozing) and switch the heater to standby. Then set the bed temperature and wait for it. When that command completes, probe the bed, then select the tool, which will switch the heater to active.

jltx

@dc42 said in help with optimizing heater temperature:

@jltx said in help with optimizing heater temperature:
I am trying to optimize my print start times by kicking off some prep work just prior to the bed reaching temperature (the long pole).

I pass the bed temp as param.B and use an expression to subtract 5 degrees. I wait for that to reach the then set final bed temp and nozzle temp without waiting, and kick off bed leveling, etc while those finish.

However, this does not work. It just heats up the bed to full temp every time before anything else. So either the expression does not work here or I don't understand how heater requests are queued by the firmware. Any help? This is 3.6 but behaved the same on 3.5.
; set bed and hotend temps
M190 S{param.B-5} ; set bed up to last 10 degress
M568 P0 R170 S{param.A} ; set nozzle to first layer temp

M140 S{param.B} ; finish bed to first layer temp
T0  ; select tool 0

...
That should work, unless either your tpre0.g or tpost0.g file waits for heating to finish. Do they?

My tpost0.g does have M116 P0, but that isn't triggered until the T0 command, correct? the very first M190 should be blocking and wait for the set temperature. Which it does, btw, because the nozzle temp does not change at all until after the bed completes. The problem is the value passed to the M190 is always param.B without offset. Even this mod still passes the full param.B, which seems impossible.

var bed_temp = {param.B}
var start_bed = var.bed_temp - 10.0
M190 S{var.start_bed} ; set bed up to last 10 degress

param.B is passed in from the gcode file thusly:

M98 P"0:/macros/print_scripts/print_start.g" A220 B55

Another trick you can do to speed up hot end heating is to set the hot end standby temperature to the active temperature minus e.g. 50C (low enough to avoid oozing) and switch the heater to standby. Then set the bed temperature and wait for it. When that command completes, probe the bed, then select the tool, which will switch the heater to active.

I will try this but would still like to resolve the expression issue above since I would like to use those reliably in other areas.

jltx

@dc42 ignore. I found the problem: the slicer is emitting its own gcode outside of the start g-code. Sorry for the bother! The expression does work.

fcwilt

@jltx said in help with optimizing heater temperature:

@dc42 ignore. I found the problem: the slicer is emitting its own gcode outside of the start g-code. Sorry for the bother! The expression does work.

Getting a slicer to not generate conflicting code can be a bit tricky.

Some slicers have options to not send temp commands - using 0 values in the slicer config.

Other slicers allow specifying the gcode "flavor" (RepRap, Marlin, etc). You can using a simple object and look at the code created for each flavor to find the best.

If you are using the feature that allows the slicer to invoke your own startup code you can ignore any code before yours is invoked, as your code can/will override it.

I have tried all the slicers and managed to find settings the prevented the slicer from generating code that conflicted with my code but it's been so long I cannot recall exactly what the settings are.

Frederick

jltx

@fcwilt Yes, this is a surprising discovery. I have been using PrusaSlicer for years but just switched to Orca. To me this is a serious Orca bug. The slicer should NOT control the machine without consent. There are custom gcode sections for a reason.

For anyone who stumbles on this, Orca looks at your start gcode and if it doesn't see any heater command (because you use a macro, for example) then it injects its own before any of your own gcode is emitted. There is NO WAY to disable directly. You can hack around this by putting M190 S0 and G10 S0 (those are the commands it is looking for, M140 also works) at the start of your start gcode and then it will not emit its own.

fcwilt

@jltx said in help with optimizing heater temperature:

@fcwilt Yes, this is a surprising discovery. I have been using PrusaSlicer for years but just switched to Orca. To me this is a serious Orca bug. The slicer should NOT control the machine without consent. There are custom gcode sections for a reason.

For anyone who stumbles on this, Orca looks at your start gcode and if it doesn't see any heater command (because you use a macro, for example) then it injects its own before any of your own gcode is emitted. There is NO WAY to disable directly. You can hack around this by putting M190 S0 and G10 S0 (those are the commands it is looking for, M140 also works) at the start of your start gcode and then it will not emit its own.

If the code generated by Orca appears before the invocation of your own code it shouldn't matter.

What happens if you specify 0 temp values in Orca?

Frederick

dc42

@jltx said in help with optimizing heater temperature:

For anyone who stumbles on this, Orca looks at your start gcode and if it doesn't see any heater command (because you use a macro, for example) then it injects its own before any of your own gcode is emitted.

This is standard behaviour of all the slicers I have used.

engikeneer

@jltx in my experience you are better to include the M190 etc lines in the Orca start code, but then comment them out. That way it 'thinks' you already have the temperature commands in there as its notnclever enough to spot that theyre commented out, but they won't mess with your macros etc (e.g. accidentally waiting for the temp to reach 0 if you use M190 S0).
At least that's what I do in PrusaSlicer...

Phaedrux

@engikeneer said in help with optimizing heater temperature:

@jltx in my experience you are better to include the M190 etc lines in the Orca start code, but then comment them out. That way it 'thinks' you already have the temperature commands in there as its notnclever enough to spot that theyre commented out, but they won't mess with your macros etc (e.g. accidentally waiting for the temp to reach 0 if you use M190 S0).
At least that's what I do in PrusaSlicer...

Ancient Slicer Wisdom

Same was true in Cura and Slic3r since days yore.

fcwilt

@Phaedrux

While there is nothing wrong with doing that it is not needed, in my experience.

Here is the start code from Cura 5.10.0:

T0
M104 S0
M109 S0
M98 P"print_begin.g"
M82 ;absolute extrusion mode
M82 ;absolute extrusion mode
M98 P"print_extrude_begin.g"
M83 ;relative extrusion mode
M83 ;relative extrusion mode
G1 F1500 E-6.5
;LAYER_COUNT:259
;LAYER:0
M107

Note that the M104 and M109 are harmless as the call to user code follows them and there is no unwanted code that follows the call to the user code.

Here is the start code from Prusa 2.9.2:

M98 P"print_begin.g"
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
M98 P"print_filament_begin.g"
M107

Again there is no unwanted code that follows the calls to user code.

Not big deal, just thought I would mention it.

Frederick