Closed Aerospacesmith closed 7 years ago
Hi,
I also have a BL Touch on my 3D Printer. The only useful setting I can see which you have different is: NUM_SERVOS
You have the value set to 1, I have the value set to 3
Pleas change the value of NUM_SERVOS to 3.
You can also refer to this guide https://3dator.com/wp-content/uploads/2016/04/AnthonyQuayle003.pdf
I can confirm there are issues with BL-Touch probes. Right now, there are two things you can do to make the problem not show up. First, make sure you have some extra space declared for:
#define Z_CLEARANCE_DEPLOY_PROBE 15 // Z Clearance for Deploy/Stow
#define Z_CLEARANCE_BETWEEN_PROBES 10 // Z Clearance between probe points
Don't try to make them as small as possible. Leave some extra room.
The other thing that is important is don't try to do the probe at a very slow speed. Normally, slowing the probe operation down is a good thing for accuracy. But the BL-Touch only puts out a 5ms 'triggered' signal and a very slow speed while probing makes it possible to miss the trigger window. This is discussed here: https://github.com/MarlinFirmware/Marlin/issues/5234#issuecomment-261759187
I'm aware of the 5ms triggering issue. My issue is that the probe is never deployed. The pin is never dropped down on a G28 command. I can manually send the gcode commands to push the pin up and down.
Did you try what I had suggested?
Ensure that the servo signals are defined as {10,90} in the servo section
Please append your Configuration.h
.
Likely you are using a configuration where the probe is just and only used for probing - not for homing.
I have my configuration.h file in the paste in link in the OP.
Here is the actual file. (I had to append .txt to the end to attach it) Configuration.h.txt
Thanks. I'd begin with not defining two types of probes at the same time.
// The BLTouch probe emulates a servo probe.
// The default connector is SERVO 0. Set Z_ENDSTOP_SERVO_NR below to override.
#define BLTOUCH
// Z Servo Probe, such as an endstop switch on a rotating arm.
#define Z_ENDSTOP_SERVO_NR 0
#define Z_SERVO_ANGLES {10,90} // Z Servo Deploy and Stow angles
Please comment the servo probe settings. A conflict with Conditionals_LCD.h is possible.
/**
* The BLTouch Probe emulates a servo probe
* and uses "special" angles for its state.
*/
#if ENABLED(BLTOUCH)
#ifndef Z_ENDSTOP_SERVO_NR
#define Z_ENDSTOP_SERVO_NR 0
#endif
#ifndef NUM_SERVOS
#define NUM_SERVOS (Z_ENDSTOP_SERVO_NR + 1)
#endif
#undef DEACTIVATE_SERVOS_AFTER_MOVE
#undef SERVO_DELAY
#define SERVO_DELAY 50
#undef Z_SERVO_ANGLES
#define Z_SERVO_ANGLES { BLTOUCH_DEPLOY, BLTOUCH_STOW }
#define BLTOUCH_DEPLOY 10
#define BLTOUCH_STOW 90
#define BLTOUCH_SELFTEST 120
#define BLTOUCH_RESET 160
#define _TEST_BLTOUCH(P) (READ(P##_PIN) != P##_ENDSTOP_INVERTING)
#if ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
#undef Z_MIN_ENDSTOP_INVERTING
#define Z_MIN_ENDSTOP_INVERTING false
#define TEST_BLTOUCH() _TEST_BLTOUCH(Z_MIN)
#else
#define TEST_BLTOUCH() _TEST_BLTOUCH(Z_MIN_PROBE)
#endif
#endif
Additionally i'd try a, for Prusas, much better tested kind of bed levelling like AUTO_BED_LEVELING_LINEAR and not a brand new one. If that works you can try AUTO_BED_LEVELING_BILINEAR.
//#define AUTO_BED_LEVELING_3POINT
//#define AUTO_BED_LEVELING_LINEAR
#define AUTO_BED_LEVELING_BILINEAR
I had started with the separate servo settings commented and tried uncommenting to see if that helped before posting the issue. It didn't. I've since re-commented them.
I switched to AUTO_BED_LEVELING_LINEAR and it fixed the issue. I can confirm that switching it back to AUTO_BED_LEVELING_BILINEAR makes G28 not deploy the BLTouch.
Now the question is: Why on Earth why?
Verrry interesting. I'll have a look. There should be no difference. G28
doesn't care what kind of bed leveling is in use. Only G29
does.
How do M401
and M402
behave?
I note in your configuration that you have this commented out. Intentional?
//#define Z_MIN_PROBE_PIN Z_MIN_PIN
I won't be able to test the probe M commands until after the Thanksgiving weekend. Yes that comment is intentional because it's defined a few lines lower for it to use the Z end stop pin.
M401 Raises the Z height by the amount defined in Z_CLEARANCE_DEPLOY_PROBE, but does not deploy the BLTouch. M402 does nothing. I can call M280 P0 S10 and M280 P0 S90 to manually deploy and stow the pin.
After some more testing, with AUTO_BED_LEVELING_LINEAR enabled the BLTouch doesn't always deploy with G28 Its about a 50% chance if it deploys or not. With the Bilinear bed leveling, it never deploys.
Using the debug command M111 S32, when I send a G28 the log pertaining to Z homing says
21:00:46.165 : >>> homeaxis(Z)
21:00:46.170 : current_position=(153.00, 98.00, 7.70) : set_probe_deployed
21:00:46.170 : deploy: 1
21:00:46.170 : do_probe_raise(6.00)
21:00:46.174 : >>> do_blocking_move_to(153.00, 98.00, 7.70)
21:00:46.174 : <<< do_blocking_move_to
21:00:46.174 : Home 1 Fast:
21:00:46.177 : >>> do_homing_move(Z, -262.50, 0.00)
21:00:46.227 : set_bltouch_deployed(1)
21:00:46.230 : current_position=(153.00, 98.00, 0.00) : sync_plan_position
21:00:51.383 : Printer reset detected - initalizing
So it looks like set_bltouch_deployed(1)
is being set, but the pin is not deployed.
M401 never deploys the pin, but the M280 P0 S10 does every time.
That's very helpful. We'll look at this in detail.
@Roxy-3D @psavva How does M401
and M402
behave on your setups?
I've already examined the config posted by @Aerospacesmith and couldn't see any issues. But if everything checks out on your systems, then maybe I can compare all your configuration files and see what differs.
I have also now installed RCBugFix, and am not experiencing the issues faced.
I will post my configuration files + try out the tests, with both auto leveling modes tonight and report back.
@Aerospacesmith, are you providing external power for the BLTouch? If not, have you bridged the 5v servo line with VCC? http://www.thetechwizard.us/download_files/Ramps_Servos.png
It may be that your BLTouch isn't getting enough power...
I'll however test and report back tonight.
That's very helpful. We'll look at this in detail. How does M401 and M402 behave on your setups?
@thinkyhead Starting with the printer connected to PronterFace just after a power-up, M401 moves the nozzle up a little bit the first time. But it does NOT deploy the pin. M402 does nothing. A subsequent M401 does nothing also. I attached the M401 and M402 logs for you. I've got extra debug code in the set_probe_deployed() function. So I've attached the actual code for that function also so you can see exactly the path it is taking.
@thinkyhead I have an extra BL-Touch probe if you want me to send you one. Paris (at ANTCLABS / BL-Touch) thought my probe might be defective and sent me a couple of replacements. And... the new version of BL-Touch that should be coming out soon will have an extra mode in it. If the servo angle is set at 60 degrees it is going to report the actual status of the pin instead of putting out a pulse.
I'll be using the new mode instead of the current 5ms pulse mode!!!
>>> M401
SENDING:M401
echo:M401
current_position=(0.00, 0.00, 11.00) : set_probe_deployed
deploy: 1
set_probe_deployed():1
set_probe_deployed():2
do_probe_raise(10.00)
set_probe_deployed():3
set_probe_deployed():4
set_probe_deployed():6
set_probe_deployed():8a
>>> do_blocking_move_to(0.00, 0.00, 11.00)
<<< do_blocking_move_to
set_probe_deployed(): returning FALSE
>>> m402
SENDING:M402
echo:M402
current_position=(0.00, 0.00, 11.00) : set_probe_deployed
deploy: 0
set_probe_deployed():1
set_probe_deployed():2
do_probe_raise(10.00)
set_probe_deployed():3
set_probe_deployed():4
set_probe_deployed():6
set_probe_deployed():8a
>>> do_blocking_move_to(0.00, 0.00, 11.00)
<<< do_blocking_move_to
set_probe_deployed(): returning FALSE
I have an extra BL-Touch probe if you want me to send you one.
@Roxy-3D Thanks! But I will be back in Portland next week, where I have awaiting me a donated BLTouch probe. I will mess with it when I get there.
So where did this end up? I'm having the same issue on my MPX.3 board and BLTOUCH. At beginning stages of troubleshooting, so I'll report back when I find something out.
So where did this end up? I'm having the same issue on my MPX.3 board and BLTOUCH. At beginning stages of troubleshooting, so I'll report back when I find something out.
Enable the
/**
* Enable detailed logging of G28, G29, M48, etc.
* Turn on with the command 'M111 S32'.
* NOTE: Requires a lot of PROGMEM!
*/
//#define DEBUG_LEVELING_FEATURE
And post a log of what it says. It is helpful if you annotate the log when important things happen. (Like if the nozzle tries to crash into the bed... Put a footnote on that location in the log.)
I have the exact same problem on some other printer. Does anyone know how I can fix this? M401 and M402 do nothing. The debug info tell deploy: 0 or deploy: 1, but the probe is not moving. M280 P0 S10 deploys everytime M280 P0 S90 retracts everytime.
I am at loss here
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.
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.
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.
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.
Configuration.h => http://pastebin.com/gqEaVhrq Configuration_adv.h => http://pastebin.com/SY8uaf3Q
Hello, I'm using the RCBugFix branch downloaded tonight (Nov 20) and am running into a strange issue. It does involve a BLTouch which I know is being tested and worked on. I have been having strange issues with it not triggering since going from RC6 to RC7, but my current issue in the RCBugFix branch may not be directly related.
My issue is that I have the firmware configured (Pastebin links above) to use the BLTouch as a probe and I have it configured almost identically in my RC6 and RC7, but in this branch it's not working. Whenever I issue a G28 command, it homes the X and Y, but then never deploys the Touch before homing Z. It just goes to the center of the bed (Safe Homing enabled) then just starts moving down without deploying the Touch. I have to keep E-Stopping the printer to prevent it from digging into my bed. I admit it is late and I may be overlooking something, but I can't figure it out. I've been comparing it to my RC7 configuration and cannot see any major differences. I have tried manually defining the servo number and angles without any effect. I can send the gcode commands M280 P0 S10 and M280 P0 S90 to manually deploy and stow the pin, but Marlin never automatically deploys it when attempting a G28.
Any help would be greatly appreciated and I would gladly help with any testing needed on the whole BLTouch trigger issue.