Grid bed compensation
-
You asked for grid bed compensation to be added to RepRapFirmware, and now you can preview it in the latest developer build (1.17dev6). In brief:
1. Define a grid like this:
M557 X20:180 Y20:180 S20 ; define a grid covering the XY area indicated with the specified grid spacingor:
M557 R100 S20 ; define a grid with the specified radius and spacing (for delta printers)If you provide both X and Y ranges and a radius, then the intersection will be probed.
2. Send G29 to probe the bed.
3. If you want to view detailed results, download file /sys/heightmap.csv. The first 3 lines describe the parameters of the grid. After that come the height measurements, 1 row per scan in the X direction from lowest X to highest X. The rows are ordered from lowest Y to highest Y. A value of 0 with no decimal point means that the point was not probed because it fell outside the defined grid radius or was inaccessible due to probe offset.
Those of you with programming experience may wish to turn the data into a graphical height map. I am hoping that this can be included in DWC eventually, if HTML5 and Javascript are up to it.
Please note, I haven't implemented G29 S2 (load height map from file) yet. Also, any sort of G32 probing cancels the height map. So on a delta printer you need to run auto calibration first and G29 second.
-
As an example I ran a quick probe on my BigBox bed:
[[language]] RepRapFirmware height map file v1 generated at 0116-10-24 07:54 xmin,xmax,ymin,ymax,radius,spacing,xnum,ynum 30.00,210.00,30.00,150.00,-1.00,60.00,4,3 -0.024,0.090,0.206,0.399 0.065,0.175,0.250,0.327 -0.049,0.111,0.249,0.405And I thought my bed was flat!
-
That works brilliantly. Word of warning if doing this on a delta set a radius carefully to avoid crashing the head into anything near the edges of the bed.
So does this apply compensation when printing or is it currently just for measuring?
Pretty flat though (its tooling plate).
RepRapFirmware height map file v1 generated at 0116-10-23 11:56
xmin,xmax,ymin,ymax,radius,spacing,xnum,ynum
-120.00,120.10,-120.00,120.10,150.00,30.00,9,9
0,0,0.024,0.030,0.001,-0.091,-0.119,0,0
0,0.062,0.054,0.033,0.040,-0.029,-0.014,-0.087,0
0.026,0.047,0.056,0.005,0.048,0.031,0.054,0.014,-0.024
0.045,0.042,0.030,0.024,0.016,-0.021,-0.024,-0.027,0.034
-0.001,-0.035,-0.000,-0.029,0.018,0.015,-0.004,0.046,-0.001
0.019,-0.001,0.068,-0.065,0.011,-0.015,-0.006,-0.010,-0.001
-0.011,-0.042,0.005,-0.041,-0.020,0.020,0.015,0.023,0.020
0,-0.022,-0.018,-0.005,-0.021,0.025,-0.024,-0.035,0
0,0,0.032,0.051,0.052,0.041,0.041,0,0 -
Yes it does apply compensation when printing in the dev6 build.
-
David Does it take account of the H Offsets from the Bed.g for a delta? or at least an approximation of them
-
It works. Even with an autocalibration deviation of 0.2, I wasn't getting an even 1st layer over the whole bed. Now I am.
-
The autocalibration takes account of the H offsets in bed.g but the grid bed compensation doesn't.
-
@dc42 isn't it G29 S1 to load a height map? S2 is described to clear the map…
-
Is there a file that is executed before the probing is done and after? Like "bed.g" for the simple bed leveling?
I am playing with the BLTouch and I have to deploy it before and undeploy after… -
DC42 how would you like us to report errors when testing the dev branches? I also posted this on github just copy/pasting it here to cover all bases.
Not sure how you would like testers to report potential problems from the testing of the Dev firmware. At least this initial time I will post both here and on duet3d forums to find out where you would prefer reports be placed.
Machine: C-bot Variant CoreXY
Board: Duetwifi 1.0
Additions: 7" Paneldue, IRProbe
Firmware Version: 1.17 Dev6Description of problem and steps taken to produce:
Following Gcodes entered manually.
M557 X30:290 Y70:290 S40
G28
G29Response from system after G29 finishes:
Height map saved to file heightmap.csv - 42 points probed, mean error 0.11, deviation 0.24
Checksum error on line 203652Additional notes:
I did this 2 other times while adjusting the grid boundaries to make it probe the area of the bed i wanted.
the following checksum errors also occured
Checksum error on line 202354
Checksum Error on line 202718 -
Is there a file that is executed before the probing is done and after? Like "bed.g" for the simple bed leveling?
I am playing with the BLTouch and I have to deploy it before and undeploy after…I could be wrong, but in the web interface, clicking the "Auto Bed Compensation" button enacts the bed.g file, so you should be able to G28, deploy probe, G29, retract probe, move to wherever you want inside of that file and that should cover you.
-
Yeah well I can write macros, actually I have them, and use them…
-
Yeah I put the G29 into my bed.g after delta autocalibration.
-
Oh that's a nice trick, didn't think about that, I can remove all the G30 from bed.g and just replace it with G29 and keep the deploy and undeploy sequence…
-
Sniffle, thanks for your report. Reporting bugs here is best. Were you entering the commands on PanelDue, the web interface, or via a USB host when you got those checksum errors?
Alex, I had forgotten that there are probes that need to be deployed. I could make it call deployprobe.g and retractprobe.g at the start and end of G29 S0. But I am now wondering if there is any point, since the bed compensation runs G32 and you can do the deploy and retract in there.
-
David
Is that to say that running a G29 will run the Auto Cal on a delta First before doing the grib Comp.?
I was just going to add G29 at the end of my Start Script in s3d but if I can just replace the G32 with G29 it will be easier
Doug
-
When I tested it yesterday running G29 just does the grid levelling.
If you put G29 into your bed.g after autocal then it will do both when you run the file from start gcode with G32. -
David: it depends on how you rate the new feature.
IMHO G29 is an improved version of G32. Though G32 is not a real feature, at least in RRF. G32 just executes the bed.g script which is just a execution of multiple G30 commands. So G30 with the plane calculation is the real feature.
So what if we declare G32 is bed compensation and G30 and G29 are just two different methods to compensate.
That way we can use bed.g and it depends on what's in it which compensation is done.On the other hand if you see G29 a replacement of G32 or an alternative then you should allow probe management for G29 too with special macros.
I vote for what I wrote first… I admit I had problems understanding it myself at first, that's why I wrote all the posts above. But now I thought about it and I think using G32 as a general bed compensation command is WTG...
-
+1 for Alex's approach. Keeping bed.g as theeditable single point for defining what happens makes the most sense.
-
For this nothing has to be changed, it is just a definition. But the documentation should probably be updated to emphasize this…
