I see 255 ms mentioned in the documents as max for a couple status frame timings. But is that the maximum for all of them?
I’m wondering the same thing as well. I’m just setting status frames that my team doesn’t use to 1000ms to fix can bus utilization issues.
1 Like
255 is the correct maximum status period for CTRE. REV has something like 65000, so we just use 60000.
2 Likes
Is there any drawback to setting a rev spark max to some really high number like 6000 or even higher if all you are doing is percent output control. Say and intake motor that is always either 100% power or 0% power?
No, but if all you need is percent output and you are struggling with your can bus moving it to pwm and off the bus may be more beneficial.
Well we are doing a bunch with a turret and a shooter. And drivetrain. Just looking to reduce it where we can on our percent output stuff. At competition so not real keen on moving them to pwm going into sat
Yes.
However, you don’t want to set all of the status frames you aren’t using to this. It’s important to space them out, or else every 255ms, up to like 300 status frames will be dumped to the CAN bus all at once.
You can’t control when the status frames are sent, only how often. Increasing the period will decrease can utilization. The CAN arbitration protocol will take care of making sure all the frames get sent.
This is also why it’s important to check the return values of config functions because during periodic spikes of high bus usage, the config functions can potentially time out.
Yea I meant to say status frame interval. my bad
I don’t actually think this is always the case.
Our team was having a lot of issues with CAN utilization, even after setting almost all of our status frames close to the max value. We have 21 CTRE CAN devices, as well as a rev PDH and pneumatics hub. We had been using a 240ms interval for most status frames, and a 50ms interval for status frames we were actually using. From my math (see below), we had a total of ~1269 frames being written per second.
Here’s our CAN utilization during a competition match at greater Pittsburgh regional.
However, based on a suggestion a CSA made to us, we decided to use prime numbers for status frame intervals.
In theory, this would give us a slightly higher CAN Bus utilization. However, in practice, we found that it nearly halved our CAN utilization. Here’s another match from the same competition after we made the switch from 240ms and 50ms to prime numbers.
.
From what I understand:
- CAN Status Frame timing is relative to a device’s boot time. I haven’t actually confirmed or denied this, but based on the behavior I’ve seen, I suspect this is the case. If anyone has a more concrete answer on this one, please speak up!
- If all devices are booting roughly at the same time (i.e.the main breaker is flipped), devices with the same status frame intervals will be sending frames at roughly the same time.
- When a bunch of devices try to send frames to the CAN Bus at once, it causes problems.
- Using different intervals to try to “space out” when status frames are being sent can help to avoid this. You probably don’t have to use prime numbers - however, the theoretical advantage of using prime numbers is that since the least common multiple of two prime numbers is quite large, the frames will “desync” over time regardless of boot order.
Much of this may be wrong. To be honest, I don’t have a lot of experience with CAN - nevertheless, thought i would share my team’s experience here in case its some use to others.
10 Likes
Much of this is wrong. See my post here for more details.
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.