Support mesh bed probing with a custom probing grid

garethky

I designed a magnetic bed for the E3D Toolchanger and discovered that there isn't a way to do both mesh bed leveling and use custom defined probing points. This came up because the arrangement of the magnets in the bed conflicts with ideal mesh probing grid. You want the grid to be as large (x/y dimensions) as possible but this inevitable causes some points to overlap with a magnet. The magnets interfere with the inductive sensor. Prusa i3 machines had this problem when they implemented 7x7 mesh probing and they solved it by shifted the exact locations of probing to avoid errors caused by the magnets.

I'd like to discuss doing a pull request to add support for this, so some up front questions:

Does this sound like something you would take a PR for?
What UX would be preferred? I proposed modifying M557 to take a file with the probe locations because the list of points might be very large. But I can imagine lots of other ways to do it.

If we can agree on the above then the "how" part comes next. That's really the discussion I want to have before I start coding. Storage of the probed points probably has to change, this might also impact the Web UI and the way that interpolation for Z is done when printing, so I don't think its a trivial set of decisions that I want to make alone.

I filed a feature request to track this in the Github project: https://github.com/Duet3D/RepRapFirmware/issues/445

garethky created this issue in Duet3D/RepRapFirmware

closed Feature Request: Custom M557 Mesh Probing Grid #445

Veti

unfortunately that feature got removed

https://forum.duet3d.com/topic/7695/removal-of-support-for-3-4-and-5-point-g32-bed-compensation

garethky

@Veti said in Support mesh bed probing with a custom probing grid:

unfortunately that feature got removed

https://forum.duet3d.com/topic/7695/removal-of-support-for-3-4-and-5-point-g32-bed-compensation

So my idea is to support custom points for G29 specifically, not G32.

dc42

You can specify the mesh origin and spacing in the M557 command. Does this not allow you to avoid the magnets, for example by selecting probe points that are between the magnets?

Allowing the XY coordinates of the probe points to be specified individually would triple the amount of memory needed to store the height map, and substantially complicate the code to use the height map during printing.

garethky

Only if I reduce the number of sample points and the x/y size. You want lots of magnets around the edge of the bed but you also want to probe there. You also generally want a larger number of probe points to find and fix local undulations in the bed surface. If I probe only a 4x4 grid its trivial. If I try to do a 9x9 grid or more it becomes problematic.

So one thing I'm thinking of is taking the arbitrary points and using least squares to interpolate the z-height at the idealized grid locations. Then the x/y coordinate data isn't needed at runtime. The idealized grid can be used to print and the printing code is unaffected. But this would just be the internal representation. The real sampled points would be stored in the mesh file (and hopefully displayed in the web UI). The conversion to the idealized grid would happen after the file is read.

garethky

If you think this is going to use too much memory on the Duet we could offload the calculations to the SBC. Something like:

Reach the point in the program that's supposed to call G29. (say after bed heater temp is reached)
Call a macro that uses M28/M29 and G30 S-1 to probe the custom set of points you want to use and write the results to the SD card.
Somehow signal the SBC that the probe log file is ready to be processed. (not sure how)
Process the log to produce /sys/heightmap.csv in its current format. There are libraries out there for Python that could produce a surface from the probed points and then smooth and sample the surface at the locations required for /sys/heightmap.csv.
Write /sys/heightmap.csv back to the SD card
Return control to the running gcode program (again, not sure how)
G30; G29 S1; and rock on!

The only blocker I see is coordinating between the SBC and the gcode running on the Duet. I could do file monitoring from the SBC and use a pause in the gcode program and hope it all works out (which I hate as a programmer but I'm not seeing a direct way to have them interact). I'll search the forum and see if anyone has done something like this.

garethky

I did a little investigating under RRF 3.1:

M28 cant be used to log the results of commands. Anything after M28 isn't executed, its just copied into the file on the SD card. So I looked at M929, under 3.1 it does not log any information, not even direct requests for a report like M408 or M411. So there I hope that in 3.2 we will be able to log info level events and maybe these will be included. Next step is to get on the beta firmware train...