Marlin: BILINEAR issues double-touch on some probe points, normal on others, erratic prob direction

[fiveangle]

Bug Report

• Description: During G29 BILINEAR issues double-touch on some probe points, normal on others
• Expected behaviour: Normal single probes
• Actual behaviour: Issues double-touch probes on some points:
  https://youtu.be/bpuzHJtRfeo
• Steps to reproduce:
  
  
  
  • Compile bugfix2.0.x with BILINEAR with 5 grid points and do not enable DOUBLETOUCH
  
  
  • G28;G29
  
  
  • Observe double-touch on some points
  
  

https://github.com/fiveangle/Marlin/blob/bf20-pb_simple_metal/Marlin/Configuration.h
https://github.com/fiveangle/Marlin/blob/bf20-pb_simple_metal/Marlin/Configuration_adv.h

```Send: G28
Recv: echo:G28
Recv: echo:busy: processing
Recv: X:51.00 Y:76.00 Z:3.00 E:0.00 Count X:1020 Y:1520 Z:1521
Recv: ok P15 B3
[...]
Recv: echo:M105
[...]
Send: G29
Recv: echo:G29
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: Bilinear Leveling Grid:
Recv: 0 1 2 3 4
Recv: 0 +0.138 +0.099 +0.067 +0.067 +0.075
Recv: 1 +0.028 -0.028 -0.071 -0.047 -0.039
Recv: 2 -0.006 -0.024 -0.049 -0.053 -0.069
Recv: 3 +0.059 +0.032 -0.004 -0.030 -0.075
Recv: 4 +0.036 -0.004 -0.020 -0.041 -0.061
Recv:
Recv: X:124.00 Y:152.00 Z:3.05 E:0.00 Count X:2480 Y:3040 Z:1521
Recv: ok P15 B3

-=dave

Update: recompiled with LCD disabled and leveling debug enabled and behavior is same.

As visually represented looking at printer top-down (`X` indicates where double-touch occurs, as also shown in video linked to above):

00000
XX000
00000
X0000
XXXXX

Debug leveling output of G28; G29:

[putty.log](https://github.com/MarlinFirmware/Marlin/files/1367420/putty.log)

I have never tested BILINEAR on the 2.0 branch until now (due to various compile errors which I've finally worked through all of) so unsure of if this is a recent regression or been there since the breakup. 

UPDATE 10/14:
Tested with 1.1.6 and still present so this is a regression that's been there for a while (I'd been working on bringing up Re-ARM on this printer but reverted recently (Re-ARM has just some bare steppers on it now).

  - Compile same options on 1.1.6 or 1.1.5 with BILINEAR but 6 grid points and do not enable DOUBLETOUCH
  - Observe double-touch on bed area as seen with bugfix2.0.x, but observe the probe pattern is reversed, starting at far end of Y axis (due to the even number of grid lines across bed) so it seems this is related to the area of the bed and not specifically each probe point being tainted along the way.

  - Compile with 1.1.4 and double-touch issue is gone.

Probing code changes start around lines 2192/2229 (114/115) in Marlin_main.cpp in these diffs: 
https://github.com/fiveangle/Marlin/compare/114...fiveangle:115

_**[INSERT TIMELAPSE-OF-CLOCK-SPINNING-FORWARD-SEVERAL-HOURS HERE]**_

I think this code is responsible:

![screen shot 2017-10-14 at 7 32 38 pm](https://user-images.githubusercontent.com/2219447/31581093-9d866692-b116-11e7-9551-cb9c84a15a14.jpg)

I suspect the probe deploy height added here, combined with my "0" deploy clearance (inductive sensor):

define Z_CLEARANCE_DEPLOY_PROBE 0 // Z Clearance for Deploy/Stow

define Z_CLEARANCE_BETWEEN_PROBES 3 // Z Clearance between probe points

```

Is causing double-touch on any areas of the bed that are lower than the G28 homeing Z point.

I haven't modified any FW or bisected 1.1.5 and 1.1.6 to test. If so, I'm not sure how best to address it though other than perhaps a hack to add a test that if Z_CLEARANCE_DEPLOY_PROBE is < Z_CLEARANCE_BETWEEN_PROBES, omit the newly added deploy test entirely.

[thinkyhead]

Has this problem remained in the latest bugfix-1.1.x branch? If so, please re-open this issue.

[fiveangle]

No change as of https://github.com/MarlinFirmware/Marlin/commit/05f8e98c4ab1f96ddb0af0dcc51af838ec9b0c30

Can't re-open as I did not close it.

[Roxy-3D]

It's reopened for you...

[fiveangle]

Thx. Tried bisecting to narrow it down, but too many fundemental compile issues on Printrboard between 1.1.4 - 1.1.5. Have a feeling this will take a while 😝

[Roxy-3D]

Does anybody want to hear my feelings towards the Printrboard people? If so... Let's start a new thread so we don't screw this one up.

[fiveangle]

I thought you liked me @Roxy-3D ? 💋 😉

Unfortunately, I see little evidence to support this being Printrboard-specific. I suspect it's triggered via a specific configuration (it's just that I have so much custom config, even that is difficult to narrow down).

[Roxy-3D]

Does anybody want to hear my feelings towards the Printrboard people?

I guess I was sloppy with my English. I should have worded that more like "Does anybody want to hear my feelings towards the Printrbot company and its lack of support for the Printrboard?"

[compatibilizer]

It is not related to Printrboard. Also it is not a bug either. Probably expected behaviour. Let me explain;

@fiveangle did you set your "#define Z_CLEARANCE_DEPLOY_PROBE" to 0?

Set it to 1 and it will return to normal.

I did try to set it to 0 because I have a fixed probe, but later realized that it says only integer values >= 1 are applicable. This is probably required due to some equation about Z clearance calculation. Can this behaviour be improved? Probably yes, but I don't think this counts as a bug since there is a word of caution already in place.

[fiveangle]

I think the only person who thinks this might be related to Printrboard is Roxy, and that's more a running joke tongue-in-cheek than the truth :)

From my first post I state my suspicion of the Z_CLEARANCE_DEPLOY_PROBE = 0being the issue. But there is no reason it should not be supported and for behavior to change. I do see the detail on in the Config.h, but from SanityCheck.h:

https://github.com/MarlinFirmware/Marlin/blob/bugfix-1.1.x/Marlin/SanityCheck.h#L693-L701 :

  #ifndef Z_CLEARANCE_DEPLOY_PROBE
    #error "You must define Z_CLEARANCE_DEPLOY_PROBE in your configuration."
  #elif !defined(Z_CLEARANCE_BETWEEN_PROBES)
    #error "You must define Z_CLEARANCE_BETWEEN_PROBES in your configuration."
  #elif Z_CLEARANCE_DEPLOY_PROBE < 0
    #error "Probes need Z_CLEARANCE_DEPLOY_PROBE >= 0."
  #elif Z_CLEARANCE_BETWEEN_PROBES < 0
    #error "Probes need Z_CLEARANCE_BETWEEN_PROBES >= 0."
  #endif

"Probes need Z_CLEARANCE_DEPLOY_PROBE >= 0."

I will confirm again that this behavior was not present in 1.1.4 and is present in 1.1.5 (since managing checkout, compile, shuffling Marlin.hex / firmware.hex to/from octoprint, dfu-util, etc there is always the possibility for human error).

But it's definitely not WAD. The issue must be fixed, either by forcing Z_CLEARANCE_DEPLOY_PROBE to be within the required range via SantityCheck.h (the hack solution) or determining where the indeterminant behavior is being injected when Z_CLEARANCE_DEPLOY_PROBE becomes 0.

Most of the commits leading up to 1.1.5 fail to compile for Printrboard due to unrelated issues so I can't test right now, and I'm not looking too forward to figuring out which ones require backporting just so I can get it to compile to then do a bisect search through the 114-115 changes to find the culprit.

But an easy immediate solution would be to submit the "hack" solution for now, and keep this open for the long-term "todo" fix.

-=dave

[fiveangle]

No longer interested in figuring out where it broke. Closing...