I can’t seem to find an answer. In the Power and CAN window of the driver station we always seem to have anywhere from 12-50 comms faults. I know that restarting the driver station clears them.
What causes them? Are they software or hardware problems? I assume it’s a communication error of some sort, but “fault” tells me it’s something with power.
I’m not familiar with CAN specifically at this level of detail, but in general a networking comms fault simply means that an invalid packet was received (incomplete, bad checksum, collision*, etc), or that no expected acknowledgement of receipt was received.
* a collision is when two devices are transmitting at the same time in the same comms path/channel.
OK, I think I see. So, for example we have the drive motors programmed to PWMs 0 and 1, but we don’t have those controllers plugged into the roboRIO, we’ll see those comm faults when we run deploy/enable the code?
In other words, the driver station is expecting a signal and throws up a comms fault alert at you when it doesn’t get that signal?
Comm faults on the CAN bus is usually caused by:
1> 2 devices on the same CAN ID
2> one of the 2 CANbus wires broken somewhere on the bus
3> one of the 120 ohm resistors is not attached
4> a stub is too long
5> resistance is too high on the CANbus
What if you have nothing on the CAN bus? No CAN wires in the roboRIO, and nothing programmed into labview that would, should or could be on the CAN bus? Any clue what might cause the comms faults then?
Would it be possible for one to even encounter comms faults if they had no CAN wires in the roboRIO, and had nothing programmed into labview that would, should or could be on the CAN bus?
As the PDP is on CAN, maybe that’s what’s doing it? Though, I thought the ability to see/talk to the PDP required getting the CTRE CAN software installed.
Do you have screenshots? Do you have any pneumatic code in place?
I think I mostly figured it out! I started poking around the driver station and saw the detailed logs of each run. It seems like ALOT of the error messages were about having a something like a motor controller programmed and assigned to a PWM channel, but we would have that motor controller unattached to the PDP because we were testing another system and just didn’t want it in the way. Many were errors about a color sensor we had a test code for, but didn’t have the sensor plugged in.
The most useful thing I found is that the DS tells you specifically which PDP channels were acting up. We had so many electrical problems last year, I’m trying to train my team to troubleshoot them. I’ve even been poring over the match files from last year and I can see exactly when and what wire got pulled out and which motor controller lead in the PDP was going haywire.
May sound like pretty basic stuff a veteran coach should know already, but—I know it now!
A comms fault is usually due to sloppy programming, from what I can see.
Sorry about the confusion with the CAN! Until now those were “the yellow and green cables”. Now I know that the PDP and CAN are interconnected.
If you’re curious, the reason I asked about pneumatics is the PCM is also a CAN device. If you have it setup in your code, you’ll be having issues communicating with it if you don’t have the CAN wires connected.
Good to hear you pinpointed what was causing you strife in this instance.