Deadly need help!deadline_missed!

I can’t stand these any more, so i come here for help. There are four ODRIVE V3.6 on my machine dog. I need to read the pos and vel info from my odrive and control them through can bus. It seems like the motor would die randomly. I found that when the baudrate set to 500kb ,it will work for a longer time, but i can’t acceept lower baudrate for there are too much stress on the bus.
I also think this problem can caused by unexpect force , it can dead when the motor is seized.
I’m in instant need of help. That’s why I’m still working when it’s 2am in the morning here.
PLEASE GAVE ME SOME HELP OR JUST TELL ME IT CANT BE SOLVED,then i can give up it and have some sleep.
P.S SORRY for my poor ENG, hope i have made myself understandable.

Can you plug USB into one of the ODrives on your dog while the system is running, and run odrivetool?
While it is running, please can you run dump_timings(odrv0) - this will save an image file with a graph showing how much spare CPU the ODrive has. Please post it here so we can see what’s going on.

If reducing the CAN bus speed helps, then it’s possible that the ODrive is running out of CPU cycles.
What encoders are you using? I have sometimes seen problems like this if I am running two different types of SPI encoder.

Can you try leaving the CAN speed the same, but reduce the rate that you are sending messages from the controller?

Thanks for your response, but i can’t find any order similar to this one on my odrivetool 0.5.1,which version do you use?

My encoder use SPI too, and it is based on magnet , i have seen a lot of feed back use the same encoder. Should the encoder be blamed for this error?

I have already add a lot of delay order in my program, but i cant accept a longer delay because the PID can not work well in that condition.

I use the odrivetool and firmware directly from the Git repository.
You can run it with python3 tools/odrivetool

You should also try compiling and flashing the latest firmware. See my post here:

Exactly which SPI encoder are you using?
Yes the encoder can sometimes cause this error, if it takes too long to read the encoder data via SPI.

Fair enough. But can you check if a longer delay fixes this error?

Please post ALL of the error codes that you get when this happens. (dump_errors(odrv0))