Closed Bettman66 closed 8 years ago
Let's take a look. Get the latest RCBugFix
, enable DEBUG_LEVELING_FEATURE
and issue the command M111 S32
before doing G28
followed by G29 V4
. Post the log here and we'll be able to see why the raise isn't happening.
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 Z_PROBE_SPEED_FAST
and HOMING_FEEDRATE_Z
? Do you see the same problem if you use a lower value for Z_PROBE_SPEED_FAST
?
I use 16x stepping, Z_PROBE_SPEED_FAST lower brought no change (motor was slower and louder.).
working config rc : Config_rc.txt Youtube : https://www.youtube.com/watch?v=mJ0AzWpVaXs&feature=youtu.be
not working config rc_bugfix: Config_rc_bugfix.txt
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 Z_MIN_PROBE_ENDSTOP
also?
Notice that the SERVO_DELAY
is overridden in Conditionals_LCD.h
where BLTOUCH
emulates a servo. It's lowered to 50 (from the default 300). See if setting a higher value like 60 or 100 here helps.
If the probe is connected to the Z_MAX
pin (the default) then possibly the raise move was interrupted because the probe was still registering as "triggered."
I'm working up a PR that adds conditions so the Z_MAX
logic so Z_MAX_PIN
won't read on a raise in the case of when the min probe pin is usurping the Z_MAX
pin.
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 G29 E
? The E flag makes the probe stow and disable completely after each point, instead of just retracting. That might be more reliable.
I made a small patch to RCBugFix
earlier but nothing likely to fix this issue. Still, grab the latest code before testing. I'd like to see the log output where you have 5 or 6 points succeeding before it fails.
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
Configuration.txt
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. G29 without E is not working.
Hi Jari, can you test "G29 E" without Z_SAFE_HOMING ?
Ahh. Z_SAFE_HOMING wasn't disabled. Strange.
Sorry. Had to revert back to commit 6335acbf5cc96f50109e987d8030b26702650a88 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...
do_probe_raise(10.00)
Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)
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
G28
works as expected
G29
fails after first probe of first location of double touch
testing G29 E
with Z_SAFE_HOMING
disabled now.
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 G29
is precarious right now. The logs show that the raise move is being initiated, but then for some reason it seems to be getting interrupted, or in any case it isn't actually occurring. I will have to add yet more logging code to determine where the main cause lies.
@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 Z_CLEARANCE_BETWEEN_PROBES
not is solved.
At This point have close the print because the probe is go out the plate.
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. I thought that when the probe has cut the first point, you can increase the coordinates of the Z axis until the switch Z does not turn off (a small offset may be useful to say when away after the endstop switch Z has disconnected).
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 BLTOUCH
being affected. It shouldn't be different from other probes in this regard, so it is a conundrum.
I am wondering if there is any kind of live debugging with breakpoints for the Arduino/Marlin (I come from a C# background and love visual studio) If I can find a way to do it I will run through the code tonight and see if anything sticks out whilst manually running through the code (I can see on google that there is a Visual studio Serial debugger for the Arduino)
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 BLTOUCH being affected. It shouldn't be different from other probes in this regard, so it is a conundrum.
I'm wondering if we should ask somebody with a BLTouch that is having problems to wire up an LED to its probe output. All of these problems could be explained if the BLTouch is not sending the proper status to the AVR board. I don't believe that is happening, but it certainly would explain all the flaky things being seen. And it is very easy thing to do so we can concentrate the search else where.
I'm wondering if we should ask somebody with a BLTouch that is having problems to wire up an LED to its probe output. All of these problems could be explained if the BLTouch is not sending the proper status to the AVR board. I don't believe that is happening, but it certainly would explain all the flaky things being seen. And it is very easy thing to do so we can concentrate the search else where.
I don't believe so as I personally switched to older commit 6335acbf5cc96f50109e987d8030b26702650a88 which seems to work nicely.
@thinkyhead Further up you said: "The E flag makes the probe stow and disable completely after each point, instead of just retracting. That might be more reliable."
Do you mean you are disabling the servo? From what I've been told by ANTCLABS, the servo pin to the BLTouch should not be disabled, even when it isn't being used. I suspect it can cause the BLTouch to misbehave if you do.
@timeshell No, the servo pin doesn't disconnect. With BLTOUCH
the servo is always left activated. It is moved to the stow angle and the probe flag is set false
.
@Jartza I'm using that commit —or the date of around Sept 21— as the basis to compare all recent changes and find the one (or more) that's most likely to be involved. I'm about halfway through that process, so I should have some list of the most likely candidates soon.
Ok, so here's what I have. I made a new branch starting with https://github.com/MarlinFirmware/Marlin/commit/6335acbf5cc96f50109e987d8030b26702650a88 and applied all the changes from the current code to it. Then I went through and made commits with all the most innocuous changes, but left out any changes that seem likely to be connected with this issue. Hopefully I didn't miss anything…
https://github.com/thinkyhead/Marlin/tree/rc_reverted_for_testing
Please test with this branch and see if it works as well as the code from Sept. 21. If it does work, then we should look at those few suspicious commits and figure out which one is the culprit. If it still fails, then I will revert some more changes and we can keep testing.
Please test with this branch and see if it works as well as the code from Sept. 21. If it does work, then we should look at those few suspicious commits and figure out which one is the culprit. If it still fails, then I will revert some more changes and we can keep testing.
I just tested the bed levelling and the BLTouch probe is now lifted between probe points like it should (also the bump feature works), so at least that works now correctly. I didn't yet try printing, though.
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:
https://github.com/thinkyhead/Marlin/commit/65b6abf5549d9bda661c7ff90dd78bd6e628ebfd
So, try making some of those changes, one at a time, and see which one causes the failure.
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.
@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 RCBugFix
. Please test and see that it works now.
@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!
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.