Closed renzaaa closed 8 years ago
Do the coordinates appear to be wrong at the end of G29, before starting the print?
Could you do a G29 with DEBUG_LEVELING_FEATURE
enabled (after M111 S255
or at least M111 S32
), and post the log output?
Also, I have a set of changes pending, which includes some potential bug fixes, so you might want to test with that branch rather than just RCBugFix
. I'd do more testing myself, but I don't have a 3D printer handy at this time.
I think I've ran into same issue (RCBugFix, last commit "d41eeb62af4bfff0094a6c293761dfbfc3bf0f75").
I'm using BLTouch with safe leveling, no other Z-endstops.
I started by clearing EEPROM (M502) after firmware update.
After I home with G28, level bed with G29, I set nozzle over bed with G1 X100 Y100 Z0
I then measure nozzle offset from bed to be 1.2mm.
Then I set the offset with M851 Z-1.2 and store it with M500
After that, G28 and G29 again. Everything looks good... except after G1 X100 Y100 Z0 the nozzle crashes to bed.
If I set the offset to -0.6 (half of the value) I get approximately correct offset. Could it be that the offset is applied twice?
Could it be that the offset is applied twice?
Just testing the RCbugfix, and came to that thought, too. After G28 everything nozzle just touches the bed as expected, after the following g29, nozzle would crash into bed.
Anyone feel like providing a log to help debug the issue?
I started by clearing EEPROM (M502) after firmware update.
M502 doesn't clear the EEPROM. It just applies default settings.
M502 doesn't clear the EEPROM.
True. And usually I start with M502 + M500 which should take values from firmware and store them to EEPROM, unless I'm mistaken? Bad wording.
I'll try to get the log out in few minutes.
The debug-log above had M851 set to 0.00, but if needed, I can get another log where Z-offset has been set to something else, if needed?
If M851
is not set to "the distance from the nozzle to the bed when the probe triggers" then the results may not be very useful.
Okay. I'll set it to -1.20mm which was the original measured distance and get new log in a minute.
It will also help if you use G29 V4
so it prints out the bed matrix.
@thinkyhead Coordinates is correct at the end of G29, but something wrong with offset. Before the latest rcbugfix was everything fine.
The probe offset isn't actually used by G29
. It's only used when doing G28
homing with a probe to determine the current Z.
EDIT: Well, actually, not entirely true… I just recently added an optional Z correction to the end of G29
that does make use of it. Almost forgot…
I don`t know whats wrong with this fix, but before latest fix is all good.
I don't know either. That's why we're here.
@Jartza Your probing seems very erratic, with offsets all over the place. Please run an M48
to see how reliable your probe is. Note that planar bed leveling will not produce good results if the probe is inaccurate or the bed is uneven. It only works well with a flat bed and an accurate probe.
Well, I had to remove the glass because there was buildtak attached to it, which now is pretty much scratched because I was too slow to hit the panic reset, and the nozzle started scraping the buildtak off 😢
8 of 8 z: 15.000000 mean: 1.225312 sigma: 0.023599 Mean: 1.225312 Standard Deviation: 0.023599
But the same happens when I put clean glass on, still the nozzle hits bed.
Hmm, well the probe seems accurate enough. I'm re-examining the way I'm doing the final Z correction, because this seems quite wrong…
Z from Probe:16.20 Matrix:15.06 Discrepancy:1.14
The "Z from Probe" value is supposed to determine where Z is based on the final probe point. It should be close to 15, but clearly here the probe offset is being included. Possibly a mistake in the code on my part. Checking into it now…
Tomorrow I will post the log output also, if the problem will not resolved.
Aha. I found it. Typo.
Here's the fix:
- float measured_z = probe_pt(xProbe, yProbe, stow_probe_after_each, verbose_level);
+ measured_z = probe_pt(xProbe, yProbe, stow_probe_after_each, verbose_level);
Okay, I patched this in RCBugFix
. Time for more coffee!
Please confirm that it's fixed so I can pretend this never happened.
I will test.
float measured_z = probe_pt(xProbe, yProbe, stow_probe_after_each, verbose_level);
This code is on before latest rcbugfix and work fine.
@renzaaa With a recent patch the code declares measured_z
earlier and needs to retain the value until probing is complete. That line conceals the original declaration and creates a temporary variable that is thrown away at the end of the block. Not good. By removing float
the correct variable is set.
In the morning I will test.
Confirmed, works now!
Excellent. Thanks @Jartza for helping to track it down. This new Z correction at the end of probing will actually fix the Z position even in cases where the M851
offset is wrong. Theoretically…
Is this in RCBugFix now?
Yes
Latest rcbugfix is working fine.
Hello. I have a similar problem. This must have already been resolved. When I command G29 the sensor levels the first point and the second point, but in the third point, the nozzle presses the table without stopping. I have to press e-stop every time. I'm using AUTO_BED_LEVELING_BILINEAR and CONFIGURATION_H_VERSION 010107
@PabloSica — Please test with the latest bugfix-1.1.x
(and/or bugfix-2.0.x
) branch to see where it stands. If you still see the bad behavior we should investigate further.
I tested this version last night and the problem persists. I'm also using the Octoprint. How can I generate a log to send you? I have not found bugfix-2.0.x in your links.
I tested this version last night and the problem persists.
Please post a new issue. This issue is closed.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
After G29 start print and nozzle crashes to the bed.