Hi @koconnor I modified my circuit a bit for the optical sensor limit switch so that it switches faster, but it didn’t help. I think the best solution for now would be to just reduce the speed to 25 for my setup only while probing for the height of components. It still compresses the nozzle at this speed for probing but just slightly - I think for now it’s manageable.
However, the issue still remains that since it’s being told MOVE=0, M114 gets updated to 0 and I’m unable to detect the actual height of components. Is there any chance you may have bandwidth to implement this?
I think it would be good to improve the MANUAL_STEPPER STOP_ON_ENDSTOP=... feature so that it can be used for probing. I’ll try to take a look at it, but I’m at least a week out from being able to work on that.
Can I ask what kind of accuracy/repeatability you get with your optical sensor and how you’ve set it up?
Any time I’ve looked at using an optical sensor, I’ve always found that the variability was too large to consider using it for the Z axis (which you seem to be doing).
I would love to be able to test it the way Klipper is recommending on that link but because position is not currently being tracked for the manual stepper, I don’t think I can do that. I think the best thing I can do is set up a scope, but I haven’t got around to doing that yet.
I’ve only tested it by manually touching the nozzle to compress it and it seems to trigger in console under 1mm for sure. But when I run it using the custom Klipper code, I see about 5mm compression before it triggers. It’s a notable difference. I’ll do my best to set up the scope this weekend… requires some soldering.
With the above, it should hopefully be possible to implement the probing movements you are looking for. Note that it will be necessary to update your macros to the new MANUAL_STEPPER ... STOP_ON_ENDSTOP=probe format. See the docs/G-Codes.md file on the development branch for the details.
If you are able to test this, please let me know what the results are (success or failure).
Hi @koconnor thanks for the update! So just to make sure I understand, I should test the work-ms-endstops branch, not the PR? And using M114 it should report the position it stopped at correct?
Yes, you’ll want to test the work-ms-endstops-20251030 branch, update the macros to use STOP_ON_ENDSTOP=probe, continue to deploy your custom M114 macro, and make sure to unmap/remap the GCODE_AXIS around any homing/probing attempts (all as previously discussed).
Hi @koconnor was this feature merged into Klipper main branch? I was planning on testing today so just double checking whether I should still download the test branch or just update my main branch to Klipper’s latest. Sorry for the delay!
The ability to “probe” using a manual_stepper was merged into the main branch. However, the ability to have multiple endstops is still only on the development branch, so as I understand it you would need to continue to use that development branch.
So I installed your test branch and first of all, the probe now works as expected where it does NOT over-compressed like it was in previous firmware versions. So whatever you changed in the code seems to have fixed it! My screenshot above is SPEED = 50 but I even tested it again at SPEED = 80 and it over-compressed by maybe just a 1mm (which is understandable since it’s moving super fast). Before it was over-compressing by closer to 5mm even at slower speeds.
That being said, the reporting seems to be off I think. I still have about 10mm of travel on my C axis. Attached my Klippy log. Any clues?
Also, you’ll need to change your MANUAL_STEPPER commands to use STOP_ON_ENDSTOP=probe . The old style (STOP_ON_ENDSTOP=2) won’t provide the new probing interface.
But your post here on the forums for the new probe setting was about a month ago. Was the code never pushed? I also couldn’t find “probe” anywhere on that commit.
@koconnor I think it’s working! I ran it twice. Second time I placed a taller object and it reported it was higher up as anticipated! This is huge for the OpenPNP community, thank you so much!! Are you planning to merge this into main?
The manual_stepper “probe” support is in mainline. The support for multiple endstops is still only on the separate development branch. I don’t have any immediate plans to merge that. I don’t want to commit it until I have a better feeling of what the long-term config format should be.
Anything I can do to help make that happen? I would love to stay on the main branch and not get left behind. I’m sure many of the OpenPNP users who would use this would love to stay on main as well
