TILT_ADJUST printers calculate wrong offset
EightFinger opened this issue · comments
First I really like your idea, but I think it doesn´t seem to work with a trident at the moment.
Today I installed your updated version trough moonraker, thanks for that!
I reverted my z_offset back to 0 and heated my chamber and did homing, plus z-tilt.
Then i did AUTO_TAP command with the following settings.
I calculated a offset of 0.110 which when saved translates to [probe_z_offset: -0.110].
My hand self measured z_offset for a nice first layer is: -0.865, which is far away from the AUTO_TAP one.
Never the less, I tried to make a test print, to fine tune the first layer, but the nozzle far too close to the bed, it is even dragging on the bed a little bit. This way the extruder can´t push any filament through the nozzle and my printer stops.
Chaning back to my old z_offset, it prints without any problems.
Am I doing something wrong?
Picture of bed with scratches:
Printer Setup:
Voron Trident 300x300x250
Stealthburner with Rapido Hotend
Vitalii3D MetalTap with 2.4.1 OptoTap PCB at 24V
@EightFinger I'm so sorry your bed got scratched!
My last commit should have fixed this issue.
I have a v2.4, so I had only tested it on printers using QUAD_GANTRY_LEVEL. Printers that use TILT_ADJUST need different math to calculate the z-offset.
Someone on Discord posted a similar issue, and I resolved it the best I could with their info.
Could you update the repo, run AUTO_TAP again, and share a screenshot of the console output? Let me know if the new version fixes it. Thank you for trying this out, and for your time!
Thanks again for the fast reply. Sadly I´m currently on vacation, so I can´t test the update now. I´ll get back to you, as soon as I can. Probably end of next week.
One different question, I think the "FORCE" command would overwrite the previously calculated offset value, right? For me it added the new calculated value to the old one, like first run -0.110, second run with FORCE=1, was -0.110 again, but it set the z-offset to -0.220, so I didn´t use the FORCE command. I will check this with this new update when I get back.
Just had the time for testing the new update. This is the console output:
I can´t test a print yet, but I wanted to show you what it calculated. Hope it helps. The value seems again very strange in comparison to my own offset value. Thanks again.
That does look odd, and is a different result from the other person's TILT_ADJUST results. phazil's results
I will look into this soon and make a fix that works for both of those results. Thanks for responding so quickly, and sharing your issue!
If run run AUTO_TAP twice, the first time it will calculate it, and the second time it will set z-offset to the last calculated result. If you run FORCE=1 it won't use the last calculated value, and will do it again. I'm not sure why your offset seemed to double when you ran it again - a fix will be implemented soon
I used the most recent update. I am finding that autotap reports and sets the z-offset to 0.06 as the z-offset, but I need to run a z-offset of 0.562, or else the nozzle runs into the bed.
Before autotap my z-offset in klipper was z_offset = -0.570
To remedy this I have done the following in my start macro
AUTO_TAP FORCE=1 #uses auto tap to calculate z-offset
SET_GCODE_OFFSET Z_ADJUST=+0.5 MOVE=1
@The-Original-Reth are you using a printer that uses QUAD_GANTRY_LEVEL, or TILT_ADJUST?
Also, could you send a screenshot of Auto TAP's console output for the calculation? Thanks for the info!
I am using a trident 300. I have set it to QGL, as there is no z_tilt.
@The-Original-Reth I've never heard of a Trident using QGL, how do you have that configured?
I may have to add a configuration option for whether you're using a flying gantry (like v2.4) or lead screws (like trident)...
I guess I was confused. Screw tilt I associate with V0. I will change it and see what happens
[auto_tap]
x: 150
y: 150
z: 10
set: 1
settling_probe: 1
calc_method: STA #<your printers leveling method, "QGL", or "STA">
stop: 1.0
step: 0.005
samples: 5
retract: 3
probe_speed: 5
lift_speed: 2
travel_speed: 150
9:25 PM
Auto TAP Results
Samples: 5, Total Steps: 23
Probe Mean: -0.0095 / Min: -0.0161 / Max: -0.0008
Measure Mean: 0.0135 / Min: 0.0135 / Max: 0.0135
Travel Mean: 0.0230 / Min: 0.0200 / Max: 0.0250
Calculated STA Z-Offset: 0.025
9:25 PM
Auto TAP sample 5
Traveled: 0.0250 from z-0.0161 to 0.0089 on step 5
9:25 PM
Auto TAP sample 4
Traveled: 0.0250 from z-0.0138 to 0.0112 on step 5
9:25 PM
Auto TAP sample 3
Traveled: 0.0250 from z-0.0103 to 0.0147 on step 5
9:25 PM
Auto TAP sample 2
Traveled: 0.0200 from z-0.0066 to 0.0134 on step 4
9:24 PM
Auto TAP sample 1
Traveled: 0.0200 from z-0.0008 to 0.0192 on step 4
9:24 PM
Auto TAP performing 5 samples to calculate z-offset with STA method
Possible steps: 200, Stop: 1.0, Step: 0.005
9:24 PM
auto_tap force=1
After changing it and running a print. I still had to add a 0.5 z-offset. In order to get a good first layer.
Auto TAP Results
Samples: 5, Total Steps: 25
Probe Mean: 0.0062 / Min: 0.0020 / Max: 0.0097
Measure Mean: 0.0312 / Min: 0.0312 / Max: 0.0312
Travel Mean: 0.0250 / Min: 0.0250 / Max: 0.0250
Calculated STA Z-Offset: 0.044
Adding on more info to the Z_TILT_ADJUST hunt.
I have 2 cases where I tested the plugin on my printer to see what data is given before even printing at all, I do have a really scarred PEI sheet available that I'll use when further updates come by.
Case 1
First case is when my Z OFFSET is hand calibrated already with a value around -0.630. If I run AUTO_TAP Force=1, it will bring on a value close to what I calibrated. Value given by AUTO_TAP was -0.603.
From my understanding this gives the correct Z offset but technically doubles the Z offset closer to the bed. Being my calibrated probe offset + the AUTO_TAP calibration.
Case 2
If I reset my probe offset and z offset in my printer.cfg and before running any type of probe_calibrate it'll bring on a z_offset nowhere similar to what it should be in Case 1.
I guess logically it makes sense with Voron Tap as the nozzle is the probe so it should be close to 0. Though from how the auto z offset calibration works right now it's probably best to just ballpark verify the z offset you would've found by hand.
Might've found a different bug. It zeros the already input z-offset, but your homed z0 (with the offset) may still have an impact on the probe/measure results?
It's weird that the probe/measure numbers are different based on your before auto-tap z-offset.
I have another module I'm working on and will port some things from that into this, like automatic homing, which should fix that issue. Maybe then the TILT_ADJUST issue will be more clear
Thank you for screenshots and detailed information!
@phazil, you were correct, the saved z-offset was impacting the results (using STA method since it also used the probe/measure instead of just the travel). It should no longer care about your previous z-offset as of this commit
Currently working on fixing issue 5, then the TILT_ADJUST issue should be easier to solve. The hunt continues...
Just reran auto_tap with your newest update.
Auto TAP Results
Samples: 5, Total Steps: 25
Probe Mean: -0.0041 / Min: -0.0048 / Max: -0.0028
Measure Mean: 0.0209 / Min: 0.0209 / Max: 0.0209
Travel Mean: 0.0250 / Min: 0.0250 / Max: 0.0250
Calculated z-offset on R8 tap: 1.250
These results are about 0.5 to large
Trident 300.
I am now getting this error on the newest revision of auto_tap
7:17 PM
Offset does not match expected result. Expected between 0.70-2.00, Got: 2.438
7:17 PM
Auto TAP Results on R8 using 'rev hop' method
Samples: 1, Total Steps: 5
Probe Mean: -1.1881 / Min: -1.1881 / Max: -1.1881
Measure Mean: -1.1631 / Min: -1.1631 / Max: -1.1631
Travel Mean: 0.0250 / Min: 0.0250 / Max: 0.0250
Calculated z-offset: 2.438
7:17 PM
Auto TAP sample 1
Traveled: 0.0250 from z-1.1881 to -1.1631 on step 5
7:17 PM
Auto TAP performing 1 samples to calculate z-offset on R8 tap using 'rev hop' method
Probe Min: -2.0, Stop: 2.0, Step: 0.005
7:17 PM
auto_tap
my previous z-offset was -1.2
My auto-tap is constantly 0.4 higher than what should be used. So I just decrease by that amount. Hopefully it can get sorted out.
So I´m back from vacation now and tried the newst update with my printer and read trough all the comments. The calculated offset is too high. My normal working offset is -0.865
How can i help you to improve this script even further?
This is my console output:
13:55
Auto TAP Results on VITALII_CNC using 'rev hop' method
Samples: 10, Total Steps: 100
Probe Mean: -0.0131 / Min: -0.0150 / Max: -0.0094
Measure Mean: 0.0369 / Min: 0.0369 / Max: 0.0369
Travel Mean: 0.0500 / Min: 0.0500 / Max: 0.0500
Calculated z-offset: 1.263
13:55
Auto TAP sample 10
Traveled: 0.0500 from z-0.0150 to 0.0350 on step 10
13:55
Auto TAP sample 9
Traveled: 0.0500 from z-0.0144 to 0.0356 on step 10
13:55
Auto TAP sample 8
Traveled: 0.0500 from z-0.0144 to 0.0356 on step 10
13:54
Auto TAP sample 7
Traveled: 0.0500 from z-0.0138 to 0.0362 on step 10
13:54
Auto TAP sample 6
Traveled: 0.0500 from z-0.0138 to 0.0362 on step 10
13:54
Auto TAP sample 5
Traveled: 0.0500 from z-0.0131 to 0.0369 on step 10
13:54
Auto TAP sample 4
Traveled: 0.0500 from z-0.0131 to 0.0369 on step 10
13:54
Auto TAP sample 3
Traveled: 0.0500 from z-0.0125 to 0.0375 on step 10
13:54
Auto TAP sample 2
Traveled: 0.0500 from z-0.0113 to 0.0387 on step 10
13:53
Auto TAP sample 1
Traveled: 0.0500 from z-0.0094 to 0.0406 on step 10
13:53
Auto TAP performing 10 samples to calculate z-offset on VITALII_CNC tap using 'rev hop' method
Probe Min: -2.0, Stop: 2.0, Step: 0.005
To add some info, I just measured some Z values of my printer. Maybe those help you in altering the calculating for Trident, Vitalii Metal TAP. Here are the Z values with no offset applied in the printer.cfg.
So I did some further testing. I used a probe and lift speed of 0.5 (really slow). This way I got very consistend and accurte measurements. Which are similiar to my hand measured value from above.
Auto TAP Results on VITALII_CNC using 'rev hop' method
Samples: 10, Total Steps: 80
Probe Mean: 0.0011 / Min: 0.0006 / Max: 0.0031
Measure Mean: 0.0411 / Min: 0.0411 / Max: 0.0411
Travel Mean: 0.0400 / Min: 0.0400 / Max: 0.0400
Calculated z-offset: 0.999
15:40
Auto TAP sample 10
Traveled: 0.0400 from z0.0006 to 0.0406 on step 8
15:40
Auto TAP sample 9
Traveled: 0.0400 from z0.0006 to 0.0406 on step 8
15:39
Auto TAP sample 8
Traveled: 0.0400 from z0.0006 to 0.0406 on step 8
15:39
Auto TAP sample 7
Traveled: 0.0400 from z0.0006 to 0.0406 on step 8
15:38
Auto TAP sample 6
Traveled: 0.0400 from z0.0006 to 0.0406 on step 8
15:38
Auto TAP sample 5
Traveled: 0.0400 from z0.0006 to 0.0406 on step 8
15:38
Auto TAP sample 4
Traveled: 0.0400 from z0.0006 to 0.0406 on step 8
15:37
Auto TAP sample 3
Traveled: 0.0400 from z0.0013 to 0.0413 on step 8
15:37
Auto TAP sample 2
Traveled: 0.0400 from z0.0019 to 0.0419 on step 8
15:37
Auto TAP sample 1
Traveled: 0.0400 from z0.0031 to 0.0431 on step 8
15:36
Auto TAP performing 10 samples to calculate z-offset on VITALII_CNC tap using 'rev hop' method
Probe Min: -2.0, Stop: 2.0, Step: 0.005
After some more testing I have an update. I needed to create a fork, I hope thats okai. I´m going to delete it if you want.
Here is what I found:
Because my Z-offset is negative if a measure it by hand, I played a bit the the DEV TAP version and if the "multiple" value is set to negative, the offset will be too, but that is prevented by the "min" settings in your script. That why i created a fork and made my own test version with my settings:
With this, I get a z-offset close to my original offset off -0.865.
Again I use a 300 Trident with Vitalii Metal Tap and a Rapido Hotend, so this does maybe apply only to me.
@EightFinger Awesome! Thanks for all the info, and for doing some tests of your own. Be careful with the negative offset. Hand measured (saved offsets) are inverted from "live offsets" like Auto TAP measures (at least that I've seen)
Last "probe method" I can think of to try is to get the measurement, and move back to z0 to check if it's still triggered.
Since Voron TAP takes a bit of force to trigger, it may be when that amount of force is applied it pushes it just enough to trigger. Since that value varies based on the magnets, rail, etc, it may not be possible to work on different versions of TAP. In this case, it could just provide min/max values (maybe?)
I'll take everyone's results and generate some graphs with the data to see if it makes things more clear, but honestly I'm not hopeful besides it being tuned on individual printers, which kind of defeats the whole purpose.
I appreciate you, and everyone who have contributed time, and I hope there's some breakthrough that fixes these issues.
@Anonoei Thanks for the answer. Your are right with the saved offsets are inverting upon saving. I changed my multiple back to a positive and to 21.5 to be more close to my value. So now it shoes 0.859 but saves to -0.859. This way it is correct.
Your idea on how to get min/max values could work. I´m not the most knowledgble, because I just start tinkering with this stuff, but I really like to try out new stuff.
I had an idea to get the nozzle touching bed value by conecting wires to the holding magnets and screws in TAP. This way we would probably know excactly the Z value when the nozzle touches the bed and the magnets disconnect. Maybe I´ll try this in the future.
Since the original problem is sovled and with more people found the right multiple for Vitalii Tap, I´m gonna close this issue. Thank you very much.