Closed dreamcryer closed 5 years ago
Hi @dreamcryer,
It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).
Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.
For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md
The log can still be attached to this ticket - just add a comment and attach the log to that comment.
Best regards, ~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
You probably need to switch the endstop logic of the BLTouch v3.0 to 5V away from the new open drain default. See my work in progress branch https://github.com/jannau/klipper/tree/bltouch_v30.
For reference the BLTouch v3.0 manual and related Marlin issue
@jannau I tested your fix and it didn't solve the problem. Somehow the pin now stays back when it touched my finger during z homing. But the motor still kept going. I wonder if it's related to the probe status reading and pin_up_touch_mode_reports_triggered setting. Without the setting, the probe status is always triggered. And with that setting, probe status is always open. klippy.log
Actually, from the log it looks like the pin value of the probe never changed.
I tried different ways to switch the probe to 5v mode in bltouch.py but wasn't able to get homing to work. The pin value never gets updated henece the probe not triggered. I added 1k ohm resistor between the z-min wire (white) and the 5v wire (red) as suggested in this post and it worked without the need to change printer.cfg.
According to the Marlin issue thread @jannau pointed out, the signal window shrank but it is still within Marlin's polling cycle (5ms). And Marlin's fix works with Ender 3. I think Klipper is polling the pin every 1ms if I didn't read the code wrong. So I am guessing somehow the probe was not switched to 5v mode correctly.
I know software but not enough about the electronics so hopefully someone could give a hand here.
FWIW, I don't have any insight into the root cause of your issue. I'd double check the wiring/config and follow the steps in docs/BLTouch.md . You can put the probe in "touch mode" and verify it reports triggered on a query_probe when you manually press the probe. (You can't detect a trigger this way in "pin down" mode.) If the probe is sensing the trigger but not reporting it then I'd guess it's bad wiring/config or a broken probe.
-Kevin
I had the same issue with BLtouch 3.0 on my ender 3 and marlin. Ended up solving it following this advice on the link below and it worked.
Trying to switch to klipper now and it's the same problem, dunno how I would implement this in klipper. He says they fixed it by setting the probe in SW_MODE when deployed.
@KevinOConnor, yeah I tried touch_mode + query_probe before but klipper didn't report it triggered. I now added a resistor to work around it. I plan to switch to skr v1.3 soon. When I do, I will try again and report back. Hopefully it's not my probe.
@Scy1, see jannau's post above. He has a fix that he is working on. I am curious if it works for you. If it does, I know my wiring or probe is bad and we can also confirm that jannau's fix works.
Before the bltouch would hit the bed and keep moving down till the nozzle would depress the bed a bit and move back up and blink red. After I tried the fix the bltouch would hit the bed turn solid red, but the nozzle would keep going down and not stop till i turn of the printer.
After I tried the fix the bltouch would hit the bed turn solid red, but the nozzle would keep going down and not stop till i turn of the printer.
Exactly what's happening to me after I apply the fix. Looks like we do have some other things needed to be fixed in klipper.
FYI, there appears to be a lot of similarity between this issue and issue #1483.
-Kevin
I have a BLTouch V3 from Creality direct, arrived last week. It also seems to be triggered at all times and doesn't work as a z-stop.
~~I think the issue of open drain being the default should be easy to fix by enabling the internal pull-up resistor of the AVR on the pin. That would not require putting the BLTouch in 5V mode. That won't even affect non-open drain BLTouch with 5V output, because the pull-up is weak and easy to override by an external signal.~~
Scratch that. Pullup is supported by having ^PC4 as endstop. ^PC4 and !^PC4 don't seem to work with the V3 though.
The behavior during G28 that I see is that the pin deploys correctly. When I trigger it, it doesn't stop Z-movement and the pin is redeployed almost immediately each time it is triggered. This continues until the nozzle hits the bed.
I'm also having issues with the bltouch v3
Initially when homing, the Z axis would just sit there like the trigger was already initiated. After changing "pin_up_touch_mode_reports_triggered:" to false, the needle will now deploy, but when triggered, the red light will turn off, and the blue will come on very faintly. After turning red, it'll re-deploy. The Z axis will not stop though.
Here is my log after running the bltouch test: klippy.log
I got it working! I had to remove the C7 z stop cap per https://www.antclabs.com/wiring3
I also have
pin_up_touch_mode_reports_triggered: False
I've also spent several hours trying to get my BlTouch to work. Here's what I ended up with.
My hardware Ender 3 with PCB V1.1.4 Original BlTouch V3.0 (March 2019)
1st Method (same as @CircuitSetup)
2nd Method Because we already use the ISP header for supply (GND, +5V) and control pin (MOSI-PB5), we can
This way there is no need to remove any capacitors from the PCB, the original z stop can be left untouched and we can connect the BlTouch only to the ISP header. There's also no need for the "sensor_mode: logic_5v" modification as suggested by @jannau .
So far I only tested it with homing command G28, but it should also work for real bed leveling workflow, I suspect.
Yep, mine is working fine for bed leveling. The only thing I noticed is when the pin retracts, the blue LED is on for a second, then goes out. It doesn't seem to effect anything though.
I'm going to close this in favour of the existing issue #1483. Also note that the documentation updates are pending in PR #1661.
-Kevin
I've also spent several hours trying to get my BlTouch to work. Here's what I ended up with.
My hardware Ender 3 with PCB V1.1.4 Original BlTouch V3.0 (March 2019)
1st Method (same as @CircuitSetup)
- Use the original z stop pin (^PC4) as sensor pin
- Remove C7 capacitor
- Set pin_up_touch_mode_reports_triggered: False
2nd Method Because we already use the ISP header for supply (GND, +5V) and control pin (MOSI-PB5), we can
- Use SCK pin with internal pull-up activated (^PB7) as sensor pin (somehow MISO-PB6 pin was not working)
- Set pin_up_touch_mode_reports_triggered: False
This way there is no need to remove any capacitors from the PCB, the original z stop can be left untouched and we can connect the BlTouch only to the ISP header. There's also no need for the "sensor_mode: logic_5v" modification as suggested by @jannau .
So far I only tested it with homing command G28, but it should also work for real bed leveling workflow, I suspect.
I don't fully understand how to wire for method #2, which has my preference. What do you mean with "Because we already use the ISP header for supply (GND, +5V) and control pin (MOSI-PB5)" ?
I'm currently using the D11 row on my V2.1 CR-10S board, and was using the Z-HomeSwitch port for the black/white wires, but also faced the issue of having a 'always-open' reply from QUERY_PROBE.
Therefore, I'd like to use your solution but can't find how to wire this. Could you help me out with this?
I.e. where to find which 'physical pin' relates to the names (PB7, etc.) used in your comment?
Thanks in advance!
For anyone coming here from Google: using the ISP header's MOSI and SCK pins for control and sensor does not work (anymore?) because Klipper (now?) knows what they are and will error out with error: pin PXn is reserved for spi
. Remaining options are to find and remove C7 and keep using the original z endstop pin, or to find another one. The display header still has one available and there's "pin 27 adapters" you can buy, but they add quite a bit of height to the board. A better option might be the connectors labelled "CHECK" (left pin is PA2) and "OFF" (right pin is PC1).
@sixtyfive Just to make this clear and don't lead anyone on the wrong track. The 2nd method (ISP header) I described above still works with the latest version of klipper. I still use the same hardware as stated above. Maybe you have a newer incompatible board, other version of BlTouch or just configured it the wrong way, but it is certainly still working. If you claim that it's not working for you, please let the people know what setup you use.
If anything I have an older board. SPI pins changing their pin numbers sounds unlikely, though. But good to have both pieces of information, now people can try the ISP header first and if that doesn't work, will still know there's other options, as well.
I broke my BLTouch so I got a new one which is version 3.0. My old one worked fine on Ender 3 with stock board. But the new probe seems to be always in open state so homing Z doesn't work. (I added pin_up_touch_mode_reports_triggered: False)
During homing z, when the pin is triggered (pushed up), it will immediately deploy again and the motor keeps going down. Manual testing touch_mode shows that the deployed pin would stay back once triggered.
query_probe command returns open all the time no matter what the pin state is. So does query_endstops. I simply swapped the z-endtop connection to old limit switch without changing the config and the query_endstops would return correct states.
klippy.log
Edit: Attached the log to the ticket instead of using a link.