ooze compensation based on heater standby time

[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}'