Closed VincentWiz closed 6 years ago
@VincentWiz Our bed tramming algorithms try to keep the distance bed-probe constant. This works pretty well as long the distance between nozzle and probe is constant. X-rotation prevents that https://github.com/MarlinFirmware/Marlin/issues/9529#issuecomment-365298112 and follwups made this a bit clarer to some.
@filipgoc Right. Almost everything can be fixed in software. The question here is if it can be done in the time we have and where can we get the needed data. This is a nonlinear problem. Until someone finds a trick we'd have to calc a sin() and or cos(). Because a similar problem exists for Y the amount of calculations will grow fast. (An idea could be to apply the correction not to every point we go, but only to tune the mesh (if we have one)). An alternative for hand tuning the mesh. While thinking about it - hand tuning the UBL mesh is the procedure to get the required data.)
@thinkyhead
Somewhere else you talked about a test to compare the probes result with a nozzle-paper-test in the mid of the bed to find the Z_PROBE_OFFSET_FROM_EXTRUDER
. For debugging purpose a way to make this test at X Y or at the current position would be nice.
@AnHardt Good point. Though, at some point, the real question does become what is desirable to fix in software, as you hint towards. A dramatic rephrasing of the thought:
"We fixed it, sonny." (Long dramatic pause. Camera zooms in on the programmer's face, visibly in pain. Trying not to cry.)
"But at what price...."
(Breaks down crying. Camera gently pans away and up into the sunny sky that offers a stark contrast to the emotional darkness of the scene. Cut.)
The question here is if it can be done in the time we have and where can we get the needed data. This is a nonlinear problem. Until someone finds a trick we'd have to calc a sin() and or cos(). Because a similar problem exists for Y the amount of calculations will grow fast. (An idea could be to apply the correction not to every point we go, but only to tune the mesh (if we have one))
If we decided to fix this in software... We probably don't need to do the sin() and cos() computation at each point. We could apply the mesh concept to the twist also. At any given location, we could be within a mesh cell that holds accurate sin() and cos() values for the twist at that location. And probably, we could do the interpolation. (It maybe it doesn't even need to be bi-linear. It maybe the bulk of the correction can be done on each individual axis.)
We would also have to figure out accurate ways to measure the twist so the correction data could be loaded and used...
For right now... It seems more reasonable to have the requirement the machine is built properly.
When we add the "too much deviation" test, Marlin will simply reject a mesh that is obviously wrong. But I fear there is no general solution to work around a weird gantry or off-angle probe. Sometimes the little wheels that the carriage rides on are a little off, and then your mesh comes out "lumpy." I don't think we can fix that automatically either.
The 'too much deviation' reminds me of missing points. Sometimes, points end up missing and can be easily filled in with G29 P3. Maybe a warning that there are missing points and that G29 P3 (or redoing the probing) would be prudent. If one runs with some terminal and can see the topology, this is not that big a deal, but over the LCD, it's not easy to see if the mesh is all filled in. Or is there an easy way I'm missing ?
EDIT: disregard, this is UBL. I got threads confused.
A follow up question to that... why would points be missing in mesh? If I do automatic probing, the probe does correctly sense the bed, and it works most of the time, why would every now and then the probing come back with one or two missing points in the mesh?
I have observed this behavior, but didn't realize it may be a bug or something.
EDIT: disregard, this is UBL. I got threads confused.
Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:
bugfix-1.1.x
or bugfix-2.0.x
to test with the latest code.DEBUG_LEVELING_FEATURE
and M114_DETAIL
and re-flash the firmware.M111 S247
to enable maximum logging.G28
to do your standard homing procedure.G29
to probe the bed. This will also enable bed leveling.Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.
You can use M114 D
as you move around the bed to see lots of details about the current position. If you see strange things, also copy them into your text file.
Since you're using BILINEAR
leveling, you can also use G29 Q
at any time to see details about leveling at the current position.
We look forward to your next report. Hopefully we can narrow this down to a single cause and fix it.
Sorry, I got threads confused. The missing points fun is from UBL. (I'm using/ testing both UBL and Bilinear ABL).
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.
Bug Report
Description: On Marlin 1.1.8, using capacitive sensor and Bilinear autolevel method, the bed isn't flat everywhere. A discussion has been open in a group on Facebook, and many people are having this issue. I tried to clear EEPROM then re-upload Marlin, no effects. I also tried to go on Marlin1.1.6, same. Other people has the BLTouch, so the issue isn't comming from the sensor. Some people are also on Marlin 1.1.6. I wanted to use the UBL for checking, but i has a compilation error (Text overflowed). I'll post my configuration.h and conf_adv.h this evening.
Expected behaviour: Autolevel should compense the Z offset everywhere on the bed
Actual behaviour: Autolevel doesn't compense the Z offset everywhere (check the picture attached - Don't take care about the bad stuff, because i had no scotch on all bed xD, just take care about the lines, and Z-offset)
With capacitive sensor
With BLTouch