BLTouch unreliable when used with NeoPixels (BTT GTR 1.0)

[muistiloppu]

Bug Description

BLTouch does not deploy when starting to print.

My Configurations

Board is BTT GTR 1.0, Marlin 2.0.7.2, BLTouch 3.1.
BLTouch was connected to the BLTouch port on the board.

Steps to Reproduce

1. Start printing by heating bed and nozzles with commands M109 and/or M190.
2. Head moves to Z-homing position.
3. BLtouch does not deploy and head crashes to the bed.

Expected behavior: [What you expect to happen]

1. Start printing by heating bed and nozzles with commands M109 and/or M190.
2. Head moves to Z-homing position.
3. BLtouch deploys and printing starts.

Actual behavior: [What actually happens]

1. Start printing by heating bed and nozzles with commands M109 and/or M190.
2. Head moves to Z-homing position.
3. BLtouch does not deploy and head crashes to the bed.

Additional Information

PWM signal goes high level and stays there for the BLtouch right away when I send heating command (M109 or M190) and after that BLtouch does not deploy for Z-homing. It happens only when bed or head is heating up alone or together. It does not happen when they are cooling down.
Commands M104 or M140 does not have this problem and Z-homing (G28) alone works fine.

For preventing a head to crash to the bed every time when this happens, I modified the "deploy_proc(){" code to brake if PWM pin stays high level by adding "|| extDigitalRead(SERVO0_PIN) == 1) {" to both " if (_deploy_query_alarm(){" statements.

================================================
bool BLTouch::deploy_proc() {
// Do a DEPLOY
if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("BLTouch DEPLOY requested");

// Attempt to DEPLOY, wait for DEPLOY_DELAY or ALARM
if (_deploy_query_alarm() || extDigitalRead(SERVO0_PIN) == 1) {
// The deploy might have failed or the probe is already triggered (nozzle too low?)
if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("BLTouch ALARM or TRIGGER after DEPLOY, recovering");

clear();                               // Get the probe into start condition

// Last attempt to DEPLOY

if (_deploy_query_alarm() || extDigitalRead(SERVO0_PIN) == 1) {

  // The deploy might have failed or the probe is actually triggered (nozzle too low?) again
  if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("BLTouch Recovery Failed");

  SERIAL_ERROR_MSG(STR_STOP_BLTOUCH);  // Tell the user something is wrong, needs action
  stop();                              // but it's not too bad, no need to kill, allow restart

  return true;                         // Tell our caller we goofed in case he cares to know
}

}

Configuration_adv.zip

[sjasonsmith]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

I'm not sure your change to read the servo pin is a valid check. When working properly there will be activity on that pin, a single read of state is not going to indicate whether or not it is working properly.

Of course any time you are testing BLTouch behavior you should do it high above the bed so that you have time to turn off the printer prior to a crash.

[muistiloppu]

I'm using oscilloscope to see the activity on that pin.
My code to read the servo pin was only to prevent expensive crashes to the heated bed (It works well. I had no any crashes, only stops).
To get the printer to print, I'm now having heating commands after Z-homing.
This BLTouch problem is still alive on the bugfix-2.0.x branch. I tested it in bang-bang and PID mode.
PWM servo signal goes to steady high level for the BLTouch only when I'm sending M109 or M190 command to heat up the printer.

[muistiloppu]

I modified the heated bed settings to be for heated chamber and M191 command did not mess up BLTouch PWM pin.
M303 command has same problems what M109 and M190 has.

[muistiloppu]

By sending command M355 S1 or S0 in ones or couple times to printer cancels PWM pulses for the BLTouch.
Commands M355 P0 to P255 with or with out S1 or S0 have same effect.
Problem might be because the bed, heater1 and BLTouch are controlled by same timer 2 (case light might be timed with the timer 2 also).

[muistiloppu]

Command M150 is messing up the BLTouch PWM pin too.

[muistiloppu]

By undefining NEOPIXEL_LED and CASE_LIGHT_ENABLE I have no any problems with the BLTouch PWM.
Heaters was giving a problem because LED strip was showing heating progress.
Some how LEDs are messing up the BLTouch PWM.

[sjasonsmith]

Thanks for providing all the detail. I would like to look into this, but have been too busy so far this week.

Did this ever work previously for you? I cleaned up some GTR pin assignments recently. I’m not sure whether this was always a problem, or if I may have introduced it.

[muistiloppu]

I just tested with Marlin 2.0.6.1 and it has same issue.

[sjasonsmith]

Have you modified pins files at all, or is your neopixel all defined in the config files? If you’ve modified any other files please attach those so I can try to reproduce.

[muistiloppu]

Here is the latest test changes. You need to define NEOPIXEL_LED and CASE_LIGHT_ENABLE to have issues with PWM.
pins_BTT_GTR_V1_0.zip

[sjasonsmith]

The NeoPixel library disables interrupts for the entire duration of updating your LEDs. I suspect that is interfering with the Servo library's timer usage.

We ran into this when writing to flash-emulated EEPROM a while ago. I added a workaround that disables servo output while the flash write is in progress. It is possible that is necessary during the NeoPixel update as well.

I've coded something up, and am about to go try it out.

[sjasonsmith]

I just tested my workaround, and while it does work, I don't love it. NeoPixels are just not very cooperative. They need tight timing that can cripple the rest of the system unless you offload it to another controller. According to my logic analyzer, updating your Neopixels disables interrupts for 3.84 milliseconds in order to update your 96 LEDs. During that time anything depending on ISR timeliness is going to misbehave. You would certainly never want to change your LED state while you are printing.

If that happens to align incorrectly with the timer interrupt for the PWM output signal things get out of sync somehow in the Servo library and it stops updating.

With my current workaround it is possible you will get some odd-length pulses when you update LEDs. Maybe that won't matter. Maybe it will cause spurious BLTouch deployment or other weirdness. I'm not really sure.

Here is a branch with my change (and your configs) in it. Go ahead and try it and let me know how it works. From there we can decide what the next step is.

https://github.com/sjasonsmith/Marlin/tree/InWork/Bug19887_GTR_PWM

[muistiloppu]

I tested it while BLTouch pin was down and up by running long G-code to turn LEDs on/off rapidly. I didn't see any failures, only longer gaps or 24 ms long pulses only when LEDs was addressed.
This may not to be the perfect fix, but what I know about servos is that they are designed to handle rough signals with RF interfering or short transmission gaps and still functioning fine. The LEDs on the printer are not toggled on/off or color/brightness changed constantly, so I think this is fine fix by now.

[sjasonsmith]

I have posted a pull request with a revised version of my workaround. I honestly don't know whether it will be accepted. If it is important to you, please go to the PR linked above, test it out, and post your opinions to the PR.

[sjasonsmith]

It looks like we went ahead and merged my workaround for this. A better NeoPixel solution may be possible, but has been lower priority than trying to eliminate other bugs.

You’ve previously stated the workaround satisfies your needs, so I will go ahead and close this. Please let me know if there are issues with it once you update to the latest code.

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