Guidance for writing a Ramp/Soak/Ramp enclosure heating routine

mckoz

New to conditional gcode, not new to gcode on the CNC side of things, but want to try my hand at using conditional gcode. I'd like to create a routine that:

Ramps up to a specific target temp in enclosure (ptc line 120V/240V heater driven by relay), using a thermocouple daughterboard
Ramp is configurable to either fast as possible or at a particular rate (degrees per minute is most likely)
Has a configurable soak time to bring all surfaces to the same temp, at the end of which, it returns a code to start the print
At the end of the print, it ramps down with a configurable ramp down time to allow normalization of print without warping
Sends an alert by email that the print is ready for deployment (optional, but helpful)

Any suggestions or partial examples or sample code are greatly appreciated. As an FYI, this will be deployed on a Duet Wifi and currently running 3.4.0beta6.

Cheers and thanks in advance, David

cosmowave

@mckoz Do you really need a "heating ramp up" mode? Normally chamber heater aren't very fast...
For the soak time you can use a simple g4 command in your startcode (or start.g). If you want, you can make it adjustable with a variable and link it to e.g. the filament, chambertemp,...

T3P3Tony

@mckoz

setting a temperature and then waiting (M116) which achieve this element (but not necessarily the ramp rate you want in #2)
Fast a possible is what you get normally. So the issue is a configurable ramp rate. There is not a firmware option to set a deg/s ramp rate so you would need to write a loop which increased the temperature set by step. This will not lead to a steady heating rate, but with a chamber heater an a large thermal mass that may not matter.
writing a macro something like the following would be the simplest

;tempramp.g macro
;S = target temperature
;R = rate in degrees/min
echo "heating to:"^{param.S}^"C at "^{param.R}^"C/min"
;assumption chamber heater is heater #1 adjust to match your config
while {heat.heaters[1].current < param.S} & {interruptHeat = 0}
     M141 S{heat.heaters[1].current + param.R}
     G4 S60 ; wait 60 seconds
M140 S{param.S}

then calling it:
M98 P"0:/macros/tempramp.g" S100 R1

This has a significant disadvantage that it will be blocking so you need to wait until it finishes running until you can do other things with the printer. In the future we will have the ability to have multiple gcode streams so they may be a non blocking method. to do this.

Just add another parameter to the example in #3 and G4 dwell for that amount of the time after the end of the while loop.
The same macro as in #2 could be used with a lower temperature to have a ramp down.
This is not an option directly however you could use the network API to query the printer state/look for a variable set at the end of the loop using a third party script.

mckoz

@t3p3tony Thank you for the guidance, I will give the macro a shot. I have written a couple of other macros and had noticed the blocking behavior, but didn't realize that you couldn't get around the single thread. Thanks as well for hitting each numbered point, that's rare in most most cases! Out of curiousity, does the blocking apply when you have multiple boards connected; i.e., could I run an accessory board on a different gcode process?

Is the non-blocking macro on your roadmap already scheduled, or is it on the desired feature list?

Thanks again for your help!
David

T3P3Tony

@mckoz said in Guidance for writing a Ramp/Soak/Ramp enclosure heating routine:

Out of curiousity, does the blocking apply when you have multiple boards connected; i.e., could I run an accessory board on a different gcode process?

This macro is running on the mainboard so it will block UI interactions. There are other channels that you could use (UART) but that's not practical.

Is the non-blocking macro on your roadmap already scheduled, or is it on the desired feature list?

Multiple gcode streams may be in 3.5 but I can't guarantee it.

mckoz

@t3p3tony Understood