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...)

[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:

Tannoo#5 (comment)

[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....

[oldmcg]

Couple more things. Are you using interrupt endstops? #define ENDSTOP_INTERRUPTS_FEATURE.
My bltouch is "older" (no blue LED), but I'm getting M48 repeatability of 0.05 when machine is "cold" and sometimes as good as 0.01 when belts are "warmed up". Check belt tension too, make sure all three belts feel about the same and have tensioner springs. I use two springs on each belt.

UBL G26 is very handy to check if grid is tuned and leveling is working correctly. I haven't tweaked the G26 pattern for delta beds yet, but it still prints a workable pattern.

[Roxy-3D]

UBL G26 is very handy to check if grid is tuned and leveling is working correctly. I haven't tweaked the G26 pattern for delta beds yet, but it still prints a workable pattern.

Bob, if you are looking for something fun to do... For Delta's we are thinking we need to print a circle just within the Delta Printable Radius. (And then we have follow up ideas to help identify (and edit) the mesh points just outside the Delta Printable Radius.)

[Bob-the-Kuhn]

My next fun project is to replace my AzteegX3pro with a Re-Arm & the Geeetech RAMPS-FD. I plugged in an obviously mislabeled stepper driver & my controller went up in smoke.

It's a wonder I hadn't killed it earlier with all the changes I've done trying to emulate a user's system.

The RAMPS-FD is coming from China so it'll be a while before my printer is fully functional again.

I need to clean up some items around the house so it'll be tomorrow before I can look at G26.

Does UBL compensate the G2 & G3 arc commands? Just wondering if there is an obvious way to generate the curves. Hmmm - it already generates half circles so I'll look that method over first.

[Roxy-3D]

My next fun project is to replace my AzteegX3pro with a Re-Arm & the Geeetech RAMPS-FD. I plugged in an obviously mislabeled stepper driver & my controller went up in smoke.

Please correct me if I'm wrong. But I thought the Re-ARM board worked with a normal, everyday, 5 Volt RAMPS v1.4 board. If that is not true... I need to know that!!!

Does UBL compensate the G2 & G3 arc commands? Just wondering if there is an obvious way to generate the curves. Hmmm - it already generates half circles so I'll look that method over first.

It should. Just because those ultimately go down into buffer_line_kinematic(). But G26 doesn't really draw circles. (Maybe it should!!!) What it does is 8 or 10 line segments that form a circular pattern. (Look close at the 'circles' and you will see some corners on them.) I was thinking it could do the same thing except with 100 line segments to go around the edge of the circular DELTA_PRINTABLE_RADIUS. But it may be more efficient to just call the same code that G2 implements.

If you do end up looking at G26... It might not hurt to see if those 'circles' can be done with G2 because that would collapse 50 lines of complicated code out of G26. Doing a 'circle' is not a lot of code. It is the complicated code to know where to start and end a partial circle along the edge (or especially the corner) of the mesh. It maybe G2 would cut all that complicated logic out of the code. That would be good!

[Bob-the-Kuhn]

Yes, Re-ARM works with the RAMPS 1.4 board.

The RAMPS-FD is supposed to be 100% RAMPS 1.4 compatible with a sixth stepper driver slot and beefier drivers. I see your point on the 3.3V signal translations it does. I'll double check the pinout before I use it. I'll start with a RAMPS 1.4 for development.

[oldmcg]

UBL for delta does G2/G3 arc, but I think UBL for cartesian probably does not do G2/3 arc yet -- need to #define PLANNER_LEVELING to make that happen, and it is disabled by default for UBL cartesian. I don't have a cartesian machine to test a change -- just guessing at behavior based on code.

The G2/3 arc code acts kind of like delta segmentation -- it just used fixed length 1mm lines to draw any arc, but does some fancy sin/cos estimations to minimize per-segment overhead.

[Roxy-3D]

This sounds like something fun to mess with.... But I won't get to it for a while. I've got too many other fun things to mess with. The 20x4 LCD Panel needs some fun code to do the 'Postage Stamp UBL Map' for Tannoo's code. And right now, I'm distracted trying to figure out everything needed to bring up the 32-Bit Re-ARM board. I want to see if I can get UBL to run on the 32-Bit version of Marlin as soon as I can.

[mbabauer]

@oldmcg I checked it with a carpenter's square and it seems pretty level. I ran the G33 as instructed, the results were:

.      c:+0.07     x:0.00   y:0.00   z:0.00
.                 yz:-0.26  zx:0.00  xy:0.00
Calibration OK                                    std dev:-2147483.750
.Height:335.70    Ex:+0.00  Ey:+0.00  Ez:+0.00    Radius:98.40
.Tower angle :    Tx:+0.00  Ty:+0.00  Tz:+0.00
Save with M500 and/or copy to Configuration.h

I would like to check the other parameters I copied over from the old config, like the delta arm length, but my caliper doesn't open wide enough for me to verify that.

Could the cabling tension have anything to do with the inconsistencies? I have all the wires from the print head wrapped with cable wrap, but it's sort of free-dangling around. Maybe it's putting enough tension that the printer thinks the head move to X,Y, but its just a tad off??? I've been thinking of coming up with a way to hang it over the top using something like rubber bands or something.

The belts all feel pretty tight. I have one belt tensioner on each right now. I can pick up some more but it may be a few days as I would have to order them from Amazon. I was also debating one picking up a set of aluminum sled carriages to replace the plastic ones that came with the printer. It just seems like the metal ones I am looking at has an much easier means of attaching the belt to the sled so that it's tight from the start.

I also did not have ENDSTOP_INTERRUPTS_FEATURE turned on, but I will now and retest everything when I get a chance.

@Bob-the-Kuhn
Here is my current Configurations.h, as requested.
Configuration.txt

I didn't make any changes to the Configuration_adv.h from what is in the bugfix-1.1.x branch.

[oldmcg]

I haven't seen G33 come back with all zeros for endstops and tower angles. Did you run with P1 instead of P7? How many passes did G33 do before giving you that result? It usually says "rolling back" after the last pass before giving the final numbers. @LVD-AC, something seems fishy about reported stddev.

My "bundle" of wires going to head is zip-tied to one of the rods. The steppers are strong enough that the cable bundle doesn't cause any movement problems.

I'm very curious if ENDSTOP_INTERRUPTS_FEATURE improves the M48 repeatability.

[mbabauer]

@oldmcg I re-ran it with ENDSTOP_INTERRUPTS_FEATURE enabled. Here is the full output:

>>> G33 P7 V2
SENDING:G33 P7 V2
G33 Auto Calibrate
echo:busy: processing
echo:busy: processing
Checking... AC
.Height:335.70    Ex:+0.00  Ey:+0.00  Ez:+0.00    Radius:98.40
.Tower angle :    Tx:+0.00  Ty:+0.00  Tz:+0.00
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
.      c:-0.10     x:0.00   y:0.00   z:0.00
.                 yz:-0.22  zx:0.00  xy:0.00
Calibration OK                                    std dev:-2147483.750
.Height:335.70    Ex:+0.00  Ey:+0.00  Ez:+0.00    Radius:98.40
.Tower angle :    Tx:+0.00  Ty:+0.00  Tz:+0.00
Save with M500 and/or copy to Configuration.h
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:endstops hit:  X:530.23 Y:530.23

And the full output from running the G29:

>>> G29
SENDING:G29
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
Bilinear Leveling Grid:
      0      1      2      3      4      5      6      7      8
 0 -0.060 -0.150 -0.317 -0.337 -0.417 -0.484 -0.399 -0.155 -0.310
 1 -0.090 -0.088 -0.084 -0.140 -0.260 -0.355 -0.296 -0.353 -0.915
 2 -0.098 -0.051 -0.062 -0.138 -0.271 -0.437 -0.383 -0.713 -1.132
 3 -0.081 -0.013 -0.038 -0.114 -0.250 -0.538 -0.539 -0.832 -0.814
 4 -0.050 +0.038 +0.145 +0.109 -0.122 -0.409 -0.575 -0.525 -0.365
 5 +0.166 +0.133 +0.199 +0.263 +0.038 -0.244 -0.463 -0.504 -0.324
 6 +0.627 +0.504 +0.573 +0.565 +0.263 -0.091 -0.387 -0.561 -0.483
 7 +1.312 +1.518 +0.998 +0.509 +0.256 +0.109 -0.190 -0.546 -0.735
 8 +2.385 +1.832 +0.971 +0.408 +0.083 +0.005 -0.036 -0.299 -0.750

[mbabauer]

Ok, I have been tinkering with this all weekend. I figured I'd just go back to basics and try to get a consistent result for height calibration using G33 P1 and fine tuning the z-offset of the probe.

I started by clearing eeprom and manually calibrating the height using a piece of paper. I was able to get the height of 335.6, and was able to auto-home and retest the height several times and each time it reproduced satisfactory results.

Now that I had the actual tested bed height, I entered that for DELTA_HEIGHT, re-cleared eeprom and uploaded the change. m500 shows the new height. Retested by doing a G28 and then the paper test...still good.

I then tried to calibrate using G33 P1. My steps were

• G33 P1
• m500
• m501 to visually see the results were there
• G28 and paper test to gauge things
• m851 z### to shift the z-offset of the probe to tune thing in
• repeat

I kept doing this over and over, but I just never could seem to get the numbers "dialed in". If I was, say, .19 too far below on the paper test, I would bump the z-offset of the prob .19 and rerun everything but it would either not change or would go in a direction I wasn't expecting at all.

So, backing up, I cleared eeprom and re-uploaded the factory settings, made sure things were as expected w/ m501, and did the same process, except this time I didn't try to use m851 but instead made the changes in the code and re-uploaded each time. I thought I finally had things right, but then I tried to do G33 p1 repeatedly, and each time I get a different result. Here was my last attempt:

>>> m501
SENDING:M501
echo:V38 stored settings retrieved (741 bytes; crc -19980)
echo:  G21    ; Units in mm
echo:  M149 C ; Units in Celsius
echo:Filament settings: Disabled
echo:  M200 D3.00
echo:  M200 D0
echo:Steps per unit:
echo:  M92 X80.00 Y80.00 Z80.00 E96.00
echo:Maximum feedrates (units/s):
echo:  M203 X200.00 Y200.00 Z200.00 E200.00
echo:Maximum Acceleration (units/s2):
echo:  M201 X3000 Y3000 Z3000 E3000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P3000.00 R3000.00 T3000.00
echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
echo:  M205 S0.00 T0.00 B20000 X20.00 Y20.00 Z20.00 E5.00
echo:Auto Bed Leveling:
echo:  M420 S0
echo:Endstop adjustment:
echo:  M666 X0.00 Y0.00 Z0.00
echo:Delta settings: L<diagonal_rod> R<radius> H<height> S<segments_per_s> B<calibration radius> XYZ<tower angle corrections>
echo:  M665 L218.00 R98.40 H335.61 S100.00 B78.21 X0.00 Y0.00 Z0.00
echo:Material heatup parameters:
echo:  M145 S0 H180 B70 F255
  M145 S1 H240 B100 F255
echo:PID settings:
echo:  M301 P22.20 I1.08 D114.00
echo:  M304 P10.00 I0.02 D305.40
echo:Z-Probe Offset (mm):
echo:  M851 Z-1.92
>>> g33 p1
SENDING:G33 P1
G33 Auto Calibrate
echo:busy: processing
echo:busy: processing
Checking... AC
.Height:335.61
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
Calibration OK
.Height:335.52
Save with M500 and/or copy to Configuration.h
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
>>> g33 p1
SENDING:G33 P1
G33 Auto Calibrate
echo:busy: processing
echo:busy: processing
Checking... AC
.Height:335.52
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
Calibration OK
.Height:335.51
Save with M500 and/or copy to Configuration.h
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing

It just doesn't seem repeatable at all. I have double-touch probing turned on, so it does a fast one followed by a slow for the read, and I have the slow speed set pretty low. I just feel something is off, as @oldmcg mentioned, but I don't know how to go about calibrating things, even manually.

[LVD-AC]

A lot has been written about the double-touch feature; it does not seem to improve accuracy. By probing the bed fast the motors could loose a step or two and those errors are accumulated to all consecutive probes until a new home command is issued.

You can test the repeatability of your probe with the M48 Xx.x Yy.y S command at different locations.

[oldmcg]

I am away and can't look at code but recently noticed that probe_Pt returns logical not raw, so probably need raw conversion on each probe_Pt result, otherwise prev z home offset might cause wrong subsequent. Double touch ignores first result, not very useful, thought about adding N probes per point and take avg.

…

Sent from my Windows 10 phone From: Luc Van Daele Sent: Monday, June 26, 2017 3:42 To: MarlinFirmware/Marlin Cc: oldmcg; Mention Subject: Re: [MarlinFirmware/Marlin] BLTouch ignoring M-commands (#7024) A lot has been written about the double-touch feature; it does not seem to improve accuracy. By probing the bed fast the motors could loose a step or two and those errors are accumulated to all consecutive probes until a new home command is issued. You can test the repeatability of your probe with the M48 Xx.x Yy.y S command at different locations. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.