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!

[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[bot]]

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.