Brainstorming for mesh bed limits.
-
I am helping from time to time some first time duet users with there config.
One of the major complaints is always "mesh bed not working". This is due the fact that when the M208 limit is at 0 the machine will not go "past" it when the meshbed is negativ.What would be a beginner friendly fix for it? Could we add a new Paramter to G29 which overrides M208 and set that to default.?
Could we let DWC print and error in the console when the machine can not compensate the mesh due to the limit.
I know ist no "major" problem but other firmware handels is diffrently. So new adopters are a little confused. And on some "spaces" in the internet they then say that mesh bed ist not working with RRF..... This was also the case with the low M566 value from the config tool.
-
@pcr good idea!
My suggestion would be to do a comparison between the mesh min and current M208 at the point the heightmap is created and/or loaded and flag a warning in console (similar to the large offset one). Wouldn't need to be too fancy, but should be quite obvious. Or at least gives a warning message that is quick and easy to Google!
-
@pcr said in Brainstorming for mesh bed limits.:
This is due the fact that when the M208 limit is at 0 the machine will not go "past" it when the meshbed is negativ.
Well keep in mind...
- there is no requirement that M208 sets a min axis limit to 0
- there is no requirement that M208 sets the limit of axis travel, it may only set the limits of the printable area
- you can run into problems at either the min or max axis limits set by M208 depending on the XY offsets of the Z probe
- if M208 does not specify the limits of axis travel you can run into problems at either at the low or high end of travel depending on the XY offsets of the Z probe
For the firmware to generate user friendly messages about the possible problems we would need another command to specify the limits of axis travel IF M208 specified the limits of the printable area.
If the firmware had access to all needed data you could actually have a new command that would simply compute the largest possible mesh grid for you. That could make things simple and foolproof.
Frederick
-
-
@engikeneer Yep about Z0.
@fcwilt M208 is like software endstop for the axis
-
Oh, this is still a problem? I remember reading that this was fixed and the mesh code would actually go below Z0...
-
@pcr said in Brainstorming for mesh bed limits.:
@engikeneer Yep about Z0.
@fcwilt M208 is like software endstop for the axis
Understood - perhaps you should add a mention of Z in your original post.
Thanks.
Frederick
-
@pcr said in Brainstorming for mesh bed limits.:
This is due the fact that when the M208 limit is at 0 the machine will not go "past" it when the meshbed is negativ.
I'm not sure what you mean by this. As stated, this is not correct. If the mesh is negative, it will allow the head to move below 0 to reach it. The only limitation on negative moves is baby stepping manually will not let you go lower than the first layer height unless M208 Z min is negative.
-
-
If what you say were true, mesh compensation would be useless because it could only compensate for areas that are higher than 0 and ignore areas that are lower than 0. That's simply not the case.
-
@pcr said in Brainstorming for mesh bed limits.:
@phaedrux is this really right? @jay_s_uk and me got this problem in the past.
Easy enough to check:
- create a 4 point height map covering the whole bed with significant displacements from Z=0 at the corners.
- establish Z=0 well off the bed
- move to the 4 points and see what happens
Frederick
-
@phaedrux that's what I want to say. I had this problem
-
Two issues with soft limits here. One is X and Y bed limits and the other is the Z limit.
For the Z limit, I set the M208 for Z to be -4:<max Z>. Then I use a straight G30 to set Z = 0 to the probe trigger position. The -4 lets me (and the bed mesh generator) travel to -4 in the Z direction (past the probe trigger position).
For X and Y, I set the mesh limits to factor in the probe X and Y offset. In my case the probe is in the positive X half of the bed, so my minimum mesh edge is X=0, and my maximum mesh edge is Bed width minus the probe X offset. In fact, I use a global variable to capture the probe X offset. This way I can use the variable in the M557 command and not need to remember to change it if I adjust the probe position. On my printer the M557 mesh bed call looks like this:
M557 X0:{345 + global.Z_probe_Xoffset} Y{5+global.Z_probe_Yoffset}:345 P5 -
@mikeabuilder said in Brainstorming for mesh bed limits.:
For the Z limit, I set the M208 for Z to be -4:<max Z>. Then I use a straight G30 to set Z = 0 to the probe trigger position. The -4 lets me (and the bed mesh generator) travel to -4 in the Z direction (past the probe trigger position).
That should not be necessary.
I will have to run a test to verify if mesh bed compensation is working as described.
Frederick
-
@pcr said in Brainstorming for mesh bed limits.:
@phaedrux that's what I want to say. I had this problem
Can you elborate?
