Marlin: [BUG] (Z probe servo type random deploy)

[fkirita]

Hello.
First, thank you for your hard work.

I use last 2.0.x and i have this malfunction:

• for Z probing i use a RC servo as servo 0;
• start printing;
• when the hot end reach the target temperature and PID start to work the servo randomly deploy at different angle;
• when the G28 start the servo it is working ok;
• during the print everything is ok;

I make a test and just start the preheating. When the hot end reach the target temperature and stay there the servo start deploying randomly.
With the previous 2.0.x release the printer working ok.
I have changed the servo with new one. The bug it is present again.
At one moment the servo jammed because of the violent move.
Please help.

Thank you,

[BigIronGuru]

Which commit level were you on when it still worked? i.e. What do you mean by previous?
What is the printer hardware? More information please?

If you turn on levelling debugging

/**
 * Enable detailed logging of G28, G29, M48, etc.
 * Turn on with the command 'M111 S32'.
 * NOTE: Requires a lot of PROGMEM!
 */
#define DEBUG_LEVELING_FEATURE

and then do it again, let's look at the logged output to see if the servo is moving because of any commands sent to it (just to prove the fault lies elsewhere).

[fkirita]

Thank you for response.

The printer use a ramps 1.4 with mega. The RC servo is ES9051.
The marlin who works is Marlin-g34-triple-2.0.x. I used this branch because i have 2 Z nema and i use G34 for Z align.
Because G34 and dual Z align was included in Marlin i want to use last marlin.

Monday I will turn on debugging and i will post the log. (the printer is at work)
Thanks

[fkirita]

Hello.

I have made more test and the conclusion is that if I heat the hot end after start the printer, without any command before, the servo start randomly deploy when the hot end reach the target temperature.
If I command a G28 first and then heat the hot end the servo work normally.
I try this many time (more then 10).

Any suggestion?

Thank you,

[BigIronGuru]

I think that the servo PWM has not started yet until for example a G28 causes it to DEPLOY. After that it has got continous PWM. Means noise on the wire can "influence" the servo.

So test this: Instead of G28 and then heating, try M401, then M402, then heating. If that also "fixes" the problem, we will know the reason for the problem

[BigIronGuru]

No, what I wrote is wrong. The servos are initialized when Marlin starts. It must be more complicated.

[BigIronGuru]

Can you please post your config files? And maybe the output from

**
 * Enable detailed logging of G28, G29, M48, etc.
 * Turn on with the command 'M111 S32'.
 * NOTE: Requires a lot of PROGMEM!
 */
#define DEBUG_LEVELING_FEATURE

[fkirita]

I send first 401 and 402 and everything working ok after that.

In config i have enabled DEACTIVATE_SERVOS_AFTER_MOVE, because the servo has a little buzz when is activated.

config.zip

[BigIronGuru]

So there is your problem. When the servos are init at Marlin start they are later deactivated. No more signal on the wire. And then you have a noisy system, and the PWM for the nozzle is going on to the wire.

You could put a M401 or a M403 or a G28 into the start code of your gcode from the slicer?

Try denoising the signal wire to the servo by a 100nf capacitor to GND, if that helps, fine, otherwise dont deactivate the servos.

But the buzzing means that the servo is a cheap one - maybe a good digital servo would not buzz.

I think you can close this, honestly.

[fkirita]

Thank you.
The printer it is large and the wires are long. I think you are right.
You was very helpful.

Have a nice day.

[AnHardt]

We should have a look into the initialization of the servos pins.
After reset, at least the AVRs, pins are input with no pullups. Connected to the servos inputs the wire acts as a perfect antenna, floating somewhere.
As far as i can remember, after a 'DEACTIVATE_SERVOS_AFTER_MOVE' the pin should be an output at low, driving the wire and the servos input into a defined state.

[Reywas62]

I am having this same issue on an SKR V1.3 board using a servo deployed probe. I did not see the issue on the MKS GEN L board using the same setup.

[thinkyhead]

Sounds like we should add this to setup… But will other platforms prefer other states? If so, we can move this to HAL_init and do it differently…

  // Init Servo Pins
  #if PIN_EXISTS(SERVO0)
    SET_INPUT_PULLUP(SERVO0_PIN);
  #endif
  #if PIN_EXISTS(SERVO1)
    SET_INPUT_PULLUP(SERVO1_PIN);
  #endif
  #if PIN_EXISTS(SERVO2)
    SET_INPUT_PULLUP(SERVO2_PIN);
  #endif
  #if PIN_EXISTS(SERVO3)
    SET_INPUT_PULLUP(SERVO3_PIN);
  #endif

[AnHardt]

For AVRs i'd tend to a OUTWRITE(pin, LOW).
But for other processors the pins mode could be PWM or something like that. No problem if the HAL completely initializes the pin and not assumes some state. To put that into the HAL seems to be slightly better.
Sorry no PR by me. The current servo code confuses me.

[tpruvot]

servos as input ? or its a dual mode input + pwm output ?

[AnHardt]

It's about bridging the time until the servo pin gets it's real initialization. That seems to be at the first use of the servo (for the AVRs - no other HAL investigated)

[Reywas62]

Just to add a little additional info to my above comment, this issue only occurs when #define DEACTIVATE_SERVOS_AFTER_MOVE is enabled AND the servo leads are in close proximity to the hotend leads. Adding a 0.1uF cap across the signal and GND pins did fix the issue for me on my SKR V1.3 board. I am using a good quality digital servo. Disabling DEACTIVATE_SERVOS_AFTER_MOVE does fix the issue but this is not an ideal solution for this issue, in my opinion.

Thanks to all of you that work on Marlin. I am just an interested user.

[AnHardt]

Ok.
SKR V1.3 is one of the LPC boards. So here we have to look at the pins state after deactivating the servo.
That's clearly output low at the AVRs.

[AnHardt]

To remember. We have the option to deactivate the servos because at the AVRs we observed a bit of Jitter in the servo pulse timing - worst while stepping/moving. Because while probing moving is essential we try to stop to pulse the servo. This is not a defined state for the servo. In RC systems the servos are always pulsed. But in my (limited for example never tested a BL-Touch) tests all servos behaved well but some lost power. Against that we can redeploj for every probe.

If you don't feel the jitter while probing, for example when using a 32bit system using hardware PWM servo signals, what are unlikely to jitter, don't activate DEACTIVATE_SERVOS_AFTER_MOVE. It's more kind of a dirty trick - not a generally good method.
For the BL-Touch DEACTIVATE_SERVOS_AFTER_MOVE is not recommended. The pin will never jitter even if the pulses are jittering.

[thinkyhead]

For the BL-Touch DEACTIVATE_SERVOS_AFTER_MOVE is not recommended. The pin will never jitter even if the pulses are jittering.

This is automatically undefined if BLTOUCH is enabled, so that is covered.

[thinkyhead]

Servo pin init for AVR and LPC176x is proposed over at the PR linked above. This should be tested and then other platforms can be added once we know what their initial states ought to be.

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