Grid bed compensation
-
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…
-
David, those errors were reported on the PanelDue, they did not occur or at least not reported on the web interface.
As to the above discussion of using bed.g as the single point of reference for enacting whichever compensation you want i definitely agree, but whats the difference between the spiral 5 point compensation and G29… I was expecting G29 to be an automated version of the later.
Is G30/3G32 Planar and G29 mesh? I'm sure its just a matter of terminology crossing my understanding wires.
-
David, those errors were reported on the PanelDue, they did not occur or at least not reported on the web interface.
What I meant was: did you enter the M557 and G29 commands on the PanelDue keyboard, or by some other means?
As to the above discussion of using bed.g as the single point of reference for enacting whichever compensation you want i definitely agree, but whats the difference between the spiral 5 point compensation and G29… I was expecting G29 to be an automated version of the later.
Is G30/3G32 Planar and G29 mesh? I'm sure its just a matter of terminology crossing my understanding wires.
The 5 point compensation requires you to set up a bed.g file (or set up the points using M557). It works on Cartesian and CoreXY printers only. You have the option of including trigger height corrections for each probe point, although it's unlikely that you would need to do that on a Cartesian or CoreXY printer.
The new grid compensation can probe a much larger number of points (currently 121 on the wired duet and 441 on the Duet WiFi). You define the area to be probed and it works out the probe points. It can be used on delta printers too. You can't enter trigger height corrections.
-
I found a little issue with the Z offset and dive height. It seems both are connected somehow when probing.
IMHO this is not ideal.
Let me describe it a bit…Lets assume we have a probe which triggers when the nozzle is 2 above the bed. So with a Z offset of 0 and a dive height of 3 when probing the bed moves to Z=3 and the probes and so on.
If you already adjusted your offset to 2 so that the nozzle touches the bed then the bed just dives by 1. I think that's because the dive is calculated from Z0 which I changed by setting the offset.
So if I have to change my offset every now and then I also have to adjust the dive height and add the offset to the desired dive height.I stumbled over this issue again because of playing with the BLTouch.
The problem here is that if the nozzle touches the bed the BLTouch is not able to trigger because it is already triggered. So if I start with a Z offset of 0 and a dive height of 2.5 then all is fine, probing is fast because the bed is just about 1 away from the trigger pin.
But when I now adjust the offset so that my nozzle touches the bed and the BLTouch lowers the pin it already hits the plate and is triggered resulting in alarm state which will break the probing sequence.IMHO the offset should not influence the dive height, the dive height should always be calculated from the trigger point of the probe and not from the Z0 location.
-
441 on the Duet WiFi
I wonder how long a probing sequence will last if you max that…
I won't try until I am not able to load the result back in
