ERROR_CONTROL_DEADLINE_MISSED & ERROR_BAD_TIMING on 0.5.4

1

Using:
ODrive v3.6 56V
odrivetool 0.5.4
fw 0.5.4 (fw itself says 0.5.3-1), flashed .elf using ST-LINK.

Control using “Ascii_and_Stdout”, input mode trap_traj.
Main loop from arduino sending commands:

  • Send t 0 xx, “xx” in {0.2, 28}
  • poll feedback and axis0.controller.trajectory_done every 50 ms until trajectory_done == 1
  • wait 2 sec

“xx” is requested position, either 0.2 or 28.

Motor stops after some hundreds of cycles back-and-forth (so far always at the 28 position, but sample size is 3 times, so…)

odrivetool shows ERROR_BAD_TIMING | ERROR_CONTROL_DEADLINE_MISSED

Arduino loop keeps working, including polling of trajectory_done: it goes to 0 and 1 as if everything worked. Of course, feedback request shows the axis actually stationary…

At first glance, these errors look like fw is not respecting it’s own real-time requirements, but given I don’t see anyone else complaining, I’m inclined to think I’m doing something wrong.

What other information is needed?

2

Just found Control_deadline_missed - #4 by skyice

Seems similar. But we don’t have any ground loops, the arduino is powered off the 5V of the ODrive itself and unless debugging, there are no outside connections besides power.

There are 4 more drives working off that same PSU howerver, so I guess I should check that. Is there a spec for power supply regulation?

But I still haven’t found anyone with “ERROR_BAD_TIMING”…

3

What type of encoders are you using? I saw something similar when using two different kinds of SPI encoder that had different clock polarities (AS5047p and MA732). The solution was to use the same type of encoder for both axes.

4

Bog standard ABZ incremental, 16384 cpr.

5

:thinking:
weird. Try dump_timings(odrv0) with both axes active, this will output an image file (timings.png iirc) which you can post here. It will show you which functions are taking the most CPU time in the control loop.

6

Do you have any pins sest to PWM mode?

7

PWM: No, unless the default configuration has them set as such.
I do have a homing sensor (min_endswitch), but that’s an industrial break-beam sensor, and even if it had erroneous activations, it would trigger endswitch-active, not this, I assume (and have accidentally tested). Debounce is 0, as it just doesn’t bounce.

In home office, will get back to you with the dump_timings() when able.

8

Basically the only thing that can cause this problem is excessive software interrupts on one or more of:

GPIO set to PWM signal
GPIO set to Step & direction
Index pin (should only trigger once, but older firmware or a bug?)