I’ve been using hte printer quite a bit now, and one thing that bugs me is that I want to reduce the time that bed levelling takes.
G34 will report the offsets from the first run, so I have a data point that I can use for how far off the endstops are. I’d like to use M666 to tweak that, ideally so that the G34 command at startup becomes redundant, and I can just use the bilinear levelling by itself. Or, at most, have the motor levelling complete in a couple of passes.
I’ve been looking for M666 examples, and they all seem to assume only 2 motors. (And the offset applies to the second, if I read correctly.) This is fine for the CNC, but with the CNC I can physically adjust the endstops more precisely, and frankly the required precision is actually less.
So how do I set 2 different offsets for the Z axis relative to Z1? The Marlin documentation is useless here. I mean, I could leave it alone, but having a visible adjustment the first iteration of G34 kind of irks me.
That would be cool. It does say “multiple endstops” Have you tried M666 Z2 .06 ? I had not even considered this, it makes sense we get a very exact number.
You could also lower the threshold a bit so it gets there faster…or if you enter the coordinates of your screw posts it also gets there faster. I did this initially but realized it would not work for users that scale the build. The third way to speed up the physical level is fine tune the multiplier. I did a bunch of tests and these work well for my build but maybe yours is differnt. I think I get there within three tries, every once in a while it takes all of them.
Oh, you can also speed up the probing travel moves and the fast Z part, and lower it to a smaller number I use a large offset in case of large deviations.
At that point I only do the physical leveling for small prints 3x3 or less. I will only run the grid/mesh if I am doing bigger stuff.
Heffe just checked his saved mesh from ~6months ago or more if I remember correctly and it was within 0.01mm or something crazy. So you can generate the mesh save it and load it each time. To speed up that bit. I am a little hesitant about this because we use both methods, but heck maybe it makes it even more accurate?
All that to say, there are a ton of options now and you know me once it worked well I stopped fiddling so I am sure I left a lot of performance on the table.
I did think most of the physical leveling stuff is under documented, I want to revisit it and submit some clarifications to the Marlin documentation. For example to specify the Z post locations what is the reference, the bed 0,0 I assume?
If you get the M666 to work we should get that submitted to the Marlin page, at least an example.
I did try entering the Z post locations, and it was faster, but a little weird. The post locations are relative to the 0, 0 point as entered, so #1 is in negative X space. I changed that though when I was re-sizing the bed and so forth in the configuration files.
I lowered the threshhold a little, but sometimes it still takes the full # of tries, so I put it back, then adjusted it again. I’ve been tweaking the amplification factor as well. I think there must be some sort of random factor, because it should get the same results every time, or really close to them.
To me, the ideal would be that I could save the endstop offsets, and the bilinear level map, just load the whole thing up, and get an excellent first layer straight from home.
Well, it is a “nice to have” thing. It’s working well as is, but I’d like that one step further.
Oh nice you have been poking at it. I am not sure why sometimes it does take all the tries, I find that odd. When I adjusted the amplification or whatever it was called, I think that made a significant difference in that. As I have it now I typically get it in 3, but if not it takes 8 and gives up. When I had the value lower, it would get it in 4-5 every time.
I am interested in M666, maybe I can mess with it this evening. The instruction build is ready to mount the wired up hot end and probe, so that would be a good reason to finish it and poke at the settings a bit.
Worst case is it could be an effect of the relatively lower resolution Z axes. I think if you lower the current, the chance of it taking tiny microsteps goes up, so maybe we would get better resolution at a lower current? (I know that the steppers really can’t take one 32nd of a step, but they can land on it if it is at least 10 steps away or something like that). Or maybe turn off interpolation on the Z axis, 256 microsteps might mess with it as well…all things I do not understand and trust to be making tiny steps better, I know they are good for large or fast but maybe not tiny.
Well I guess to add to this…what sort of level should we be working towards? If we mesh level anyway, what is a good physical value? With a repeatability of 0.005mm (AntCLabs), 0.005mm the size of our microsteps (I think), and a target of 0.04mm it seems doable (8 micro steps). At the same time with a first layer height of .2mm - .35mm that seems a bit excessive across a 200+mm bed.
For the levelling that I do on my Duet machine, I aim for within .05mm, which is a full order of magnitude less than the precision of the sensors. At .05mm, my first layer remains acceptable, with maybe a bit of squish at some points, but generally good finish results. It’s good enough for bed adhesion and avoids most elephant foot problems, and is well within any reasonable tolerances that I might have for printed object layer height.
I was also looking at this kind of thing for RepRap Firmware. M666 is only for Deltas in RRF, so there’ no direct equivalent.
Just in case anyone is wondering though, you can definitely make adjustments like this though, since everything is gcode. I am going through this for converting my LowRider to RRF. Making the adjustments to Z squaring is easier in firmware than hardware. This is partially the fault of my stop design, which I should improve, and partly just that it’s a pain to get in there with a screwdriver because the one adjustment is jammed into the corner of the room, and my knees don’t like me squatting down to where I can reach the adjustment screw, even less so in cramped quarters.
It does three point to physically level the bed (as many times as needed), then it does as many points as you want to mesh level it.
The part we are trying to speed up is how many tries it takes to get the first physical level to within the tolerances we set (0.05mm across the entire bed). To speed up the mesh level you can only speed up travel moves.
The Amplification parameter of G34 lets you increase the “swing” of correction for each attempt. I don’t recall the specific values, and I’m not where I can check at the moment, but when I first enabled auto Z levelling it used to take multiple round of up to 5 attempts. I’m pretty sure I increased the amplification setting, and now it rarely takes more than 3 attempts to get the bed levelled within the tolerance.
If I recall correctly, when amplification is too high, then the corrections “overshoot” and never succeed, so it was pretty easy to optimize. Keep increasing the A parameter until levelling fails, then back it off a bit. The allowable range for A is from .5 (dampened to 1/2 gain) to 2.0 (double gain). I’m guessing a factor of 1 means no boost or dampening.
That is good to know! We currently have it set to 1.55. I can run the tests again and have a look at the numbers to see if they overshoot and by how much. The tough part is how is it going to do with a 200^2 bed vs a 350^2 bed?
I think it does the math based on where you tell it the sensors are, so I wouldn’t think bed size would be a factor (other than travel time between the sensed locations).
There is an option to tell it where the lift points are but we do not use them, because of how it can vary, at that point I do not think it uses the amplifier.
