thierryzoller
commented
4 years ago Issued a G28 :
Closed thierryzoller closed 4 years ago
thierryzoller
commented
4 years ago Issued a G28 :
thierryzoller
commented
4 years ago Issued a G29 :
thierryzoller
commented
4 years ago thierryzoller
commented
4 years ago Issued a G29Q
2020-05-04 14:54:27,382 - SENT: G29 Q 2020-05-04 14:54:27,385 - RECV: echo:G29 Q 2020-05-04 14:54:27,388 - RECV: current_position= X257.00 Y310.00 Z15.07 : >>> G29 2020-05-04 14:54:27,388 - RECV: Machine Type: Cartesian 2020-05-04 14:54:27,398 - RECV: Probe: BLTOUCH 2020-05-04 14:54:27,398 - RECV: Probe Offset X28.00 Y-33.00 Z-3.05 (Right-Front & Below Nozzle) 2020-05-04 14:54:27,408 - RECV: Auto Bed Leveling: BILINEAR (disabled)
thierryzoller
commented
4 years ago Issued an M420 S1
2020-05-04 14:56:20,423 - RECV: echo:M420 S1 2020-05-04 14:56:20,433 - RECV: current_position= X257.00 Y310.00 Z15.07 : Leveling OFF 2020-05-04 14:56:20,443 - RECV: current_position= X257.00 Y310.00 Z15.00 : ...Now ON 2020-05-04 14:56:20,447 - RECV: current_position= X257.00 Y310.00 Z15.00 : sync_plan_position 2020-05-04 14:56:20,447 - RECV: echo:Bed Leveling ON 2020-05-04 14:56:20,447 - RECV: echo:Fade Height OFF 2020-05-04 14:56:20,457 - RECV: X:257.00 Y:310.00 Z:15.00 E:0.00 Count X:20560 Y:24800 Z:6028
thierryzoller
commented
4 years ago Issued an G26 R999
m420 s1 SENDING:M420 S1 echo:Bed Leveling ON echo:Fade Height OFF
Videos here :
Picture here:
(Those are scratches, not filament)
thierryzoller
commented
4 years ago I dont think that is the way it is supposed to work. The only way I suceed in printing is leveling the bed manually
thierryzoller
commented
4 years ago Let me know what you need from me please.
thierryzoller
commented
4 years ago I turned off the Printer after the last post 2 days ago and haven't touched it since. Today I power it up, connect to it via Pronterface and the Z-Offset now shows
M851 X28.00 Y-33.00 Z-2.35
As you can see in the logs above it was previously during the tests:
M851 X28.00 Y-33.00 Z-3.05
I have not changed printed or done anything to the printer. Is there some sort of Savestate error and the wrong values are being used?
thierryzoller
commented
4 years ago Here is the full log from todays startup :
thierryzoller
commented
4 years ago Gents I went through all that hassle just to get to the bottom of this, would apprecivate someone chiming in :) @thinkyhead
encodedLife
commented
4 years ago Hey, i also have the Bltouch 3.1 (on Skr 1.3) i use the following settings:
define Z_MIN_PROBE_ENDSTOP_INVERTING true
define Z_PROBE_LOW_POINT -10 <- this should be higher then the Z-Probe offset
also level the corners br
Edit: i know -10 for Z_PROBE_LOW_POINT is a little bit to much but i don´t even know why this setting is there
thierryzoller
commented
4 years ago Thanks polato but we had ton of reports that Marlin is not compensating correctly since the latest releases. This post is an attempt to help properly debug this. For instance I am not goin to set "Inverting True" when this is not required for my setup. Leveling the corners is not the issue.
ziporah
commented
4 years ago I experienced issues as wel, for the sake of trying, I inverted my axis and set X to max end-stop instead of min-end stop, altered all other required settings to make X work correctly and re-ran the probe. My conclusion here is that the probing sequence is exactly the same, while it should be reverted. it starts at X 220-probing distance, Y0-probing distance, while it should start at X0-probing distance, Y0-probing distance. This seems to verify the issues I'm seeing, the leveling matrix doesn't take the inversion settings into account and seems to map the wrong matrix on the bed. I will try printing again with this settings and update here. Not sure I might have to do the same for my Y axis, I'm still trying to tracking this...
encodedLife
commented
4 years ago Hey, i also have the Bltouch 3.1 (on Skr 1.3) i use the following settings:
define Z_MIN_PROBE_ENDSTOP_INVERTING truedefine Z_PROBE_LOW_POINT -10<- this should be higher then the Z-Probe offsetalso level the corners br
Edit: i know -10 for Z_PROBE_LOW_POINT is a little bit to much but i don´t even know why this setting is there
well, I forgot to say that I also changed my homing. Before my homing point where on rear right now I put the end stops to front left and also changed these settings. And now it´s working better but not as it should be.
@thierryzoller could you try following:
Calibrate the Z-Offset with a sheet of paper and save the value.
Make bed leveling with: G29
Turn of Bed leveling: M420 S0
Go to the first leveling Point: G42 I0 J0
Print the Bed Leveling Mesh Values: M420 V
Then go to zero with the z axis: G1 Z0
Turn Bed leveling on: M420 S1
the current Z-position on the Display should change to the (0,0) value of the printed Mesh values. If you use the following command G1 Z0, the same space should be available as for the paper calibration.
When I perform these steps, the distance between the nozzle and the bed is more or less than the point at which I performed the paper calibration.
ziporah
commented
4 years ago I followed your procedure exactly, the values shown are inverted. I went to G42 I2 J2, my grid value is +0.43 there. Then go to G1 Z0 with bed leveling disabled. enable leveling. The display shows - 0.43 and go to G1 Z0, the bed moves up 0.43 instead of going down.
encodedLife
commented
4 years ago I followed your procedure exactly, the values shown are inverted. I went to G42 I2 J2, my grid value is +0.43 there. Then go to G1 Z0 with bed leveling disabled. enable leveling. The display shows - 0.43 and go to G1 Z0, the bed moves up 0.43 instead of going down.
ok i think there is the bug.
EDIT: to get a better understanding about the bug someone with another Probe or another Probe system should try the same steps. Then we can determine if this bug is only on BLTouch 3.1 or in the FW.
I´m sorry I don´t have so much time, to investigate in this problem. I would recommend using this bug finding strategy, i you want.
ziporah
commented
4 years ago I have a simple bl touch. I only defined this in the config: ‘’’
‘’’
thierryzoller
commented
4 years ago Upload you config please
thierryzoller
commented
4 years ago @polato94 : There is no need to as it worked beforehand on previous builds, rather than staying theoretical one should take a look at the code and determine where the error happens. Signed/unsigned ? For that I have to leave it to someone else. The bug was demonstrated and reproduced. I am unaware what part of the code is responsible for this operations - and would expect a Dev to step in.
You said: to get a better understanding about the bug someone with another Probe or another Probe system should try the same steps. Then we can determine if this bug is only on BLTouch 3.1 or in the FW.
thierryzoller
commented
4 years ago 
marcjwebb
commented
4 years ago hya all, hope everyone here is safe and well. wondered if this was fixed in the latest bugfix on the firmware page? i am too getting this issue. ( ender 3 pro, bltouch v3.1, marlin 2.0.5.3 )
thinkyhead
commented
4 years ago Still tracking down the cause. If someone knows a particular version of Marlin where it's still okay, that would be useful data. I'll be able to get into troubleshooting this issue in about 12 hours….
thinkyhead
commented
4 years ago I went to G42 I2 J2, my grid value is +0.43 there.
Then go to G1 Z0 with bed leveling disabled. Enable leveling. The display shows -0.43. Go to
G1 Z0, the bed moves up 0.43 instead of going down.
If the Z position was 0 before leveling was disabled, then the display should should indeed show -0.43. That accords with my description above. And, at the very least, moving to Z0 is supposed to move the nozzle farther away from the bed. So there is definitely something amiss!
That could be a case where the planner wasn't sync'ed with the updated Z position after it was changed by the set_bed_leveling_enabled function… or as alluded to, the soft endstops could be getting in the way.
You can check whether the planner and the logical position are properly synchronized by turning on M114_DETAIL and then sending M114 D at the point just after you disable leveling, but before you (don't) do the move to Z0. That will probably reveal that the planner and the logical position are out of phase. If only it could tell us where and how…
It would be worth doing some experiments to see if changing the values of the Z min soft endstop has any effect on leveling behavior. I bet there's something there. See if doing M211 S0 has any effect on the way this bug manifests, or if turning off soft endstops altogether makes some difference.
If handling has been changed recently around set_bed_leveling_enabled or around the way soft endstops get applied or reckoned — perhaps in relation to the MIN_POS/MAX_POS settings— in recent months, these would be good things to check…
I will look into this more in about 10-12 hours, after the whole sleep thing.
ziporah
commented
4 years ago Upload you config please This is my current configuration
this is my configuration test with Linear, which appears to be totally off, reverting back to bilinear (only change in following file) Configuration_adv.txt Configuration.txt
ziporah
commented
4 years ago I reconfigured my X axis to default behaviour, uploaded clean firmware, reset to default settings, ran G28, followed by G29 here's the output:
at Z:4129 => the Z axis was still in the position after homing and bed leveling then issued the first G1 Z0 display showed -0.88 befor the final G1 Z0 and Z went up on G1 Z0 If you need some more debugging info, let me know, I'll try to collect asap. Should I try the 0.2.0-bugfix branch ? => re-programmed with M114_DETAIL enabled, running the procedure again, will post when finished
thierryzoller
commented
4 years ago the current Z-position on the Display should change to the (0,0) value
My display doesn't show Z, what M503 value should I watch?
ziporah
commented
4 years ago M114 D shows the current value
thierryzoller
commented
4 years ago @polato94 : This is bug-fix2.0 build from an hour ago - I did what you said step by step. After the 420 S1 there was 0 movement of the Z axis and M114 D shows
> X:28.00 Y:25.00 Z:0.19 E:0.00 Count X:2240 Y:2000 **Z:0**I should have been -0.190 as far as I can tell :
> Bilinear Leveling Grid:
0 1 2 3 4 5 6
0 -0.190 -0.139 -0.150 -0.128 +0.006 +0.047 +0.127
1 -0.165 -0.116 -0.115 -0.114 +0.012 +0.066 +0.135
2 -0.104 -0.054 -0.065 -0.058 +0.064 +0.095 +0.155
3 -0.036 +0.003 -0.006 -0.011 +0.092 +0.107 +0.174
4 +0.055 +0.090 +0.059 +0.039 +0.121 +0.148 +0.188
5 +0.187 +0.199 +0.148 +0.106 +0.169 +0.142 +0.189
6 +0.242 +0.254 +0.198 +0.158 +0.233 +0.206 +0.243### Step by Step:
> G28 :
> X:127.00 Y:188.00 Z:14.97 E:0.00 Count X:10160 Y:15040 Z:6000
> G29 :
> X:257.00 Y:310.00 Z:15.00 E:0.00 Count X:20560 Y:24800 **Z:6092** <**--- Why 92?**
> G42 I0 J0
> G29Q gives me ABL Adjustment Z-0.183
>m420 v also gives me z-0.183
> M420 S0
> X:257.00 Y:310.00 Z:15.23 E:0.00 Count X:20560 Y:24800 Z:6092
>g1 z0
> m420 s1
> X:28.00 Y:25.00 Z:0.18 E:0.00 Count X:2240 Y:2000 Z:0The nozzle scratches the Bed at this point @polato94
ziporah
commented
4 years ago This is still 0.2.x firmware, this time with M114_DETAIL compiled in Clean again, homing G28, bed level G29 Z position after homing on display: 9.55 Z position after disabling bed leveling : 10 Z position after G42 I2 J2 , G1 Z0 : 0 Re-enable leveling : -0.442 Z position after G1 Z0 : 0 => axis went up detailed info in this gist: https://gist.github.com/ziporah/f82595526618b0a5deaf7a4ba887897e
let's wait for @thinkyhead to chime in his ideas.
thierryzoller
commented
4 years ago Here is the Debug Log:
thierryzoller
commented
4 years ago I can also notice no compensation when doing G1 travel moves. Not sure that is supposed to be compensated.
thierryzoller
commented
4 years ago In an attempt to find a build that works I flashed 2.0.5 - One observation, I turned ABL off, the Z motor slightly adjusted midst printing move (althought it is on the very same layer). I turned ABL on, same thing. Why would the zmotor ever so slighly spin when executing a printing move in the middle of a layer?
hitbyatruck
commented
4 years ago Hello, everyone. This bug has been driving me nuts as well. It's been over a week of trying to figure out the problem and I still can't figure out why the ABL is not compensating for the mesh while printing. As anyone been able to figure out what may be causing this bug? After several tries with different firmware versions, nothing seems to make sense for why this keeps happening, when several people don't have the same problem. I'm with an Ender 3 with a SKR mini E3 V1.2 and a BLtouch V2.1. Let me know if there's any other information that may be prove usefull on solving this problem and I'll try to debug it along with you guys, if you don't mind.
HooverC91
commented
4 years ago Following and willing to provide input. I have a Prusa Bear with both a PINDA and a Genuine BLTouch 3.1 and noticed the BLTouch has far worse results than the PINDA (as if its compensating some but not enough). I tested this by greatly skewing the bed and printing first layer tests. The only difference is the mounting location- PINDA (23, 5, 0.68) vs BLTouch (-24.3, -34.1, 2.13)
hitbyatruck
commented
4 years ago As of now, the current bugfix 2.0.x seems to be working out ok... so far, at least.
thinkyhead
commented
4 years ago Good to hear that the current bugfix ABL is behaving. ABL has been pretty solid on our test machines, but I still hear about some anomalies related to …maybe… soft endstops. We're not entirely sure. But, between prints there seems to be an accumulating error in Z. Other than that, the compensation does follow the bed contours when it's supposed to.
For troubleshooting leveling and getting a deeper look at what might be going on, the DEBUG_LEVELING_FEATURE adds a lot of extra logging that appears with M111 S32. But for checking whether the leveling at a particular spot on the bed is correct, the combination of that with M114_DETAIL allows you to:
G29 Q to get a report of bed leveling compensation at the current point, and alsoM114 D to get deeper details about the steppers and leveling calculations.thierryzoller
commented
4 years ago Sorry to rain on the parade @hitbyatruck - latest bugfix0.20 (today) didn't fix anything and introduced Y stutter (other issue). Hence why keep this issue is open, still waiting on way to help solving it. Also changed softstop to -10, didn't change a thing.
My video shows it crashes the bed, provided full logs. Was waiting on what to do next. What should I do next?
thinkyhead
commented
4 years ago Thanks for all the data. At this point you will have to wait for someone with troubleshooting and coding ability to install the latest Marlin on a test machine, investigate the issue, narrow down the cause, and hopefully resolve the issue and submit a patch for testing.
GhostlyCrowd
commented
4 years ago Still tracking down the cause. If someone knows a particular version of Marlin where it's still okay, that would be useful data. I'll be able to get into troubleshooting this issue in about 12 hours….
If it helps every person with ABL issues who has rolled back to 2.0.3 is 100% happy that i have personally rolled back. Many of them are too busy printing to move forward again to test, I have one friend who is willing to test as soon as this last batch of PPE is done. Also UBL does no suffer from this issue, but as stated above it appears to be a mesh inversion or non-iversion, related to no respecting the inversion or lack of in the axis in the firmware.
thinkyhead
commented
4 years ago it appears to be a mesh inversion or non-iversion
We'll see. I have closely examined the log output from @thierryzoller and @ziporah related to how turning leveling on and off affects the current Z position and the underlying stepper count. Everything there looks appropriate.
A very simple controlled test that anyone can try is to make a fake mesh that is all zeros to start with, and then just change the center point value. Do small and large moves around the center to see how the nozzle behaves. Of course, keep the nozzle above the bed so that you don't damage any components.
Start out with the Z Fade turned off so that you get full Z adjustment at any height. Later, experiment with how changing Z fade affects movement. We've tried to make changing the Z fade during segmented movement a safe thing to do. However, it's not necessarily recommended, so during testing only change Z fade in-between moves.
By using very controlled numbers and a very controlled set of moves, along with detailed logging using G29 Q and M114 D (as needed) it should be obvious when Z is moving too much or too little or going in the wrong direction.
The thing to do then is to make some short, fake print job that doesn't heat up or extrude, but just turns on leveling, moves XY around, then raises Z and moves XY some more, and does this for about a centimeter in height. The G-code could contain your usual slicer start/end G-code, along with "M114 D" commands to examine any "interesting" codes that your slicer inserts.
At the end of the fake print job, try to run the fake print job again, and look closely to see if Z is getting thrown off, and by how much. Check to see if the M114 D report shows a discrepancy at the same time.
It would be worth trying G-code that contains G28 and M420 S1 at the top. And then to try again without the G28 that re-homes XYZ. Does the G28 fix the XYZ position?
Take careful note of whether your first G28 was done with a cold bed, and your second G28 was done on a heated bed. The bed can expand by a large amount, and the contours of the mesh will vary depending on how hot the bed is. For this reason, always heat your bed before you do G28 with a probe or measure your bed with G29.
Generally, should you do G28 and/or G29 between prints?
G28 is good between prints to account for expansion.G28 is not strictly needed.G29 between prints can't hurt, since heat warp isn't entirely predictable.To get a sense of how much the bed may be expanding, Marlin contains useful new feature called PROBE_TEMP_COMPENSATION. It requires the probe to have a temp sensor, but you can set TEMP_SENSOR_PROBE equal to 998 and it will just use the bed temperature. You can then use the G76 command to measure the deflection of your bed at a range of temperatures, and this will also pick up some of the error that the bed temperature might be introducing to your probe.
thinkyhead
commented
4 years ago 2.0.3
I will closely compare 2.0.3 to the code that followed. It sounds like even 2.0.4 exhibits some anomalies.
ziporah
commented
4 years ago I just tried compiling 2.0.3 and ran a test print on it, I'm not really convinced the leveling is working as expected. I reset my settings, G28, G29, Z offset measurement on probe point I2 J2, but it slams the head in the glass plate when I reload settings and restart with the measured offset. I lowered the offset from -3.50 to -3.20 and then I can start printing, but it shouldn't be off anyway. There must be something amiss by disabling the soft endstops with M211 S0. Second observation is that the leveling on the back of the plane still seems to be wrong. it still pushes the head to deep in the bed, while at front it is slightly to high. The print sticks to the bed, but I don't believe this is optimal and leveling is still not correct here. The print covers the inner 3x3 matrix, it's not a full bed coverage test
>>> M420 V
SENDING:M420 V
Bilinear Leveling Grid:
0 1 2 3 4
0 +0.203 +0.064 -0.025 +0.229 -0.193
1 -0.628 -0.116 -0.270 +0.195 -0.389
2 -0.760 -0.368 -0.017 -0.015 -0.154
3 -1.172 -0.442 -0.079 +0.150 -0.246
4 -0.963 -0.974 -0.375 +0.246 -0.106
echo:Bed Leveling ON
...
M503
echo: M851 X2.00 Y-63.00 Z-3.20I just tried compiling 2.0.3 and ran a test print on it, I'm not really convinced the leveling is working as expected. …
@ziporah
Is your bed really this un level (below) or is this part of the ABL error you are seeing? If its really this unlevel you should try to manually address that at least get the corners with in reason of each other for ABL to work, it compensates for bed level issues but it's not a miracle worker, you will still have issues on a very unlevel bed even with ABL so if your bed is indeed as below, wildly unlevel this may be part of the problem.
ziporah
commented
4 years ago I'm totally baffled what's wrong with the machine/firmware. I've leveled the bed manually several times, and I did manage to print without the ABL, before I added the BL Touch. I added it in order to get better prints, but even after running G29 several times in a row, it is showing different meshes on each iteration. Yes, the bed is heated at 60 degrees. I've already run M48 to validate the BL touch and it shows a correction of 0.026 consistent over several runs. In total madness I disassembled the bed, removed the Y axis, cleaned everything, measured all again to be parallel and sliding smooth, so I can't find nothing wrong there. I would at least expect the mesh that's measured to be the same on each run, within the tolerance of the BL touch, but even that's a dream ...
thierryzoller
commented
4 years ago @GhostlyCrowd : From left bottom to left top there is around 1mm of difference, the graph is grossly misrepresenting. ABL should easily cover 1mm from a 300mm distance. Mine is a bit more level, but still doesn't work. Not the problem.
thierryzoller
commented
4 years ago I do not have the tolerance issue that you are describing, as can be seen in the logs I posted above. So we can exclude that as the issue.
GhostlyCrowd
commented
4 years ago This is an example i just pulled from a friend on 2.0.3, 2.0.3 was the latest build where he didnt have abl issues and the bltouch failing to deploy and driving the tool head into his bed.
He is using more mesh points and extrapolating beyond the grid. Try a few more mesh points and extrapolation and see if it at leats improves your symptoms on 2.0.3
thierryzoller
commented
4 years ago BLTouch failed to deploy only in case I had a wiring issue (lose connection) - there is an issue documenting this on here.
thierryzoller
commented
4 years ago Understand that we should be looking everywhere, but as the person that has opened this issue, can we stay within that frame for a second? I have no deviation of BLTouch measures, it deploys correctly and coherently. What I am seeing is :
As promised, following the many ABL & BLTouch issues, I proceeded to debug mine.
Configuration.txt Configuration_adv.txt