Z_CLEARANCE_BETWEEN_PROBES RCBugFix #4913
Labels
Comments
|
Let's take a look. Get the latest |
thinkyhead
added
Bug: Potential ?
Needs: More Data
|
Link on Youtube (https://youtu.be/UeRB-Q4rdfM) |
|
It looks like the moves are being attempted, but are not succeeding. Are you using 32x microstepping on your Z axis? What are your settings for |
|
I use 16x stepping, Z_PROBE_SPEED_FAST lower brought no change (motor was slower and louder.). working config rc : not working config rc_bugfix: |
|
Getting the same issue but intermittently, sometimes it retracts, othertimes its hit or miss |
|
Which endstop pins are your BLTOUCHes connected to? And are you using Notice that the If the probe is connected to the I'm working up a PR that adds conditions so the |
This was referenced Sep 30, 2016
|
Mine is connected to the Z_MIN, Not using Z_MIN_PROBE_ENDSTOP I tested this changing the Servo Delay to 75, then 100 but neither effected it. On an related note, when it does fail, it ALWAYS fails on the 6th to 7th probe (Using AUTO_BED_LEVELING_LINEAR) See video |
|
The BLTouch behavior was changed in recent weeks only to retract the BLTouch in-between probes. I can't see why a raise would be aborted, since the Z min endstop isn't checked for moves away from the bed. Do you see any difference if you do I made a small patch to Why does the BLTouch probe go into error condition? I couldn't tell what was setting it off. So far the log indicates that the raise is being sent, but as your video shows, the move is not completing. Moves are not typically aborted, unless they are moves towards an active endstop that has been triggered. I can write code to test for that and add debugging. Please post your Configuration files also. |
|
Tested with the latest but as you guessed, did not fix the problem. G29 E does seem to be more reliable but still gives errors (on G28 mainly G29 seems to be ok) on Step 6, the BL Touch starts deployed, then Z goes down, the second the pin hits the bed it starts to move to step 7 then errors as the pin has not retracted. I have not got advance debugging on yet but config is attached |
|
I can confirm this with the latest RCBugFix and BLTouch, for me even the first probe on G29 fails (using PROBE_DOUBLE_TOUCH) as after first hit to bed the Z-axis does not move up, but starts moving down again. The "bump" happens correctly with G28. |
|
Also, strangely, after failing G29 and BLTouch reset, when doing homing again with G28, the Z-axis moves down instead of up (the clearance making move). |
|
When I disable Z_SAFE_HOMING, G29 E works for me. |
|
Hi Jari, can you test "G29 E" without Z_SAFE_HOMING ? |
|
I get strange results and strange stop. Can't even make it to G29 because G28 fails |
|
Ahh. Z_SAFE_HOMING wasn't disabled. Strange. |
|
Sorry. Had to revert back to commit 6335acb which I at least know did work, as I have some prints I have to get done. Will test with Z_SAFE_HOMING disabled later... |
Seems to indicate that the probe is showing up as "triggered" before being deployed. |
|
having this same issue with the very latest rcbugfix. i am using bilinear, doubletouch, z_safe_homing is enabled
testing not having any success getting the carriage to move to center of the bed for homing. always trying to home outside of bed (due to hotend being at 0,0) have done a few things with these settings but nothing seems to work as I think it should. // The center of the bed is at (X=0, Y=0)
//#define BED_CENTER_AT_0_0
// Manually set the home position. Leave these undefined for automatic settings.
// For DELTA this is the top-center of the Cartesian print volume.
//#define MANUAL_X_HOME_POS 0
//#define MANUAL_Y_HOME_POS 0 |
|
Sorry @bleugray, the state of |
|
@thinkyhead let me know what i can do to help out testing. |
|
Any news on this or more debugging needed? |
|
Hello, now I have try the new version (RcBugFix) have see most change, but the problem with
|
|
I have a proposition for you, I have analyzed the code as much as I can. The problem is due to the fact that when you make the raise of the plate, the current position is updated, but the movement has not actually occurred. I do not know well the code, but for you it should be very easy to implement the solution that I thought: You can use the same behavior that already exists for the Home of the Z, but in reverse. In this way we will be sure that the deck is detached from the sensor. I hope my solution will be useful. Thanks for your work. |
|
A feature of Marlin is that when a probe or endstops are enabled and triggered, the steppers simply stop, and then the position is incorrect. We make sure to always know when a move for homing or probing is being done, and the stepper code makes sure only to test an endstop or probe when an axis is moving in the direction towards the endstop or bed. When moving away from the bed, it should not be possible to get this kind of interruption. As you point out, the position is updated but the move doesn't take place. The only cause for a move to not occur once initiated is due to an endstop trigger, which means either the endstop/probe isn't being disabled, or the endstop flag isn't being cleared. So far in looking at the code I haven't been able to find a causal link. I need to look through issues and see if it's just |
|
RC_Reverted_for_testing, G28 & G29: |
|
So from your testing, apparently the culprit has to be one of the changes in this commit that I've just added to the branch: So, try making some of those changes, one at a time, and see which one causes the failure. |
None of them, it seems. Applied them, one by one. Still working. |
|
I even tried pulling the latest from your branch to make sure I didn't miss anything from the patch. Still works. |
|
Now the difference between RCBugFix and RC_reverted_for_testing is pretty small: |
|
I'm now a bit baffled. Gonna try the absolutely latest RCBugFix and see if it works with it. |
|
Hmm… very interesting! |
|
For reason or another, it now seems to work with the latest RCBugFix too! Anybody else willing to confirm? |
|
Give me half hour and I will be able to confirm |
|
Possibly disregard what I said, may have been a hardware issue with my sensor, re-testing |
|
Ok so, I have the exact same issue as before, Fails 90% of the time on probe 7 out of 9 on the bed level. and is intermittent with G28 using the latest RC Bugfix |
|
This is strange. For me G28 & G29 -combination now works. |
|
@DatenThielt Do you see the problem in the branch linked below? It's a version of Marlin where I've left out recent changes that have the potential to be involved. https://github.com/thinkyhead/Marlin/tree/rc_bltouch_debug |
|
@thinkyhead Tested with the rc_bltouch_debug and G28 G29 and now working 100% of the time, So it seems it it something in one of those commits, Let me know if you need anything |
|
@DatenThielt I've just applied a patch to |
|
@thinkyhead So just tested the new RCBugFix I am getting about 30% failure on G28 (3/10 tries fails), G29 seems to be working perfectly though! |
|
Just to elaborate, G28 fails on the 2nd probe, First probe extends, Z goes down and then the probe hits the bed and retracts, then instantly extends again hitting the bed and causing an error (As no Z raise happened) |
|
@DatenThielt Are you actually using the |
|
@thinkyhead I am using the BLTouch probe option with the latest Turn Printer On -> Prepare -> Auto Home -> (Fail) -> Prepare -> Auto Home -> (Success) I have included a video of this process. Once again it only fails about 30% of the time. Video: https://youtu.be/zPD4lmpy-Wc |
|
In the video it appears not to even register the second probe. The Z axis continues to move down and only registers the probe due to its error state (which also appears as triggered). This indicates to me that the probe is malfunctioning. |
|
I notice that your second probe speed is really, really slow. #define HOMING_BUMP_DIVISOR {2, 2, 4} // Re-Bump Speed Divisor (Divides the Homing Feedrate) |
|
How would I increase the second speed sorry? |
|
⏫ The default Z bump divisor is 4. Try changing it to 3 or 2. #define HOMING_BUMP_DIVISOR {2, 2, 4} // Re-Bump Speed Divisor (Divides the Homing Feedrate) |
|
That seems to have done it! Appears to be fully functional and reliable 👍 |
|
Good to know! My guess was that the BLTouch throws an error if it's enabled for too long without getting triggered. |
|
The BLTouch will throw an error if its between triggered/non-triggered state for too long. Or in other words if the pin is half way up or half way down for too long. |
|
It might make the most sense to just set the default Z homing bump divisor to 3 instead of 4 to avoid this issue. 4 seems kind of excessive, anyway. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Z CLEARANCE BETWEEN PROBES does not work with bltouch.
G28 works beautifully, G29 does not work.
The z axis does not move up, after the first measurement point.
with RC works bltouch great.
The text was updated successfully, but these errors were encountered: