Missing steps ESP32 S2 in high dynamic usage

[ChrGri]

Hello and thank you for this awesome library.

This library is used with an ESP32 S2 Mini in my DIY active pedal (https://github.com/ChrGri/DIY-Sim-Racing-Active-Pedal/blob/main/Arduino/Esp32_S2/Main/Main.ino). Here, a Loadcell measures force applied to the pedal and uses a closed loop stepper (https://www.omc-stepperonline.com/de/nema-23-integrierter-easy-servo-motor-180w-3000rpm-0-6nm-84-98oz-in-20-50vdc-buerstenloser-dc-servomotor-isv57t-180) to adjust the pedal position. Unfortunately, after some usage, the pedal seems to lose its neutral position, thus the pedal tilts more and more to the ground and I'm trying to understand the root cause of this problem.

The cycle time of the code is approx. 130 us and depending on the loadcells reading, a new non-blocking moveTo(..., False) is executed. The position and direction might significantly differ from the cycle before. Stepper speed and acceleration are configured rather high as required by the application.

Step+ and Dir+ of the motor are wired to 3V3 and Step- and Dir- are wired to the GPIOs. I wonder, if applied in this configuration, some stepper code logic needs to be changed from rising to falling edge? Other remarks of potential solutions are highly welcome.

BR

[ChrGri]

@gin66 Thx you for fixing the lost steps. Meanwhile, I've mounted a regular ESP32 on my pedal to be able to switch between RMT and MCPWM. The good news is, that none of them seem to have issues with step loss. However, the response of the stepper to dyanmic input seems to be quite different for RMT and MCPWM. In MCPWM the pedal response is perfect. No delay or latency whatsoever. In RMT, the response sometimes seems to be delayed and not smooth. Without knowing the root cause of the difference, I would describe the behaviour as if the input queue is full, the target position is not updated by new commands until the queue is completed entirely.

[gin66]

There is a difference in regard to direction changes. The RMT will do DIR change only, if the current command in the queue does not generate steps. If this is not the case, then the driver will add a pause, which may slow down in a highly dynamic use case.

Does this match your experience ?

[ChrGri]

That's possible. Is there a technical reason for that functional difference?

[gin66]

Yes, this arises from the current implementation. The RMT buffer is split into two parts and usually one half executes one command from the step queue. This means, while one half is being processed by the RMT HW, then the other buffer can be prepared with the next command. If now a command with direction change needs to be processed, the dir output needs to update. If the currently executing command is performing steps, it is not possible to safely change the dir output without risking one step in the wrong direction. So the driver requires the current running command to have no steps in order to change the direction pin. If this is not the case, then the driver inserts a pause.

Perhaps there are alternative ways to avoid this, just I have currently no good idea, how this can be done. Normally direction change appear at stopped motor, so I would expect most application to have no issue with this pause.

This raises the question, if this technical implementation causes the observed behavior or not.

[ChrGri]

Thank you for the detailed explanation. Since I'm currently using the regular esp, this does not need prioritization tbh.

If you want to verify your assumption, I could trigger a serial print for specific conditions/state and try to correlate that with the pedal response. Do you have an idea which state to check (internal variable or function argument of the API)?

[gin66]

direction changes could be a trigger. this you can get directly from the port pin