How to test PDP with possible bad CAN Bus port


The team I have started mentoring this year has a PDP with a label on the back saying “bad CAN bus”. It is not known why this label was applied. I am focussed on electrical and mechanical and don’t have any recent experience with software (I last wrote software for PC’s, AT’s and XT’s).

How can we test the PDP to verify that the CAN Bus port on that PDP is working correctly? We have other PDP’s as well as RoboRios availableto test the PDP with.

On page 19 of the “Power Distribution Panel User’s Guide”, I found something about the “ERROR 1 CTRE CAN Receive Timeout”. If our RoboRio is connected to a good PDP would we not get this error when we boot up vs getting the error when connected to a PDP with a bad CAN Bus port?

Does the software do a check on boot up to find all the devices or does one have to explicity make the software communicate with the particular device to know if it is present, i.e. read the current from one of the PDP channels?


I suppose the simplest test is to hook the PDP to a roboRIO, then see if the Driver Station log is getting PDP voltage updates.

You can also take the PDP cover off and inspect the CAN circuit board for burnt traces.

Also use the roboRIO webdash to see if the PDP shows up.
Connect via USB to the roboRIO and browse with IE11 to and the PDP should appear on the left hand side.
In this case you must be sure that the CTRE webdash config has been applied to the roboRIO.
You can verify by connecting a third device, e.g., PCM, to the CAN bus as a test case.


Exactly what Mark said.

Also if you power up the PDP and the CAN lights don’t turn on, that’s a signal that the CAN module in the PDP is broken. You can contact CTRE about sending it in for repair or use it for a non-competition bot, but without the CAN functionality it’s not FRC legal.


Here’s an example of a burnt CAN circuit board.


Thanks for your quick replies, Mark and Ari.

Does any specific software have to be loaded in the RoboRio to perform the tests you described? From your descriptions, it sounds like as long as some software is loaded, the FRC specific operating system software will cause the CAN LED to turn on and for battery voltage values to be read from the PDP and displayed on the driver station dashboard.


The CAN bus works with just the FRC image on the roboRIO.
So, the PDP lights will be red blinking if no CAN bus is detected, and will be yellow or green blinking if the PDP is successfully communicating with the roboRIO via CAN bus.
No lights on the PDP if the CAN circuit has some damage.
The PDP voltage logs will be automatically collected and added to the Driver Station logs.

Using the roboRIO webdash to look at what CAN devices are on the bus requires the CTRE Phoenix webdash config be installed as a separate step whenever the roboRIO has been imaged.

No user code affects these responses.


Take a close look at the terminating jumper on the PDP. We had one last year that was giving us fits with CAN buss communication issues. I found that the terminating jumper was not set in place correctly and had bent over one of the pins. I can only guess that the jumper setting against the pin instead of actually connecting to the pin was causing significant noise on the buss. I straightened the pin, reinserted the jumper and that fixed the problem.

Mark, what else did you find inside the PDP that caused that much damage? That looks like the chips took a lot of current through the devices.