ref_temp or current_temp is out of range
Closed this issue · 41 comments
I am looking over the macro but Im unsure what the issue is.
I get these errors:
Error evaluating 'gcode_macro _FDC:gcode': gcode.CommandError: ref_temp or current_temp is out of range 26.7, 29.1
Maybe you have an idea what I have done wrong?
Cheers!
ref_temp is the klipper z_thermal module, it is set when you home z, according to your sensor temp
out of range mean the temp is below what your captured, so you need to heat it up a bit
is it oke to manually lower the variable_temp_min to just below my ambient room temp?
I could manually copy a bed mesh with that temp between the default and the first one captured?
I heated up a bit and now I get this:
Invalid syntax 'BED_MESH_PROFILE TILT_AND_LOAD=37.9 CURRENT_TEMP=37.9 REF_TEMP=35.9 stepper_z=-0.01317884326415858 stepper_z1=-0.01716027855020011 stepper_z2=-0.026264791489262224'
It's also not loading a bed mesh, but that might be due to the above message?
is it oke to manually lower the
variable_temp_minto just below my ambient room temp?I could manually copy a bed mesh with that temp between the default and the first one captured?
Nope
I heated up a bit and now I get this:
Invalid syntax 'BED_MESH_PROFILE TILT_AND_LOAD=37.9 CURRENT_TEMP=37.9 REF_TEMP=35.9 stepper_z=-0.01317884326415858 stepper_z1=-0.01716027855020011 stepper_z2=-0.026264791489262224'It's also not loading a bed mesh, but that might be due to the above message?
You didn't do step 3.5
This one?
Only if applicable (if you set TRAM_EVERYTIME to True) you will need to override the bed_mesh.py file.
I didn't realize I had to set that to true for this to work, I took that for some special use case.
I'm sorry I am unsure how to proceed.
I backed up bed_mesh.py and replaced it with the FDC version.
I can't find TRAM_EVERYTIME variable, where is it set? Does it default to True and do I only need to set it to False on a quad Z printer?
Assuming its on, I should add this:
z_positions:
0,0
150,300
300,0
But where? In the [bed_mesh] section?
I ask because that setting happens to carry the same name as in the [z_tilt] section of my vcore config.
Thanks for all the help!
This one?
Only if applicable (if you set TRAM_EVERYTIME to True) you will need to override the bed_mesh.py file.I didn't realize I had to set that to true for this to work, I took that for some special use case.
It's in the measure script, you should have seen it when you modified the python vars
But where? In the
[bed_mesh]section?
Yes
Klipper throws an error that z_tilt is not a supported option for bed_mesh.
Klipper throws an error that
z_tiltis not a supported option forbed_mesh.
It means it didn't load the new bed mesh module...did you restart?
Yes, I did, a Pi reboot just in case. I'll retrace my steps and recheck to be sure its all as it should be.
Ive got another issue I need to fix first though, it stopped homing. It does X and then throws an error and stops.
Show me your [bed_mesh]
This is in printer.cfg
[bed_mesh]
speed: 500
horizontal_move_z: 3
mesh_min: 30,30
mesh_max:270,270
probe_count: 7,7
fade_start: 0
fade_end: 0
mesh_pps: 2,2
algorithm: bicubic
bicubic_tension: .2
z_positions:
0,0
150,300
300,0
And this is in RatOS/printers/v-core-3/300.cfg
[bed_mesh]
horizontal_move_z: 5
mesh_min: 20,20
mesh_max:265,260
probe_count: 7,7
fade_start: 1.0
fade_end: 10.0
mesh_pps: 2,2
algorithm: bicubic
bicubic_tension: .2
[z_tilt]
z_positions:
0,0
150,300
300,0
ps. it actually loaded a bed mesh default so with the z_positions in bed_mesh, it did load the new bed_mesh.py I think.
Don't know what to tell you...
Can you screenshot the actual error?
I reverted bed_mesh.py, commented out the bed_mesh section in printer.cfg and homing works again.
I put bed_mesh.py back in place, uncomment bed_mesh without the mesh_min and mesh_max so that it uses the ratOS 300.cfg. The errors remain:
10:35 Must home axis first: 54.997 0.000 14.969 [0.000]
10:35 Must home axis first: 54.997 0.000 14.969 [0.000]
10:35 G28
I reverted
bed_mesh.py, commented out thebed_meshsection in printer.cfg and homing works again.I put
bed_mesh.pyback in place, uncommentbed_meshwithout themesh_minandmesh_maxso that it uses the ratOS 300.cfg. The errors remain:10:35 Must home axis first: 54.997 0.000 14.969 [0.000] 10:35 Must home axis first: 54.997 0.000 14.969 [0.000] 10:35 G28
This I don't know about, doesn't seems related to fdc
I meant the z_tilt error you have
I had to scroll back for that and I made a mistake in my post (sorry!). That wasn't about z_tilt, it was z_positions not being supported. A reboot this morning solved that after putting the correct bed_mesh.py in place.
Sorry about that ...
Since that is working, I now get that homing error. I think it must be related because when I revert the bed_mesh.py and remove the z_positions from the bed_mesh section, homing works again.
put
mesh_min: 40,40
mesh_max:260,260
Nope, printhead just moves on X triggers the endstop switch and throws an error.
horizontal_move_z: 3
horizontal_move_z: 5
Nope. Doesn't help.
I started commenting out all the changes and enable them one at a time.
Its this fade_end: 0. I can leave fade_start. Once fade_end was commented out it started homing again.
Nope. Doesn't help.
I started commenting out all the changes and enable them one at a time.
Its this
fade_end: 0. I can leavefade_start. Oncefade_endwas commented out it started homing again.
Yep fade_start 0 is not needed, only fade_end 0
My bad. I took the RatOS config, copy/pasted and adjusted both without thinking.
Thanks again! Appreciate your help and patience.
Revert back the min max and horizontal to what you did your measure with
oh boy ... I am completely baffled.
Now its fade_end too that throws the homing error. Settings that worked no longer seem to work.
No idea...sorry
Oke, so please bare with me.
I've been comparing the new against the original bed_mesh.py. I think there are two places where fade is used, in class bed_mesh and in class MoveSplitter. The latter is untouched, but in class bed_mesh there is one line of code added, self.pmgr.initialize().
Doesn't an initialize clear that variable/dict or whatever pmgr is?
Because above that, pmgr is actually filled with config:
# setup persistent storage
self.pmgr = ProfileManager(config, self)
self.save_profile = self.pmgr.save_profile
Either way, with my extremely limited python knowledge that line seems out of place?
Oke, so please bare with me.
I've been comparing the new against the original bed_mesh.py. I think there are two places where fade is used, in
class bed_meshand inclass MoveSplitter. The latter is untouched, but inclass bed_meshthere is one line of code added,self.pmgr.initialize().Doesn't an initialize clear that variable/dict or whatever pmgr is?
Because above that, pmgr is actually filled with config:
# setup persistent storage self.pmgr = ProfileManager(config, self) self.save_profile = self.pmgr.save_profileEither way, with my extremely limited python knowledge that line seems out of place?
You are the first one that reports this error...so it's strange
Having said that, I do see klipper made minor changes to bed_mesh.py that I don't see how they can affect anything but who knows
right?
Try the attached one
bed_mesh.zip
Well look at that, homing is working again 😁 .
It doesn't seem to load a bed mesh though ...
Should it load the default profile after a Klipper restart or would it first load it when starting a print job?
are you on RatOS 2?
I see 2 changes in that file. That initialize() line I referred to is gone and another line has changed, if x_dist < 1. or y_dist < 1 to if x_dist <= 1. or y_dist <= 1.
Well look at that, homing is working again 😁 .
It doesn't seem to load a bed mesh though ...
Should it load the default profile after a Klipper restart or would it first load it when starting a print job?
It does not load bed mash now, you have to load it yourself, that's a klipper change, view the changelog of klipper
Anyway, FDC takes care of that
I was trying to find you discord to see if (and how) you wanted me to share my results, graphs etc :).
and yes, I was literally just marveling over my first layer print haha.
Before FDC they didn't look like that?
Or you just installed it fresh with the new printer?
I've had this printer for a little over a year now but the bowing of the rails (or extrusions, depends how you look at it I guess 😉 ) was giving me fits.
PLA required a cold printer, I had to loosen the rails, fasten them, make a mesh, highten or lower top corners, make a mesh, until I was happy (less than 0.2mm variance), so I could print PLA. A first layer test with little 1 layer slabs in the corners would always have 1 or 2 too close. Most prints it doesn't matter as it usually doesnt cover the entire plate but still ..
For ABS or ASA, I let it soak and simmer in its own heat for hours, make a mesh, loosen rails, bla bla bla. Sometimes I was looking at over 0.4mm variance after printing PLA.
I stopped doing that ... it sucks.
This is the first time I can remember the first layer test has all the little slabs in each corner perfect. I was just joking to someone that they are so beautiful Im going to save them!
I am really hoping this will continue to work as well as it does now .. the printer is soaked, I started a 18h job so tomorrow I'll see if I can make a first layer test when its cooled off.
Many thanks so far. Let me know if you like to see some graphs or other output. I took a new measurement today with almost 90 points. Over 10K of config lines 😋 .
90 points? you have beacon?
If you have before and after pics of layers and top layers that will help
No I meant it took like 90 meshes over the course of that 3 hours.
I'll see what I can do (need to search the trash for old ones).
No I meant it took like 90 meshes over the course of that 3 hours.
That's wild, most people get 25-40
Yeah I noticed that the first time around, but the problem is during a mesh, the gantry rises several degrees; basically it heats up faster than we can take meshes. I cranked up an external heater right away, too.
So what I did now is leave the printer open until the gantry slows down warming up, close the printer, wait for it to stabilize and then turn up the external heater. It reached stable temps before the end of the script so I think this will make it more accurate, what do you think?
The conditions should be exactly the same as you print....otherwise it won't work
Don't worry about missing temp, FDC interpolate the in-between values