So this is our first year using a CANivore, I’m wondering if/how everyone everyone splits up their CAN buses and if anyone have any best practices?
For example, do you guys put all your REV devices on the RIO (pretty sure they don’t work on the CANivore) and then everything else on your CANivore? Do you put some CTRE devices on the rio and some on the CANivore? Etc
We were thinking of putting our REV devices + Drivetrain(/any motors on our chassis) Falcons on the RIO, then all of our super structure/anything that goes outside the frame on our CANivore, that way if anything goes wrong with the devices where it’s more likely to disconnect the CAN bus, we’d still have our drive train on the RIO side.
Does anyone notice any improvements using the CANivore over the CAN bus on the RIO when the bus is NOT overloaded?
Curious to hear about everyone’s setups/reasoning!
Edit: @Jacob_C I’m curious if there are any features that FD devices support this year to take advantage of the 64data byte frames or is this future use still? In the implementation for this year are there any signals that are split across multiple frames that would be a single frame when on a FD bus? Or are there any “downsides” to running FD devices on the RIO bus for this year?
Yes, Rev stuff does not work on CANivore. The only things that work with CANivore are Pigeon 2, CANcoder, Falcons, and CANdle. We are also using it and what I would say to do was put everything compatible with CANivore on it because it has higher bandwidth. I THINK that other CTRE stuff does not work on CANivore but I am not sure
I do have another question, external sensors for falcons, is it possible to use external sensors from 1 bus for falcons on another bus? If so, is there any additional latency going cross bus? If so are you aware of what that number is, or is it negligible?
I’m curious if there are any features that FD devices support this year to take advantage of the 64data byte frames or is this future use still?
I can quickly comment on this. Currently, in Phoenix v5 we have not added any new features exclusive to CAN FD.
However, Phoenix Pro does provide a few features exclusive to CANivore and CAN FD, such as Timesync and continuous fusion with the new “FusedCANcoder” remote sensor feature. Phoenix Pro also uses 64-byte frames for status signals, which reduces bus utilization and latency. In the future, we may also add additional functionality to Pro control requests that may require larger CAN FD frames.
Ah thank you, I forgot about the differences between v5 and Pro, are 2 CANivores supported on 1 RIO? For example if we wanted 1 for in frame devices and 1 for out of frame devices.
We’re also putting the drivetrain on the CANivore and everything else on the rio, but mostly because we have 12 CAN devices on the drivetrain (8 Falcons, 4 CANcoders). I would be more worried about CAN utilization than the USB cable getting unplugged at that point. Without swerve through, the drivetrain should probably be on the rio.
We noticed our CAN utilization was way too high yesterday so we switched to the CANivore mid season and put 15 Falcons on that bus. Our RIO can loop was used for just the pneumatic hub iirc. Our CAN util was fr fr chilling—after the switch I don’t recall ever seeing more than 50% on any CAN bus.
The one thing that I will note to really pay attention to is the recommendation to stick to daisy chaining. We run a bus topology and had no CAN issues on the CANivore until worlds at which there was always one motor on the bus that wouldn’t work (this happened to be towards the end of the loop). CAN FD is sensitive to your can bus topology and I’m pretty sure this is what causes our issue: we replaced the motor 3 times and it literally just wouldn’t work. If that motor connected to CAN other motor on the bus would just flop. Highkey made me pressed bc the fix was to move one motor to the RIO can bus and then later on in the offseason we had to move another one.
I doubt this is applicable to many teams but any teams running bus topology should highkey consider daisy chaining or making your CANivore bus as short as possible.
So unless I’m misunderstanding, when you said you had issues with “bus topology” I assume you mean star topology which isn’t recommended on the RIO bus and from the CTRE docs doesn’t work with a FD Bus due to the higher speed, daisy chaining is line/bus topology.
I’m pretty sure it’s called bus topology? Atl that’s what I’ve seen in networking. Hopefully this image clarifies what I mean if the terminology was confusing.
From what I’ve seen in networking and on wpilib docs, daisy chaining is generally referred to as “daisy chaining topology.” Bus topology is lowkey weird term in the sense that it can refer to the actual topology as shown above or it’s just a vague term used to label your overall can bus topology (whether it’s daisy chaining, star, ring, bus, etc.)
You are right in saying it’s not suited for CAN FD because of faster transmission times. We thought we would be fine running bus topology if we just kept our stun lengths short but as I mentioned above bus topology can cause some p funky problems if your loop is too long. How long is too long is a question I have yet to find the answer to.
This only applies for CAN FD tho. Bus topology on the RIO has always been fine for us and is largely preferred so one device doesn’t take down the whole network.
From my understanding that picture for Line/Bus is the same as your Bus topology which is the same as “daisy chaining” as the CAN H/L pins from each device are just shorted together. So the “drop line” is just the trace from the pads that the green/yellow wires are soldered to to the microcontroller in the talon.
