[2.0.x] different bltouch init

[GMagician]

Change to prevent error on startup

[GMagician]

Now error is not raised on startup, but I'm not able let it show in other situation.
Maybe someone can test it and see if it works and signal error when bltouch is really faulty

Address #11111

[thinkyhead]

I'm not sure why the BLTouch needed to be extended and then retracted on startup, except to make sure that it knows to change its internal state to definitely be retracted. Perhaps if it's not extended first then it never knows to disable itself.

Are you simply unable to generate an error state for testing? Maybe if you pulled the pin down while the probe is idle that would be enough to have it throw an error on reboot…?

[GMagician]

I tryed to lower pin when near to bed to put it in error state.
In this state (led is blinking) reset and stow commands seems enough to turn off blinking.
The only thing I've not checked is "triggered" state. I'll do some more test

[GMagician]

@thinkyhead

I'm not sure why the BLTouch needed to be extended and then retracted on startup, except to make sure that it knows to change its internal state to definitely be retracted. Perhaps if it's not extended first then it never knows to disable itself.

On startup bltouch already does such sequence.

I have to say that mine is not original and maybe I have to expect some "different" behaviour

[GMagician]

@thinkyhead ok test done. When in error it report triggered (if it is stowed or deployed. I stowed it manually) when I command home (it calls reset and stow) status change to open in both up or down position

[thinkyhead]

The only "error" we were really testing for — the one that this is aiming to fix for the startup test — is that the BLTouch is reporting "triggered" as soon as it's deployed. One simple workaround would be to just ignore this factor in set_bltouch_deployed by adding a second parameter…

bool set_bltouch_deployed(const bool deploy, const bool do_test/*=true*/) {
  if (deploy && do_test && TEST_BLTOUCH()) { // If BL-Touch says it's triggered
    bltouch_command(BLTOUCH_RESET);    //  try to reset it.
    bltouch_command(BLTOUCH_DEPLOY);   // Also needs to deploy and stow to
    bltouch_command(BLTOUCH_STOW);     //  clear the triggered condition.
    safe_delay(1500);                  // Wait for internal self-test to complete.
                                       //  (Measured completion time was 0.65 seconds
                                       //   after reset, deploy, and stow sequence)
    if (TEST_BLTOUCH()) {              // If it still claims to be triggered...
      SERIAL_ERROR_START();
      SERIAL_ERRORLNPGM(MSG_STOP_BLTOUCH);
      stop();                          // punt!
      return true;
    }
  }

  bltouch_command(deploy ? BLTOUCH_DEPLOY : BLTOUCH_STOW);

  #if ENABLED(DEBUG_LEVELING_FEATURE)
    if (DEBUGGING(LEVELING)) {
      SERIAL_ECHOPAIR("set_bltouch_deployed(", deploy);
      SERIAL_ECHOPAIR(", ", int(do_test));
      SERIAL_CHAR(')');
      SERIAL_EOL();
    }
  #endif

  return false;
}

…and in the init function just pass false as the second parameter…

FORCE_INLINE void bltouch_init() {
  // Make sure any BLTouch error condition is cleared
  bltouch_command(BLTOUCH_RESET);
  set_bltouch_deployed(true, false);
  set_bltouch_deployed(false);
}

Would this leave the BLTouch in a weird state if the pin hits the build plate on startup?

[GMagician]

I noticed that with my code no error is raised when G29 is done.
With original code is raised but this doesn't stop G29 at all (UBL)

[GMagician]

@thinkyhead

Would this leave the BLTouch in a weird state if the pin hits the build plate on startup?

Yes, this is why I added some commands in G28 on a previous commit. A good choice should be to avoid deploy when not required and maybe test it the first time it is deployed...

[thinkyhead]

There might need to be extra error handling in some places. When the probe fails to deploy, do_probe_move will return an error flag (true) and this causes run_z_probe to return NAN. If for some reason the error isn't generated by set_bltouch_deployed then these downstream functions will just continue as though the probe had deployed successfully.

[GMagician]

I think this self explain why it doesn't stop...

const float measured_z = probe_pt(rawx, rawy, stow_probe ? PROBE_PT_STOW : PROBE_PT_RAISE, g29_verbose_level); // TODO: Needs error handling

NAN is returned when probe fail but this will not stop G29 from going to next point

[thinkyhead]

Well, UBL's G29 doesn't care if a probe succeeds or not. It just fills in the NAN and keeps going as part of its normal operation. Points that failed to probe successfully it just expects will be filled in by a separate manual-probing procedure later.

[GMagician]

In my opinion it works correctly. I don't use bltouch for homing so someone should test it.
I tested with G29 and host raise error correctly.
I also found and fixed a possible missed fault

[GMagician]

@thinkyhead do you think a 1.1.x counterpart is required or 1.19 will born without this