Marlin: BLTouch ignoring M-commands
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!
mbabauer
All 63 comments
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
Roxy-3D
on 10 Jun 2017
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:
- Connect BLTouch, power up controller and upload the firmware
- Blue LED will be ON if a servo signal is present. Blue LED is faint.
- 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".
- M280 P0 S10 ; should deploy the probe and the orange LED will be OFF.
- M119 ; should return OPEN
- M280 P0 S90 ; should stow the probe and the orange LED will be ON
- M280 P0 S60 ; puts it into the M119 test mode.
- The probe should remain stowed and the blue LED should be OFF. If it's ON then the unit needs to be adjusted.
- M119 ; should return TRIGGERED
- M280 P0 S160 ; returns it to normal operation
- M119 ; should return OPEN.
Bob-the-Kuhn
on 11 Jun 2017
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.
mbabauer
on 11 Jun 2017
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.
Bob-the-Kuhn
on 11 Jun 2017
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.
mbabauer
on 11 Jun 2017
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.
Bob-the-Kuhn
on 11 Jun 2017
Fair enough about the M119, but when I run the following:
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?
mbabauer
on 12 Jun 2017
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.
Roxy-3D
on 12 Jun 2017
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:
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.
mbabauer
on 12 Jun 2017
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.
Bob-the-Kuhn
on 13 Jun 2017
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 haveZ_PROBE_OFFSET_FROM_EXTRUDER set to-.2based 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?
mbabauer
on 13 Jun 2017
.2 mm isn't a lot of room. I have my BL-Touch at -1.027mm
Roxy-3D
on 13 Jun 2017
.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
on 13 Jun 2017
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:
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.
mbabauer
on 13 Jun 2017
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?
Bob-the-Kuhn
on 13 Jun 2017
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 theM502, M500, M501sequence? 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.
mbabauer
on 13 Jun 2017
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:
- Connect BLTouch, power up controller and upload the firmware
- Blue LED will be ON if a servo signal is present. Blue LED is faint.
- 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".
- M280 P0 S10 ; should deploy the probe and the orange LED will be OFF.
- M119 ; should return OPEN
- M280 P0 S90 ; should stow the probe and the orange LED will be ON
- M280 P0 S60 ; puts it into the M119 test mode.
- The probe should remain stowed and the blue LED should be OFF. If it's ON then the unit needs to be adjusted.
- M119 ; should return TRIGGERED
- M280 P0 S160 ; returns it to normal operation
- M119 ; should return OPEN.
Bob-the-Kuhn
on 13 Jun 2017
Did you do these changes?
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PINdefine 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.
mbabauer
on 13 Jun 2017
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_PINat the very end. - In configuration.h change
#define Z_MIN_PROBE_PIN Z_MIN_PINto#define Z_MIN_PROBE_PIN 18
Bob-the-Kuhn
on 14 Jun 2017
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?
mbabauer
on 14 Jun 2017
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
*/
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
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
Bob-the-Kuhn
on 15 Jun 2017
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?
mbabauer
on 15 Jun 2017
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
on 15 Jun 2017
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.
Bob-the-Kuhn
on 15 Jun 2017
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.
mbabauer
on 16 Jun 2017
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.
Bob-the-Kuhn
on 16 Jun 2017
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
on 16 Jun 2017
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.
mister-walter
on 16 Jun 2017
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
on 20 Jun 2017
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
on 20 Jun 2017
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.
brucehvn
on 20 Jun 2017
@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.
mbabauer
on 20 Jun 2017
@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.
mister-walter
on 20 Jun 2017
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
on 20 Jun 2017
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
@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?
brucehvn
on 21 Jun 2017
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.
Bob-the-Kuhn
on 21 Jun 2017
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
Roxy-3D
on 21 Jun 2017
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!
mbabauer
on 21 Jun 2017
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.
Bob-the-Kuhn
on 21 Jun 2017
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.
oldmcg
on 21 Jun 2017
@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
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.
oldmcg
on 22 Jun 2017
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.
Roxy-3D
on 22 Jun 2017
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.
Bob-the-Kuhn
on 22 Jun 2017
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."
Roxy-3D
on 22 Jun 2017
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?
Bob-the-Kuhn
on 22 Jun 2017
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....
Roxy-3D
on 22 Jun 2017
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.
oldmcg
on 22 Jun 2017
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.)
Roxy-3D
on 22 Jun 2017
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.
Bob-the-Kuhn
on 22 Jun 2017
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!
Roxy-3D
on 22 Jun 2017
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.
Bob-the-Kuhn
on 22 Jun 2017
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.
oldmcg
on 22 Jun 2017
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.
Roxy-3D
on 22 Jun 2017
@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.
mbabauer
on 23 Jun 2017
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.
oldmcg
on 23 Jun 2017
@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
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 P1m500m501to visually see the results were thereG28and paper test to gauge thingsm851 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.
mbabauer
on 26 Jun 2017
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.
LVD-AC
on 26 Jun 2017
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.
oldmcg
on 26 Jun 2017
Related issues
Glod76
·
3Comments
modem7
·
3Comments
Ciev
·
3Comments
ceturan
·
4Comments
manianac
·
4Comments
Most helpful comment
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: