I’d like to request some quick feedback on an improvement to the TUNING_TOWER command I’d like to implement.
Many (including myself) get confused with the current syntax, which works well for towers where the parameter changes smoothly, but requires extra calculations, or even a spreadsheet, when using the BAND option. Specifically I’d like easier syntax for printing towers like this one: Smart compact temperature calibration tower by gaaZolee - Thingiverse.
Here’s the current documentation:
TUNING_TOWER COMMAND=<command> PARAMETER=<name> START=<value> FACTOR=<value> [BAND=<value>]: A tool for tuning a parameter on each Z height during a print. The tool will run the given COMMAND with the given PARAMETER assigned to the value using the formula value = start + factor * z_height. If BAND is provided then the adjustment will only be made every BAND millimeters of z height - in that case the formula used is value = start + factor * ((floor(z_height / band) + .5) * band).
I’d like to be able to specify “start at 225C, skip 2mm, then decrease by 5C every 5mm”. I don’t want to have to calculate the factor, or adjust for the .5 in the formula.
I propose adding two arguments:
STEP=<value>. This can be used instead of FACTOR. If specified, the formula used is value = start + step * floor(z_height / band). It would be an error to specify both FACTOR and STEP.
SKIP=<value_mm>. Skips this many millimeters of Z height before starting the tower. Useful for e.g. the base or stand of a tower.
The following simple command can then be used for the above tower. Note the values for the parameters are immediately known to the user, and no calculations are needed:
I like the addition of the SKIP; that’d be useful for this gaaZolee tower, which is my go-to. I just went through this myself to run a temp tower and I do think making it a bit more user-friendly would be nice.
Probably the best way to propose this is to submit a working PR.
particularly the section floor(z_height / band). if the purpose of this is to identify the band that a particular layer belongs to, then the correct implementation should be based on format ceil(x-y/y) instead. otherwise the first band will always be short of 1 layer compared to the other bands, for example a 0.2 layer height model will only have 4 layers in the first band when it should have 5. as long as layer height is a nonzero value (it has to be–layer height zero is technically not a layer), this change is backwards compatible. unless this actually ties into another part of the code which does allow for layer height = 0 for some strange reason, then i guess the floor() method works but it still bugs me.
thoughts? sorry if i should have started another thread.
when dealing with custom STLs and TUNING_TOWER, we often have to look at the slicer preview whereby layer 1 is always a nonzero z_height and in my example table above temperature changes every 1mm should happen on 1.2, 2.2, 3.2, 4.2 and so on, instead of 1.0, 2.0, 3.0 etc which the current implementation using floor() will do.