gin66
commented
1 week ago The current implementation of the delay from enable till motor start is done in the queue handling routine. The implementation will fill the stepper queue with pauses as needed. The max delay is defined of max. number of pause commands fitting in the queue. The delay per command is 65535 ticks a 16MHz, which is approx. 4ms. The stepper queue on esp32 is fixed to 32 entries. Before the first step command 31 commands fit, so max delay is approx. 128ms.
Solutions:
- increase hardcoded value for stepper queue size: https://github.com/gin66/FastAccelStepper/blob/e57f7b4fe676d5ea3ee44a0048b92d1770e5c7da/src/fas_arch/common_esp32.h#L29 to e.g. 50. I’m future release I could allow to provide compiler definition via platformio.ini
- do not use auto on/off and do it manually
- use the callback/external pin feature and the callback implements 200ms delay by returning disabled status until pause is complete and then return enabled status
my recommendation is the third option, while second option may be more transparent on application side
jh83
I have an issue with a stepper driver from StepperOnline (DM542T). Im 99% sure that it is related to the "setAutoEnable" and the timing delay set by the "setDelayToEnable".
The spec sheet for the stepper driver says that "Enable time to be at least 200ms" and they also show this in their datasheet:
It seems there is a limitation on the setDelayToEnable which is related to the hardware. In my case i'm using ESP32 and the max delay is 120ms (?). I have tested with this delay and the stepper motor looses steps.
But if i skip the "setAutoEnable" and enable the motor manually then no steps are skipped which leads me to beleive that the step/dir pulses are being sent before the driver has been activated, e.g the time between the enable time and the stp/dir pulses is shorter then specified in the spec sheet.
Is there any way to have a longer time set in the "setDelayToEnable" function?