Our CAN usage is at 80% usage. Our robot has 2 talon fxs, 9 spark maxes, 4 cancoders, and 4 Victor spxs. Is it expected to be that high?
That seems fine as a number of devices, one reason CAN utilization can be increased is the length of the loop, do you have a lot of long runs, or just a bundle of cable somewhere?
Ill let other offer more input, but that’s where I’d start.
I would say that the run for this year is not any longer than previous years I also for got to mention that we will occasional drop frames from our cancoders or our spark maxes
Can you explain how the length of the loop increases CAN utilization?
6 Likes
Increase in can length doesn’t increase can utilization. But increase in can utilization does increase the length if you have long wires between devices. Because CAN runs at like 1MBPS, havign a super duper long run can cause timing issues. Generally, with a reasonable robot size and routing of CAN Wires it should be fine
I feel I’ve seen somewhere that it can if you exceed the maximum length of a branch, but I can’t find a source for that information, so I may incorrect in my memory, either way it would be an extreme example(such has having 50ft bundled up somewhere.)
Based on the information provided I would imagine it would be some sort of code issue, are you doing any power monitoring?
If you are occasionally missing frames that sounds like your CAN bus is not very high quality (a bad transmission line). CAN is very good about retrying when it fails, so that can drive up your percentage. CAN will retry A LOT before you get a failure.
Daisy-chaining like the Spark Max are designed for is a pretty good way to maintain the integrity of the channel (transmission line), but it does give you a lot of connections along the bus; any one of them fails and it takes down any devices after it.
Using branches is a better way, but make sure you keep the branches under 6" for CAN.
(lots of technical terms here. Search CD or google them for more details)
1 Like
We are running at 80 percent can utilization with 15 motors and 1 pcm.
Do you notice and can frame not received or stale errors
1 Like
If you’re concerned about it, you can turn down the frequency of status frames you’re 100% sure you don’t need. But if it’s working fine as is, I’d leave it.
We did notice problems with the can bus on a couple occasions. The first was when we had duplicate spark max id’s. The second was when we were setting the spark Max pidf values every loop. This seemed to flood the bus.
Electrical signals propagate along a conductor at the speed of light, 2.998 x 10^8 m/sec. It travels about 3.3 m in a nanosecond. It is not clear how the very minor increase in propagation delay can affect CAN utilization when it is an insignificant fraction of the microprocessor’s clock cycle.
Electrons typically flow about 60% the speed of light. Depends on the cable.
With 15 Spark Max and a PCM our CAN bus is running 55-60%.
We have 47% ish (can’t remember specific number) CAN usage.
5 Spark Maxes, 6 Talon SRXs
I think you might have misplaced a decimal point. Light, of course, travels at 1 foot per nanosecond, and I think meters are more than that.
(Also there’s a velocity factor that means EM waves propagate at slower than c in wire, but that’s probably not significant here.)
Possibly. Regardless, the point is that the propagation time in the CAN bus in an FRC robot is not going to be a factor in the issue being discussed.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.