BLTouch support?

[dragonnn]

I know that Z-probe isn't really finished but I am trying to get bltouch working as normal endstop. With diffing it as servo I can control it, with command SET_SERVO SERVO=bltouch ANGLE=10 I can deploy bltouch. The problem is when homing after touching the bed bltouch locks up and I am getting: "!! Endstop z still triggered after retract" Bltouch locking is a complete normal thing, we just need reset and deploy it again before doing retract. And I can not find a good way to do it with would be "hackish".

[KevinOConnor]

On Mon, Nov 13, 2017 at 04:11:32PM +0000, Mateusz wrote:

I know that Z-probe isn't really finished but I am trying to get bltouch working as normal endstop. With diffing it as servo I can control it, with command SET_SERVO SERVO=bltouch ANGLE=10 I can deploy bltouch. The problem is when homing after touching the bed bltouch locks up and I am getting: "!! Endstop z still triggered after retract" Bltouch locking is a complete normal thing, we just need reset and deploy it again before doing retract. And I can not find a good way to do it with would be "hackish".

Take a look at the work-probe-20170609 branch for demo probe code - you likely don't want to use the homing code during probing.

-Kevin

[dragonnn]

I look at it but I don't see an option to do anything with a servo after homing and before retract.

[dragonnn]

https://github.com/dragonnn/klipper/commit/281b43e9ccf0cf7f2c283549e909414c1b81eafb it is not perfect because on home_end I should set two angles, first 260 then 90 but I don't know how to make delay between two set_angles commands (I am sure using time.sleep(0.3) isn't the right way :D).

[KevinOConnor]

On Tue, Nov 14, 2017 at 04:56:31PM +0000, Mateusz wrote:

it is not perfect because on home_end I should set two angles, first 260 then 90 but I don't know how to make delay between two set_angles commands (I am sure using time.sleep(0.3) isn't the right way :D).

I'm not familiar with the bltouch, but if you want to invoke a delay, call the toolhead.dwell() method between actions. That will cause the toolhead to insert a timed delay in the schedule of events sent to the mcu. Specifically, after invoking dwell(), the print_time obtained from toolhead.get_next_move_time() will be adjusted by the given amount of time.

-Kevin

[tgiphil]

+1

[KevinOConnor]

The work-probe-20170609 test branch now has code that allows arbitrary g-code to be run on each probe attempt. This may be useful for setting a servo position before/after each probe. (The branch also allows the probe to be used in place of a normal z endstop and it has homing_override code that can be used to position the head prior to Z probing.) See the updated config/example-extras.cfg for the details.

cd ~/klipper ; get fetch ; git checkout origin/work-probe-20170609 ; sudo service klipper restart

I don't have a good way to test this - please let me know your results (success or failure).

[stoto]

That's awesome news Kevin, I will try to test this and get back to you.

[ohaase-dev]

Hi Kevin,

thanks a lot for the work. I just tried the probe-branch on an anet-board and it works in general. If I configure the bltouch as serve, the angles for self-test(260), reset(120) and stow(90) works as expected, but wenn I try to deploy the probe with angle 10 nothing happens.

Could this possible be because the duty-cycle is not low enough? I also tried other low angles, but none worked. I just did a quick check with a multimeter, I see the changes in different duty-cycles but even with 0 I have some power left on the pin.

Regards Olaf

[KevinOConnor]

On Wed, Jan 24, 2018 at 12:02:00PM -0800, mediumo wrote:

Hi Kevin,

thanks a lot for the work. I just tried the probe-branch on an anet-board and it works in general.

Great! Can you post your config so others can test?

If I configure the bltouch as serve, the angles for self-test(260), reset(120) and stow(90) works as expected, but wenn I try to deploy the probe with angle 10 nothing happens.

Could this possible be because the duty-cycle is not low enough? I also tried other low angles, but none worked. I just did a quick check with a multimeter, I see the changes in different duty-cycles but even with 0 I have some power left on the pin.

I'm not familiar with the details of the bltouch - what did you expect to happen after setting an angle of 10?

If you think Klipper did something wrong, then post the klippy.log file here after following the directions at:

https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

-Kevin

[ohaase-dev]

Sure, it's working now. I found some more information for the pulse width: bltouch Redeem

values from Redeem seems to be working, now the pulse width for the angles described by bltouch seems to be correct.

[servo bltouch]
# pin PA4 on Anet/Melzi Clone board
pin: PA4
maximum_servo_angle: 180
minimum_pulse_width: 0.0006
maximum_pulse_width: 0.0024

Nevertheless the sensor always triggers the z-endstop. which should not be the case with deployed pin. I also tried to reset the alarm etc, but nothing is working.

I quickly flashed back to Marlin to see if there is something wrong with the sensor or the solenoid itself, but there everything is working. I will try to find more. Maybe somebody else can test with my settings. It seems that @dragonnn already had it working.

[ohaase-dev]

OK, should have tested this after a good night sleep. @KevinOConnor : new features in the probe-branch are working like a charm with this config:

# just added the new or changed lines, #.... to show that there are probably other lines in your config
[stepper_z]
#.....
endstop_pin: probe:z_virtual_endstop

[probe]
pin: ^PC4
speed: 5.0
#z_position: 0.0
activate_gcode: SET_SERVO SERVO=bltouch ANGLE=10
                SET_SERVO SERVO=bltouch ANGLE=60
deactivate_gcode: SET_SERVO SERVO=bltouch ANGLE=90

[homing_override]
gcode: G28 X0 Y0
        G91
        G1 Z10
        G90
        G1 X110 Y110
        G28 Z0
        G1 Z10

one thing: As you see I tried to lift the nozzle a bit before z-homing for two reasons:

1. to make sure nothing blocks the move to the middle of the bed
2. if you are near your real z=0 position probe could already be triggered at deployment because you are below the probes triggering point

It seems like the relative move command is not executed. Is it still blocked because z is not homed yet? Maybe it would make sense to allow movements in homing_override for not homed axes or introduce somthing like Marlins Z_SAFE_HOMEING as an option?

Olaf

[KevinOConnor]

On Thu, Jan 25, 2018 at 07:37:56AM +0000, mediumo wrote:

activate_gcode: SET_SERVO SERVO=bltouch ANGLE=10 SET_SERVO SERVO=bltouch ANGLE=60 deactivate_gcode: SET_SERVO SERVO=bltouch ANGLE=90

FYI, you may want to add a small delay after the SET_SERVO command so that it has time to deploy. Something like:

activate_gcode: SET_SERVO SERVO=bltouch ANGLE=10 SET_SERVO SERVO=bltouch ANGLE=60 G4 P200

[...]

one thing: As you see I tried to lift the nozzle a bit before z-homing for two reasons:

1. to make sure nothing blocks the move to the middle of the bed
2. if you are near your real z=0 position probe could already be triggered at deployment because you are below the probes triggering point

It seems like the relative move command is not executed. Is it still blocked because z is not homed yet?

Yes.

Maybe it would make sense to allow movements in homing_override for not homed axes or introduce somthing like Marlins Z_SAFE_HOMEING as an option?

This was discussed in issue #111. I didn't port that part of homing_override to the probe branch, but I can. Out of curiosity, how would you make sure the printer doesn't ram into the top of the frame if a G28 is issued when the head is already at the top?

-Kevin

[ohaase-dev]

good idea,

it works at the moment since i make sure the nozzle/probe is serveral millimeters above the bed before i start, and with bltouch its pretty quick since its a solenoid, no actual servo.

Perfect, thought of a similar solution. testing the M120/M121 commit from @dragonnn fork right now. (I don't actually know if it is a good idea to override the check_move completly, would probably be better to bypass the checks in the kinematics classes so other checks could be taken into account, too?) It's similar to M211. Another solution would be to use G92 (if it would set the axis homed like in #140

You can't make sure you don't hit any physical boundary. But I would say better hit the top then the bed (which could be damaged). In most cases you would have your top-boundary a little bit under the physical maximum, at least for cartesian. Anyways in this way somebody does this by purpose via configuration and should know what it means?

[KevinOConnor]

FYI, the work-probe-20170609 branch has been merged into master.

[ZerR2D0]

Hello everyone,

how can I find out which pin the BLTOUCH uses on my MKS BASE? no servo appears in the M43 pinout :(.

Thanks for your help.