BLTouch ignoring M-commands

[mbabauer]

High, all.

I am VERY new to this, so my appologies if this is being posted in the wrong place. I am trying to add a BLTouch Smart to my Anycubic Kossal but having problems.

When I turn on the printer, the BLTouch does it's self test, moving the pin out and in twice, then I get a solid red light. I am not seeing any blue light at all (maybe this version doesn't have it???). If I pull the pin out the red light goes off.

My setup is as follows:

• Anycubic Kossal Pulley
• Marlin Firmware v1.1.0-RC8 (Downloaded from the Anycubic Google Drive page
• BLTouch Smart wired to the S0 and Z- prongs on the TriGorilla board

My config is: current_config.txt

I have the Black and White wires from the BLTouch wired to the Z- S and G pins (there is also a V pin, but the board seems not to boot up at all if I us that one). It doesn't seem to matter which way the White and Black wires are connected, as long as I am not using the V.

For the servo wires I have the Yellow wired to S, Brown wired to -, and Red wired to +.

Any help is much appreciated!

[Roxy-3D]

The blue light is primarily noticed on the very latest probes. If I had to guess... The last 6 weeks all of the probes have blue lights now.

The position of the white and black wires do matter. By doing a M119 you probably will be able to see if the controller board thinks the probe is triggered or not. Because the BL-Touch only sends out a pulse... It should always be in an open state when you do a M119.

You should be able to control the BL-Touch by doing these commands:

• M280 P0 S260 ;reset
• M280 P0 S120 ;self test
• M280 P0 S90 ;stow probe pin
• M280 P0 S10 ;deploy probe pin

[Bob-the-Kuhn]

What version of Marlin are you running? I don't recognize the configuration.h file.

If your BLTouch has a serial number then it has a blue LED. It's on the right side at the bottom of the PWB on the inside.

Here's a sequence to see if your BLTouch with a serial number is hooked up correctly:

1. Connect BLTouch, power up controller and upload the firmware
2. Blue LED will be ON if a servo signal is present. Blue LED is faint.
3. M119 ; should return OPEN. If not check that the BLTouch is enabled in the configuration. If enabled then check wiring and check that the correct pin is being used. Also check that Z_MIN_ENDSTOP_INVERTING and Z_MIN_PROBE_ENDSTOP_INVERTING are both set to "false".
4. M280 P0 S10 ; should deploy the probe and the orange LED will be OFF.
5. M119 ; should return OPEN
6. M280 P0 S90 ; should stow the probe and the orange LED will be ON
7. M280 P0 S60 ; puts it into the M119 test mode.
8. The probe should remain stowed and the blue LED should be OFF. If it's ON then the unit needs to be adjusted.
9. M119 ; should return TRIGGERED
10. M280 P0 S160 ; returns it to normal operation
11. M119 ; should return OPEN.

[mbabauer]

The blue light is primarily noticed on the very latest probes. If I had to guess... The last 6 weeks all of the probes have blue lights now.

Mine has a QR code with a 9-character string that I guess could be a serial number. Just below it, in tiny letters is "Smart V1.0". It is also has a wiring harness instead of having the wires directly attached to it. I am pretty sure this is the one I have.

You should be able to control the BL-Touch by doing these commands:

These are the commands I am trying. M119 returns "open" for the Z-minus, but when I issue the M280 commands it doesn't do anything. If I pull out the pin, the red LED goes off but M119 still shows Z-minus as "open". I have tried flipping the wires around but no difference. I don't see any blue LEDs at all, just the red.

What version of Marlin are you running? I don't recognize the configuration.h file. I got the firmware from here. It's reported as 1.1.0 RC8.

[Bob-the-Kuhn]

Nice - BLTouch has done away with the soldered wires & gone to a connector.

I take it that you downloaded Anycubic_kossel.rar or it's brother.

That software puts the servo0 signal on pin 7. Marlin puts it on pin 11.

If I read my notes properly pin 7 on RAMPS 1.3 was servo0. On RAMPS 1.4 (the current one) servo 0 is pin 11.

Change your motherboard define from "33" (RAMPS 1.3 EFB) to "43" (RAMPS 1.4 EFB) and I think it'll start working.

[mbabauer]

Change your motherboard define from "33" (RAMPS 1.3 EFB) to "43" (RAMPS 1.4 EFB) and I think it'll start working.

Ok, the M-commands are working now. I can raise/lower the pin and can run the "self test". But the M119 still is reporting "open" even when the pin is pulled out. Still need to figure out why. I'll try to fiddle with the connections to Z-min and see if maybe it's just the order.

[Bob-the-Kuhn]

M119 will almost never report the BLTouch as triggered unless you put the BLTouch into the self test mode. In normal operation the BLTouch sends out a 5mS pulse when triggered. You'll have to be very lucky or very persistent to catch that pulse with M119.

If you use the sequence above you'll find out if the BLTouch's output is working properly.

There's an alternative method to determine if the BLTouch is fully functional. Issue the M43 S1 command and follow the directions on the host screen (not the LCD screen). To enable the M43 commands you'll need to enable PINS_DEBUGGING in configuration_adv.h.

[mbabauer]

Fair enough about the M119, but when I run the following:

G28
G29

The BLTouch pin will extend, then the head will smash into the bed and it will drag out violently towards X-, Y-, (front left corner). I double-checked and the bottom of the BLTouch is almost spot-on at 8.3mm above where the print head is. I have Z_PROBE_OFFSET_FROM_EXTRUDER set to 0 right now, maybe that needs to be something else?

[Roxy-3D]

Can you deploy the Z-Probe with a M280 P0 S10 And then manually raise the pin until it triggers. It should trigger before the pin is above the bottom of the nozzle.

[mbabauer]

Can you deploy the Z-Probe with a M280 P0 S10 And then manually raise the pin until it triggers. It should trigger before the pin is above the bottom of the nozzle.

Here are the steps I just performed:

G28
M280 P0 S10
G1 X0 Y0 Z5 F7000

Then I used the -.1 stepdown in Printerface until the pin popped up and the light was on. This was at Z.2. I then repeated it and got the same result.

My printer is leveled right now so Z0 has just a slight bit of friction with a thin sheet of paper.

Edit: I tried setting the Z_PROBE_OFFSET_FROM_EXTRUDER to -.2, based on the above test, but it's still dragging across the bed.

[Bob-the-Kuhn]

The paper test will get you close. You'll need to refine the Z_PROBE_OFFSET_FROM_EXTRUDER based on what it's actually doing.

Make sure leveling is off when you set Z_PROBE_OFFSET_FROM_EXTRUDER. Don't forget to do the M502, M500, M501 sequence to save it to EEPROM.

[mbabauer]

You'll need to refine the Z_PROBE_OFFSET_FROM_EXTRUDER based on what it's actually doing. Heh, well right now it's dragging the print head violently across the bed. I have Z_PROBE_OFFSET_FROM_EXTRUDER set to -.2 based on the test above:

#define X_PROBE_OFFSET_FROM_EXTRUDER -36.5     // X offset: -left  +right  [of the nozzle]
#define Y_PROBE_OFFSET_FROM_EXTRUDER -23   // Y offset: -front +behind [the nozzle]
#define Z_PROBE_OFFSET_FROM_EXTRUDER -.2  // Z offset: -below +above  [the nozzle]

Maybe it's trying to probe too fast or something?

[Roxy-3D]

.2 mm isn't a lot of room. I have my BL-Touch at -1.027mm

[mbabauer]

.2 mm isn't a lot of room. I have my BL-Touch at -1.027mm Ok, I was basing it off what the documents said, 8.3mm above the top of the of the print head. Let me try to move it down a bit and see what happens.

[mbabauer]

Ok, I adjusted my bracket until the pin activated at 2.1 above the bed, then I set the Z_PROBE_OFFSET_FROM_EXTRUDER to -2.1 in the configuration.h and uploaded. But, when I do the following:

G28
G29

It still bangs dead into the bed then rubs the printhead out towards the X-,Y- corner, so hard it's tearing the tape I have there.

[Bob-the-Kuhn]

Every probe should look like this:

• Head descends quickly
• The pin extends when the nozzle gets to the Z_CLEARANCE_DEPLOY_PROBE height. The speed also changes to Z_PROBE_SPEED_FAST.
• The nozzle continues to descend until the pin is pushed far enough up that the orange/red LED comes back on. At this point the nozzle should raise up to the Z_CLEARANCE_BETWEEN_PROBES (or is it Z_CLEARANCE_DEPLOY_PROBE?) height.
• The pin will extend and then the nozzle descends at the Z_PROBE_SPEED_SLOW speed.
• The nozzle continues to descend until the pin is pushed far enough up that the orange/red LED comes back on. At this point the nozzle should raise up to the Z_CLEARANCE_BETWEEN_PROBES (or is it Z_CLEARANCE_DEPLOY_PROBE?) height.

I'll bet that's not happening.

I expect this is another example of wrong settings because of a poorly worded Z probe section. We have to come up with something better.

You're homing in the +Z direction which means you're using the Z_MAX endstop for homing and the BLTouch only for probing. In this situation you need the following defines: //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

define Z_MIN_PROBE_ENDSTOP

I don't know if #define Z_MIN_PROBE_PIN Z_MIN_PIN is acceptable or not. Have you used the sequence I gave you or the servo probe test to verify that the BLTouch's output is hooked to the correct pin?

When you do a G28 and then a G0 Z0, how far above the bed is the nozzle?

[mbabauer]

When you do a G28 and then a G0 Z0, how far above the bed is the nozzle? The nozel is homed exactly to 1 paper thickness from the bed when I do that sequence. I have manually leveled the bed and the correct Z height is stored in my configuration.h (#define MANUAL_Z_HOME_POS 335.7).

Have you used the sequence I gave you or the servo probe test to verify that the BLTouch's output is hooked to the correct pin? Is this the M502, M500, M501 sequence? I thought this was done after G29 runs successfully?

Every probe should look like this: Here are my settings for each of those:

• #define Z_CLEARANCE_DEPLOY_PROBE 50
• #define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z (HOMING_FEEDRATE_Z is 60*60)
• #define Z_CLEARANCE_BETWEEN_PROBES 5
• #define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2)

If I run the G28, G29 sequence, this is what I seem to get:

• Head autohomes at top
• Head moves in the X-, Y- direction (front-left corner of the grid)
• Pin deploys and red light turns faint blue
• Head descends slowly, pin is triggered and red light comes on, but keeps descending until the head crashes into the bed.
• Head keeps moving in the X-, Y- direction, dragging and vibrating across the bed

I took a video of it this morning and shared it here.

[Bob-the-Kuhn]

You definitely do NOT have the probe's output setup properly.

Did you do these changes?

//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define Z_MIN_PROBE_ENDSTOP

The M502, M500, M501 sequence is used when you have the EEPROM enabled and want to save your changes.

G29 does NOT save the results to EEPROM. You'll need to do the M502, M500, M501 sequence to save the results.

The sequence to determine if the BLTouch is setup properly is:

1. Connect BLTouch, power up controller and upload the firmware
2. Blue LED will be ON if a servo signal is present. Blue LED is faint.
3. M119 ; should return OPEN. If not check that the BLTouch is enabled in the configuration. If enabled then check wiring and check that the correct pin is being used. Also check that Z_MIN_ENDSTOP_INVERTING and Z_MIN_PROBE_ENDSTOP_INVERTING are both set to "false".
4. M280 P0 S10 ; should deploy the probe and the orange LED will be OFF.
5. M119 ; should return OPEN
6. M280 P0 S90 ; should stow the probe and the orange LED will be ON
7. M280 P0 S60 ; puts it into the M119 test mode.
8. The probe should remain stowed and the blue LED should be OFF. If it's ON then the unit needs to be adjusted.
9. M119 ; should return TRIGGERED
10. M280 P0 S160 ; returns it to normal operation
11. M119 ; should return OPEN.

[mbabauer]

Did you do these changes? //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

define Z_MIN_PROBE_ENDSTOP

Yes, I made those changes when you suggested them and uploaded to the printer. I also ran the eeprom_clear script first just to make sure it wasn't holding on to any bad values.

With the above steps, everything was good until Step 9. At that step, M119 returns "open" still, but the blue light is off on the probe.

[Bob-the-Kuhn]

I think I know what the problem is.

#define Z_MIN_PROBE_PIN Z_MIN_PIN doesn't work. The problem is Z_MIN_PIN isn't defined yet so Z_MIN_PROBE_PIN's value is nothing.

The work around is to do one of the following:

• Preferred - in the file pins_RAMPS.h add the line #define Z_MIN_PROBE_PIN Z_MIN_PIN at the very end.
• In configuration.h change #define Z_MIN_PROBE_PIN Z_MIN_PIN to #define Z_MIN_PROBE_PIN 18

[mbabauer]

I made those changes but it's still showing "open" after M119. I also tripple-checked all the wires are where they should be (orange/red/brown to S0 and white/black to Z-Min). Is there some way to test the board directly, like maybe putting voltage on one of the Z-MIN pins, to see if it's maybe the board isn't working or isn't setup right?

[Bob-the-Kuhn]

The M43 command has several useful options. You'll need to enable PINS_DEBUGGING in Configuration_adv.h to activate M43.

M43 I1 is the first command I'd issue. It lists all the pins on the board and the signal(s) attached to it. Z_MIN_PIN and Z_MIN_PROBE_PIN should be both assigned to the same logical pin.

M43 S1 is the next one I'd do. This will test the BLTouch.

M43 I1 W1 will continuously scan all the pins and report any changes. Short the ground pin to the signal pin on the Z_MIN connector. That'll pop up the logical pin number along with the signals assigned to it.

  /**
   * M43: Pin debug - report pin state, watch pins, toggle pins and servo probe test/report
   *
   *  M43         - report name and state of pin(s)
   *                  P<pin>  Pin to read or watch. If omitted, reads all pins.
   *                  I<bool>  Flag to ignore Marlin's pin protection.
   *
   *  M43 W<bool>  - Watch pins -reporting changes- until reset, click, or M108.
   *                  P<pin>  Pin to read or watch. If omitted, read/watch all pins.
   *                  I<bool>   Flag to ignore Marlin's pin protection.
   *
   *  M43 E<bool> - Enable / disable background endstop monitoring
   *                  - Machine continues to operate
   *                  - Reports changes to endstops
   *                  - Toggles LED_PIN when an endstop changes
   *                  - Can not reliably catch the 5mS pulse from BLTouch type probes
   *
   *  M43 T<bool>  - Toggle pin(s) and report which pin is being toggled
   *                  S<pin>  - Start Pin number.   If not given, will default to 0
   *                  L<pin>  - End Pin number.   If not given, will default to last pin defined for this board
   *                  I<bool> - Flag to ignore Marlin's pin protection.   Use with caution!!!!
   *                  R       - Repeat pulses on each pin this number of times before continueing to next pin
   *                  W       - Wait time (in miliseconds) between pulses.  If not given will default to 500
   *
   *  M43 S<bool> - Servo probe test
   *                  P<index> - Probe index (optional - defaults to 0
   */

[mbabauer]

M43 I1 is the first command I'd issue.

I don't see any pins listed as Z_MIN_PROBE_PIN, but Z_MIN_PIN is listed on Pin 18 with Input =0. The full output was:

>>> M43 I1
SENDING:M43 I1
PIN:  0        RXD                         Input  = 1
PIN:  1        TXD                         Input  = 0
PIN:  2        X_MAX_PIN                   Input  = 0    TIMER3B    WGM: 0    TIMSK3: 2   Can't be used as a PWM because of counter mode
PIN:  3        <unused>                    Input  = 1    TIMER3C    WGM: 0    TIMSK3: 2   Can't be used as a PWM because of counter mode
PIN:  4        FIL_RUNOUT_PIN              Input  = 1    TIMER0B    WGM: 3    TIMSK0: 5   Can't be used as a PWM because it's being used as an interrupt
PIN:  5        SERVO2_PIN                  Output = 0    TIMER3A    WGM: 0    TIMSK3: 2   Can't be used as a PWM because of counter mode
PIN:  6        SERVO1_PIN                  Output = 0    TIMER4A    WGM: 1    TIMSK4: 0   can be used as PWM
PIN:  7        <unused>                    Input  = 0    TIMER4B    WGM: 1    TIMSK4: 0   can be used as PWM
PIN:  8        HEATER_BED_PIN              Output = 0    TIMER4C    WGM: 1    TIMSK4: 0   can be used as PWM
PIN:  9        FAN_PIN                     Output = 0    TIMER2B    WGM: 1    TIMSK2: 0   can be used as PWM
PIN: 10        HEATER_0_PIN                Output = 0    TIMER2A    WGM: 1    TIMSK2: 0   can be used as PWM
PIN: 11        SERVO0_PIN                  Output = 0    TIMER1A    WGM: 4    TIMSK1: 2   Can't be used as a PWM because of counter mode
PIN: 12        PS_ON_PIN                   Output = 0    TIMER1B    WGM: 4    TIMSK1: 2   Can't be used as a PWM because of counter mode
PIN: 13        LED_PIN                     Input  = 0    TIMER0A    WGM: 3    TIMSK0: 5   Probably can't be used as a PWM because counter/timer is being used as an interrupt
PIN: 14        <unused>                    Input  = 1
PIN: 15        Y_MAX_PIN                   Input  = 0
PIN: 16        LCD_PINS_RS                 Output = 1
PIN: 17        LCD_PINS_ENABLE             Output = 0
PIN: 18        Z_MIN_PIN                   Input  = 0
PIN: 19        Z_MAX_PIN                   Input  = 0
PIN: 20        SDA                         Input  = 1
PIN: 21        SCL                         Input  = 1
PIN: 22        <unused>                    Input  = 1
PIN: 23        LCD_PINS_D4                 Output = 0
PIN: 24        E0_ENABLE_PIN               Output = 1
PIN: 25        LCD_PINS_D5                 Output = 0
PIN: 26        E0_STEP_PIN                 Output = 0
PIN: 27        LCD_PINS_D6                 Output = 0
PIN: 28        E0_DIR_PIN                  Output = 0
PIN: 29        LCD_PINS_D7                 Output = 0
PIN: 30        <unused>                    Input  = 1
PIN: 31        BTN_EN1                     Input  = 1
PIN: 32        <unused>                    Input  = 1
PIN: 33        BTN_EN2                     Input  = 0
PIN: 34        <unused>                    Input  = 1
PIN: 35        BTN_ENC                     Input  = 1
PIN: 36        <unused>                    Input  = 1
PIN: 37        BEEPER_PIN                  Output = 0
PIN: 38        X_ENABLE_PIN                Output = 1
PIN: 39        <unused>                    Input  = 1
PIN: 40        <unused>                    Input  = 1
PIN: 41        KILL_PIN                    Input  = 1
PIN: 42        <unused>                    Input  = 1
PIN: 43        <unused>                    Input  = 1
PIN: 44        <unused>                    Output = 0    TIMER5C    WGM: 1    TIMSK5: 0   can be used as PWM
PIN: 45        <unused>                    Input  = 0    TIMER5B    WGM: 1    TIMSK5: 0   can be used as PWM
PIN: 46        Z_STEP_PIN                  Output = 0    TIMER5A    WGM: 1    TIMSK5: 0   can be used as PWM
PIN: 47        <unused>                    Input  = 1
PIN: 48        Z_DIR_PIN                   Output = 0
PIN: 49        SD_DETECT_PIN               Input  = 0
PIN: 50        AVR_MISO_PIN                Input  = 1
PIN: 51        AVR_MOSI_PIN                Output = 1
PIN: 52        AVR_SCK_PIN                 Output = 0
PIN: 53        AVR_SS_PIN                  Output = 1
PIN: 54 (A 0)  X_STEP_PIN                  Output = 0
PIN: 55 (A 1)  X_DIR_PIN                   Output = 0
PIN: 56 (A 2)  Y_ENABLE_PIN                Output = 1
PIN: 57 (A 3)  <unused>                    Input  = 1
PIN: 58 (A 4)  <unused>                    Input  = 0
PIN: 59 (A 5)  FILWIDTH_PIN                Analog in =  464
PIN: 60 (A 6)  Y_STEP_PIN                  Output = 0
PIN: 61 (A 7)  Y_DIR_PIN                   Output = 0
PIN: 62 (A 8)  Z_ENABLE_PIN                Output = 1
PIN: 63 (A 9)  <unused>                    Input  = 1
PIN: 64 (A10)  <unused>                    Input  = 1
PIN: 65 (A11)  <unused>                    Input  = 1
PIN: 66 (A12)  MAX6675_SS                  Input  = 0
PIN: 67 (A13)  TEMP_0_PIN                  Analog in =  980
PIN: 68 (A14)  TEMP_BED_PIN                Analog in =  981
PIN: 69 (A15)  TEMP_1_PIN                  Analog in = 1023

M43 S1 is the next one I'd do.

Not sure what to look for here, and just to note the M280 commands do seem to control the BLTouch now. Full output was:

>>> M43 S1
SENDING:M43 S1
PIN:  0        RXD                         protected
PIN:  1        TXD                         protected
PIN:  2        X_MAX_PIN                   protected     TIMER3B    WGM: 0    TIMSK3: 2   Can't be used as a PWM because of counter mode
PIN:  3        <unused>                    Input  = 1    TIMER3C    WGM: 0    TIMSK3: 2   Can't be used as a PWM because of counter mode
PIN:  4        FIL_RUNOUT_PIN              Input  = 1    TIMER0B    WGM: 3    TIMSK0: 5   Can't be used as a PWM because it's being used as an interrupt
PIN:  5        SERVO2_PIN                  Output = 0    TIMER3A    WGM: 0    TIMSK3: 2   Can't be used as a PWM because of counter mode
PIN:  6        SERVO1_PIN                  Output = 0    TIMER4A    WGM: 1    TIMSK4: 0   can be used as PWM
PIN:  7        <unused>                    Input  = 0    TIMER4B    WGM: 1    TIMSK4: 0   can be used as PWM
PIN:  8        HEATER_BED_PIN              protected     TIMER4C    WGM: 1    TIMSK4: 0   can be used as PWM
PIN:  9        FAN_PIN                     protected     TIMER2B    WGM: 1    TIMSK2: 0   can be used as PWM
PIN: 10        HEATER_0_PIN                protected     TIMER2A    WGM: 1    TIMSK2: 0   can be used as PWM
PIN: 11        SERVO0_PIN                  Output = 0    TIMER1A    WGM: 4    TIMSK1: 2   Can't be used as a PWM because of counter mode
PIN: 12        PS_ON_PIN                   protected     TIMER1B    WGM: 4    TIMSK1: 2   Can't be used as a PWM because of counter mode
PIN: 13        LED_PIN                     Input  = 0    TIMER0A    WGM: 3    TIMSK0: 5   Probably can't be used as a PWM because counter/timer is being used as an interrupt
PIN: 14        <unused>                    Input  = 1
PIN: 15        Y_MAX_PIN                   protected
PIN: 16        LCD_PINS_RS                 Output = 1
PIN: 17        LCD_PINS_ENABLE             Output = 0
PIN: 18        Z_MIN_PIN                   protected
PIN: 19        Z_MAX_PIN                   protected
PIN: 20        SDA                         Input  = 1
PIN: 21        SCL                         Input  = 1
PIN: 22        <unused>                    Input  = 1
PIN: 23        LCD_PINS_D4                 Output = 0
PIN: 24        E0_ENABLE_PIN               protected
PIN: 25        LCD_PINS_D5                 Output = 0
PIN: 26        E0_STEP_PIN                 protected
PIN: 27        LCD_PINS_D6                 Output = 0
PIN: 28        E0_DIR_PIN                  protected
PIN: 29        LCD_PINS_D7                 Output = 0
PIN: 30        <unused>                    Input  = 1
PIN: 31        BTN_EN1                     Input  = 1
PIN: 32        <unused>                    Input  = 1
PIN: 33        BTN_EN2                     Input  = 0
PIN: 34        <unused>                    Input  = 1
PIN: 35        BTN_ENC                     Input  = 1
PIN: 36        <unused>                    Input  = 1
PIN: 37        BEEPER_PIN                  Output = 0
PIN: 38        X_ENABLE_PIN                protected
PIN: 39        <unused>                    Input  = 1
PIN: 40        <unused>                    Input  = 1
PIN: 41        KILL_PIN                    Input  = 1
PIN: 42        <unused>                    Input  = 1
PIN: 43        <unused>                    Input  = 1
PIN: 44        <unused>                    Output = 0    TIMER5C    WGM: 1    TIMSK5: 0   can be used as PWM
PIN: 45        <unused>                    Input  = 0    TIMER5B    WGM: 1    TIMSK5: 0   can be used as PWM
PIN: 46        Z_STEP_PIN                  protected     TIMER5A    WGM: 1    TIMSK5: 0   can be used as PWM
PIN: 47        <unused>                    Input  = 1
PIN: 48        Z_DIR_PIN                   protected
PIN: 49        SD_DETECT_PIN               Input  = 0
PIN: 50        AVR_MISO_PIN                Input  = 1
PIN: 51        AVR_MOSI_PIN                Output = 1
PIN: 52        AVR_SCK_PIN                 Output = 0
PIN: 53        AVR_SS_PIN                  Output = 1
PIN: 54 (A 0)  X_STEP_PIN                  protected
PIN: 55 (A 1)  X_DIR_PIN                   protected
PIN: 56 (A 2)  Y_ENABLE_PIN                protected
PIN: 57 (A 3)  <unused>                    Input  = 1
PIN: 58 (A 4)  <unused>                    Input  = 0
PIN: 59 (A 5)  FILWIDTH_PIN                Analog in =  463
PIN: 60 (A 6)  Y_STEP_PIN                  protected
PIN: 61 (A 7)  Y_DIR_PIN                   protected
PIN: 62 (A 8)  Z_ENABLE_PIN                protected
PIN: 63 (A 9)  <unused>                    Input  = 1
PIN: 64 (A10)  <unused>                    Input  = 1
PIN: 65 (A11)  <unused>                    Input  = 1
PIN: 66 (A12)  MAX6675_SS                  Input  = 0
PIN: 67 (A13)  TEMP_0_PIN                  protected
PIN: 68 (A14)  TEMP_BED_PIN                protected
PIN: 69 (A15)  TEMP_1_PIN                  Analog in = 1023

M43 I1 W1

Not sure what this was supposed to do, but it caused a loud screeching sound. I used a piece of metal to try to ground the S pin to the G pin, but it didn't do anything. The output was:

>>> M43 I1 W1
SENDING:M43 I1 W1
45        <unused>
66 (A12)  MAX6675_SS                   = 1 (838)
11        SERVO0_PIN                   = 1

[Bob-the-Kuhn]

Shoot - I forgot you were running RC8. Some files need to be updated & M43 S1 just isn't available.

Please copy these files into your directory. and then re-run M43 I1. pinsDebug.zip

[mbabauer]

I am getting a lot of compiler errors:

Arduino: 1.8.2 (Mac OS X), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

In file included from sketch/Marlin_main.cpp:4861:0:
sketch/pinsDebug.h: In function 'bool pwm_status(uint8_t)':
pinsDebug.h:172: error: 'SERIAL_PROTOCOL_SP' was not declared in this scope
   SERIAL_PROTOCOL_SP(2);
                       ^
sketch/pinsDebug.h: In function 'void timer_prefix(uint8_t, char, uint8_t)':
pinsDebug.h:275: error: 'SERIAL_PROTOCOL_SP' was not declared in this scope
   SERIAL_PROTOCOL_SP(3);
                       ^
sketch/pinsDebug.h: In function 'void pwm_details(uint8_t)':
pinsDebug.h:363: error: 'SERIAL_PROTOCOL_SP' was not declared in this scope
         SERIAL_PROTOCOL_SP(18);
                              ^
sketch/pinsDebug.h: In function 'void report_pin_state_extended(int8_t, bool, bool)':
pinsDebug.h:419: error: 'SERIAL_ECHO_SP' was not declared in this scope
         else SERIAL_ECHO_SP(8);   // add padding if not an analog pin
                              ^
pinsDebug.h:423: error: 'SERIAL_ECHO_SP' was not declared in this scope
         SERIAL_ECHO_SP(26);  // add padding if not the first instance found
                          ^
In file included from sketch/Marlin_main.cpp:4861:0:
pinsDebug.h:468: error: 'SERIAL_ECHO_SP' was not declared in this scope
       SERIAL_ECHO_SP(8);   // add padding if not an analog pin
                       ^
pinsDebug.h:471: error: 'SERIAL_PROTOCOL_SP' was not declared in this scope
       SERIAL_PROTOCOL_SP(12);
                            ^
pinsDebug.h:480: error: 'SERIAL_ECHO_SP' was not declared in this scope
         SERIAL_ECHO_SP(9);   // add padding if not an analog pin
                         ^
exit status 1
'SERIAL_PROTOCOL_SP' was not declared in this scope

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

I see SERIAL_PROTOCOL_SP is being referenced in pinsDebug.h, but I don't see it being defined anywhere else. I think I am missing a file.

As a side note, should I consider updating to the latest Marlin FW? Would that maybe help debug the problem better?

[Bob-the-Kuhn]

You're correct - the files I sent came from the newer software.

Moving to bugfix-1.1.x would be great!

You'll need to transfer your machine specific items to the new config files. The best way I've found to do this is to use an editor that will do a side by side difference display. I like using the Compare plugin within Notepad++.

There's also a new tool that's supposed to automate the process of getting new software and transferring the configuration files over. It's called marlin-conf and marlin-confg , depending on which page you're on. It uses the NPM system./service. I think the starting point is either https://github.com/akaJes/marlin-config#readme or https://www.npmjs.com/package/marlin-conf

[Bob-the-Kuhn]

I just tried marlin-conf. If you're running Windows then start on this page.

It doesn't offer bugfix-1.1.x but it does offer 1.1.3. I'd rather you use bugfix-1.1.x as it has the latest M43 debug tools.

It does take some getting used to. Seems to do what it says it'll do.

[mbabauer]

Alright, I am trying my hand at marlin-conf. Installation was pretty easy (I am a developer, mostly web, so pretty familiar w/ NPM and such). I am trying to go through my Configuration.h line-by-line and match that to what is in the tabs of Marlin configurator, but I am not finding the section in mine marked "Delta". Where do I set up those values? I also see a G-code setting for DELTA_AUTO_CALIBRATION (G33), but I don't see where to turn that on nor do I even need it.

[Bob-the-Kuhn]

Looks like the latest release of marlin-conf doesn't support deltas.

The main discussion on this tool is in issue #6722. There's no mention of delta in there.

Looks like you're stuck with doing a manual update.

[Roxy-3D]

That probably can be cured pretty easily. But Delta's keep getting treated like the ugly step child. (for example: UBL didn't run on Delta's until @oldmcg stepped up and did the conversion...)

[mister-walter]

Recently I spent a few days banging my head against the wall with the same issue - BLTouch ramming the bed when homing Z.

It turned out that I had connected the BLTouch's 2-wire connector to the endstop connector on my controller board with the wrong orientation! Unlike mechanical switches, the BLTouch's endstop connector must be connected in the correct orientation for it to work.

Definitely something to check before taking more drastic measures.

[brucehvn]

I'm trying to enable PINS_DEBUGGING in Configuration_adv.h and I'm getting this error when compiling:

In file included from /tmp/build02b7aff43f9d093fa8c6e697da41d699.tmp/sketch/Marlin_main.cpp:6376:0: pinsDebug.h:97: error: invalid conversion from 'int' to 'const char*' [-fpermissive] }; ^ pinsDebug.h:97: error: invalid conversion from 'int' to 'const char*' [-fpermissive] pinsDebug.h:97: error: invalid conversion from 'int' to 'const char*' [-fpermissive]

This is with the bugfix-1.1.x branch pulled just now and compiling using Arduino 1.6.9 on Linux. commenting the PINS_DEBUGGING define allows the compilation to proceed.

[brucehvn]

Ok, so I'm having the same problem as the OP wheras the BLTouch is not responding to the M commands and it does not self test when the machine fires up, but the blue led is on all the time. I'm not using any special pins, just connecting it to the servo 1 pins. I've checked and double checked the plug is oriented properly and on the right servo pinset. I've checked continuity on the extension cable and it's fine. I did have the black/white wires reversed, but after reading about that, I've corrected that. M119 is showing "open" all the time.

I was running 1.1.3, but just switched to the bugfix-1.1.x branch in hopes it would magically fix this, but it's not. Attached are my configuration.h and configuration_adv.h files. I just enabled the #define BLTOUCH and no other servo stuff.

@Bob-the-Kuhn you mention in your standard BLTouch test steps for #8:

8. The probe should remain stowed and the blue LED should be OFF. If it's ON then the unit needs to be adjusted.

What do you mean by "needs to be adjusted"? configs.zip

[brucehvn]

Ok, it looks like my problem was not having a jumper between 5V and VCC on the header just next to the reset button. When I added that jumper, the BLTouch started self testing and responding to the M280 commands. I guess I thought that since the blue LED was on before, it was getting servo power, but I guess not.

[mbabauer]

@mister-walter Which way did you end up connecting the white and black wires? I have tried all combinations, so there is definately something not right in either the software or the board, but it would help to know which way they needed to be oriented. Right now I have the black on S (signal) and white on G (ground). There is also a V (voltage), but when I connect to that the board doesn't boot at all.

@brucehvn My servo is working now. It ended up being wired wrong in my case. I had two of the wires swapped. Now I can issue the M280 commands, but G29 still causes the head to crash and drag into the bed. I don't think the Z-min is working correctly.

@Bob-the-Kuhn Thanks again for all your help. I tried fiddling with marlin-conf over the weekend but could not figure out how to get the Delta settings working. In the end I posted an issue there. Maybe at some point I'll have time and can maybe just alter the code myself and do a PR. In the meantime, I have manually pulled down the bugfix-1.1.x branch and I am slowly going through all the configs to copy over my current firmware settings over.

[mister-walter]

@mbabauer You definitely don't want to connect to the voltage pin, that shouldn't mess up your BLTouch but it will certainly cause behavior you don't want. That pin is for providing power to endstops that need it (like opto-interrupter endstops). The BLTouch gets its power from the servo connection.

I have black on ground and white on signal, flipping it caused it to always appear to be open.

[Bob-the-Kuhn]

Yes, black goes to ground & white goes to signal.

If you tie black to +V you're shorting power to ground which will most likely keep your controller from powering up.

[Bob-the-Kuhn]

I was able to take your configuration files & verify that your properly setup for BLTouch. Servo signal goes to the Servo0_pin function which is tied to logical pin 11. Signal pin goes to Z_MIN_PIN which is tied to logical pin 18.

I wasn't able to reproduce the PINS_DEBUGGING compile problem. I downloaded bugfix-1.1.x and downloaded Arduino 1.6.9.

I did run into a compile problem with ultralcd.cpp. Lines 3217-3219 need to be deleted.

  #if HAS_BED_PROBE && DISABLED(BABYSTEP_ZPROBE_OFFSET)
    static void lcd_refresh_zprobe_zoffset() { refresh_zprobe_zoffset(); }
  #endif

[brucehvn]

@Bob-the-Kuhn I just downloaded arduino 1.8.3 and I do not get the PINS_DEBUGGING compile error now. I didn't get the error you are hitting with either arduino version. Were you using my configuration files to compile or just the stock bugfix-1.1.x?

[Bob-the-Kuhn]

Those lines in ultralcd.cpp are like a bad penny - they keep popping up. I hope they stay dead this time.

I was using the config files you posted earlier in this thread.

[Roxy-3D]

Those lines in ultralcd.cpp are like a bad penny - they keep popping up.

ultralcd.cpp has a lot of issues. Tannoo and I are trying to clean it up. But it is confusing as $h|+. There are a bunch of symbols that don't even need to be in it:

https://github.com/Tannoo/Marlin/issues/5#issuecomment-309616264

[mbabauer]

OMG! It works! All I did was upload the bugfix-1.1.x branch after manually copying over the settings from my old config. Made no changes at all to them, just 1-for-1 translation the best I could. Here is the output when I ran the G29:

Bilinear Leveling Grid:
      0      1      2      3      4      5      6      7      8
 0 -0.112 -0.180 -0.154 -0.112 -0.180 -0.371 -0.454 -0.269 -0.306
 1 -0.057 -0.075 -0.134 -0.127 -0.223 -0.268 -0.346 -0.293 -0.907
 2 -0.085 +0.011 -0.050 -0.088 -0.196 -0.312 -0.233 -0.695 -1.335
 3 -0.006 +0.024 +0.012 -0.102 -0.263 -0.438 -0.539 -0.964 -1.040
 4 +0.112 +0.201 +0.095 -0.041 -0.197 -0.447 -0.650 -0.629 -0.511
 5 +0.203 +0.296 +0.312 +0.275 +0.038 -0.307 -0.550 -0.650 -0.484
 6 +0.764 +0.579 +0.548 +0.378 +0.125 -0.066 -0.375 -0.670 -0.690
 7 +0.995 +0.793 +0.773 +0.509 +0.210 +0.020 -0.179 -0.504 -0.838
 8 +1.240 +1.173 +0.892 +0.442 +0.099 -0.032 -0.077 -0.251 -0.681

Now I think I just need to go back over @Bob-the-Kuhn 's instructions above on how to get these settings into the eeprom and make small adjustments to the Z offset of the probe to hone it in. Then I should be off to the races!

@Bob-the-Kuhn and everyone else, thanks so much for all the fantastic help. You were all EXTREMELY helpful and I do really appreciate it!

[Bob-the-Kuhn]

I'm concerned that you're not getting good readings. The 0.4mm & 0.5mm changes between adjacent samples seem large.

Try running the M48 command. That'll give you some idea of the error in the BLTouch probe results. You'll need to enable Z_MIN_PROBE_REPEATABILITY_TEST in configuration.h to enable the M48 command.

[oldmcg]

I get more consistent results with my bltouch using Z_PROBE_SPEED_SLOW 500 and BLTOUCH_DELAY 400, and be sure bed heater and nozzle heater are both off for probing.

[mbabauer]

@Bob-the-Kuhn Repeatability test results:

Mean: -0.065010 Min: -0.104 Max: -0.004 Range: 0.100
Standard Deviation: 0.027640

And the second time I ran it:

Mean: -0.028761 Min: -0.104 Max: 0.021 Range: 0.125
Standard Deviation: 0.041078

I also slowed down the probing as suggested by @oldmcg :

#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 8)  // Calculates to 4000 / 8 = 500
...
#define BLTOUCH_DELAY 400

And I ran G29 again:

Bilinear Leveling Grid:
      0      1      2      3      4      5      6      7      8
 0 +0.045 +0.012 -0.242 -0.312 -0.330 -0.459 -0.395 -0.270 -0.585
 1 -0.157 -0.025 -0.022 -0.077 -0.148 -0.268 -0.371 -0.520 -1.279
 2 -0.098 -0.089 -0.137 -0.213 -0.258 -0.387 -0.421 -0.916 -1.568
 3 +0.007 +0.049 +0.062 -0.014 -0.188 -0.475 -0.614 -1.114 -1.184
 4 +0.200 +0.263 +0.245 +0.109 -0.147 -0.472 -0.725 -0.692 -0.578
 5 +0.291 +0.458 +0.412 +0.350 +0.100 -0.244 -0.600 -0.733 -0.536
 6 +1.002 +0.892 +0.723 +0.528 +0.150 -0.103 -0.392 -0.728 -0.767
 7 +1.566 +1.281 +0.948 +0.722 +0.198 -0.113 -0.304 -0.586 -0.907
 8 +2.009 +1.601 +1.146 +0.526 +0.082 -0.206 -0.362 -0.489 -0.814

[oldmcg]

I think you must have some delta geometry a bit off. Make sure the bed is mounted roughly square to the towers -- I use a square but a book will work too. Then with DELTA_AUTO_CALIBRATION defined in configuration.h, try running G33 P7 V2 before G29. If the results look "better" then you can save the G33 calibration results with M502.

I can't speak for BILINEAR leveling but UBL bed leveling is working well for me on delta with bugfix_1.1.x. I use UBL_MESH_INSET of zero and 11x11 grid. The G29 sequence is then G29 P1 to BLtouch-probe the points that can be reached by the probe, then G29 P2 to do the manual nozzle/paper leveling for grid points that can't be reached by the X/Y offset probe (use knob by LCD to run nozzle up and down and push click when it's dragging the paper), and then for delta specifically G29 P3.15 to fill the remaining points outside the circular bed to complete the grid. Run G29 T at any point in the sequence to see the grid, G29 S0 to save the mesh, G29 A to activate leveling with that grid.

[Roxy-3D]

And... my guess is oldmcg has the geometry of his Delta tuned pretty well so he didn't mention this... But after you get your mesh setup, there is one more tool that is there to help you. You can do a G26 to print a Mesh Validation Pattern on the bed. With that, you can see mesh points that are not quite perfect. You can move the nozzle over those areas and do a G29 P4 R to edit an area's mesh points up or down. If you repeat the G26 and G29 P4 two or three times... You should get perfect adhesion across 100% of your bed every time.

[Bob-the-Kuhn]

There's definitely something wrong with the probing. The differences between points in the first mesh post are off by as much as 0.7 mm compared to the differences in the second mesh post.

You should be getting better repeatability on the M48 command, What's the mechanical resolution of your Z axis?

Please post your current configuration.

[Roxy-3D]

There's definitely something wrong with the probing. The differences between points in the first mesh post are off by as much as 0.7 mm compared to the differences in the second mesh post.

It would be good if the M48 was returning better numbers. But Delta's are notorious for having waves in the nozzle height across the bed. And even if those .7mm differences are the result of bad probe values... If he can print a G26 pattern, it will be clear those points are wrong and need to be adjusted.

I guess what I'm really saying is "The G26 pattern is going to tell you the truth about what is happening at various places on the bed."

[Bob-the-Kuhn]

Is G26 just for UBL? There was some discussion about making it available to other systems.

Is there a way to edit the bilinear mesh?

[Roxy-3D]

G26 currently works just for UBL. It is not going to be difficult to change, but G26 makes use of the has_control_of_lcd_panel = true; and I think the ultralcd.cpp file only turns on the required support if UBL has been activated. We might want to enable that same control for BiLinear so G26 can be used there also.

Is there a way to edit the bilinear mesh?

Not with UBL's interactive editor. But the M421 command edits all of the various mesh bed leveling schemes mesh points. So... If we get G26 to work with BiLinear Mesh Leveling... M421 can be used to update the mesh. And... The same methodology should work there too. (Print a G26 pattern... Edit the bad areas of the mesh... repeat until you have perfection...)

Is G26 just for UBL? There was some discussion about making it available to other systems.

This really should be done. BiLinear Mesh Leveling would benefit from this happening. And it really should be very straight forward to do. But I'm not going to get to it for a while because I have too many other distractions. If you get bored and are looking for something to do... Please feel free....