Mesh Bed Compensation Screwy
-
Perfect I have this too. Was just about to write a long question about this too.
For me it seems like the duet does the compensation wrong… But as you say, it could be my Bigbox.
This is my problem:
Doing five point leveling I get this:
This is my printer head at X=0 Y=0 Z=5:
So that is in front of the printer… Looking at the five point picture. My bed "lean" to the back... But looking at the first layer it seem to overcompensate in the back. Or the sensor measure wrong.I usually measure when the bed is hot (and the hotend) but not this time...
My method is this:
-
First I measure a five point
-
Then I mechanically level the bed until all corners are within 100-50 microns
-
Then I do a mesh level now I use a smaller mesh for speed but I used a 176 points mesh before.
This is the result
This I thought should give me a very good first layer.
My duet setup is available at E3D forum: https://forum.e3d-online.com/index.php?threads/bigbox-duetwifi-controller.1766/page-12 entry 231
And this is my Duet firmware:
Firmware Version: 1.17e (2017-02-10)
WiFi Server Version: 1.03 (ch fork)
Web Interface Version: 1.14a -
-
Tried everything I can think even starting from scratch but still the same issue, I've gone back to just using it for an endstop for now until I have the patience to try again.
-
Your consistency checks indicate that the probe produces a consistent result at a fixed point, but they don't tell us whether it produces the same result everywhere on the bed. I suggest you pick the highest and lowest points from the height map and measure the probe trigger height at those points. If you find a significant difference, use feeler gauges to measure the distance between the bed and the bottom of the sensor board when the nozzle is just touching the bed, at both points. That will indicate whether the difference in trigger height is caused by varying tilt.
-
My problem seem to be the same…
Looking at the five point measuring map produced the bed is leaning towards the back...
Looking at the failed print the back is to the left of the picture. The duet seems to "over compensate" for the tilt.
This is the strange behavior I do not understand and seems like the same as pcsentinel is having.
This seem like the probe measures the "same" but the duet seem to compensate wrong...
Looking at the result from two mesh leveling's done a few hours apart it seems like it measures OK, (almost the same result but can still be wrong actual values). But I do not understand how the duet gets from this to the extrem overcompensation I get. (looking at the picture you can clearly see that the bed is pressed against the nozzle so no plastic is extruded. (the line farthest from the camera)
26.00,299.00,12.00,188.00,-1.00,32.00,9,6
0.062, -0.053, -0.030, 0.095, -0.018, 0.097, 0.110, -0.088, -0.005
0.062, -0.045, 0.095, 0.120, 0.075, 0.135, 0.097, 0.047, 0.110
0.070, 0.065, 0.060, 0.152, 0.188, 0.190, 0.293, 0.120, 0.045
0.060, 0.040, 0.110, 0.132, 0.185, 0.188, 0.095, 0.210, 0.190
0.067, 0.017, 0.122, 0.162, 0.090, 0.210, 0.150, 0.027, 0.142
-0.072, -0.013, -0.015, 0.020, 0.080, -0.005, -0.010, 0.057, -0.08226.00,299.00,12.00,188.00,-1.00,32.00,9,6
0.080, -0.043, -0.003, 0.110, 0.007, 0.112, 0.117, -0.068, 0.015
0.085, -0.025, 0.120, 0.137, 0.097, 0.152, 0.115, 0.075, 0.127
0.095, 0.082, 0.082, 0.175, 0.205, 0.207, 0.320, 0.135, 0.062
0.085, 0.057, 0.125, 0.150, 0.205, 0.210, 0.107, 0.225, 0.212
0.092, 0.033, 0.148, 0.180, 0.115, 0.232, 0.162, 0.045, 0.170
-0.053, 0.010, -0.008, 0.027, 0.095, -0.005, -0.005, 0.060, -0.078The only explanation if the bed level compensation is OK is that the measurement is unreliable.
-
Hi DC42, i'll try that tonight, but as an fyi I also tried 4 point plane correction. When I try and move the bed after this I get a small jolt on the motors, which I cant identify and then the machine locks up and wont respond until power cycled. Bed.g below.
; bed.g
; called to perform automatic bed compensation via G32
;
; generated by RepRapFirmware Configuration Tool on Sun Feb 26 2017 13:25:00 GMT+0000 (GMT Standard Time)
G90
; Clear any bed transform
M561; Probe the bed at 4 points
G30 P0 X49 Y29 H0 Z-99999
G30 P1 X171 Y29 H0 Z-99999
G30 P2 X171 Y171 H0 Z-99999
G30 P3 X49 Y171 H0 Z-99999 S4 -
There is definitely something wrong with the mesh-bed-compensation. The first thing I wondered about were the spurious pauses while printing At first I thought it is the non-extruding-move while changing perimeter.
I investigated further and found out the "stops" are at specific positions even if I move the head manually through the paneldue. When the "stops" occur the bed moves in Z-direction a significant amount (0.5mm) although it should change only gradually according to the heightmap.csv.
I then tried to find the spots where these "stops/jumps" occur and they were always at some 5mm border, for example between 184.9mm and 185mm or 74.9mm and 75mm.
To me it seems there is some rounding error which can happen more easily when using inverse multiplication instead of division, taking a first glance at HeightMap::GetInterpolatedHeightError() I couldn't spot any issue although the HeightMap::InterpolateXY looks a bit overcomplicated in favour of just clamping the values.
I guess I'll just run some tests and debug these functions hoping that these are not some compiler or CPU specific rounding errors. … -
Hi, that would definitely align with what I was seeing on the four square print as mentioned above. But I also found that after running through the compensation and then just executing a simple X move from X0 to X200 then the Z was very jumpy
-
Ok, so I loaded GrodanB's heightmap.csv and then sampled the whole bed ( HeightMap::GetInterpolatedHeightError() ) with a 4mm (and 2mm) resolution and visualised the result with excel.
The first one is rather off, the area clearly wrong. Debugging it showed that GridDefinition::recipSpacing is still at its default value (for a 20mm grid) after loading the .csv.
After fixing that it is much better, but still some hard jumps at the borders, so I'll debug the border-interpolation next.
My fixes as well as the (very shoddy) simulator I use can be found here: https://github.com/ChristophPech/RepRapFirmware
-
I just made a short video of the smooth motion without g29, and the choppier motion with.
I'm not sure if it's a bug, maybe all the variables eat up the processing power?
But I don't remember my 8 bit board doing this.
Here's the video:
https://youtu.be/igNx0sjtSqE -
I found an error in one of the interpolation functions and fixed it (pull request pending)
The result looks much better:
-
But there is still more. Zeroing out the last two columns gives me this:
The interpolation overflows into the first column of the next line. Fixing it:
The final result of the whole mesh:
looks quite good. -
And we can even do better by using bicubic interpolation:
Since Z is often the slowest axis, smoothing it out will mean smoother movement for the other axes.But there still remain two last issues: unprobed points with a 0 csv are being clamped to zero, this can easily be fixed
Second: points outside the probing area remain constant. These should be extrapolated, maybe something like linear regression.
Thoughts?
-
@CHP, many thanks for diagnosing and fixing these issues. I have accepted your pull request, and I will release a new 1.18 beta soon incorporating these changes.
-
Hi CHP, can I just say thank you for identifying this and fixing, very very much appreciated.
DC42, have you any idea what going on re my comment about 4 pont adjustment above?
thanks
-
@CHP although I only understand have of what you said(the hampster wheel in my head is seizing up), the pictures you put up show that you've found a way to wrangle the angry pixies flowing to my motors, and I thank you for it.
-
Hi CHP, can I just say thank you for identifying this and fixing, very very much appreciated.
DC42, have you any idea what going on re my comment about 4 pont adjustment above?
thanks
You need to probe clockwise round the bed, not anticlockwise. One of these days I'll get round to either re-ordering the points or generating an error message if they are in the wrong order.
-
Hi, tried this which is clockwise
G30 P0 X151 Y151 H0 Z-99999
G30 P1 X151 Y49 H0 Z-99999
G30 P2 X49 Y49 H0 Z-99999
G30 P3 X49 Y151 H0 Z-99999 S4but same result, just gives a small judder on first move after running the bed level and then wont move anymore. (Sorry)
-
Update, maybe its just my misunderstanding of how this works, but commented out last line and moved S to third line as
G30 P0 X100 Y151 H0 Z-99999
G30 P1 X151 Y151 H0 Z-99999
G30 P2 X151 Y49 H0 Z-99999 Sworks and I can then see compensation movement through moves, yet to try with a print though
-
Hi, tried this which is clockwise
G30 P0 X151 Y151 H0 Z-99999
G30 P1 X151 Y49 H0 Z-99999
G30 P2 X49 Y49 H0 Z-99999
G30 P3 X49 Y151 H0 Z-99999 S4but same result, just gives a small judder on first move after running the bed level and then wont move anymore. (Sorry)
Start with your X49 Y49 point as P0 and go clockwise from there.
-
Further Update, changed the coords so that there were four but not in a perfect square. And now it works with 4, but following running the bed compensation, Z is set to an insane neagtive number of -199.91
G30 P0 X49 Y151 H0 Z-99999
G30 P1 X150 Y150 H0 Z-99999
G30 P2 X149 Y50 H0 Z-99999
G30 P3 X51 Y50 H0 Z-99999 SGo back to 3points as
G30 P0 X100 Y151 H0 Z-99999
G30 P1 X149 Y50 H0 Z-99999
G30 P2 X51 Y50 H0 Z-99999 Sand Z after shows 5.73 and z compensation across the bed seems to work, again need to wait till tonight to try a print
