I am having trouble with multiplying a variable. There seems to be an issue with floating point and string charachters, but I don't see any. The very first temp change breaks the code.,
#floating point variable issue
narrow sleet
summer swan
I think you can set heater temperatures to non-integer values if you use something like SET_HEATER_TEMPERATURE HEATER=extruder TARGET=123.5 but not if you do it with "regular gcode" (M104/109/140/190). I very much doubt you need that kind of precision, you can just cast it to an integer instead.
narrow sleet
I don't I just want to multiply it by .75 !! so simple, yet this has driven me mad. tried everything, but I keep getting errors.
as far as I have read the set command inside the macro creates a temporary var. in this case of type float.
summer swan
yes, but once you use it, it will look something like M109 S123.4 which doesn't work (only integers allowed). If you make it an integer instead (replace float with int at the end of the expression) it will be a plain integer without decimals which should work. Or maybe if you do SET_HEATER_TEMPERATURE HEATER=extruder TARGET={EXTRUDER_TEMP} instead of M109 it might also work.
At least from what I just tested in the gcode console, M109 with any decimals just gets ignored, while SET_HEATER_TEMPERATURE seems to work well for non-integer temperature values.
narrow sleet
oh ok, I hear you barking now! Thank you.
summer swan
also those math expressions are a bit wonky. It's Jinja (I think jinja2) if you want to look further into how those work, not really a "klipper thing".
and stuff called "filters" (those |this|that things)
narrow sleet
one more question, so it's heating up on the G28 call, but I cant for the life of me find where that macro is
summer swan
G28 is a built in klipper command, but it itself shouldn't do anything heating related. Though it can be "overridden" with a user macro that could do whatever.
Also it's not too uncommon to have gcode for the z probe that is run when the probe is activated, like with a TAP to make sure nozzle is a reasonable temperature when poking at the bed.
(I have that under activate_gcode in the [probe] section)
narrow sleet
It must be in klicky macros some place, but I cannot for the life of me figure it out. im just letting it probe hot, when it fails il have a replacement ready. im tired of the complicated klicky setup.
thank you for your help!
summer swan
It must be in klicky macros some place, but I cannot for the life of me figure i...
I'd just search through the whole set of config files for anything M104 or M140. If you have a lot of them, you can get the whole complete config (including any macros) by downloading a klippy.log file from the web ui, which will put everything in one place. Might still not be obvious exactly where it comes from but at least it should provide some clues to look for as to what macros might be messing with hotend temperatures.
narrow sleet
yeah I did that, let me try again
failed. I will purge the klippy log, then examine on my next print.
summer swan
if you restart the printer it will roll over the log, and then when you download it it will just be the "startup stuff" (including all config) and none of the "printing stuff"
narrow sleet
chased my tail all day
it came from orca slicer. I thought I got rid of the startup code!
M190 S[bed_temperature_initial_layer_single]
M109 S[nozzle_temperature_initial_layer]
PRINT_START EXTRUDER_TEMP=[nozzle_temperature_initial_layer] BED_TEMP=[bed_temperature_initial_layer_single]
argggggg
thank you for your help!!!
im done with Orca! back on Prusa. I just can't get used to the workflow
that's better. Thanks for your help again!!!
summer swan
i haven't used orcaslicer in a while, but from what I remember they're pretty similar in that regard. And no matter what slicer, you have to make sure the print start gcode matches up with how the printer is setup (and given that there basically is no one "default voron klipper setup", you can never rely on the presets)