Unable to use M421 (Set Mesh Level Matrix) commands due to usage conflict

[bdowling]

I think I should have posted this over here, sorry. Realized when I couldn't find the RCBugFix branch in Dev.

https://github.com/MarlinFirmware/MarlinDev/issues/421

(Love the irony of getting it issue number 421 there though)

---

M421 are unable to be set due to a conflict in the code regarding what X and Y values are to be passed. Well, technically, I can set the X0, Y0 ;)

https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Marlin_main.cpp#L5855

The test of the parameters are checking that an index is being passed, but then those values are being handed off to the mapping functions mbl.select_x_index(x) and respective y rather than being used as an index.

I would like to propose that the interface be modified to offer consistency such that the relevant output from M503 can be pasted back into the serial to be able to set/reload these parameters if so needed. Currently M503 outputs the absolute X and Y coordinates. It could go either way, change the M503, or change M421 to accept the physical coordinates. I'm not sure how widely this is used. I think I must be the first to try. ;)

Ref: http://reprap.org/wiki/G-code#M421:_Set_a_Mesh_Bed_Leveling_Z_coordinate

Willing to submit a PR on this, just wanted to open the discussion for the above.

[epatel]

I tried to raise this issue a year ago. To no result. I consider it broken because it uses a method from mbl that was created for a totally different use.

72bf6ac

[bdowling]

FYI, M503 is rounding the mesh output numbers, where as G29 shows them in more precision. So the cut & paste I proposed above actually introduces slight variances.

G29
....
Recv: Measured points:
Recv:   2.82500  2.55000  2.25000
Recv:   2.82500  2.87500  2.57500
Recv:   2.50000  2.35000  2.20000

M503
.....
Recv: echo:  M421 X5.00 Y5.00 Z2.83
Recv: echo:  M421 X130.00 Y5.00 Z2.55
Recv: echo:  M421 X255.00 Y5.00 Z2.25
Recv: echo:  M421 X5.00 Y100.00 Z2.83
Recv: echo:  M421 X130.00 Y100.00 Z2.88
Recv: echo:  M421 X255.00 Y100.00 Z2.58
Recv: echo:  M421 X5.00 Y195.00 Z2.50
Recv: echo:  M421 X130.00 Y195.00 Z2.35
Recv: echo:  M421 X255.00 Y195.00 Z2.20

[jbrazio]

@epatel in your opinion what would be the best way to fix this ?

[thinkyhead]

I tried to raise this issue a year ago. To no result.

You can see clearly at the link 72bf6ac that I raised two points in two quick responses, but received no answer. If there was "no result" it's because the conversation was never taken up and the issue was forgotten. That's just what happens when an issue is not pressed.

So… If there is a bug in the way that these positions are being matched to grid indices, then we should fix that. I can certainly fix the output of M503. But I still believe that it's "most compatible" to have M421 use nearest-coordinates instead of grid-point indices.

[thinkyhead]

For getting proper indices to "match" a given X or Y coordinate, I suggest following this approach:

int select_x_index(float x) {
  for (uint8_t i = 0; i < MESH_NUM_X_POINTS; i++)
    if (fabs(x - get_x(i)) <= (MESH_X_DIST) / 2)
      return i;
  return -1;
}

int select_y_index(float y) {
  for (uint8_t i = 0; i < MESH_NUM_Y_POINTS; i++)
    if (fabs(y - get_y(i)) <= (MESH_Y_DIST) / 2)
      return i;
  return -1;
}

If the given coordinate is close enough to a grid point (a wide margin of half-the-space-between is given), then the nearest index is returned. For a near-matching grid this will work great. If the grid is changed or moved before re-flashing the board, code can look for a returned index of -1 to indicate that the grid is probably obsolete, and to either throw it away or synthesize a new grid.

[Roxy-3D]

But I still believe that it's "most compatible" to have M421 use nearest-coordinates instead of grid-point indices.

There is another method that might be worth discussing. I don't know if this really makes sense but I do envision people moving the nozzle to a random location where they are having problems getting the first level adhesion. This point would not necessarily be at a point on the mesh. What if instead of finding the nearest mesh point to apply the correction, we do a bi-linear correction in both X & Y of the four mesh points around the specified correction? And of course, the closer that correction is to a mesh point, the more weighting it would be given.

[bdowling]

Why does M421 need to accept non grid points? I feel like this over complicates this function and provides more confusion for the user.

What if the user has two or more flaws in their bed inside one grid region and they input them all? This is not going to give them the result they expect by allowing non-edge points. That's for finding the closest by half or the bi-linear correction. (They could up the grid size to 7x7 or It's time to get a new bed if they need that much correction! !)

Coordinates passed should match what M503 outputs. If we want to let them skip decimals, give a +-1 mm reach.

Also, can someone help me understand the overlap functionality with G29 S3? They are working on the same mbl grid, are they not?

In any case I'd like to see this simplified. When we get better at automatic mesh leveling we can do more magical things. ;)

[Roxy-3D]

Why does M421 need to accept non grid points?

I think one of the answers to this question is the fact that an imperfection in the bed is most likely to show up between a couple of mesh points and not right at a mesh point. So if you have a high (or low) spot on your bed, you will be able to see that as the first layer is going down. It is fairly straight forward to pause the print and move the nozzle to the location where the flaw is apparent. Probably, this is not at a mesh point.

But now that you know where the flaw is, what do you do about it? Probably you want to push or pull the mesh at that location.

[bdowling]

If the problem is that localised, isn't this likely to make matters worse at the local grid point and others because you are just pushing or pulling the whole plane? Possibly even hitting the bed at grid corners if Z you want to interpolate was a low spot. Depending on how far off from corners the problem is.

It might be better if this is a supported use case to increase the grid size to support smaller quadrants.

[epatel]

@thinkyhead What I meant was that I raised the question of how good that implementation was and if you look at the PR I refer to your didn't even care to compile the code before submitting it to the repo. I still think it no good to try to do this, even with a nearest neighbour. I do not want to tangle up in fruitless discussion with you yet again. (My) Life is to short. Back then I presented the facts, and really I didn't expect anyone to try it, and it took until now for someone to actually do that. Let them show you I though, you never believe me anyway. Reasons for not doing it like that is basically why re-sampling is bad, you know the Nyquist theorem etc? (apart from the broken implementation) I think we are talking about so small values and few samples that there is a need have true number and not re-sampled. I believe they could actually be re-sampled off so the effect could get a magnitude worse. Safe would maybe go from 5 to 3 or some matching steps, pruning points. I have not and I will not use this feature so I leave this discussion here.

[epatel]

@jbrazio I would ask what the feature is for, and then implements accordingly. I imagine the use case is for saving to file a grid measurement and then be able to load it again, so I would lean to using indices and be fine with that. Changing number of measuring points (re-flash printer) or changing between ABL and MBL (also re-flash) is for me totally expected times for re-probing the bed (I re-probe mine like once a month anyway). Maybe because room temperature (season change) change it topology or screws/springs holding it or what ever.