[BUG] BLTouch deploys during movement when using CoreXY, Re-ARM and TMC2130 with 256 microstepping

[drmulligan]

Description

While performing XY movements, the BLTouch pin randomly deploys. Sometimes the red light turns off, sometimes the blue. While looking at the servo1 (D11) output with a logic analyzer I found that there is extreme "jitter." (See actual behaviour for description of jitter.) Deployments seem to happen most often, though not exclusive to, changes in direction. Occasionally deployments of the pin happen during XY movements too. No amount of manually induced vibrations cause the pin to deploy while stationary. Setting the X and Y microstepping to 16, from 256, make servo1 output look completely normal and there are no random BLTouch pin deployments during XYmovements.

My configuration is : Re-ARM Ramps 1.6 4x TMC2130 drivers using SPI RRD Smart Graphics LCD BLTouch 24V PSU

Steps to Reproduce

1. Configure for Re-ARM, CoreXY, TMC2130 spi, and 256 microsteps on X and Y. Compile and reboot.
2. Using pronterface issue G28
3. Using pronterface load and print attached file with XY movements. The exact XY movements don't seem to be important, the file is just short and repeatable.

Expected behavior: [What you expect to happen] 1475uS pulse on servo1 (D11) every 20mS.

Actual behavior: [What actually happens] Long periods of time with no pulses at all on servo1 (D11) When there are pulses, they are sometimes not the correct length. Occasionally the pulse stays high for 20mS or much longer.

Additional Information

Attached are my configuration.h, configuration_adv.h, and platformio.ini configuration files as well as the gcode file I've been using to test called g0.gcode. I have also attached a pair of logic analyzer files called marlin_servo1_x256y256, one is a screen capture image png the other is a PulseView .sr file. The logic analyzer files show printing g0.gcode along with a few seconds before and after. You will see that the pulse was happening every 20mS at the beginning and end but not so consistently during the print. If needed I can export the PulseView file in other formats. I can also acquire more captures if necessary and/or if this one didn't show all the flavours of jitter. Is there a pin I can use to trigger my logic analyzer to the beginning and end of a print or gcode file? Is it as simple as issuing a M43 P4 S1 at the beginning of my file? Is there a better signal to use?

marlin_servo1_x256y256.zip

[p3p]

I'm surprised you managed to have consistent motor control and serial comms, 2560 steps/mm @ 300mm/s is 768000 steps/s you're pushing the poor MCU harder than I thought would work at all, micro-stepping makes motors quieter but you don't really get any other benefit, In general I would say keep the steps/s below 80K which is when double/quad stepping kicks in, some drivers dislike the pulse train that generates.

I have a fix for the Servo issue, in that I'm going to push an update to the framework that will enable Hardware PWM on pins that support it, but that underlying issue of overloading the MCU will effect other things badly.

[drmulligan]

Your answer corresponds to another observation I made which I haven't yet had time to validate is the sensor doesn't deploy as often, or maybe at all, when moving slower. I do realize 300mm/s is too fast but I didn't realize what failure would look like. I should have realized not being able to service timing interrupts would be a likely symptom.

You said 80K is a good target, is that considering that this, a 100MHz LPC1768, is a relatively speedy processor? I guess a MAX7219 would come in handy here eh? I have one handy so all I need to do is find 3 free pins. Perhaps the other 3 servo pins.

[p3p]

You said 80K is a good target, is that considering that this, a 100MHz LPC1768, is a relatively speedy processor?

Yea, AVR platforms start double stepping to compensate for ISR overhead at 10K steps/s. (quad stepping at 20K) so 80K is a reasonable performance increase before double stepping using the same code, there are plans to take advantage of ARM hardware more after stabilising 2.0.

Microstepping can't simulate higher real steps/mm hardware to any real extent so in general I recommend keeping it low enough to keep out of the multistepping bands, the non continuous pulse train is louder and if the driver wants to interpolate, probably confusing.

[drmulligan]

I misunderstood what double and quad stepping is. I understand now. Thank you.

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