Bltouch problem with RC8 and MKS gen 1.4

[Sicon76]

Hello! I have some problems with RC8 and the bltouch as Z min endstop, hope you can help me. I have a MKS gen 1.4 board (#define MOTHERBOARD BOARD_MKS_13) and I have no problems using a mechanical endstop in the z min port, it works as it should, when I enable the bltouch and the Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN both with the bltouch or the mechanical endstop attached in the zmin - port, I always have a triggered status after a M119 command when it should be open and an open status when i manually trigger the mechanical endstop or the bltouch and this happen for any combination of true and false of these parameters Z_MIN_ENDSTOP_INVERTING and Z_MIN_PROBE_ENDSTOP_INVERTING . I tried Z_MIN_PROBE_ENDSTOP instead, in this case the z min status was correct, the z probe status is always triggered (even if I didn't attach the probe to any other pin) so I think there is something that always give a triggered status enablig the bltouch option with my board even if there isn't a real trigger, maybe some wrong pinout? What do you think? I tried to use the ramps board as motherboard type, but it is the same.

Thank you!

[Bob-the-Kuhn]

The BLTouch holds the line low when not triggered and pulses it high for 5ms when it is high. You'll never see the BLTouch say triggered when you issue a M119 command because the pulse is long gone before M119 can read the pin.

How are the switch & the BLTouch wired up?

Wiring the BLTouch and the mechanical switch's NC in series may be the way to go for you. The Z_MIN signal will be low unless either are triggered or the cable comes off.

Wiring them in parallel won't work. The signal will always be low unless you trigger both at the same time.

Are you wanting to use the BLTouch for probing and the mechanical endstop for homing? Another approach is to use a dedicated probe pin.

Another tool you can use in your troubleshooting is the M43 E1 command (pinsdebugging has to be enabled at the end of config_adv). This will monitor the endstops and report low or high when one changes state. Once the signal is behaving as you want then use M119 to verify that Z_MIN_ENDSTOP_INVERTING is set properly.

[Bob-the-Kuhn]

FYI - I've proposed a change to the wording of the probe section in config.h - the following may help clarify things.

Pasted Configuration

```cpp //=========================================================================== //============================= Z Probe Options ============================= //=========================================================================== // @section probes // // Probe Type // Probes are sensors/switches that are activated / deactivated before/after use. // // Allen Key Probes, Servo Probes, Z-Sled Probes, FIX_MOUNTED_PROBE, etc. // You must activate one of these to use Auto Bed Leveling below. // // Use M851 to set the Z probe vertical offset from the nozzle. Store with M500. // // A Fix-Mounted Probe either doesn't deploy or needs manual deployment. // For example an inductive probe, or a setup that uses the nozzle to probe. // An inductive probe must be deactivated to go below // its trigger-point if hardware endstops are active. //#define FIX_MOUNTED_PROBE // Z Servo Probe, such as an endstop switch on a rotating arm. //#define Z_ENDSTOP_SERVO_NR 0 // Defaults to SERVO 0 connector. //#define Z_SERVO_ANGLES {70,0} // Z Servo Deploy and Stow angles // NUM_SERVOS also needs to be set. This is found later in this file. Set it to // 1 + the number of other servos in your system. // The BLTouch probe emulates a servo probe. // If using a BLTouch then NUM_SERVOS, Z_ENDSTOP_SERVO_NR and Z_SERVO_ANGLES // are setup for you in the background and you shouldn't need to set/modify/enable them // with the possible exception of Z_ENDSTOP_SERVO_NR. // #define BLTOUCH // BLTouch WARNING // Unless using interrupt endstops, there is a MINIMUM feedrate for Marlin to reliably // sense the BLTouch. If the feedrate is too slow then G28 & G29 can sometimes result // in the print head being driven into the bed until manual intervention. // The minimum feedrate calculation is: // feedrate minimum = 60 / ( DEFAULT_AXIS_STEPS_PER_UNIT * 2.5mS ) // This applies to the HOMING_FEEDRATE_Z. If PROBE_DOUBLE_TOUCH is enabled then it also // applies to Z_PROBE_SPEED_SLOW. // Enable if you have a Z probe mounted on a sled like those designed by Charles Bell. //#define Z_PROBE_SLED //#define SLED_DOCKING_OFFSET 5 // The extra distance the X axis must travel to pickup the sled. 0 should be fine but you can push it further if you'd like. // Z Probe to nozzle (X,Y) offset, relative to (0, 0). // X and Y offsets must be integers. // // In the following example the X and Y offsets are both positive: // #define X_PROBE_OFFSET_FROM_EXTRUDER 10 // #define Y_PROBE_OFFSET_FROM_EXTRUDER 10 // // +-- BACK ---+ // | | // L | (+) P | R <-- probe (20,20) // E | | I // F | (-) N (+) | G <-- nozzle (10,10) // T | | H // | (-) | T // | | // O-- FRONT --+ // (0,0) #define X_PROBE_OFFSET_FROM_EXTRUDER 10 // X offset: -left +right [of the nozzle] #define Y_PROBE_OFFSET_FROM_EXTRUDER 10 // Y offset: -front +behind [the nozzle] #define Z_PROBE_OFFSET_FROM_EXTRUDER 0 // Z offset: -below +above [the nozzle] // X and Y axis travel speed (mm/m) between probes #define XY_PROBE_SPEED 8000 // Speed for the first approach when double-probing (with PROBE_DOUBLE_TOUCH) #define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z // Speed for the "accurate" probe of each point #define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2) // Use double touch for probing //#define PROBE_DOUBLE_TOUCH // // Allen Key Probe is defined in the Delta example configurations. // // *** PLEASE READ ALL INSTRUCTIONS BELOW FOR SAFETY! *** // - RAMPS 1.3/1.4 boards may be able to use the 5V, GND, and Aux4->D32 pin. // - Use 5V for powered (usu. inductive) sensors. // - Otherwise connect: // - normally-closed switches to GND and D32. // - normally-open switches to 5V and D32. // Normally-closed switches are advised and are the default. // // PIN OPTIONS\SETUP FOR Z PROBES // // // WARNING: // Setting the wrong pin may have unexpected and potentially disastrous consequences. // Use with caution and do your homework. // // // All Z PROBE pin options are configured by defining (or not defining) // the following five items: // Z_MIN_PROBE_ENDSTOP – defined below // Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN – defined below // DISABLE_Z_MIN_PROBE_ENDSTOP – defined below // Z_MIN_PIN - defined in the pins_YOUR_BOARD.h file // Z_MIN_PROBE_PIN - defined in the pins_YOUR_BOARD.h file // // If you're using a probe then you need to tell Marlin which pin to use as // the Z MIN ENDSTOP. Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN determines if the // Z_MIN_PIN or if the Z_MIN_PROBE_PIN is used. // // The pin selected for the probe is ONLY checked during probing operations. // If you want to use the Z_MIN_PIN as an endstop AND you want to have a Z PROBE // then you’ll need to use the Z_MIN_PROBE_PIN option. // // Z_MIN_PROBE_ENDSTOP also needs to be enabled if you want to use Z_MIN_PROBE_PIN. // // If you have Z_MIN_PROBE_PIN defined in your pins_YOUR_BOARD.h file then it can // be disabled (undefined) by either 1) enabling DISABLE_Z_MIN_PROBE_ENDSTOP or // 2) disabling Z_MIN_PROBE_ENDSTOP // // The settings needed to use the Z_MIN_PROBE_PIN are: // 1. select the type of probe you're using // 2. define Z_MIN_PROBE_PIN in your pins_YOUR_BOARD.h file // 3. disable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN // 4. disable DISABLE_Z_MIN_PROBE_ENDSTOP // 5. enable Z_MIN_PROBE_ENDSTOP // NOTE – if Z_MIN_PIN is defined then it’ll be checked during all moves in the // negative Z direction. // // The settings needed to use the Z_MIN_PIN are: // 1. select the type of probe you're using // 2. enable Z_MIN _PIN in your pins_YOUR_BOARD.h file // 3. enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN // 4. enable DISABLE_Z_MIN_PROBE_ENDSTOP // 5. disable Z_MIN_PROBE_ENDSTOP // NOTES – if Z_MIN_PROBE_PIN is defined in the pins_YOUR_BOARD.h file then it’ll be // ignored by Marlin // // // To continue using the Z-min-endstop for homing, be sure to disable Z_SAFE_HOMING. // Example: To park the head outside the bed area when homing with G28. // //#define Z_MIN_PROBE_ENDSTOP #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN //#define DISABLE_Z_MIN_PROBE_ENDSTOP ```

[Grogyan]

This seems to be even more confusing, regarding what is too fast for probing with BLTouch. Minimum feedrate, should be maximum feedrate?

// BLTouch WARNING
// Unless using interrupt endstops, there is a MINIMUM feedrate for Marlin to reliably
// sense the BLTouch. If the feedrate is too slow then G28 & G29 can sometimes result
// in the print head being driven into the bed until manual intervention.
// The minimum feedrate calculation is:
// feedrate minimum = 60 / ( DEFAULT_AXIS_STEPS_PER_UNIT * 2.5mS )
// This applies to the HOMING_FEEDRATE_Z. If PROBE_DOUBLE_TOUCH is enabled then it also
// applies to Z_PROBE_SPEED_SLOW.

// X and Y axis travel speed (mm/m) between probes
#define XY_PROBE_SPEED 8000
// Speed for the first approach when double-probing (with PROBE_DOUBLE_TOUCH)
#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z
// Speed for the "accurate" probe of each point
#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2)
// Use double touch for probing
//#define PROBE_DOUBLE_TOUCH

#define HOMING_FEEDRATE_Z  (4*60)

With the above calulation that would mean a feedrate of 6 (mm/s?) which is a good rate My home printer has a steps/mm of Z at 1600, which represents 4 (mm/s) of travel.

I reckon specifying in the comment exactly what the maximum feedrate, homing or otherwise, a BLTouch can be

[Bob-the-Kuhn]

The calculation results are in "units per minute".

With 1600 steps/mm I calculate a minimum feedrate of 15mm/minute or 0.4mm/s

I think minimum feed rate is the proper term. Going slower than the calculated feed rate will probably result in problems.

I think I'll add to the proposed changes something like: results are in mm/minute or inches/minute, depending on what units you're using

[Blue-Marlin]

feedrate minimum = 60 / ( DEFAULT_AXIS_STEPS_PER_UNIT * 2.5mS ) has the interesting unit of [S/minute/(steps/mm * mS/step)] = S\*mm/(minute\*mS) = meter/minute

[Grogyan]

I would expect that you would want to go slower so as to not miss the interrupt. Maybe i'm wrong on this assumption. I'm still on RC6 bugfix, and only got a small issue with initial z home probing, which i've managed to work around by instigating a preemptive M280 P0 S10 command before G28 Z0.

[Bob-the-Kuhn]

@Grogyan - Interrupts for endstops was only just added in RC8 and is still considered experimental.

The current (non-interrupt) system samples the endstop & probe signals on every step pulse. You need to be moving fast enough to guarantee that two samples will occur during the 5mS pulse from the BLTouch.

@Blue-Marlin - the units of measure conversions on this one are definitely interesting. It took me quite a while to understand that we were saying the same thing.

Doing all the conversions possible it is indeed Meters/Minute. Using X steps/mm and no conversions within the equation you end up with: feedrate (in Meters/Minute) = 60/(X*2.5) Since we want mm/minute the equation ends up being
feedrate (in mm/Minute) = 60,000/(X*2.5) If you leave it as X steps per unit and convert just the milli-seconds

 feedrate (in units/Minute) = (60 seconds/ minute)/(X steps/unit * 0.0025 seconds/step) 
 feedrate (in units/Minute) = 60 units/(X * 0.0025 minute)
 feedrate (in units/Minute) = 60,000 units /(X * 2.5 minute)

[Sicon76]

Sorry to have confuse you when I wrote about the mechanical endstop and the bltouch together, I never put them that way and I need to have only bltouch attached, I just use the mechanical one to help me to understand the behaviour when triggered or not. I did another test: when I used the fixed probe option I had a perfect z endstop state after a m119 command, it was normaly open and if I pushed the mechanical endstop it was triggered, but when I decomment the bltouch option (leaving all others options untouched) I had a triggered status even if I didn't push the mechanical trigger! I don't know what are the differences between enabling the bltouch option versus the fixed probe for the endstops, they should be the same when not triggered, what do you think?

[Bob-the-Kuhn]

What are your settings for the following?

• Z_MIN_ENDSTOP_INVERTING (true/false, enabled/disabled)
• Z_MIN_PROBE_ENDSTOP_INVERTING (true/false, enabled/disabled)
• Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN (enabled/disabled)
• Z_MIN_PROBE_ENDSTOP (enabled/disabled)
• the mechanical switch - are you tying the normally open or normally closed contact to the signal line? Is the common tied to ground?
• is there a pull up on the signal? Can be either a physical resistor or having ENDSTOPPULLUPS enabled or ENDSTOPPULLUP_ZMIN enabled

I believe the settings needed to use the Z_MIN_PIN are:

• select the type of probe you're using - in your case the BLTouch
• define Z_MIN _PIN in your pins_YOUR_BOARD.h file
• enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
• enable Z_MIN_PROBE_ENDSTOP_INVERTING and set it to false
• enable DISABLE_Z_MIN_PROBE_ENDSTOP
• disable Z_MIN_PROBE_ENDSTOP
• enable ENDSTOPPULLUPS or ENDSTOPPULLUP_ZMIN

When the system is setup properly you'll never see the Z_MIN/Z_PROBE triggered when you do a M119 command. To see the BLTouch cause a triggered state with M119 you'll need to do the following in this order:

1. send M280 P0 S10 command - this lowers the probe
2. send M280 P0 S60 command - this puts the BLTouch in the "M119" mode
3. manually push the probe up until it triggers
4. a M119 command should show it as triggered

To go back to normal you'll need to send M280 P0 S90 (probe up) or possibly M280 P0 S160 (alarm release)

[Sicon76]

I used Z_MIN_ENDSTOP_INVERTING true and false and nothing changed in the behaviour (always triggered ) when I use the bltouch option, with fixed probe option it inverts the logic of the endstop. Z_MIN_PROBE_ENDSTOP_INVERTING is always false with bltouch (looking at the code) and even so changing from true to false brings the same behaviour with the bltouch option. The mechanical endstop I am using works perfectly with fixed probe option. Don't know about hte pullup, i used #define ENDSTOPPULLUPS for the mechanical endstops and works fine (not with the bltouch option on, as always) The Z_MIN_PIN is the same of a ramps (18), DISABLE_Z_MIN_PROBE_ENDSTOP isn't in the marlin Rc8 code I have, Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is enabled and try to enable #define ENDSTOPPULLUP_ZMIN : same thing, after power on the printer and send M119 the zmin is always triggered even if I don't push anything (always with bltouch enabled in marlin), so in the end I don't know what is the difference between fixed probe setting and bltouch one becasue with fixed probe all work, with bltouch is always trigger no matter the changes in all these parameters (and with the bltouch phisically disconnected so it's not it). I send the M280 P0 S10 , pin is extended, m119 says triggered, M280 P0 S90 , pin retracted, says open , it's the same behaviour with the mechanical endstop so it's not the bltouch, there is something in the code when enabling the bltouch option that gives that false triggered status even if nothing is attached to the zmin endstop port.

I did a debug of a g28 homing, this is the part for the Z (bltouch option on and attached)

19:19:27.006 : Z_SAFE_HOMING >>>
19:19:27.006 : current_position=(0.00, 0.00, 10.00) : sync_plan_position
19:19:27.006 : destination=(82.00, 110.00, 10.00) : Z_SAFE_HOMING
19:19:27.006 : >>> do_blocking_move_to(82.00, 110.00, 10.00)
19:19:28.230 : <<< do_blocking_move_to
19:19:28.230 : >>> homeaxis(Z)
19:19:28.230 : current_position=(82.00, 110.00, 10.00) : set_probe_deployed
19:19:28.230 : deploy: 1
19:19:28.230 : do_probe_raise(10.00)
19:19:28.230 : >>> do_blocking_move_to(82.00, 110.00, 10.00)
19:19:28.230 : <<< do_blocking_move_to
19:19:28.230 : Home 1 Fast:
19:19:28.230 : >>> do_homing_move(Z, -285.00, 0.00)
19:19:28.286 : set_bltouch_deployed(1)
19:19:28.286 : current_position=(82.00, 110.00, 0.00) : sync_plan_position
19:19:28.352 : set_bltouch_deployed(0)
19:19:28.352 : <<< do_homing_move(Z)
19:19:28.352 : Move Away:
19:19:28.352 : >>> do_homing_move(Z, 10.00, 0.00)
19:19:28.352 : current_position=(82.00, 110.00, 0.00) : sync_plan_position
19:19:29.062 : N24 M105*17
19:19:30.887 : <<< do_homing_move(Z)
19:19:30.887 : Home 2 Slow:
19:19:30.887 : >>> do_homing_move(Z, -20.00, 1.00)
19:19:30.943 : set_bltouch_deployed(1)
19:19:30.943 : current_position=(82.00, 110.00, 0.00) : sync_plan_position
19:19:31.066 : set_bltouch_deployed(0)
19:19:31.066 : <<< do_homing_move(Z)
19:19:31.066 : >>> set_axis_is_at_home(Z)
19:19:31.066 : For Z axis:
19:19:31.066 : home_offset = 0.00
19:19:31.066 : position_shift = 0.00
19:19:31.066 : soft_endstop_min = 0.00
19:19:31.066 : soft_endstop_max = 190.00
19:19:31.066 : *** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
19:19:31.066 : > zprobe_zoffset = 0.00
19:19:31.066 : > home_offset[Z] = 0.00
19:19:31.066 : current_position=(82.00, 110.00, 0.00) :
19:19:31.066 : <<< set_axis_is_at_home(Z)
19:19:31.066 : current_position=(82.00, 110.00, 0.00) : sync_plan_position
19:19:31.066 : current_position=(82.00, 110.00, 0.00) : > AFTER set_axis_is_at_home
19:19:31.066 : current_position=(82.00, 110.00, 0.00) : set_probe_deployed
19:19:31.066 : deploy: 0
19:19:31.066 : do_probe_raise(10.00)
19:19:31.066 : >>> do_blocking_move_to(82.00, 110.00, 10.00)
19:19:32.119 : N25 M105*16
19:19:33.642 : <<< do_blocking_move_to
19:19:33.642 : >>> do_blocking_move_to(82.00, 110.00, 10.00)
19:19:33.642 : <<< do_blocking_move_to
19:19:33.642 : <<< homeaxis(Z)
19:19:33.642 : <<< Z_SAFE_HOMING
19:19:33.642 : current_position=(82.00, 110.00, 10.00) : > (home_all_axis || homeZ) > final
19:19:33.642 : current_position=(82.00, 110.00, 10.00) : sync_plan_position
19:19:33.642 : current_position=(82.00, 110.00, 10.00) : clean_up_after_endstop_or_probe_move
19:19:33.642 : <<< gcode_G28
19:19:33.642 : X:82.00 Y:110.00 Z:10.00 E:0.00 Count X: 8245 Y:11001 Z:3992

---

Don't know what to do next, maybe download rc7 and try again?

[Bob-the-Kuhn]

Attach your configuration.h, configuration_adv.h, pins_RAMPS.h, and pins_MKS_13.h files that you use with the BLTouch so I can review them.

Don't go back to RC7 - it has some known BLTouch problems.

Please enable ENDSTOPPULLUPS or ENDSTOPPULLUP_ZMIN. Without this the pin is floating which can give unreliable results.

Do NOT enable FIX_MOUNTED_PROBE when using the BLTouch.

---

Sanity check - by chance are you using one of the BLTouch clones? If yes then maybe there's a difference in how they operate.

---

Let's get back to basics.

A lot of this is a repetition of what's been done earlier but I want to go through all the steps I'd take to troubleshoot this on my machine.

What pins are the five BLTouch wires connected to?

Download the latest RCBugFix. Copy all your setup info over, except the endstop & probe stuff, to the new configuration.h and configuration_adv.h files. Download to your board & verify that the motors move as expected.

Set your configuration.h to the following:

#define USE_ZMIN_PLUG
#define ENDSTOPPULLUPS
#define Z_MIN_ENDSTOP_INVERTING false
//#define FIX_MOUNTED_PROBE
//#define BLTOUCH
//#define Z_MIN_PROBE_PIN X_MIN_PIN
//#define Z_MIN_PROBE_ENDSTOP
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

With nothing connected to the Z_MIN pin, the M119 command should say triggered.

Connect the mechanical switch NC to the Z_MIN pin and the common to ground. M119 should say open.

Press & hold the mechanical switch. M119 should say triggered.

Remove the mechanical switch. M119 should say triggered.

Attach the BLTouch. M119 should say open.

Make the following changes to your configuration.h file

#define BLTOUCH
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

Verify that the BLTouch pin goes up & down.

M280 P0 S10   -  lowers the probe
M280 P0 S90   -  raises the probe

Issue the following commands

M280 P0 S10   -  lowers the probe
M280 P0 S60   -  M119 test mode

M119 should say open.

Manually push the probe up. It should retract & stay retracted.

M119 should say triggered.

[Sicon76]

First of all, thank you Bob-the-Kuhn for your time, I followed your step by step and I reach the end with nothing wrong, but the last steps: after I send m280 P0 S60 the bltouch retracts its pin (m119 says open) so I can't push the probe up as you wrote, I can only push down (this way m119 says triggered), is it normal or this is the problem? What next?

Thank you again!!!

[Sicon76]

I did a video of the problem, it's after a G28 and during the Z probing (the bltouch doesn't have the support), as you can see, after the z clearing it extends the probe and suddenly retracts it as find the trigger and then repeat for the second time

https://youtu.be/FLeBxRvFsUE

[Bob-the-Kuhn]

Something is still wrong. We need to be able to manually verify proper operation before we do anything else.

Issuing the M280 P0 S60 command doesn't retract the probe on my system.

In my testing I've always had the head up high enough that the probe couldn't touch the bed. That way I could push the probe up towards the body with my finger until the probe retracts on it own. All of this assumes the head is stationary.

When I say push up I'm manually pushing the probe toward the retracted position. The BLTouch will ALWAYS fully retract the probe once the trigger point is reached. If it's in the S60 (M119) mode then it'll stay retracted. If it's in the normal mode then it'll fully retract, wait about 1/4 second and then deploy/extend the probe. The attached videos show how my system works. BLTouch.zip

I saw your video. It's probably just the photography but your BLTouch looks longer than mine & I don't see the light inside the body being on when the probe is retracted and off when it's extended. My BLTouch is about 36.5mm from the top to the point where the probe leaves the body.

In the video I see the X axis double tap, then the Y axis double tap and then I don't see any Z axis movement. Why is there no Z movement? I'm guessing that either the Z stepper isn't plugged in or the Z_MIN signal is already in the triggered state. If the Z stepper is functional then something besides the BLTouch is pulling the signal active. Possibilities that come to mind are:

• Z_MIN cable issues - not likely because M199 said triggered before attaching the BLTOUCH and after attaching it said open.
• Z_MIN_ENDSTOP_INVERTING issues? No because M119 is reporting as expected.
• BLTouch attached incorrectly? Please tell me what color wire is attached to which pin in your system.

• Could there be a second function assigned to the Z_MIN pin? I ran into a situation where this caused a problem. Attached is some code that (hopefully) will be in the next Marlin release. It'll report all the names attached to a pin. To use it do the following:

  1. Save a copy of your pinsDebug.h file - it's going to be overwritten.
  2. Unzip the attached file and copy all three into your Marlin directory. This will overwrite your pinsDebug.h file.
  3. In Configuration_adv.h enable the PINS_DEBUGGING flag
  4. Compile & upload
  5. Issue the following command: M43 I1
  6. Scroll up to the Z_MIN_PIN and see if anything else is assigned to it and verify that it's an input with a logic level of zero.
  7. Command a Z_AXIS movement.
  8. Do another M43 I1 and verify that nothing has changed
  9. Do a M43 E1 command - it'll sample the endstops and report if there's any changes.
  10. Do your G28. It should show the X & Y but not the Z changing states.

[ghost]

The MKS boards have all , the physical pullups resistors soldered on the board , so impossible to use , a BLTOUCH , because bltouch send voltage and , the high state is permanent by the physical resistor

Use a GEETECH 3D TOUCH , that give a ' contact ' on his out pin

And all is good You can also , destroy the resitor on the board after identify it

steeve

[Sicon76]

Could you explain better or point me to a link about the mods to do on the geetech 3d touch to work on my MKS board?

Thank you!

[Sicon76]

I asked more because I already have a geetech 3d touch, I wrote it as a bltouch just to give an idea of the kind of the sensor I have and when you wrote that the geetech could work I tought there is something to do to trick that I didn't do. If you say that it should work then I have a broken unit.

Thank you anyway

[Roxy-3D]

Issuing the M280 P0 S60 command doesn't retract the probe on my system.

@Bob-the-Kuhn I just noticed this sentence. I do not believe S60 physically does anything. It just changes the electrical signal being put out. And it only does that on the very newest of the BL-Touch probes. What it does is report whether the pin is pushed in enough to trigger the HAL effect or not. It is my belief you still need to use the S10 position to deploy the probe pin and S90 to retract it.

[Bob-the-Kuhn]

@studiodyne - it's really unusual to have to remove the pull up resistors. They're an absolute must on mechanical endstops and required on most hall effect endstops. I have them on all 6 of my endstops and on my BLTouch. I'm running hall effect endstops.

Are you saying that your GEEETECH wouldn't work with the pull up resistor in place but works now that you've removed the resistor?

@Roxy-3D - correct - on my BLTouch the S60 command does not result in the probe physically moving. To use the M119 mode I manually issue the S10 to deploy, then the S60, then trigger the BLTouch (push the probe back up towards the body), issue a M119 command which reports the BLTouch as triggered and finally issue a S90 which sets the signal back to open.

I'd heard that there were recent changes to the BLTouch but I couldn't find anything on what they were.

FYI - I received my BLTouch in late July.

[Bob-the-Kuhn]

@studiodyne - I just looked at the MKS gen7 rev 14 schematic and there are no physical pullup resistors on the three endstops. The endstop connectors have +5V, signal and ground.

If there is a newer schematic out then please point me to it.

There is an option to enable the pullup resistors within the Atmel. This is enabled/disabled within the configuration.h file.

Please attach your configuration.h, configuration_adv.h and pins_GEN7_14.h files & I'll see if I can spot something wrong.

[Bob-the-Kuhn]

@studiodyne - do you have your GEETECH working?

[Bob-the-Kuhn]

Please attach your configuration.h, configuration_adv.h and pins_GEN7_14.h files & I'll see if I can spot something wrong.

Edit by Roxy:

Please attach your configuration.h, configuration_adv.h and pins_GEN7_14.h files & I'll see if I can spot something wrong.

When doing this... Attach the files and DO NOT just paste the entire text into a post. It makes the entire thread unreadable!!!

What do you mean by "does not work"?

• Tried to probe the bed but the head crashed
• The M119 command always says open (that is normal for the BLTouch)
• The BLTouch doesn't deploy or stow when you send the M280 P0 S10 and M280 P0 S90 commands

The only physical pullups on the board are the 4.7K for the two thermistor inputs.

I don't see a servo connector on the schematic.

The end stop connectors have this pinout:

• 1 - sensor input
• 2 - ground
• 3 - +5V

Could you have the endstop connector/wiring reversed?

[ghost]

What do you mean by "does not work"?

Tried to probe the bed but the head crashed
The M119 command always says open (that is normal for the BLTouch)
The BLTouch doesn't deploy or stow when you send the M280 P0 S10 and M280 P0 S90 commands

---

BLTOUCH pass the dual up down test , push the pin and retract immediatly , repush the pin and retract immediatly and HOMING FINISH without touching the bed

The only physical pullups on the board are the 4.7K for the two thermistor inputs. I have permanent 5 v due to a resitor i'm electronician i know electronics and i know when a pullup resistor is on a input , The permanent 5v falls to zero when i plug the geetech , the geetech is always closed ' i think ' because the voltage on the out is close to zero all the time , and tranmit a quick +5v when touching , it's enough to trig the mks gen The geetech have no resistive mesurement , so i think it's a mosfet or transistor that switch and force the low state on the input and deliver a quick high state when probing The exact reverse functionnality of the bltouch Tomorow i will make some try with a free pin that is non pulled up

I don't see a servo connector on the schematic.

The end stop connectors have this pinout:

1 - sensor input
2 - ground
3 - +5V

Could you have the endstop connector/wiring reversed?

[ghost]

all my comments were wrong , i have deleted them Now , i have the same problem than sicon The geektech works , the bltouch bug I will make all test sequences to compare the two sensors , may be i will discover what is the diffence and what is the problem

[Bob-the-Kuhn]

Sorry - I was looking at the Gen 7 schematic, NOT the MKS schematic. As far as I know there isn't an MKS schematic available to the public. If you have one I'd dearly love to have a copy.

Perfect? As a fellow engineer I expect you to be improving it until it's broken! ;-) At least that's what I tend to do. :-(

=============================================

BLTOUCH pass the dual up down test , push the pin and retract immediatly , repush the pin and retract immediatly and HOMING FINISH without touching the bed

Is this still true? If yes then I think the BLTouch is working properly.

Forget about the M280 P0 S60 "feature" on the BLTouch. It's just something that is supposed to help when troubleshooting a problem. It's NOT used by G28, G29, G30 or M48.

==========================================================

The BLTouch keeps the output signal low until it is triggered and then it drives the signal high for 5mS. The rise time is under a microsecond so the BLTouch has to have a totem pole output configuration.

Here's the settings in your file that could affect the BLTOUCH

#define USE_ZMIN_PLUG
//#define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop 
//#define ENDSTOPPULLUP_ZMIN
//#define ENDSTOPPULLUP_ZMIN_PROBE
#define BLTOUCH
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define Z_MIN_ENDSTOP_INVERTING true.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false

The only item of concern I saw in the files was the two inverting flags were set differently. The probe one is set correctly fro the BLTouch. I don't think the other is used when Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is enabled.

#define Z_MIN_ENDSTOP_INVERTING true.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false

[ghost]

GEETECH S10 ........ go down all OPENED s90.......... go up all OPENED S60 ......... PIN DOWN manualy = Zmin OPENED AND PIN UP manualy = TRIGGERED S60 don't move the pin , if up , stays up , if down stays down , but activates the test mode

Config h

// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
#define X_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Y_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Z_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define X_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false// set to true to invert the logic of the endstop.

[Bob-the-Kuhn]

Why do you have Z_MIN_ENDSTOP_INVERTING set to true?

[ghost]

no i have corrected as the original config that works because , i modify in non stop mode , i test all possibility , i have given you , a non original config , but i can told you that i have tried all possibilitiés , i will never be here , if it was just a ' DEFINE PROBLEM' lol When i have plugged my first geetech , i have modified nothing , just DEFINE BLTOUCH all have worked at the first boot I love ' geetech' lol

[Bob-the-Kuhn]

Everything is working?

[ghost]

with the geetech , you have the result ALL WORKS IT'S MAGIC

[Bob-the-Kuhn]

YEAHHHHHH!!!!!!!!

[ghost]

Now i will make all test sequences with BLTOUCH and you will compare , and ask me all you want , i make the test for you

[ghost]

Hey , geetech have ever worked , it's just THE BL TOUCH SENSOR that not work !! I want to find the issue

[ghost]

Now i make test on a hotplug of the BLTOUCH SENSOR , no reset no boot

[ghost]

wait a few minutes

[Roxy-3D]

Forget about the M280 P0 S60 "feature" on the BLTouch. It's just something that is supposed to help when troubleshooting a problem. It's NOT used by G28, G29, G30 or M48.

I do intend to directly support the S60 mode when possible. But right now, I have an unanswered email out to Antclabs. The newest version of the BL-Touch is the only version of the BL-Touch that supports the S60 mode. And I do not have one of those to code against or use to test for correct behavior. But it is not a 'debug feature' for trouble shooting problems. It changes the output signal of the BL-Touch to not be a pulse. Instead it outputs a steady logic level who's value id dependent upon whether the pin is depressed enough or not to trigger the HAL sensor.

The BLTouch keeps the output signal low until it is triggered and then it drives the signal high for 5mS. The rise time is under a microsecond so the BLTouch has to have a totem pole output configuration.

The BL-Touch uses an AVR Tiny. It is my belief it directly drives the output signal from one of the AVR's GPIO pins. It is not a vanilla 'Totem Pole' configuration. If so, it has more circuitry than that because it can (and I believe does) have a pull up resistor capability and it can also be tri-stated.

The only item of concern I saw in the files was the two inverting flags were set differently. The probe one is set correctly fro the BLTouch. I don't think the other is used when Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is enabled.

I am bringing up a gMax 1.5+ as we speak and it uses a BL-Touch probe. I ran into a problem with Sanity_Check.h complaining about:

#define Z_MIN_ENDSTOP_INVERTING true.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false

I changed it to:

#define Z_MIN_ENDSTOP_INVERTING false.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false

and so far everything is working for me... But I have not done an extensive probe of the bed yet to build the UBL mesh.

[Roxy-3D]

Now i make test on a hotplug of the BLTOUCH SENSOR , no reset no boot

If you are going to hotplug the probe... It would be well advised to do a M280 P0 S160 to 'Reset' it.

[ghost]

GEETECH VS BLTOUCH results

ON GEETECH GEETECH S10 ........ go down all OPENED s90.......... go up all OPENED S60 ......... PIN DOWN manualy = Zmin OPENED AND PIN UP manualy = TRIGGERED S60 don't move the pin , if up , stays up , if down stays down , but activates the test mode

ON BLTOUCH S10 the pin DOWN , M119 = TRIGGERED S90 The pin UP , M119 = all opened re S10 PIN DOWN - M119 TRIGGERED re S90 the pin UP , M119 all opened S60 the pin up , STAYS UP , won't down M119 = ALL OPENEd

---

PLEASE CODE SOMETHING TO FIX IT loll

---

Config h

// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
#define X_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Y_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Z_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define X_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false// set to true to invert the logic of the endsto

[Bob-the-Kuhn]

That S60 mode was in the ANTCLAB docs when I bought mine in July.

When I'm sitting at the console and typing the commands then the S60 mode works (M119 command reports the BLTouch triggered when I manually push the pin up toward the body).

I tried to do the same thing in code but didn't get reliable results.

See PR #5729 guaranteed BLTouch detection for details.

[ghost]

i have a low cost chinese BLTOUCH , i'm sure that it's an imitation, bought on aliexpress at low cost

Do you think the software inside is not a true copy of a true bltouch ?

[ghost]

@Sicon76 , can you tell me if you have an OEM certified BLTOUCH , or a half price BLTOUCH perfect imitation ' with perfect labelling ' , bought on aliexpress or ebay ?

[Bob-the-Kuhn]

Wouldn't surprise me that it was different. The clones have been known to fix issues present in the original.

If the S60 mode worked reliably on a BLTouch from day one then we'd be using it. The 5mS pulse idea was not well thought out.

[Roxy-3D]

See PR #5729 guaranteed BLTouch detection for details.

Yes! I'm actually crossing that code over right now. The problem is I was using RC-8 and all the Stepper.cpp code changed and your patch doesn't make sense in that context. So... I'm restarting using RCBugFix and hopefully, in an hour I'll have your code crossed over and working!

THANK YOU VERY MUCH FOR THAT CODE!!!!!

[Bob-the-Kuhn]

@Sicon76 - sounds like you're still down. If you want you can send me your unit & I'll hook it up to my logic analyzer & see what it does.

---

BLTOUCH perfect imitation ' with perfect labelling ' , bought on aliexpress or ebay

Sounds like it's pretty hard NOT to buy a perfect imitation since the only place you can get ANTCLABS units is on Ebay.

Maybe I've got the perfect imitation.

[Roxy-3D]

@Bob-the-Kuhn Bob... I have guaranteed legitimate units sent to me by Paris at Antclabs to test against. If you are not sure if you are fighting a clone problem, I can apply the test to a 'known good' unit.

[ghost]

@Bob-the-Kuhn Can you simplifiy the situation , we have 3 sensors , the geetech ' perfect ' , the bltouch imitation , and the BLTOUCH ' real ' For the moment , the geetech works , the imitation not working , and BLTOUCH i will know in a few days lol Can you give me the issue for this If we buy the REAL BLTOUCH ? All works ? If we want to have a clone fully functionnal , do we have to add , a tricked code to avoid the bad triggering process

What is the end of this story ?

[ghost]

Or may be , i write a mail to PARIS , and i asked her to extend the pulse to 250 ms , to be sure ? ;-)

[ghost]

Or for more reactivity , i can ask to the cloning factory , to increase the time of the pulse lolll

[Bob-the-Kuhn]

It would be nice to have others test my code.

I don't think that clone, perfect imitation or real matters anymore to the S60 issue. There are units out there that don't have S60 functionality or have unreliable S60 operation so we're doomed to have continuing support issues if we incorporate S60 into the Marlin code.

The only way to peace & quiet for all users is to make sure we can reliably work with the 5mS pulse mode of operation.

[ghost]

i will test your code , but , i hate ' github' , i understand nothing !!! i don't know how it works , i'm lost here , i don't know how to do the simple things I'm beginner Thk you very much for your help

I go to your branch and i will try to find ' your code ' , and if i find it , i will try to incorporate in my firm , and if the compilator would be nice , it will compile something to test

THk you