Hello. Quick question. We are trying to map out our CAN ids in a structured way. What are the ranges of CAN ids? 0-64? Thanks.
0 is reserved. I believe it is the Roborio’s ID
Thanks. How high do they go?
I believe frc CAN IDs are 6 bit, so the ID range should be 0-63, but I’d check the WPILIB documentation to be sure.
1 Like
Looks like 63 is reserved, so there’s that. Otherwise, looks like all systems go.
CTRE: 0-62
REV: 1-63 (I think)
Other vendors: Not sure. Probably 0-63 or 0-62.
1 Like
In the bigger world there are different implementations of Canbus IDs that are incompatible with each other. Fortunately FRC has narrowed that down.
The numeric address is 0-63 (6 bit). In FRC the name (and ID address) is actually longer so each device type has it own set of numeric numbers. IE a sparkmax2 is a different address than a PH2 or a PCM2. 0 is usually reserved for new devices so you don’t have address conflicts when you put in new devices on the bus. The exception in FRC land are the pneumatic modules and the power distribution board since they are mostly single devices.
1 Like
Keep in mind that multiple devices of different types can have the same CAN ID. I don’t recommend it for simplicitys sake but you can do it.
Where did you see this? I don’t think that is true for all vendors
1 Like
That’s wild. I never knew and I also wouldn’t recommend.
Possibly misreading the line in the WPIDocuments saying it “may” be reserved for specific messages. So case by case it could be reserved.
Everyone is already using the same ID for multiple devices whether they know it or not. Rio, PDP/PDH, etc default to 0 (or 1 I think for REV stuff) and are rarely changed. That said, i agree that i would avoid re-using that number for motor controllers and other devices youre likely to have multiple of.
1 Like
I thought it was the ID of the PDP (That’s how we have it configured, anyways). I’m curious to see how this differs between vendors
As people have said, the IDs are per device type, so you can overlap device ids on different device types.
No device ids are restricted from use by spec. It’s just that some vendors choose to block out certain ones. Like rev makes id 0 considered unconfigured, so it’s not a valid id for use. Whereas ctre is fine with a device being 0, but I think they block out 63 for other reasons (I might be wrong here)
It’s highly recommended to leave the power distribution and pneumatics modules at their default ids. Wpilib and the ds logging depend on this, so if you change them you lose ds logging, which is problematic.
2 Likes
Thanks everyone. That is super useful information. Really appreciate it. We will be a lot more organized with our can ids.
Actually not. the device number is part of the canID. If you look at the example below, the device number is only part of the canID. Multiple devices on the bus with the same can ID will make you sad.
Thad_House explained it very well in his post. (As he always does)
1 Like
Yes im well aware of that. My post was using the colloquial usage of the term “CAN ID”, which as you alluded to is the device ID field. Given this usage, my comment is perfectly accurate
Note that these IDs play a role in message priority. This is mostly an issue is your CAN bus utilization is high, but it helps to explain why certain instances of the same device tend to have errors more than others when the bus is very busy. Lower IDs will have priority.
For more detail in this area, this might be a decent article: Controller Area Network (CAN Bus) - Bus Arbitration - Copperhill.
A cool trick is to make your CAN ids the same as your PDP/PDH channel numbers. That makes it possible to use the source code to interpret driver station logs.
3 Likes
Documentation is good too. Though, we weren’t as thorough as we should have been this year.
Ex. PUBLIC - FRC 4096 2023 Electronics Tracker - Google Sheets
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.