Topics

Rat Rig Community [Unofficial]•2y ago

Homing not working consistently

Been having some issues where the printer isn't homing properly. I have a 500 that I've got setup as sensorless homing, and it has been working fine until today. These errors are not consistent so it's been a little hard to trouble shoot. For example, I press the home all in Mainsail and X will move to the home. In the console it shows the run and hold current, and right after that it gives the error "Must home axis first: 290.000 250.000 14.999 [0.000]" and stops with the print head around X0. If I type in MAYBE_HOME in the console, it shows that X is homed and is homing Y Z, and will start moving towards Y with the print head still at X0. Without making any changes to the configuration, I can restart the printer and it may work fine the next time I home it, or it may home X properly, move to the center of the bed, then give me the same "must home axis first" error with Y staying around Y0.
Any help here?

115 Replies

miklschmidt•2y ago

Please post a klippy log, downloaded right after it fails

xenial-blackOP•2y ago

klippy_10.log

xenial-blackOP•2y ago

So for testing, I clicked Set Center Kinematic Position and so far, it hasn't given me any more errors even after a reboot. Ok, I take that back, it did happen again after I made a change in my config to put some of my macro's back in. But clicked the same button, and it's working again. Yeah so here's what I'm kinda seeing. I have chamber temp turned on, and the first homing will fail unless I click Set Center, it will home properly, until the chamber is heated, then it tries to home again, and this one will fail. Any ideas on this?

miklschmidt•2y ago

sorry i forgot about this. My only suggestion is to try a stock setup, and see if it fails there too You've got quite a lot of custom stuff going on Ah, i see it now

[stepper_x]
step_pin = x_step_pin
dir_pin = x_dir_pin
enable_pin = !x_enable_pin
rotation_distance = 40
microsteps = 64
homing_speed = 20
homing_retract_dist = 0
position_max = 500
position_endstop = -1
endstop_pin = toolboard:x_endstop_pin
position_min = -1

[stepper_x]
step_pin = x_step_pin
dir_pin = x_dir_pin
enable_pin = !x_enable_pin
rotation_distance = 40
microsteps = 64
homing_speed = 20
homing_retract_dist = 0
position_max = 500
position_endstop = -1
endstop_pin = toolboard:x_endstop_pin
position_min = -1

Notice the endstop pin. You're including the physical-endstop toolboard config. Don't do that

xenial-blackOP•2y ago

Let me look and see what's going on with that. Ahh, I see where it's at in the printer.cfg that I can turn off the endstop pin. Didn't realize that I forgot that line when I moved over to sensorless homing. When this print is finished, I will restart and see if that works. So it's looks like it's still happening. I will work here in a bit to remove most of my customizations and test it from a cleaner state. And it's still random. Sometimes it gives me the error after X homes and stops it from moving back to the center of Y, sometimes X works properly, moves to the center of the bed then homes Y, and stops before it moves back to the center of the bed to home Z. Then sometimes it works 100% correct. lol

Helge Keck•2y ago

just dropping it here to rule it out, if you use sensorless homing you are not supposed to connect anything to the old endstop ports, this can cause all sort of problems

xenial-blackOP•2y ago

klippy_13.log

xenial-blackOP•2y ago

I just got it to do it again. I can disconnect the X sensor, it's kind of a left over thing that I never changed.
In this log. Right before I rolled over the log, it homed properly. I then rolled over the log, and it homed X properly, then errored when Y homed before it moved it to the center of Y. This is also with the configs put back as much as I could. I am using canbus and that's the only changes I made to the ebb42 and octopus board configs. I couldn't figure out how to override the baud: and serial: sections of the [mcu] section from printer.cfg Well correction. I did add 4pin fan and removed the temperature sensor section of the toolboard. But everything else is the same. I did go ahead and unplug the physical endstop from the tool board, and still did the same thing.

Helge Keck•2y ago

i would do what mikl suggested, starting with a clean isntallation without all the additions

xenial-blackOP•2y ago

I removed all of the configurations from printer.cfg except the ones that are needed for canbus.

blacksmithforlife•2y ago

CAN isn't supported in ratos https://os.ratrig.com/blog/no-you-dont-want-to-use-can

xenial-blackOP•2y ago

It's not supported from the default configs. Doesn't mean it won't work.

blacksmithforlife•2y ago

correct

xenial-blackOP•2y ago

But this issue is not connected to canbus. Canbus isn't needed for sensorless homing.

Helge Keck•2y ago

i have the printer.cfg open here, its full of unneeded configurations this is not a default config

xenial-blackOP•2y ago

You're talking about the overrides at the bottom? Or other macros?

Helge Keck•2y ago

we suggested that you start with a new config, thats not a new config

xenial-blackOP•2y ago

Ok. Stand by.

Helge Keck•2y ago

like a new ratos installation, you can use another SD card if you want

xenial-blackOP•2y ago

Ok. So I went back to completely stock, and started adding sections of the configuration I had before and testing to see if the problem would come back. Everything worked fine until I added z_thermal_adjust, then the error came back.

miklschmidt•2y ago

Why in the world are you using sensorless homing on X if you have a physical endstop connected?

miklschmidt•2y ago

https://github.com/Klipper3d/klipper/blob/master/klippy/extras/z_thermal_adjust.py#L30 I don't think z_thermal_adjust works with sensorless homing, or any homing_override in general.

GitHub

klipper/z_thermal_adjust.py at master · Klipper3d/klipper

Klipper is a 3d-printer firmware. Contribute to Klipper3d/klipper development by creating an account on GitHub.

miklschmidt•2y ago

I also think it's completely unnecessary and causes more harm than good if you're using a proper probe Best i can do is tell you to run SET_Z_THERMAL_ADJUST ENABLE=0 before homing and SET_Z_THERMAL_ADJUST ENABLE=1 after homing. That should stop it from trying to correct Z movement in the middle of a homing move. It's actually a pretty huge bug in that code that it tries to move Z when z is not homed.

xenial-blackOP•2y ago

Mainly I was having issues on Y homing with a physical endstop and just went full hammer and did both when I was trying to fix the y homing issue I was having. I must have missed where z thermal adjust can be turned off. Let me test that.

miklschmidt•2y ago

Yeah sensorless homing is a way to get more problems, not less problems 🙂

xenial-blackOP•2y ago

Well, it did solve my y homing issues. lol

sensitive-blue•2y ago

Anyway it seems there is something buggy in the homing routines. I have a nearly stock VCore 3.1 / 300 - config and get a similar error sometimes. The story so far: I recently changed completely to RatOS 2 and while also servicing the mechanics and playing around, i found that (reproducable) bug. No sensorless homing is used and also no "strange" stuff like thermal adjustments and so on (just Helge Keck´s PAM is used)... Ok, i home all axes, do a bed tilt and afterwards i run a bed mesh (just clicking on "Heightmap"-"calibrate" and confirming "default". When i change to the dashboard, switch off the motors (mesh is still visible under "Heightmap" afterwards) and try to home all axes again, it homes "x". When it comes to move the toolhead again, it throws an error: "Must home axis first: 34.998 272.000 14.975 [0.000]".... Now, when i clear the mesh and try again, everything works perfectly. Imho the homing routine should ignore any meshes.

miklschmidt•2y ago

I have observed no problems during homing on any of my machines, all of them running 2.0. Motors off should reset all homing state, and a G28 always homes all axes, so i can't really see how this is possible. Could you post your printer.cfg?

sensitive-blue•2y ago

Confirmed, "Motors off" resets the homing state. Just the (formerly "manually" generated) default-mesh (even though it never gets loaded somewhere) doesn´t get cleared with "motors off" and as long, as it´s available in "Heightmap", it throws the error 😉

sensitive-blue•2y ago

printer3.cfg

sensitive-blue•2y ago

The .cfg is still "under construction" xD

miklschmidt•2y ago

So if you clear your bed mesh, do several G28 -> M83 -> G28 -> M83 there are no issues? Actually, instead of G28 -> M83 -> G28 -> M83 try doing what you did before to reproduce, but calibrate the bed_mesh with an actual name other than default. If that still throws an error, try clearing the bed mesh (BED_MESH_CLEAR) after turning the motors off, before homing again. That will give me something to go on It does seem as if there are some klipper internals that aren't being set correctly after the inital z_hop. I'm just not sure why yet.

sensitive-blue•2y ago

M83?? 🤔 Think, you meant M84 ... 😂 But anyway: Yepp, if the mesh gets cleared (did it via the button on the "Heightmap"-page) before clicking "Home Axes", everything is fine 🙂 Have to try this evening with a different mesh name. Will tell you the results then 🙂 I think to remember, with one of the last updates (since Feb) , something got changed with the automatic mesh loading in klipper. Maybe it has to do something with that ... That Bug is not a big deal for me, i was just curious, how to reproduce it 😉

miklschmidt•2y ago

M83?? 🤔 Think, you meant M84 .

Gah, yes ofcourse.

something got changed with the automatic mesh loading in klipper. Maybe it has to do something with that

I don't think so, z_thermal_adjust causes the same issue. It's probably an issue with the [ratos_homing] module, it's very simple and is just a combination of safe_z_home and homing_override, so i'm not entirely sure yet why it's not working. My theory is that marking z unhomed after the inital Z hop, causes some internal klipper state to be only partially correct. Even though that's exactly what safe_z_home does.. 🤷‍♂️

sensitive-blue•2y ago

Did that [ratos_homing] module change from RatOS 1.2 to 2.0 ? I still have a 2nd VCore 3.1 running 1.2 (with klipper up to date...) ... So this evening, when i do the tests, i also will compare to the "old" system, if there´s some different behaviour. (Maybe every bit of information helps 🙂 )

miklschmidt•2y ago

It wasn't a thing in 1.2. It was required in 2.0 because of the stowable probes, it also made handling of sensorless homing easier. Also allows for individual homing mechanisms on x and y.

xenial-blackOP•2y ago

Unfortunately the logs are not giving a whole lot of info on what's causing the error, and the error looks exactly like if you typed G0 Y250 in the console with the motors off. It almost seems like when the ratos_homing does it's thing to move the just homed axis back to center, perhaps its issuing a full XYZ move instead of just moving the just homed axis? I do see in the homing.cfg it's only doing a G0 X or G0 Y though.

miklschmidt•2y ago

It almost seems like when the ratos_homing does it's thing to move the just homed axis back to center,

The theory is that the internal state is borked at this point and the printer ends up doing bed_mesh (or thermal_offset) adjustments during that "return to center" move, which fails because Z isn't homed yet. A "full xyz" move wouldn't make any difference. If any of the axes it's trying to move is unhomed, it will fail. Problem (as far as i can tell) lies in klipper trying to move Z on an X or Y move (due to bed mesh or thermal_adjust) without Z being homed.

xenial-blackOP•2y ago

It might be something to do with Z since it hasn't been homed yet, but the printer is saying that the axis is homed after the error. So if it gives me that error after homing X, X is homed, and I can G0 X everywhere as if it worked properly.

miklschmidt•2y ago

I wonder if it's a bug in klipper. Would have to implement a homing routine without [ratos_homing] to test.

xenial-blackOP•2y ago

Ahh, I think I see what you're saying.

miklschmidt•2y ago

Do those moves actually work after it has failed?

xenial-blackOP•2y ago

When it moves X from X0 to X250, it wants to look at the thermal or bedmesh adjustments between x0 and x250, and wants to move Z, but since Z isn't homed it errors.

miklschmidt•2y ago

exactly

xenial-blackOP•2y ago

I will double check again, but if I'm not mistaken it does.

miklschmidt•2y ago

Then my theory is incorrect and i have no idea what's going on 😂 unless that error clears the broken state, in which case another G28 should work without errors.

xenial-blackOP•2y ago

But I do also see where when setting center kinematic position it it places all axis as homed, regardless of what their position is.

miklschmidt•2y ago

Yes, that will set the position (and homing state) of all axes. I need to see if i can reproduce this with v1.2.4 (and if i can reproduce it with v2.0, haven't tried yet)

xenial-blackOP•2y ago

Ok, so I just homed the printer, X worked properly, Y went to the home position then errored. When doing a G1 Y250 F7800 it was still erroring. So you might be correct in that it's trying to reference what ever the Z adjustment is during homing. But I wonder if this is because ratos wants to move the gantry into the center of the bed vs klipper's leaving X where it is, then homing Y.

sensitive-blue•2y ago

That´s, why i also try on RatOS 1.2 later... Same klipper, just without that homing routine from RatOS 2.0 😉

miklschmidt•2y ago

indeed, would be very interesting to know

xenial-blackOP•2y ago

So sitting in the error state from the last home, issuing a G28 the gantry moved a little, and errored again.

miklschmidt•2y ago

But I wonder if this is because ratos wants to move the gantry into the center of the bed vs klipper's leaving X where it is, then homing Y.

That shouldn't matter, it's all klipper. There are native klipper things to do the exact same thing, such as [safe_z_home]. Yep as soon as it got to a point where it needed to adjust Z 🙂 So theory not busted yet

xenial-blackOP•2y ago

I don't think safe_z_home is used until after X & Y is homed.

miklschmidt•2y ago

True, safe_z_home doesn't move X back to center. In any case, we did this with [homing_override] before in 1.2.4 when using sensorless homing. And also it doesn't make any sense, since it works fine the first time. If you have no bed mesh active, g28 works just fine.

xenial-blackOP•2y ago

From what I can remember on an ender 3 that I was running vanilla klipper on, X would home and stay put, then Y would home, then move X & Y to the safe position. But that wouldn't account for moving X & Y into the safe z location.

miklschmidt•2y ago

I know There's no moving back to center without a [homing_override] that explicitly does that. It's quite possible that simply doesn't work. (if a bed_mesh or thermal_adjust is loaded/defined) I would however consider that a major bug in the klipper internals

xenial-blackOP•2y ago

At least as a work around, why not set the z kinematic position at the start of the homing override?

miklschmidt•2y ago

And i will create and issue if that is indeed the case When i looked at the code for bed_mesh, it doesn't check if the Z is homed before correcting Z.

xenial-blackOP•2y ago

Granted, I do think that's a bug in klipper also.

miklschmidt•2y ago

So, it's no wonder it fails.

xenial-blackOP•2y ago

You're talking about bed_mesh in klipper's code?

miklschmidt•2y ago

Because if i do, Z will be homed if homing fails. That is potentially dangerous yes

xenial-blackOP•2y ago

If homing fails, couldn't there be a check and shutdown of klipper if it does?

miklschmidt•2y ago

No, there's no try/catch in gcode :/ I could maybe build it into the python module. It's kind of complicated though.. But i will look into it Honestly i think it should be fixed in klipper

xenial-blackOP•2y ago

What potential failure do you forsee where setting Z as homed and there be a homing failure? I can agree with this.

miklschmidt•2y ago

There's no point in those modules (bed mesh / thermal adjust) to move Z if Z isn't homed. That's a bug.

xenial-blackOP•2y ago

I do agree there.

sensitive-blue•2y ago

Also my thoughts, when i stumbled over this 🙂

xenial-blackOP•2y ago

Where ever you submit the bug, I can go there and post info on it also. I wonder if this might be the reason for the bed mesh needs to be explicitly called in the start print that was changed recently?

miklschmidt•2y ago

Will post it here when i do Might come with a pull request. It looks super easy to fix It's just a simple check, where there already is an inferior one.

sensitive-blue•2y ago

Ouff... Did some tests and have some updates for you.... 1st RatOS 2.0: It makes no difference, which name for the mesh i choose. As long, as a mesh is calibrated, the homing routine throws the error, when it tries to center the x-axis for homing y afterwards. Now the interesting part in RatOS 1.2... Here homing (at 1st look) works as intended, BUT a) it doesn´t try to center the x-axis and therefore it homes y without problems. What´s really interesting: After G28, mesh (also here the name doesn´t matter), M84 and homing just "X"... Now, even if i try to just move the x-axis (which is homed), it throws the same error. Homing Y will work, as long, as i don´t move the (already homed) x-axis. When i clear the mesh, i can home X (all other axes still "off") and move in x, however i want to .... So i guess, the error occurs, when Klipper has a mesh calibrated and tries to compensate any x/y-plane movement in z-direction. In RatOS 2.0´s homing routine the error also wouldn´t have showed up without "centering" the X-axis before homing Y...

xenial-blackOP•2y ago

Here's whats odd that I've seen. Without changing anything, sometimes X would home properly and would error on Y homing, then sometimes it would error when trying to home X. I wish I could point to a Klipper update or something (as I've been printing with the ratos homing for a while without issues), but I did a klipper update and put the z thermal adjust in right about the same time.

miklschmidt•2y ago

All is consistent with my theory. You basically just confirmed it, it is indeed a bug in klipper. exactly

Helge Keck•2y ago

this is a interesting thread

miklschmidt•2y ago

I think we've found a bug It's an easy fix I'll put together a PR But first i need to test the fix 😄 The bug has been there forever. People just normally home everything before moving any axes.

xenial-blackOP•2y ago

Makes sense, I wasn't able to narrow it down for sure.

miklschmidt•2y ago

God dangit i can’t reproduce the bug.

Helge Keck•2y ago

i would make sure you guys are using the same firmware for the board, who knows

miklschmidt•2y ago

G28, BED_MESH_CALIBRATE, M84, G28 X and then G0 X150 works fine Was running 0.11.0-121, upgrading to latest now i'll try turning mesh fade off too I can kill the centering during x/y homing, sensorless homing is just way more reliable that way. And i'm pretty sure it would die when going to the center for homing Z instead. Omg I updated. Now when i do G28X after calibrating the bed mesh, my pi dies.. 😂 What the fuck is going on

Helge Keck•2y ago

🍿

miklschmidt•2y ago

Just gone from the network.

Helge Keck•2y ago

i have this once a month

miklschmidt•2y ago

No description

Helge Keck•2y ago

happens only with 2.4ghz networks on my side

miklschmidt•2y ago

This has never happened to me before

Helge Keck•2y ago

mostly after i shut down the pi, doesnt happn if i jsut cut the power all my printers are getting ethernet cables now

miklschmidt•2y ago

.. but It crashed As in, it's dead It's not a wifi problem

Helge Keck•2y ago

ok, thats bad scary

miklschmidt•2y ago

It recentered the axis though 😂 guess i'm cutting power Okay apparently the machine i'm testing on is running an older 2.0 release. I think the death was coincidental. It's before logrotation was fixed etc. It is however running the same code, and i cannot make it reproduce the bug. @michaelw7177 @chaaalyy Can you try to reproduce with the following in your useroverrides:

[ratos_homing]
z_hop: 25

[ratos_homing]
z_hop: 25

That's the only difference i can think of. Default is 15 though, you'd have to have a mesh that containt a point within the X travel move that is < -5mm to get within bed mesh fade range (it fades between 0 and 10 by default). So z>10 there's no bed mesh adjustment going on It's different for z_thermal_adjust of course, but i do not have one calibrated, so that one is harder for me to test I'll disable mesh fade and see what happens

xenial-blackOP•2y ago

Do a bed mesh load.

miklschmidt•2y ago

I did Makes no difference BINGO Reproduced Disabling bed_mesh fade did the trick

00.32
Must home axis first: 200.000 0.000 25.003 [0.000]
00.32
Must home axis first: 200.000 0.000 25.003 [0.000]
00.32
Run Current: 1.58A Hold Current: 1.58A
00.32
Run Current: 1.58A Hold Current: 1.58A
00.32
Run Current: 0.70A Hold Current: 0.70A
00.32
Run Current: 0.70A Hold Current: 0.70A
00.32
G28
00.32
BED_MESH_PROFILE LOAD="ratos"

00.32
Must home axis first: 200.000 0.000 25.003 [0.000]
00.32
Must home axis first: 200.000 0.000 25.003 [0.000]
00.32
Run Current: 1.58A Hold Current: 1.58A
00.32
Run Current: 1.58A Hold Current: 1.58A
00.32
Run Current: 0.70A Hold Current: 0.70A
00.32
Run Current: 0.70A Hold Current: 0.70A
00.32
G28
00.32
BED_MESH_PROFILE LOAD="ratos"

I have never been so happy to see an error before 😂

xenial-blackOP•2y ago

Hahaha

miklschmidt•2y ago

Aight, now for the klipper hacking! It's fun.. As soon as i clear the bed mesh i can move x again. If i can't fix it in klipper, i can hack around it in the homing routine. Checking for z homing state in bed_mesh:move() didn't solve it. I'm about to test it in bed_mesh:get_position() Bingo, fixed Now the question is. Did i introduce other bugs ... 😂 @chaaalyy if you can test this "fix" i'd be much obliged:

diff --git a/klippy/extras/bed_mesh.py b/klippy/extras/bed_mesh.py
index 92c3ac54..2cc8c273 100644
--- a/klippy/extras/bed_mesh.py
+++ b/klippy/extras/bed_mesh.py
@@ -173,7 +173,9 @@ class BedMesh:
             return 1.
     def get_position(self):
         # Return last, non-transformed position
-        if self.z_mesh is None:
+        curtime = self.printer.get_reactor().monotonic()
+        kin_status = self.toolhead.get_kinematics().get_status(curtime)
+        if self.z_mesh is None or 'z' not in kin_status['homed_axes']:
             # No mesh calibrated, so send toolhead position
             self.last_position[:] = self.toolhead.get_position()
             self.last_position[2] -= self.fade_target
@@ -198,9 +200,13 @@ class BedMesh:
         return list(self.last_position)
     def move(self, newpos, speed):
         factor = self.get_z_factor(newpos[2])
-        if self.z_mesh is None or not factor:
-            # No mesh calibrated, or mesh leveling phased out.
+        curtime = self.printer.get_reactor().monotonic()
+        kin_status = self.toolhead.get_kinematics().get_status(curtime)
+        if self.z_mesh is None or not factor or 'z' not in kin_status['homed_axes']:
+            # No mesh calibrated, mesh leveling phased out or z not homed.
             x, y, z, e = newpos
+            logging.info("bed_mesh no mesh adjustment: Current Z: %.4f fade_target: %.4f "
+                    % (z, self.fade_target))
             if self.log_fade_complete:
                 self.log_fade_complete = False
                 logging.info(

diff --git a/klippy/extras/bed_mesh.py b/klippy/extras/bed_mesh.py
index 92c3ac54..2cc8c273 100644
--- a/klippy/extras/bed_mesh.py
+++ b/klippy/extras/bed_mesh.py
@@ -173,7 +173,9 @@ class BedMesh:
             return 1.
     def get_position(self):
         # Return last, non-transformed position
-        if self.z_mesh is None:
+        curtime = self.printer.get_reactor().monotonic()
+        kin_status = self.toolhead.get_kinematics().get_status(curtime)
+        if self.z_mesh is None or 'z' not in kin_status['homed_axes']:
             # No mesh calibrated, so send toolhead position
             self.last_position[:] = self.toolhead.get_position()
             self.last_position[2] -= self.fade_target
@@ -198,9 +200,13 @@ class BedMesh:
         return list(self.last_position)
     def move(self, newpos, speed):
         factor = self.get_z_factor(newpos[2])
-        if self.z_mesh is None or not factor:
-            # No mesh calibrated, or mesh leveling phased out.
+        curtime = self.printer.get_reactor().monotonic()
+        kin_status = self.toolhead.get_kinematics().get_status(curtime)
+        if self.z_mesh is None or not factor or 'z' not in kin_status['homed_axes']:
+            # No mesh calibrated, mesh leveling phased out or z not homed.
             x, y, z, e = newpos
+            logging.info("bed_mesh no mesh adjustment: Current Z: %.4f fade_target: %.4f "
+                    % (z, self.fade_target))
             if self.log_fade_complete:
                 self.log_fade_complete = False
                 logging.info(

Put that into a file on your pi, then apply to klipper:

nano ~/homing_fix.diff
cd ~/klipper
git apply ~/homing_fix.diff
sudo systemctl restart klipper

nano ~/homing_fix.diff
cd ~/klipper
git apply ~/homing_fix.diff
sudo systemctl restart klipper

Then do a FIRMWARE_RESTART in mainsail console, and try to reproduce the bug. Also try a print and see if the mesh compensates correctly. To undo the patch:

cd ~/klipper
git checkout klippy

cd ~/klipper
git checkout klippy

miklschmidt•2y ago

https://klipper.discourse.group/t/bug-bed-mesh-and-z-thermal-adjust-applies-z-changes-even-if-z-isnt-homed/7415 Let's see how i can make a fool of myself this time 😄

Klipper

Bug: bed_mesh and z_thermal_adjust applies z changes even if z isn'...

I think i have located a bug, at least the behavior doesn’t seem intended. Steps to reproduce Make sure bed_mesh fading is disabled [bed_mesh] fade_end: 0 Now load a mesh (or calibrate a new one and run M84) home X: BED_MESH_LOAD PROFILE=default G28 X If we move X now, we’ll get an error G0 X90 Result: Must home axis first: 200.000 0.00...

xenial-blackOP•2y ago

I can test it also in a few hours. Wait..... It makes sense why I'm seeing it on the z thermal adjust and didn't on the bed mesh for me. I don't have fade turned on for my z thermal adjust. That makes sense now why I didn't see it on the bed mesh before is because Z was considered over the fade limit.

miklschmidt•2y ago

Yep! Fade for z thermal adjust should fix it too. Like it's either that, or make sure to clear the mesh and disable z thermal adjust before homing. Which sucks 😄

xenial-blackOP•2y ago

Yep. Might be why this bug may not have been found very much because bedfade would like be set to 10 or so and Z home is 20.

miklschmidt•2y ago

Yep, but fade is disabled by default in klipper. So i would kinda expect someone else to run into it. But there's a few prerequisites that have to line up before you get the error, and that's what makes it looks like a random fuckup, so i imagine many just go "weird, RESTART" and then it works again. Like i've had quite a few of these reports through out the lifetime of RatOS now that i think of it, and i haven't put the pieces together until now, all because of you guys. Big <:ratrig_heart:1064311078290456727>

xenial-blackOP•2y ago

Hahaha. And at the start of this thread, yall thought I was crazy. lol

Helge Keck•2y ago

i still belive you are like the rest of us

xenial-blackOP•2y ago

If everyone around you is crazy, that makes everyone normal. lol

sensitive-blue•2y ago

Good morning 🙂 I just tried to apply your "fix" 😉 To be honest: i´m not very experienced in linux, but managed to copy the diff-code, save it as file and when i try to apply it via git, i get [error: patch fragment without header at line 1: @@ -173,7 +173,9 @@ class BedMesh: ] Did i miss something? Update 🙂 Managed to apply the fixes via WinSCP -> downloading bed_mesh.py -> editing manually with notepad++ -> reuploading file (of course i have a backup of the original file 😉 ). Did some tests and and now at least the klipper part seems to work. Didn´t check, if the created mesh will get "used", when printing and so on, but homing and moving x/y with a loaded mesh while z isn´t homed, seems to work. But as usual: Fixed one bug, found another one (this time i guess, it´s inside RatOS 2.0´s homing routine, because on 1.2 everything is fine): Try G28 -> do a bed mesh (name doesn´t matter) -> M84 -> G28 X -> It lifts Z and homes X (as intended). -> G28 Y -> It lifts Z another time and homes Y (Not too bad until now) -> X and Y are showing "green" now, both axes are homed. -> Now try G28 Z ............ Believe it or not: It lifts Z (as intended...) and shows : [Must home axis first: 150.000 150.000 15.040 [0.000]] 😂 Without loaded mesh, all axes do, what i would expect 🙂 I know, now it can get a "policy discussion" very quickly 😉 But wouldn´t it be the best solution to clear all possible z-offsets like meshes or temp compensations immediately, when you do a M84 ? Example (Not a bug, maybe just an improvement): You switch off the motors (for whatever reason) and rehome all axes. If Z gets rehomed (and maybe there´s a slightly difference in position now), all applied compensations are a little bit "off". So deleting them @M84 wouldn´t just solve any problems caused by them, it would also ensure, they are "up to date", when they are needed....

Helge Keck•2y ago

please no, this would kill my idex z-offset i need the z-offset even after a m84

sensitive-blue•2y ago

Yeah, but isn´t that a fixed offset, relative from one extruder to the other and independent from meshes or temperature compensations ?

Helge Keck•2y ago

i just have red remove all z-offsets and my bell ringed 😆

sensitive-blue•2y ago

I know: Tinkering around in these homing routines isn´t just a simple task. With all our different setups, meshes, probe-offsets, compensations and / or skew corrections it´s very difficult to ensure, everything works perfectly. I also wouldn´t love to see a crashed nozzle or printbed, just because my machine moved somewhere i didn´t expect it. And to be honest: With a 1st layer sometimes @0.12mm, there isn´t much room for errors xD

miklschmidt•2y ago

Wat.. All applied compensations are still valid after an M84 (that's why saved meshes make sense in the first place), on the v-core 3 it requires a completed z-tilt, but otherwise they're valid. People in the klipper discourse thread are like "i haven't seen this problem for 5 years. you're high"

sensitive-blue•2y ago

😂 Not high... We´re just 🤪 ... 😁 Just a question 🙂 I´ve just seen, you already changed some macros for the update RatOS 2.0.0.30 to 2.0.0.31 ... If i update now, maybe i can´t do any further tests, hunting the klipper bug xD So just in case, i still want to switch back to 2.0.0.30, which files will get changed? I´ll backup them before the update to have the possibility of switching back, if necessary...

miklschmidt•2y ago

You can, the change was only to add BED_MESH_CLEAR to END_PRINT which should prevent most of these issues in practice. Only changed macros.cfg

xenial-blackOP•2y ago

@miklschmidt I added a bit to that thread to help. Brdmesh clear is good for that but definitely doesn’t solve z thermal does it?

miklschmidt•2y ago

Thank you, was a tough crowd.. No it does not

xenial-blackOP•2y ago

They they are in a position where they don't see why this can be an issue because their use case doesn't have that problem. Like this issue with bed mesh loaded or z thermal won't affect G28 where it homes X and leaves X there to home Y, then I think any Z adjustments are ignored to move to the safe Z location. But if there is a need or want to move either X or Y with an override, then this is where bed mesh or z thermal comes into play. Now the other approach that you might want to think about is to make it a problem because of z thermal adjust being the primary issues instead of bed mesh as there is documentation to clear bed mesh at the end of print especially with Klipper requiring loading a bed mesh in the print start macro now and not just loading default. With this mentality they think that clearing the bed mesh is the solution and there is not bug (it's a feature not a bug. lol) But turning off z thermal isn't something that is loaded and cleared with the start print macro usually, and might point it out as an actual bug. z thermal is like filament runout sensor as it can be disabled if needed for special instances, but why in the hell should you disable filament runout to home the printer. Um, you don't. That's a bug. Same with z thermal, you shouldn't disable this just to home the printer. The bed mesh would just be a happy side effect. lol I almost think that they will consider since the ratos_homing extra is there that this isn't a problem with klipper, but a problem with that plugin.

miklschmidt•2y ago

Yep, but it behaves exactly the same with homing_override

xenial-blackOP•2y ago

Do the logs look the same?

Rat Rig Community [Unofficial]Join

13KMembers

View on Discord

Want results from more Discord servers?

Add your server