Hi all!
Looking for some insight here as to why the CAN message Tx rates would be inconsistent. I’m guessing I might be asking too much of the device, but wanted to reach out and see if there’s anything I could do to improve this without reducing performance.
I’m running a single ODrive Pro on a 1Mbps CAN bus point to point, and properly terminated on both ends. (So only two devices, the ODrive, and my ECU) I have all of the feedback messages set to a 1ms Tx rate. I can back down on some of them, but I really need speed, position, and torque to be at 1ms at the very least. I’d like to have Iq Measured and Setpoint at 1ms as well for diagnostics, along with bus voltage and current, but I can drop those down to 5ms or even 10ms if needed.
As you can see below in this screenshot (cursors are set to approx 1ms), some messages are at 1ms, but there are these “bursts” that occur back to back that are in the realm of 0.36ms. Which are then usually folowed by a gap of ~2ms. My guess is that the CAN processor is just getting hung up and overrun on broadcast requests.
However, the bus load is only at 65%, and there are zero error frames, as you can see here. So it’s a pretty clean bus. There’s also nothing else on the bus right now. The ODrive is the only thing broadcasting (since this is just a test bench for now).
Next question is on the Rx side of things. I want to run my external control loop at 1ms. So I intend to send Torque Commands at 1ms. If I try to do that, will the ODrive even update the internal target that quick internally? If not, what is the limit of how quickly it can update?
Thank you!