Can't run 4 motors at once

[jackthese]

I have a system running on a ESP32 DEVKIT 1 that has four attached BigTree 2209 drivers running four NEMA 17 motors. Any combination of 1, 2 or 3 motors run perfectly, but if I try running all 4 motors simultaneously using, say, MoveTos they all go into fibrillation until the commands are complete. Curiously, the system worked perfectly some 6 or 8 months ago. The program is very complex, and most likely I've buried the problem somewhere in there, but I thought I'd ask the community if anyone else has encountered this? Thanks...

[gin66]

Which lib version do you use ?

[jackthese]

Sorry for the delayed response, but I've been looking for errors in my code. I'm using a web-based control panel (ESPUI), so I can run multiple tests with various motors turned on or off for the test move sequence. Upon startup, all commanded move sequences using any one, two or three motors works perfectly, for as many runs I do. Once I try a four-motor run, that run and all subsequent runs using one, two or three motors does not work, like there's "permanent damage". Restart restores functionality. currently running 0.30.13, but tried 0.30.4 with similar results (gave some compiler warnings, but continued to link and upload). Have used 24V 2Amp wall wort, and also a lab 5 Amp supply. for the motors. Tried multiple ESP32s. Tried BigTree 2209 V1 and new V2 drivers. Tried new set of all motors. Development board has all soldered wires and headers(headers for ESP32 and all drivers)

Current .pio file: [env:esp32doit-devkit-v1] platform = espressif32 board = esp32doit-devkit-v1 framework = arduino lib_deps = teemuatlut/TMCStepper@^0.7.3 esphome/AsyncTCP-esphome@^2.0.1 adafruit/Adafruit SSD1306@^2.5.9 gin66/FastAccelStepper@0.30.13 upload_speed = 921600

[gin66]

Sorry for the inconvenience. Unfortunately there is no automated test suite to ensure, that functionality is not broken. I am testing on esp32 hw quite rarely.

Ideas to try:

• As it may be driver type related, please try stepperConnectToPin(step_pin,DRIVER_RMT); and check if this remedies the issue.
• fix the stepper task to one core: either engine.init(0); or engine.init(1);

[gin66]

btw: if the issues occurs, will there be steps lost ?

[jackthese]

Well, the plot thickens. For the Trinamic drivers, I'm using an option to set direction over a common UART, instead of using an actual ESP32 pin for each motor. The Trinamic library provides calls for setting a two-bit driver address, and then for reading and writing to the proper register for direction change. I do that in the callback routine from your library. And you can also read and write to a different register that sets the uSteps/Step, from 2 to 256. That register appears to be getting corrupted somehow, but only if fours motors are running simultaneously. Might be due to me slamming too many UART commands at once to set four directions. May be a UART timing issue, and I need to run this to ground. So I'm going to suggest that you can stand down for now, and I'll get back to you with what I find out. As always, I appreciate the quick and very helpful advice you always provide.

[gin66]

Thanks for sharing latest findings.

For the external callback: It may be better in the external pin callback only to set and read flags. Then a cyclic parallel task (e.g. 2ms cyclic) could poll these flags, update the direction pin via UART and on success feedback flags to the external pin callback.

The sequence could be:

1. Stepper task (4ms cycle):
   • motor is running forward
2. Stepper task (4ms cycle):
   • motor direction change needed
   • external pin callback is invoked (need backward)
   • => read flag feedback (is forward) and report old direction (forward). callback set flag (backward)
     3. Polling task (2ms cycle)
   • flag change detected (backward)
   • set direction pin via uart (to backward)
   • on success update flag feedback (is backward)
     4. Stepper task (4ms cycle):
   • motor direction change still needed
   • external pin callback is invoked (need backward)
   • => read flag feedback (is backward) and report new direction (backward). no flag set needed.

[gin66]

stale