markniu
Accuracy / Calibration / Z-Adjust (Z-Offset) issues?
I have been dealing with multiple issues from the sensor since I received it. It will be extremely consistent for a day or two, and then be completely inaccurate the next day. Prints and beds have been getting ruined.
This is the first time I've been able to quantify the changes that are occurring.
I have tried collision homing and calibration and it will either cause the nozzle to ruin my bed or my printer will attempt contactless printing (printing above the bed) this causes wildly inconsistent first layers...
I love the sensor when it works. It's amazing. I just want (need) it to be more consistent.
Console output:
16:16:57 probe accuracy results: maximum 0.107500, minimum 0.097500, range 0.010000, average 0.102500, median 0.102500, standard deviation 0.003162
16:16:04 probe at 158.000,115.000 is z=0.102500 (pos:0.922500 - bd:0.820)
16:15:57 PROBE_ACCURACY at X:158.000 Y:115.000 Z:1.000 (samples=5 retract=5.000 speed=0.8 lift_speed=0.8)
16:15:57 PROBE_ACCURACY SAMPLES=5
16:14:58 probe accuracy results: maximum 0.102500, minimum 0.082500, range 0.020000, average 0.095167, median 0.097500, standard deviation 0.006110
16:14:58 probe at 158.000,115.000 is z=0.097500 (pos:0.917500 - bd:0.820)
16:14:44 probe at 158.000,115.000 is z=0.102500 (pos:0.922500 - bd:0.820)
16:14:31 probe at 158.000,115.000 is z=0.102500 (pos:0.922500 - bd:0.820)
16:14:18 probe at 158.000,115.000 is z=0.099167 (pos:0.912500 - bd:0.813)
16:14:04 probe at 158.000,115.000 is z=0.092500 (pos:0.912500 - bd:0.820)
16:13:51 probe at 158.000,115.000 is z=0.097500 (pos:0.917500 - bd:0.820)
16:13:38 probe at 158.000,115.000 is z=0.097500 (pos:0.917500 - bd:0.820)
16:13:24 probe at 158.000,115.000 is z=0.087500 (pos:0.917500 - bd:0.830)
16:13:11 probe at 158.000,115.000 is z=0.092500 (pos:0.912500 - bd:0.820)
16:12:58 probe at 158.000,115.000 is z=0.082500 (pos:0.912500 - bd:0.830)
16:12:51 PROBE_ACCURACY at X:158.000 Y:115.000 Z:1.000 (samples=10 retract=5.000 speed=0.8 lift_speed=0.8)
16:12:51 PROBE_ACCURACY
16:12:35 probe accuracy results: maximum 0.082500, minimum 0.047500, range 0.035000, average 0.065500, median 0.067500, standard deviation 0.011446
16:12:35 probe at 158.000,115.000 is z=0.082500 (pos:0.902500 - bd:0.820)
16:12:22 probe at 158.000,115.000 is z=0.077500 (pos:0.907500 - bd:0.830)
16:12:08 probe at 158.000,115.000 is z=0.072500 (pos:0.902500 - bd:0.830)
16:11:55 probe at 158.000,115.000 is z=0.072500 (pos:0.892500 - bd:0.820)
16:11:42 probe at 158.000,115.000 is z=0.072500 (pos:0.892500 - bd:0.820)
16:11:28 probe at 158.000,115.000 is z=0.062500 (pos:0.892500 - bd:0.830)
16:11:15 probe at 158.000,115.000 is z=0.062500 (pos:0.882500 - bd:0.820)
16:11:02 probe at 158.000,115.000 is z=0.057500 (pos:0.877500 - bd:0.820)
16:10:48 probe at 158.000,115.000 is z=0.047500 (pos:0.867500 - bd:0.820)
16:10:35 probe at 158.000,115.000 is z=0.047500 (pos:0.877500 - bd:0.830)
16:10:34 PROBE_ACCURACY at X:158.000 Y:115.000 Z:1.000 (samples=10 retract=5.000 speed=0.8 lift_speed=0.8)
16:10:34 PROBE_ACCURACY
16:10:20 0.94mm
16:10:20 M102 S-2
16:10:17 G1 Z1
16:10:13 1.94mm
16:10:13 M102 S-2
16:10:07 G1 Z2
16:09:59 0.88mm
16:09:59 M102 S-2
16:09:51 G1 Z1
16:09:36 0.16mm
16:09:36 M102 S-2
16:09:32 G1 Z0.2
16:09:28 0.97mm
16:09:28 M102 S-2
16:09:23 G1 Z1
16:07:38 BDsensorVer:V1.2c,switch_mode=1,collision_homing=0,collision_cal=0
16:07:30 G28
One other issue: I recently updated my Host OS, Klipper and pulled the latest commit for this project.
I was getting the most consistent results for roughly 2-3 weeks before updating my system. I utilized Collision Homing but would manually calibrate the sensor as I could never get good results with collision calibration. The Nozzle was almost always too high above the bed with collision calibration.
collision_homing=1
collision_calibrate=0
Following the update, even with collision_calibrate off, the sensor would notice a "change" in the bed surface or nozzle distance and automatically recalibrate with collision calibration.
Any help or guidance would be greatly appreciated.
M102 S-5 Calibration Printout
18:09:04 904 at 3.9mm
18:09:04 893 at 3.8mm
18:09:04 888 at 3.7mm
18:09:03 879 at 3.6mm
18:09:03 870 at 3.5mm
18:09:03 862 at 3.4mm
18:09:03 851 at 3.3mm
18:09:03 841 at 3.2mm
18:09:02 829 at 3.1mm
18:09:02 818 at 3.0mm
18:09:02 809 at 2.9mm
18:09:02 795 at 2.8mm
18:09:02 781 at 2.7mm
18:09:02 766 at 2.6mm
18:09:02 752 at 2.5mm
18:09:02 739 at 2.4mm
18:09:02 721 at 2.3mm
18:09:01 703 at 2.2mm
18:09:01 687 at 2.1mm
18:09:01 669 at 2.0mm
18:09:01 650 at 1.9mm
18:09:00 629 at 1.8mm
18:09:00 611 at 1.7mm
18:09:00 588 at 1.6mm
18:09:00 566 at 1.5mm
18:09:00 543 at 1.4mm
18:08:59 520 at 1.3mm
18:08:59 497 at 1.2mm
18:08:59 473 at 1.1mm
18:08:59 448 at 1.0mm
18:08:59 425 at 0.9mm
18:08:59 395 at 0.8mm
18:08:59 371 at 0.7mm
18:08:59 347 at 0.6mm
18:08:58 318 at 0.5mm
18:08:58 292 at 0.4mm
18:08:58 267 at 0.3mm
18:08:58 243 at 0.2mm
18:08:58 220 at 0.1mm
18:08:57 213 at 0.0mm
18:08:57 M102 S-5
could you attach the klippy.log file, actually, I recommend people to use the collision_homing and collision_calibration that will be more accuracy than manual calibration. in most case, the problem for the collision_calibration are the speed in the cfg file.
Ideally, the first value should be 20 greater than the second value that is hard to do with manual calibration.
18:08:58 243 at 0.2mm 18:08:58 220 at 0.1mm 18:08:57 213 at 0.0mm 18:08:57 M102 S-5
There is a new update of the BDsensor.py that can detect the z_offset changed(homing with different bed temperature or the nozzle is not clean or plate changed ... ) >=0.05mm, then it will auto calibrate the sensor again after each G28 See this blog: https://www.pandapi3d.com/post/new-feature-for-bdsensor
Following the update, even with collision_calibrate off, the sensor would notice a "change" in the bed surface or nozzle distance and automatically recalibrate with collision calibration.
could you attach the klippy.log file, actually, I recommend people to use the collision_homing and collision_calibration that will be more accuracy than manual calibration. in most case, the problem for the collision_calibration are the speed in the cfg file.
for some reason I am getting a "Failed to upload klippy.log"
I will post my config file.
Ideally, the first value should be 20 greater than the second value that is hard to do with manual calibration.
18:08:58 243 at 0.2mm 18:08:58 220 at 0.1mm 18:08:57 213 at 0.0mm 18:08:57 M102 S-5
I will search for a calibration in my logs that utilizes collision now, to see how the numbers compare.
Ideally, the first value should be 20 greater than the second value that is hard to do with manual calibration.
18:08:58 243 at 0.2mm 18:08:58 220 at 0.1mm 18:08:57 213 at 0.0mm 18:08:57 M102 S-5
Ideally, the first value should be 20 greater than the second value that is hard to do with manual calibration.
18:08:58 243 at 0.2mm 18:08:58 220 at 0.1mm 18:08:57 213 at 0.0mm 18:08:57 M102 S-5
Here are 2 more instances of Collision Homing. These 2 instances both have Collision_Calibration=1. They are also back to back with each other.
collision_calibration_log2.txt
from here BDsensorVer:V1.2c,switch_mode=1,collision_homing=1,collision_cal=0 , it is still the manual calibration
and the difference between the first 2 number is less than 10
397 at 0.0mm
403 at 0.1mm
Ideally, the first value should be 20 greater than the second value that is hard to do with manual calibration.
18:08:58 243 at 0.2mm 18:08:58 220 at 0.1mm 18:08:57 213 at 0.0mm 18:08:57 M102 S-5
from here
BDsensorVer:V1.2c,switch_mode=1,collision_homing=1,collision_cal=0, it is still the manual calibration and the difference between the first 2 number is less than 10 397 at 0.0mm 403 at 0.1mmIdeally, the first value should be 20 greater than the second value that is hard to do with manual calibration.
18:08:58 243 at 0.2mm 18:08:58 220 at 0.1mm 18:08:57 213 at 0.0mm 18:08:57 M102 S-5
Yes, this is with the new update that does collision calibration whenever collision homing is active, if it detects a difference in the BD value > 0.5.
It is still a collision calibration. The next two logs have collision calibration on in the BDsensor section of the printer.cfg
from here
BDsensorVer:V1.2c,switch_mode=1,collision_homing=1,collision_cal=0, it is still the manual calibration and the difference between the first 2 number is less than 10 397 at 0.0mm 403 at 0.1mmIdeally, the first value should be 20 greater than the second value that is hard to do with manual calibration.
18:08:58 243 at 0.2mm 18:08:58 220 at 0.1mm 18:08:57 213 at 0.0mm 18:08:57 M102 S-5
Here is the klippy.log from MCU start up to doing the collision calibration and shows the BD Sensor has collision homing and calibration on, with the two back-to-back homing and calibration sequences.
I apologize if I am being difficult. I am not sure why github won't let me upload the klippy.log file. Possibly a size limit?
collision_calibration_log_long.txt
not 0.5 but 0.05mm that is within 0.1mm, so the problem is how to fix the first 2 data in calibration, need to maker sure the difference between the first 2 data at least 10 and ideally 20.
Yes, this is with the new update that does collision calibration whenever collision homing is active, if it detects a difference in the BD value > 0.5.
It is still a collision calibration. The next two logs have collision calibration on in the BDsensor section of the printer.cfg
not 0.5 but 0.05mm that is within 0.1mm, so the problem is how to fix the first 2 data in calibration, need to maker sure the difference between the first 2 data at least 10 and ideally 20.
Yes, this is with the new update that does collision calibration whenever collision homing is active, if it detects a difference in the BD value > 0.5.
It is still a collision calibration. The next two logs have collision calibration on in the BDsensor section of the printer.cfg
I agree. I noticed on the first instance it goes:
284 at 0.1mm
282 at 0.2mm
330 at 0.3mm
seems here is the problem, the bed temperature is not stable.
Yes, the bed is heating up for a heat soak cycle. These examples I am providing, however, are what I am experiencing no matter if the bed is cold, warming up, heat soaked for an hour or longer with no temperature fluctuations.
I have never gotten more than a difference of 10 between the 1st and 2nd values.
I will look at my log and see what I find.
No problem. BTW, there is another command M102 S-7 that can help you to get the raw real time data from the sensor.
Yes, the bed is heating up for a heat soak cycle. These examples I am providing, however, are what I am experiencing no matter if the bed is cold, warming up, heat soaked for an hour or longer with no temperature fluctuations.
I have never gotten more than a difference of 10 between the 1st and 2nd values.
I will look at my log and see what I find.
seems here is the problem, the bed temperature is not stable.
I found an instance of the bed being at 104.3-104.6C and the BDsensor decided to recalibrate. I will upload what I found.
What else could be causing this?
The main issue I have with collision calibration (besides the 1st and second value being greater than 10) is my first layer has no squish and is essentially falling out of my extruder and onto the bed. And when I change the z-offset, it just does the same thing over again, once I need to home again.
seems here is the problem, the bed temperature is not stable.
Attached is a log with a room temperature bed, fresh calibration, with and without collision homing/calibration.
You will see the calibration values are remarkably similar, However, the BD sensor still required a recalibration with CH/CC.
Immediately after Manual Calibration
The BD sensor began throwing weird data at Z1.0 and Z0.2.
At first, M102 S-2 value at Z1 was 1.0mm. Perfect!
Next, I went to Z0.2 (As this is the height of my first layers and extremely critical). M102 S-2 was 0.10999999999999999mm ~ 0.11mm
So, I check Z1.0 again. M102 S-2 = 0.9200000000000002mm
I decided to try M102 S-7:
Raw data:490, Then we can calculate the distance by comparing to the calibration data:0.9200000000000002mm
In a last ditch effort, I ran the following commands:
G1 Z1
M102 S-7
Raw data:508, Then we can calculate the distance by comparing to the calibration data:1.0mm
G1 Z0.2
M102 S-7
Raw data:292, Then we can calculate the distance by comparing to the calibration data:0.10999999999999999mm
Outside of the Z1.0 value moving 0.08mm, the Z0.2 was consistently at 0.10999999999999999mm but this is 0.09mm off of where it should be..
After utilizing Collision Homing and Collision Calibration
I decided to try the same iteration but after CH/CC are enabled and here are the results.
12:28:12 M102 S-7
12:28:08 G1 Z0.2
12:27:57 Raw data:483, Then we can calculate the distance by comparing to the calibration data:0.9000000000000001mm
12:27:57 M102 S-7
12:27:52 G1 Z1
12:27:50 G1 Z2
12:27:43 Raw data:463, Then we can calculate the distance by comparing to the calibration data:0.8200000000000001mm
12:27:43 M102 S-7
12:27:39 G1 Z1
12:27:33 Raw data:264, Then we can calculate the distance by comparing to the calibration data:0.09999999999999998mm
12:27:33 M102 S-7
12:27:28 G1 Z0.2
12:27:18 Raw data:484, Then we can calculate the distance by comparing to the calibration data:0.9000000000000001mm
12:27:18 M102 S-7
12:27:10 G1 Z1
I think I find there is a software bug here that I don't consider the z_offset. you can try to set the z_offset to 0 in the cfg first. I will also do more test with z_offset.
seems here is the problem, the bed temperature is not stable.
Attached is a log with a room temperature bed, fresh calibration, with and without collision homing/calibration.
You will see the calibration values are remarkably similar, However, the BD sensor still required a recalibration with CH/CC.
Immediately after Manual Calibration
The BD sensor began throwing weird data at Z1.0 and Z0.2.
At first, M102 S-2 value at Z1 was 1.0mm. Perfect!
Next, I went to Z0.2 (As this is the height of my first layers and extremely critical). M102 S-2 was 0.10999999999999999mm ~ 0.11mm
So, I check Z1.0 again. M102 S-2 = 0.9200000000000002mm
I decided to try M102 S-7:
Raw data:490, Then we can calculate the distance by comparing to the calibration data:0.9200000000000002mmIn a last ditch effort, I ran the following commands:
G1 Z1 M102 S-7 Raw data:508, Then we can calculate the distance by comparing to the calibration data:1.0mm G1 Z0.2 M102 S-7 Raw data:292, Then we can calculate the distance by comparing to the calibration data:0.10999999999999999mmOutside of the Z1.0 value moving 0.08mm, the Z0.2 was consistently at 0.10999999999999999mm but this is 0.09mm off of where it should be..
After utilizing Collision Homing and Collision Calibration
I decided to try the same iteration but after CH/CC are enabled and here are the results.
12:28:12 M102 S-7 12:28:08 G1 Z0.2 12:27:57 Raw data:483, Then we can calculate the distance by comparing to the calibration data:0.9000000000000001mm 12:27:57 M102 S-7 12:27:52 G1 Z1 12:27:50 G1 Z2 12:27:43 Raw data:463, Then we can calculate the distance by comparing to the calibration data:0.8200000000000001mm 12:27:43 M102 S-7 12:27:39 G1 Z1 12:27:33 Raw data:264, Then we can calculate the distance by comparing to the calibration data:0.09999999999999998mm 12:27:33 M102 S-7 12:27:28 G1 Z0.2 12:27:18 Raw data:484, Then we can calculate the distance by comparing to the calibration data:0.9000000000000001mm 12:27:18 M102 S-7 12:27:10 G1 Z1
I think I find there is a software bug here that I don't consider the z_offset. you can try to set the z_offset to 0 in the cfg first. I will also do more test with z_offset.
What do you mean? Right now, whenever I set my Z-offset with:
Z_OFFSET_APPLY_PROBE
# I will get
BD_SENSOR: z_offset: [some value]
However, I can only get that Z-Offset to work for one calibration and only while the printer stays on. If I hit 'Save Config' and the printer restarts, I have to do another calibration and new z-offset.
Could this be something to do with my Z axis? Or do you think the Z-Offset is not being applied to the BD_Value and causing a new calibration to occur?
Another issue I noticed was if I executed the following commands after calibration:
M102 S-2
1.09999999999mm
# and then I adjust the Z-offset +0.1mm, and redo the commands I get an output of:
1.03899999999mm
# I can't find the exactly location in the log file to show you.
# Nor are these "real" values.
# But it did show me that if I adjust my offset by the amount the sensor is off, it does not actually correlate to real values.
I hope this information helps. I am manually dialing in the z-offset every print right now.
After a few cycles of prints and MCU start-ups I have noticed my collision calibration is giving better results. I'm not sure why. But figured I'd share.
I do still need to change my Z-offset after every print or MCU start-up. Most recently, from -0.180 to +1.75.
17:19:45 430 at 0.9mm
17:19:45 402 at 0.8mm
17:19:45 375 at 0.7mm
17:19:45 349 at 0.6mm
17:19:45 321 at 0.5mm
17:19:45 295 at 0.4mm
17:19:44 268 at 0.3mm
17:19:44 241 at 0.2mm
17:19:44 217 at 0.1mm
17:19:44 201 at 0.0mm
17:19:43 M102 S-5
I have fixed the problem of having to recalibrate after each homing by the none zero z_offset, you can update the BDsensor.py like the following command
cd ~/Bed_Distance_sensor/
git fetch --all && git reset --hard origin/new && git pull
In that case, I recommend you to use the real time level feature https://github.com/markniu/Bed_Distance_sensor/wiki/How-to-run-Real-Time-Level
I found that the first layer is better and stable than normal mesh bed level, because it adjust the nozzle by measuring the distance in real time.
I do still need to change my Z-offset after every print or MCU start-up. Most recently, from -0.180 to +1.75.
In that case, I recommend you to use the real time level feature https://github.com/markniu/Bed_Distance_sensor/wiki/How-to-run-Real-Time-Level
Updated BDsensor.py and I'm running the real time leveling. Only thing I needed to adjust was the z_adjust to 0.03mm (higher from the bed). This gave me amazing first layers!
I am running into another issue since enabling Real Time leveling and disabling bed mesh.
I keep getting random errors related to my stepper_z. This most likely is related to my printer.cfg or my machine g-code in orca.
In my machine G code "before layer change" The text box already had:
;BEFORE_LAYER_CHANGE
G92 E0
Should the Real time leveling If statements go before or after this g-code?
I am not home right now but will update once I am able to dig into the klippy.log.
Mark, thank you for all your help so far. I truly appreciate it!
You're welcome, I'm glad that I can help.
the Real time leveling consum some cpu time in the MCU to adjusting the z motors that will cause some noise from XY motors especially in high speed of nozzle travel moving while printing in first layer.
if there are some errors you can try to increase the rt_sample_time
So, I am back to square one. I am still having issues with Z_offset. The problem I am having is I need to constantly, live tune the z_offset with collision homing. After I apply a new z_offset, The BDsensor needs to recalibrate when it is homed next (i.e. new print) because it detected a change. Then the Z_offset is essentially nullified. And the sensor uses the new calibration as Z=0 when in reality, Z is really 0.2... requiring me to adjust 0.2 in the z_offset during the print. The Z_offset will keep growing, after 1 print its 0.2, the next 0.4, and so on.
I believe the issue is still in the BDsensor.py file. Where Z_Offset is not being respected as a fixed value, AFTER calibration occurs.
Thanks! I just check the code and noticed that there maybe a bug like you said, Could you replace this line code in the BDsensor.py
replace
self.gcode.run_script_from_command("G1 Z0")
to
self.gcode.run_script_from_command("G1 Z%.2f"%self.z_offset)
I will also test it on my printer late
So, I am back to square one. I am still having issues with Z_offset. The problem I am having is I need to constantly, live tune the z_offset with collision homing. After I apply a new z_offset, The BDsensor needs to recalibrate when it is homed next (i.e. new print) because it detected a change. Then the Z_offset is essentially nullified. And the sensor uses the new calibration as Z=0 when in reality, Z is really 0.2... requiring me to adjust 0.2 in the z_offset during the print. The Z_offset will keep growing, after 1 print its 0.2, the next 0.4, and so on.
I believe the issue is still in the BDsensor.py file. Where Z_Offset is not being respected as a fixed value, AFTER calibration occurs.
I just reflashed firmware with the updated bdsensor.py file. Testing now and will update you