[BUG] BLTouch: DEACTIVATE_SERVOS_AFTER_MOVE or not??

[Andrei-Pozolotin]

Description

Fails to auto-disable servo pwm signal after servo has completed the motion.

Steps to Reproduce

1. build with #define DEACTIVATE_SERVOS_AFTER_MOVE

2. verify servo is working via M280 P1 S0, etc

3. try to move servo actuator with hand

Expected behavior: servo shaft moves freely after the move

Actual behavior: servo continues to stay energized, can not move with hand after move is complete

Additional Information

perhaps due to use of non-default pin mapping
see #13314

config snapshot: Configuration.h#L2078
https://github.com/random-builder/Marlin/tree/f531df1c494b3f85b2c986d14f2993c0e3f3ad14

[AnHardt]

DEACTIVATE_SERVOS_AFTER_MOVE should read 'Deactivate servo pulsing after move' - but that's a bit long.
What the servo makes from this is not defined. (Should not happen in normal RC-operation.)
Years ago I tested a bunch of different servos. Some depowered the motor. Some left the power on and tried to hold the position determined by the last received pulse(s). That may depend on, if the servos electronic is analog or digital. Could also depend on the manufacturer, series or type of the servo.
If the servo does not depower, there is no reason to be worried about.
If DEACTIVATE_SERVOS_AFTER_MOVE works as intended, there can't be pulse jittering, because there should not be pulses.

---

But - if the servo is not depowerd, there is another possible reason for a jittering servo angle. If VCC (5-6V) is varying a lot - in the right (wrong) frequency - that may be visible/feelable. There is no way to improve that by Marlin.

[Andrei-Pozolotin]

1. I verified 5v servo supply quality - there is only 15mv ripple
   a) the jitter I reported in [BUG] MKS-SBASE/LPC1768 servo vs stepper interference #13314 occurs only when steppers are moving
   b) there is no jitter when there is no stepper activity that could be attributed to 5v supply

2. I measured that servo pwm signal
   is still present after the move is completed, as follows:

M280 P1 S0   -> period=20ms, pulse=0.53ms, peak-to-peak=3.3v
M280 P1 S90  -> period=20ms, pulse=1.46ms, peak-to-peak=3.3v
M280 P1 S180 -> period=20ms, pulse=2.39ms, peak-to-peak=3.3v

[drzejkopf]

It doesn't work, because you have enabled BLTouch, go to src/inc/Conditionals_LCD.h and comment line 468

#undef DEACTIVATE_SERVOS_AFTER_MOVE

[Andrei-Pozolotin]

1. The change of src/inc/Conditionals_LCD.h/#undef DEACTIVATE_SERVOS_AFTER_MOVE
   does make it work as expected, servo is de-powered, thank you.

2. But that makes no sense to me at the moment.
   a) How come BLTouch servo is treated differently then any other servo?
   b) BLTouch also needs to suppress jitter to avoid "false control angles", correct?
   c) That configuration setting contradicts official BLTouch manual, if I read that properly?
   https://docs.wixstatic.com/ugd/f5a1c8_c22571a27da74a5096efbfe8757f2f97.pdf

//============================ R/C SERVO support ========================== 
#define NUM_SERVOS 3
#define SERVO_ENDSTOP_ANGLES {{0,0}, {0,0}, {10,90}} // 10=deploy, 90=retract
#define DEACTIVATE_SERVOS_AFTER_MOVE

3. Alternatively, if BLTouch is indeed special, how can one ensure that
   BLTouch/DEACTIVATE=false can coexist with regular-servo/DEACTIVATE=true
   to avoid jitter?

[Andrei-Pozolotin]

1. perhaps it should be documented here about possible configuration interference: generic servo vs bltouch servo:
   https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/Configuration.h#L2105

//#define DEACTIVATE_SERVOS_AFTER_MOVE

2. experiments show that DEACTIVATE_SERVOS_AFTER_MOVE is not needed by BLTOUCH here,
   sensor works just fine on LPC1768, perhaps this should be made optional instead:
   https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/inc/Conditionals_LCD.h#L455

  #undef DEACTIVATE_SERVOS_AFTER_MOVE

[thinkyhead]

If the #undef DEACTIVATE_SERVOS_AFTER_MOVE is not needed, great! It was added after some discussion where it wasn't completely clear-cut whether to enable it or not. #3902 (comment) Upon review, it does seem safe to either remove that line, or even (ironically) to replace it with #define DEACTIVATE_SERVOS_AFTER_MOVE.

[AnHardt]

//#define DEACTIVATE_SERVOS_AFTER_MOVE

was the suggestion of the first original manual for the BL-Touch (at least for the Kickstarter version).
(But they have been wrong in that many points. Why not also in this.)

[boelle]

@Andrei-Pozolotin have you tried to test with latest bugfix 2.0.x to see if the issue us still present?

[boelle]

@Andrei-Pozolotin is the issue still there?

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[Vertabreak]

i'm gonna retest this and if i see any gain ill send PR.
it does seem silly to prevent the use of the option on the bltouch unless it causes some crazyness.

[InsanityAutomation]

i'm gonna retest this and if i see any gain ill send PR.
it does seem silly to prevent the use of the option on the bltouch unless it causes some crazyness.

Antclabs does not recommend it and after testing as klipper turns off pwm, it found absolutely 0 change in function, just the input light on the bltouch goes out. No change to repeatability either.

[Vertabreak]

that test was on a real bltouch? not a clone?
the 3dtouch is not reliable at all and im willing to try anything that might make it better.
if this helps there seems to be no point to not to allow the define to be used if the user needs it.
this is assuming after 30 or 40 tests i get anything useful.

[Vertabreak]

nope makes the 3dtouch not function at all.

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