-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
probe_eddy_current: implement surface scannng #6558
Conversation
Thanks! I have some high-level comments:
Thanks again, |
Hi Kevin, I'll try to address each question comment.
Bed Mesh could instantiate the ProbeScanHelper rather than go through the ProbePointsHelper. I avoided this since I thought the ProbeScanHelper might be useful for other modules that use the probe. Other than that, I'm open to ideas, but I'm not sure if there is a better way to handle it.
They are an enhancement, however its necessary to get the best results for a "rapid" scan. Specifically the rapid mode works best when some overshoot is applied to the points where a change in direction occurs. It also helps to add some curvature to the direction change. In addition its necessary to avoid entering faulty regions if possible. I had considered refactoring Bed Mesh's "points" into a generator previously. Since point generation is configurable at runtime and
I agree. FWIW, when performing a traditional probe (typically during QGL) on occasion I get a "Unable to obtain probe_eddy_current sensor readings" error. I suspect this is a timing issue, the samples are still being collected by the bulk interface and the bulk callback has yet to be triggered. The fix may be as simple as increasing the delay to .3 seconds. |
Hi. Sorry - been super busy the last couple of weeks.
That makes sense. I'll take another look over the next few days to see if any ideas "pop up" for me.
I agree on the utility of the functionality. I was more wondering about merge ordering - possibly merging basic scanning and then advanced scanning on top. Not a big deal though.
One thing to note is that the current probing code calls I did not see an equivalent mechanism in the new scanning code, but it's possible I missed it. If If samples are started once for all probes, then there shouldn't be timing gaps in the reports. So, if you're seeing that then we'll need to track down why it is occurring. If you've got a test case that shows it I'll try to reproduce it here. Thanks again, |
Completely understand, we'll get it done on your timeline.
Ah, I see. I think it would be possible to just pick commit f359e43 if that is what you would prefer. I did attempt to perform thorough testing of the Bed Mesh changes, although there is always the chance of a regression with this kind of change. In the event that something strange pops up a user can dump the entire mesh state using the new
I haven't run into the issue with scanning. The diff --git a/klippy/extras/probe_eddy_current.py b/klippy/extras/probe_eddy_current.py
index 2b78464d0..a1a1c271c 100644
--- a/klippy/extras/probe_eddy_current.py
+++ b/klippy/extras/probe_eddy_current.py
@@ -266,7 +266,7 @@ class EddyEndstopWrapper:
while 1:
systime = reactor.monotonic()
est_print_time = self._mcu.estimated_print_time(systime)
- need_delay = self._trigger_time + 0.200 - est_print_time
+ need_delay = self._trigger_time + 0.300 - est_print_time
if need_delay <= 0.:
break
reactor.pause(systime + need_delay) |
Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html There are some steps that you can take now:
Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available. Best regards, PS: I'm just an automated script, not a human being. |
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>
In addition, do not respond with generated points. Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Dumps mesh data to a file. Includes current probed and mesh values, 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>
Add a ProbeScanHelper that samples points without lifting the tool, and optionally without stopping the tool. Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Add documentation for surface scanning, the new BED_MESH_DUMP command and the graph-mesh.py script. Signed-off-by: Eric Callahan <arksine.code@gmail.com>
41bfe88
to
f6bd5da
Compare
Thanks again for working on this. Again, sorry for the delay in responding. My main feedback is that I think we should refactor the probing interface prior to merging this code. I can do this refactoring work, and I can have something up for review next week. I think we should do the refactoring first, as I fear if we add more code with the existing probe interface, it will be increasingly difficult to perform a refactor. In the future, it seems there are going to be 4 different probing mechanisms with the ldc1612: "descend_until_trigger", "scan", "rapid_scan", and "descend_until_tap". There are also 4 different "probing classes" in Klipper today: probe.py, bltouch.py, probe_eddy_current.py, and smart_effector.py. I think we can rework the "probing interface" in all of these classes so that we can better support the different probing mechanisms in the future. Roughly, here's what I'm thinking we can change the probing interface to:
I'm hoping that the above interface will scale to future ldc1612 and loadcell requirements. With this interface, I don't think we would need specific "scan" logic in What are your thoughts on the interface? Some other notes:
This is all up for discussion, so let me know what your thoughts are. Thanks again, |
Thanks for the feedback Kevin.
This sounds like an improvement. I agree that we need a better way to handle all of the different ways a probe sample can be taken. Presumably we would still keep
Indeed I left it out. I'm surprised it works without the decorator, that could be a Python 3 thing.
Sounds good to me. In summary, it looks like we can remove |
Hi both, when we can expect to see this changes? |
Closing this PR, as it has been superseded by #6617. |
This is a re-creation of PR #6537, rebased against master now that the ldc work has been merged. The first pull request was against the work-ldc branch, so the PR was closed when the branch was deleted.