Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Favmir opened this issue Jun 14, 2022 · 12 comments
Open

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

Favmir opened this issue Jun 14, 2022 · 12 comments
Labels
enhancement New feature or request

Comments

@Favmir
Copy link

Favmir commented Jun 14, 2022

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
Copy link
Owner

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
Copy link
Author

Favmir commented Jun 15, 2022

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
Copy link
Owner

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 jneilliii added the enhancement New feature or request label Jun 15, 2022
@jneilliii
Copy link
Owner

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?

image

@jneilliii
Copy link
Owner

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

image

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
Copy link
Author

Favmir commented Jun 16, 2022

Oh? Awesome! I'll try it out asap

@Favmir
Copy link
Author

Favmir commented Jun 16, 2022

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
Copy link
Owner

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.

image

@jneilliii
Copy link
Owner

slightly better view showing the inset probe points.

image

@Favmir
Copy link
Author

Favmir commented Jun 16, 2022

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
Copy link
Owner

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
Copy link
Author

Favmir commented Jun 16, 2022

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants