[BUG]: X and Y coordinates of graph doesn't match the actual locations

[Favmir]

Describe the bug
The X and Y location of the graph uses Octoprint's printer profile's custom bounding box as its base. However, the actual locations the probe hit the bed are also affected by 1. probe offset and 2. bed margin

1. If you set your custom boundary to be 0~235 the bed leveling data will tell you the coordinates (0, 59, 118, 176, 235) has been probed. However, since my printer's probe is offset 27 to the left compared to the nozzle, in reality it has actually probed (0, 52, 104, 156, 208). It simply cannot probe at 235 due to machine limitation.

2. By default marlin has about 20 margin away from the bed edges. <Configuration.h> #define PROBING_MARGIN 20 This means the leveling mesh will actually be the size of 195x195(instead of 235x235). But the graph will still tell you that you've got a mesh of 235x235.

Firmware and Version
Marlin 2.9.0.3

[jneilliii]

You are correct, the graph does approximate based on the printer's profile and a division of the number of reported points. There are older versions of Marlin that would actually report the x, y, and z of the points and the plugin does read that information that is reported that way. There's also lots of different options for how bed leveling is configured and supporting all of them is fairly unrealistic, hence the approach taken.

[Favmir]

You are correct, the graph does approximate based on the printer's profile and a division of the number of reported points. There are older versions of Marlin that would actually report the x, y, and z of the points and the plugin does read that information that is reported that way. There's also lots of different options for how bed leveling is configured and supporting all of them is fairly unrealistic, hence the approach taken.

So it's just a visual thing and bed leveling itself is working fine, right? That's what I was most worried about.

As for the bug, maybe user manually inputting the min/max probing locations could be a better solution, rather than using the Octoprint's bounding box. It took me quite some time to figure out which setting was changing the graph's size.

[jneilliii]

So it's just a visual thing and bed leveling itself is working fine, right?

Correct, it doesn't actually effect what the firmware sees or does, it's just a visual bug/inconsistency.

rather than using the Octoprint's bounding box

Yeah, it could definitely be a potential solution. if custom bounding box isn't enabled in OctoPrint it uses the bed size of the profile. The only unfortunate side effect of that approach is then the visualized 3d bed doesn't match the actual bed dimensions and would be reduced in size and might then cause confusion from that perspective. Would have to ponder/experiment a bit to see if there's a compromise between the two.

[jneilliii]

Maybe something like this where I just put a simple plane that is equal to the bed dimensions and averaging all the probe points heights?

[jneilliii]

I just realized after starting to look at the settings interface that the current release candidate branch already includes probe offset options.

https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/releases/tag/1.1.2rc2

If you want to test it out to see if it works for your request that would be great. Go into OctoPrint's Software Update Settings and change the release channel for the plugin to Release Candidate and upgrade when prompted.

[Favmir]

Oh? Awesome! I'll try it out asap

[Favmir]

I have installed the test branch and tested it. The offset settings are there, but they don't seem to be doing anything at the moment. The graph and the data sheet report the bounding box numbers regardless of the offsets.

[jneilliii]

Did you run update mesh after setting the numbers? Can't remember exactly where I was with that and think it might do it while collecting the data. In either case, I've made some progress with this other approach. Averaging the 4 quadrants to get heights for each corner and drawing a 50% transparent reference plane.

[jneilliii]

slightly better view showing the inset probe points.

[Favmir]

I've found the cause. The offset only applies when you have custom bounding box disabled.

The x and y values on both the graph and data sheet change now that I've set the printer's bed size as limit, but the 50% transparent bed isnt' showing up yet. I'll try to find the cause for that.

Btw, the purpose of the transparent plane is that users should try to align the bed with the suggested height, right? But I personally think it'd be more useful if the transparent plane was representing the z=0 plane instead. Some printers use z endstop to set the coordinates and use BLTouch to compensate, and some other printers that don't use z endstop set z=0 using the height of the middle point — both could use the z=0 indicator for help. Meanwhile I don't think the graph needs another indicator for suggested average height, since the graph's color is already doing that very well…… Although I didn't think throughly enough to be sure that this is the best idea myself.

[jneilliii]

The transparent plane changes haven't been uploaded yet. Still messing with it. The idea with these last changes was to graph a representation of the bed's tilt but as a single plane rather than multiple probed points. In theory, one could use that simpler 4 point plane to quickly adjust screws and potentially have it replace the current corrections matrix with just 4 points with turn angles.

[Favmir]

The transparent plane changes haven't been uploaded yet. Still messing with it. The idea with these last changes was to graph a representation of the bed's tilt but as a single plane rather than multiple probed points. In theory, one could use that simpler 4 point plane to quickly adjust screws and potentially have it replace the current corrections matrix with just 4 points with turn angles.

Sounds nice. I probably didn't understand your intentions because I don't use the corrections matrix myself. I'd love it if you could address the 'offset not working when custom bounding box is on' thing as well while at it. I'll make sure to test the new transparent plane when it drops!