Trying to find a white paper that talks about the inner workings for the CAN bus protocol. I remember seeing it on CD months, maybe years ago, perhaps authored by CTRE but can’t see to find it on CD. Could someone offer up a link if they know what I’m talking about? Thanks All. Happy Summer.
Are you talking about the CAN standard in general (electrical specs, signalling, lower-level behavior), or the FRC-specific implementation (including the manufacturer/device type/device ID encodings)?
Here’s the docs on how FRC allocates the CAN address space, if that’s what you wanted.
How about this from CTRE?
Not sure what I’m looking for. I’m trying to get a Pigeon and a non-FRC CAN device to be on the same CANbus and be able to communicate with a RIO. Separately, I can get the RIO to talk to each. The non-FRC CAN device is communicating via CANOpen protocol which I have some documentation for and I think I understand. The Pigeon I’m not sure I understand what is the CAN protocol and thus don’t know what’s not playing nicely.
Just trying to figure out if we can peer under the hood to get a clue on how to make the 2 devices communicate on the same CAN bus.
Might not be possible, but wanted to give it a try.
What APIs are you using to talk to the non-FRC CAN device? The NetComm library opens the Linux CAN device and provides a CAN session mux. Are you using the HAL/NetComm CAN APIs or trying to open the CAN /dev/ device yourself (which likely conflicts with NetComm trying to open it).
We are writing this in LabVIEW.
We are using these API’s:
Embedded CAN for RIO addon Drivers.
So you won’t actually be able to use those API’s directly. Because the robot program itself is going to open the CAN handle, and you can only have 1 CAN handle open.
However, there are wrappers exposed in the Robotics Library to access the CAN handle in a shared way.
You can use the Send and Receive blocks there to send and receive CAN messages, similarly to the embedded can library (In fact the embedded can library is used behind those VI’s, except just the C version so its usable across languages)
This might be a stupid question, but what if we’re not running your standard ROBOT Main.vi.
Does it still open the CAN Handle?
If you load the driver station vi, it will automatically load. And that vi is the only way to talk to a ds.
Additionally, since ctre doesn’t make their can packets public, the only way to use them is to use phoenix, which uses the higher level apis, and require the ds to be loaded as well.
Yes that one. I do also think that theres some other hidden initialization elsewhere. I haven’t dug in in a while.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.