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

bed_mesh: add support for "rapid" scanning #6617

Merged
merged 7 commits into from
Jun 19, 2024

Conversation

Arksine
Copy link
Collaborator

@Arksine Arksine commented Jun 11, 2024

This pull request builds on #6610, adding support for optimized travel paths when a rapid_scan is requested. In addition, the probe_finalize() method no longer depends on on the XY coordinates received from the probing procedure to populate the Z matrix.

The final commit in this series updates gnupru to the latest release in ci-install.sh. It appears that version 2023.1 fails due to a missing dependency.

@KevinOConnor
Copy link
Collaborator

Thanks. I cherry-picked your gcc-pru build patch.

This PR seems good to me. I think we should give a few days for others to comment, but otherwise I'm ready to commit when you are.

Not a "blocker", but have you considered using a webhooks endpoint instead of the BED_MESH_DUMP command (and have graph_mesh.py directly pull the json from the unix domain socket)? The gain would be that it would also enable the web frontends to access all this information in the future. It would also avoid having to describe the low-level details of the command, the file name, file location, file contents to users. Again, not a "blocker".

Thanks again,
-Kevin

docs/Bed_Mesh.md Outdated Show resolved Hide resolved
KevinOConnor referenced this pull request Jun 12, 2024
Instead of directly calling axis_twist_compensation, send an event
that can perform the necessary updates.

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
@Arksine Arksine force-pushed the dev-scanning-refactor-20240610 branch from 10ba63d to 6d4cdb1 Compare June 12, 2024 11:24
@Arksine
Copy link
Collaborator Author

Arksine commented Jun 12, 2024

Not a "blocker", but have you considered using a webhooks endpoint instead of the BED_MESH_DUMP command (and have graph_mesh.py directly pull the json from the unix domain socket)? The gain would be that it would also enable the web frontends to access all this information in the future. It would also avoid having to describe the low-level details of the command, the file name, file location, file contents to users. Again, not a "blocker".

I think this is a good idea. I'll rework BED_MESH_DUMP into a bed_mesh/dump_mesh API request.

@c0psrul3
Copy link

👍 this works great

KevinOConnor and others added 2 commits June 15, 2024 12:46
Add a scanning mode that does not require pausing the toolhead at each
probe point.

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
This adds supplemental path generation that implements
"overshoot" when a change of direction is performed
during a rapid scan.  This overshoot reduces measurement
error at the extremes of the mesh along the X axis.

Signed-off-by:  Eric Callahan <arksine.code@gmail.com>
@Arksine Arksine force-pushed the dev-scanning-refactor-20240610 branch 3 times, most recently from 06a650a to d89a669 Compare June 16, 2024 16:45
@Arksine
Copy link
Collaborator Author

Arksine commented Jun 16, 2024

I have removed the BED_MESH_DUMP gcode command in favor of a bed_mesh/dump_mesh API. The graph_mesh script can fetch the data in one of three ways:

  • A direct connection to Klipper's unix socket
  • The bridge connection via Moonraker
  • A json file

The json file can be created with the graph_mesh dump <input> command. This allows for users to share the dump when troubleshooting if necessary. The Moonraker connection allows users to run the script on a Desktop class PC enabling animations and live mesh previews.

@KevinOConnor
Copy link
Collaborator

Thanks. It looks good to me. If there are no further comments, I'll look to commit in a couple of days.

-Kevin

@@ -282,6 +287,32 @@ def cmd_BED_MESH_OFFSET(self, gcmd):
gcode_move.reset_last_position()
else:
gcmd.respond_info("No mesh loaded to offset")
cmd_BED_MESH_DUMP_help = "Dump mesh data to file for analysis"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor - dead line of code?

-Kevin

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Should be fixed now.

Returns current mesh configuration and state.  Includes probed and
mesh matrices, saved profiles, current points, and travel paths.

Signed-off-by:  Eric Callahan <arksine.code@gmail.com>
Signed-off-by:  Eric Callahan <arksine.code@gmail.com>
The scan modes provide kinematic XYZ coordinates in the
probe results.  These positions may deviate from the requested
positions, which can introduce errors in mesh generation when
transposing the result into the Z matrix.

Rely on the coordinates generated by bed mesh to transpose
the matrix, presuming that points at the same index in the
list match.

Signed-off-by:  Eric Callahan <arksine.code@gmail.com>
In addition, do not respond with generated points.

Signed-off-by:  Eric Callahan <arksine.code@gmail.com>
Signed-off-by:  Eric Callahan <arksine.code@gmail.com>
@Arksine Arksine force-pushed the dev-scanning-refactor-20240610 branch from d89a669 to fa5342f Compare June 17, 2024 22:07
@KevinOConnor KevinOConnor merged commit a19d64f into Klipper3d:master Jun 19, 2024
1 check passed
@KevinOConnor
Copy link
Collaborator

Thanks!

-Kevin

@Arksine Arksine deleted the dev-scanning-refactor-20240610 branch June 19, 2024 17:51
@Cereal-Killa
Copy link

Question, are there more patches to get the BTT Eddy to work on the official Klipper branch or is this it?

@KevinOConnor
Copy link
Collaborator

There are a number of features that have been discussed or are in progress. Here's my understanding of the status:

I expect the above is what most users will expect.

There are a few things in discussion that are not in mainline:

Hope that helps,
-Kevin

@Cereal-Killa
Copy link

There are a number of features that have been discussed or are in progress. Here's my understanding of the status:

Hope that helps, -Kevin

Absolutely, in this case I'll stick to the BTT branch for the time being, specially due to the homing feature.
Thanks Kevin

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

Successfully merging this pull request may close these issues.

None yet

4 participants