ooze compensation based on heater standby time

o_lampe

Hi gents,
I've cobbled together a template for my dual extrusion printer. It has different nozzle sizes and the standby time varies depending on the amount of 'infill' and 'perimeter'. Especially the 0.8mm nozzle for infill oozes a lot (volcano hotend)
It's not tested yet, I ask you to make a sanity and syntax check, before I go into the deep
(don't hold back)

ooze_compensation.txt

; Ooze-compensation based on heater standby time evaluated by 'state.upTime'
; works for dual extrusion and assumes that the standby temps are close or equal to print temps

; config.g specifies global variables
global tool0_primed = false		; tool is 'off'
global tool1_primed = false

global tool0_ooze_temp = 180	; only if current temp is higher than ooze_temp, we will see oozing
global tool1_ooze_temp = 180	

global standby_duration = 0		; only works when there is exactly one tool in standby (mixing tools or >2 tools need different times)

global tool0_ooze_factor = nn.nn		; varies depending on nozzle diameter (maybe add variation later, based on {heat.heaters[#].active - tool#_ooze_temp})
global tool1_ooze_factor = mm.mm

; tfree#.g sets the starting time for standby duration (can we assume it was used before and is on print temp?)
if heat.heaters[#].current is >= global.tool#_ooze_temp
	set global.standby_duration = state.upTime		; this tool will ooze, so let the count begin

; tpre# checks for primed_status
if global.tool#_primed = false
	set global.tool#_primed = true
	; maybe add some priming extrusion here
	
; tpost#.g checks if it was selected before (primed?) then calculates the extra ooze-compensation 
M116 P#		; wait for temp rising to print temp
if global.tool#_primed = true
	; maybe some extra smart calculation based on M307 cooldown time can take place here?
	; simple calculation when standby_temp = print_temp (for shortest tool changes)
	var extra-retraction = (tool#_ooze_factor * (state.upTime - standby_duration))		
	G1 E(extra-retraction)F(tools[#].retraction.unretractSpeed)
	echo "Tool # got Ooze compensation of:"
	echo extra-retraction
	set global.standby_duration = 0

//edit
I've already noted some syntax errors (set global misses everywhere) Will post a new one soon
//edit2
done

shirnschall

@o_lampe If your tool is inactive for a long time I think the extra extrusion will be too large. Have you tried using something like arctan to calculate this instead of (tool#_ooze_factor * (state.upTime - standby_duration)) yet?

o_lampe

@shirnschall
Good point!
Maybe the easiest way is to limit max-compensation. We can assume, the hotend fan is on, so we don't have to fear heatcreep over extended standby-time. What would then be the max ooze volume? Size of the meltchamber inside the nozzle?
Or just catch up all the ooze from a paused tool and weight it? Density of the common filaments is known....

addon for tpost#.g

if extra-retraction > global.tool#_maxcompensation
	G1 E(global.tool#_maxcompensation)F(tools[#].retraction.unretractSpeed)
	echo "Tool # got max compensation"
else
	G1 E(extra-retraction)F(tools[#].retraction.unretractSpeed)
	echo "Tool # got Ooze compensation of:"
	echo extra-retraction
set global.standby_duration = 0

Needs definition of tool#_maxcompensation, too.

shirnschall

@o_lampe I would think (and this is just a guess) the amount of filament oozing out is dependent on multiple different factors. E.g. the nozzle size, the type of filament, the temperature, the standby temperature, the ambient temperature the time it takes for the nozzle to cool down, the pressure inside the system, etc.

For some first tests, I would probably go with either weighing the filament or experiment with some different values and go on from there.

Maybe Poiseuille's Law can be used to calculate the amount of filament oozing out. I am not sure however as (I think) both the pressure and the viscosity of the filament are time/temperature dependent.

o_lampe

@shirnschall
Above all that, there's Bowden tube length and last extrusion speed. Probably that's what you meant with 'pressure'?
I guess, from a math-noob point of view (like me), it would be easier to transscript for others, when we keep the goal in focus: reduce print time, by reducing reheat time and skip the wipe-tower. (*)

*) I can't use SlicerPE's wipe tower, because the nozzles have different sizes.

o_lampe

OK, I found the nerve to test the new toolchange macros and now they produce some reasonable numbers, but also one error.
Always and only the first global variable in config.g throws an error of 'already exists'.

Here are the working T0-macros

;tfree0.g
if heat.heaters[0].current >= global.tool0_ooze_temp
	set global.standby_duration = state.upTime		; this tool will ooze, so let the count begin
	echo "Countdown for T0 has started"

;tpre0.g
if global.tool0_primed = false
	set global.tool0_primed = true

;tpost0.g
M116 P0
if global.tool0_primed = true && heat.heaters[1].current >= global.tool0_ooze_temp     ; watch out! heat.heater numbers are not the same as toolnumbers (bed heater is heater[0])
	var extra_retraction = global.tool0_ooze_factor * (state.upTime - global.standby_duration)		
	if var.extra_retraction > global.tool0_maxcomp
		;G1 E{global.tool0_maxcomp}F{tools[0].retraction.unretractSpeed}
		echo "Tool 0 got max compensation"
	else
		;G1 E{var.extra_retraction}F{tools[0].retraction.unretractSpeed}
		echo "Tool 0 got Ooze compensation of:"
		echo var.extra_retraction
	set global.standby_duration = 0

There's also an issue with setting T0 as active tool in config.g. I tried to put the globals before and after T0 but running M98 P"config.g" ended up in an neverending loop.
I have to boot up and send T0 from DWC to activate it.

o_lampe

@chrishamm
I simulated a dual extrusion file with the new toolchange macros and was surprised, not to see any 'echos' from the macros.
Does the simulation actually run through those at all?
If not, what if we had some G4 and other time consuming commands in there?
The simulation result would be way off then. Not to mention M116 heatup times during tool changes. I admit, they are difficult to simulate.

If I want to make an offer for a customer and precalculate 'machine time' , such simulation is my ruin....

OwenD

@o_lampe

If you run M98 P"config.g" then you will get a warning that global(s) exist because there were indeed initialised when you originally booted.

There's also an issue with setting T0 as active tool in config.g. I tried to put the globals before and after T0 but running M98 P"config.g" ended up in an neverending loop.
I have to boot up and send T0 from DWC to activate it.

Selecting or deselecting a tool without using the "P0" parameter will cause your tpre and tpost macros to run during the execution of config.g

o_lampe

@owend
Thanks Owen, the T0 P0 tip was indeed helpful. It also allowed me to switch 'heater2' from off to standby status, without going through the macros.

I tried to check the globals status in the object model, but couldn't find them. Aren't they listed somewhere?
Calling them all with 'echo global......' is not the best way IMHO.

OwenD

@o_lampe
You can't really check for the existence of a variable.
The null object in the object model doesn't support that usage.
You just have to define them once the use SET thereafter to modify them.
Trying to define them again will give a console error but no other ill effects apart from any value you used in the second attempt (probably) won't be applied.

dc42

@owend said in ooze compensation based on heater standby time:

You can't really check for the existence of a variable.

You can't in 3.3beta2, but you can in the latest source code, using the new 'exists' function.

OwenD

@dc42 said in ooze compensation based on heater standby time:

@owend said in ooze compensation based on heater standby time:

You can't really check for the existence of a variable.

You can't in 3.3beta2, but you can in the latest source code, using the new 'exists' function.

Awesome.
Is there a binary for that, or would I have to compile from source?

Phaedrux

@owend In case DC42 doesn't reply due to time zone, and I'm not sure, but you could try the latest builds from the mini5 testing thread to see if it's present in that build.

https://www.dropbox.com/sh/qlucwfda9257p7u/AABoJogMNT-9P0kefE2W_0bxa?dl=0

o_lampe

In the meantime I tested the macros a bit more and had to adjust the math. Now every tool has it's own ooze-countdown.
ooze_compensation.txt

It also looks like, there's no math allowed in 'echo {expression}'?
Also I have to add a local variable and calculate things before using the result in 'G1 E{expression}'