We initially had our PDH on the rio CAN bus and everything was working as expected (ie we were able to control the switchable port. Nice feature REV). Mid season, we split the CAN bus by adding a CANivore to help with issues we were having with CAN traffic due to a large number of Falcons and CANCoders (Lots of people seem to have the same issue with Swerve Drive this year). While adding the CANivore did fix our CAN traffic issues, we now have lost the ability to control the PDH as it was on the end of the CANivore CAN bus, not the rio CAN bus.
The constructor for the frc::PowerDistribution object doesn’t seem to take a CAN bus name. Has anyone been able to communicate with a PDH on a CANivore CAN bus?
Obviously we could rewire the CAN buses to move the PDH to the RIO bus, but we were hoping to avoid this.
Wow, that the quickest response ever. Is it just the software is not compatible at the moment (ie it may be fixed in a future wpilib update), or is it not compatible because of a hardware issue? like it doesn’t support CAN FD? (odd, seeing as it is a newly released product and surely CAN FD will take over in the FRC space in years to come)
The FAQ page for the CANivore says that it may in the future support non CAN FD devices. This would also be a CTRE firmware thing and not a WPLib thing*.
*
They would have to add support for another CAN bus though
Falcon 500s, CANdles, CANcoders, and Pigeon 2.0 are the only current FRC devices that support CAN FD. I’m not sure if it was clear to REV that CAN FD would even be legal in the space when they were developing the new control system. It exists because CTRE had been building it into their products starting with the 2019 releases with the plan to release the CANivore to take advantage of it later on.
The CANivore only supports CAN FD right now, so you can’t even use it with CTRE’s older releases, including the still common Talon SRX and Victor SPX. That may or may not change in the future, as CTRE has stated.
CAN FD could have potential, but if accessing it remains locked behind a $300 product I don’t see it taking over. Especially with REV hinting at utilizing SPARK MAXs as socket CAN devices. Significantly more economical relief for bus utilization sounds like it’s on the way.
Another downside is CAN FD is more sensitive to electrical issues, and teams already have a hard enough time with CAN 2.0 as it is. I have no feel for how much more sensitive, but it’s certainly a nice upgrade from CAN 2.0, so I am curious to see if it does take over or not.
The terminators are techically required for both CAN and CAN FD, CAN is a little more tolerant of being under-terminated.
CAN FD is way more sensitive to bus length, stub lengths, and untwisted wires, so wiring quality is much more important with CAN FD.
I would only use daisy chain connections with CAN FD and make sure the bus is properly terminated.
If you start the Bus at the Rio and end it at the PDB or PDH, the termination resistors are handled for you. With the Canivore, you need to provide the termination resistor at the end of the chain. The Canivore has a software selectable termination resistor for its end. . To provide backward compatibility, the Canivore will have to drop down to Can Bus 2.0 and the resulting slower bus speed.
To clarify - if EVEN ONE standard CAN device is connected to a CAN FD bus, the entire bus will not work at CAN FD speed. The standard device will put error frames on the bus every time it sees a CAN FD message.
I don’t know if CTRE firmware steps back to regular CAN if they detect a non-FD device, or if the whole bus just errors out.
My understanding is the current Canivore just runs Canfd. If you connect a Can 2.0 device, like the OP’s PDH, it just doesn’t talk. It does not crash the bus.
Yes. I meant that CAN 2.0 is more lenient while still technically required. With proper termination, CAN FD works just fine too. Our robot’s canivore network this year isn’t a daisy chain and has ~13 stubs.
Also the concern about being sensitive to wiring is more in regards to the teams not on Chief Delphi participating in nuanced discussions about CAN specs
If the PDH didn’t talk at all, how do you get the driver station diagnostics? Wouldn’t that also violate R716?
CAN does not work that way. If a standard CAN device sees a CAN FD packet it must, per the CAN standard, destroy the packet and send an error frame. That will cause the CAN FD device to retransmit, triggering another error frame, until the CAN FD device goes bus-off and stops sending any messages. So for it to work at all, the CTRE devices would have to notice the errors and drop back to regular CAN, or the PDH isn’t CAN standard compliant.
The PHD stop communicating with RIO when he switched it the Can FD bus. The OP did not mention drive station diagnostics so I don’t what errors it was throwing. Yes it does violate rule R716. Probably easy to miss since the PHD is connected to a CanBus, just not the right one. (The rule does not require that the PHD actually be able to talk to RIO.)
I have not personally tried this. Presumably since the bus is running a higher bit rate than a Can 2.0 device is expecting and probably cannot read it, the 2.0 device is just not responding. I am going be the reports that people are connecting a 2.0 device (PDH) and the bus is not crashing.
On pt. 2 - CAN devices aren’t supposed to “just not respond” per the standard, they’re supposed to transmit an active error frame as soon as they see an error. Which in this case would be the point where the CANFD frame switches to high bit rate since that looks wrong to a standard CAN controller. The error frame destroys the message being sent. If the sending device gets an error frame every time it tries to transmit, it’ll go bus-off after 16 frames. Then the next CANFD device would do the same thing, until the whole bus is trashed.
But clearly this isn’t happening, because the CANFD bus works with the PDH connected.
What might be happening is that the PDH could have been constructed using a microcontroller that supports CANFD (since quite a few new ones do) but REV didn’t configure it to transmit using CANFD frames for obvious reasons. The CANFD-capable micro probably won’t send error frames when receiving CANFD frames since it knows they’re valid CANFD frames.
The PDH would still be able to send its data frames (about status, currents, etc) to the CANivore using normal CAN messages, those are perfectly valid on a CAN FD bus.
The CANivore probably isn’t set up to forward the switchable output control frame back to the PDH, because the PDH isn’t supposed to be connected to the CANivore.
So the fact that it does work at all could be due to weird luck…
