Consistent CANTimeoutException via CAN-serial interface

I’ve spent the last 48 hours trying to configure CAN communication through Java without any success. I’m getting consistent timeouts while trying to connect to the Jaguars. I’d really appreciate any help from anyone who has successfully configured CAN.

Here’s my current configuration:

-A single black Jaguar, flashed with Black_Jaguar_92 firmware, device ID set to ‘2’, connected via its serial/CAN port (the left one) with a hybrid serial cable/CAN terminator (built to the manual’s specs) to the serial port on the cRIO. CAN terminator in place on the other port of the Jaguar.

-Jaguar firmware version/device ID and CAN/serial cables/terminators verified via BDC-COMM. Outgoing CAN communication from the Jaguar verified by chaining up to 4 black jaguars and operating them simultaneously through BDC-COMM.

-cRIO freshly imaged with the 2011_v25 image, with the “Black Jaguar Serial Bridge” selected as the CAN driver before imaging. Verified serial port functionality by connecting a computer and observing cRIO boot process through HyperTerminal. Boot is observable through serial connection until NetConsole plugin loads.

-All FRC Java plugins updated to the latest revision (posted Jan 17th).

Here’s my test code:

package edu.wpi.first.wpilibj.templates;
import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.CANJaguar;
import edu.wpi.first.wpilibj.Timer;

public class CANTestBot extends IterativeRobot {

CANJaguar jag;

public void robotInit() {
   for (int i = 0; i < 5; i++) {  //try to instantiate the jag a few times
        try {
            jag = new CANJaguar(2);
        } catch(Exception e) {


Here’s the NetConsole output from a deploy of this code (with the cRIO “Console Out” DIP switch set to OFF):

[cRIO] VxWorks
[cRIO] Copyright 1984-2006 Wind River Systems, Inc.
[cRIO] CPU: MPC5200 – Wind River Lite5200 BSP.
[cRIO] Runtime Name: VxWorks
[cRIO] Runtime Version: 6.3
[cRIO] BSP version: 2.0/10
[cRIO] Created: Jul 29 2009, 13:41:47
[cRIO] ED&R Policy Mode: Deployed
[cRIO] WDB: Ready.
[cRIO] Leaving debug.o StartupLibraryInit
[cRIO] * Loading StartupDlls: NiRioRpc
[cRIO] * Loading StartupDlls: niorbs
[cRIO] * Loading StartupDlls: NiViSrvr
[cRIO] * Loading StartupDlls: visa32
[cRIO] * Loading StartupDlls: nivissvc
[cRIO] task 0xee4928 (PAL00fb5da8) deleted: errno=0 (0) status=0 (0)
[cRIO] NI-RIO Server 3.2 started successfully.
[cRIO] task 0xc5fe68 (NiRioRpc) deleted: errno=0 (0) status=0 (0)
[cRIO] * Loading StartupDlls: nivision
[cRIO] * Loading StartupDlls: niserial
[cRIO] * Loading StartupDlls: FRC_FPGA
[cRIO] * Loading StartupDlls: FRC_NetworkCommunication
[cRIO] task 0x1b0d818 (t2) deleted: errno=0 (0) status=0 (0)
[cRIO] FRC_NetworkCommunication was compiled from SVN revision 2203
[cRIO] NI-VISA Server 4.5 started successfully.
[cRIO] task 0xe63110 (t1) deleted: errno=1835009 (0x1c0001) status=1 (0x1)
[cRIO] FPGA Hardware GUID: 0x2EAA5E59CAF1A8A966853A011B61CC91
[cRIO] FPGA Software GUID: 0x2EAA5E59CAF1A8A966853A011B61CC91
[cRIO] FPGA Hardware Version: 2011
[cRIO] FPGA Software Version: 2011
[cRIO] FPGA Hardware Revision: 1.5.3
[cRIO] FPGA Software Revision: 1.5.3
[cRIO] * Loading StartupDlls: FRC_BlackJagBridgePlugin
[cRIO] FRC_BlackJagBridgePlugin was compiled from SVN revision 60
[cRIO] * Loading StartupDlls: FRC_JavaVM
[cRIO] [OTA Server] Version: 2011 FRC, Jan 6 2011, 09:47:42
[cRIO] Welcome to LabVIEW Real-Time 8.6.1f3
[cRIO] [Squawk VM] Version: 2011 FRC, Jan 17 2011, 16:12:19
[cRIO] [Squawk VM] Version: 2011 FRC, Jan 17 2011, 16:12:19
[cRIO] FPGA Hardware GUID: 0x2eaa5e59caf1a8a966853a011b61cc91
[cRIO] FPGA Software GUID: 0x2eaa5e59caf1a8a966853a011b61cc91
[cRIO] edu.wpi.first.wpilibj.can.CANTimeoutException
[cRIO] at edu.wpi.first.wpilibj.can.CANExceptionFactory.checkStatus(
[cRIO] at edu.wpi.first.wpilibj.can.JaguarCANDriver.receiveMessage(
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.receiveMessage(
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.receiveMessage(
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.getTransaction(
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.getFirmwareVersion(
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.initCANJaguar(
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.<init>(
[cRIO] at edu.wpi.first.wpilibj.templates.CANTestBot.robotInit(
[cRIO] at edu.wpi.first.wpilibj.IterativeRobot.startCompetition(
[cRIO] at edu.wpi.first.wpilibj.RobotBase.startApp(
[cRIO] in virtual method #10 of javax.microedition.midlet.MIDlet(bci=17)
[cRIO] at javax.microedition.midlet.MIDletTunnelImpl.callStartApp(64)
[cRIO] at com.sun.squawk.imp.MIDletMainWrapper.main(110)
[cRIO] in virtual method #95 of com.sun.squawk.Klass(bci=25)
[cRIO] at
[cRIO] at
[cRIO] in virtual method #47 of com.sun.squawk.VMThread(bci=42)
[cRIO] in static method #3 of com.sun.squawk.VM(bci=6)
</snip four more CANTimeoutException stack traces>

If I turn the cRIO “Console Out” DIP switch to ON, then the cRIO boot process hangs after:

[cRIO] * Loading StartupDlls: FRC_BlackJagBridgePlugin
[cRIO] FRC_BlackJagBridgePlugin was compiled from SVN revision 60

…and the cRIO is unresponsive until rebooted.

What have I missed, where have I gone wrong? Thanks in advance.

This is not correct. The Console Out switch needs to be off to use the Black Jag Bridge Plugin.

As for your timeout issue, do you have a way to verify that the plugin is generating serial traffic on the port? Maybe hook it to your PC? You may not be able to interpret the traffic since it is not printable, but it would be good to know if there is traffic and how much. Note that the plugin configures the serial port for 115200 baud.


OK, I connected my PC to the cRIO serial port at 115200/8/n/1/n and tried to instantiate a CANJaguar.

I received some data over serial, but I’m guessing only a couple of bytes. In hyperterm it appeared as 11 printed characters. Is this the amount of data you expected?

Sounds pretty reasonable… and you’re sure that bdc-comm shows you the same device number of 2? Your systems seems like it should work from what I can tell from your posts. Any other details you think may be relevant?


OK, looks like it was a signal/noise issue - we are using 6-conductor flat cable for our serial link. Your comment about the 115200bps connection got us thinking about noise, so we shortened our serial cable from six feet down to 2 feet, and now we have our first successful serial connection from the cRIO to the Jag.

Maybe we’ll switch our cabling to twisted pair in the future.


Another option that will probably help is placing the CAN terminator in the RJ instead of the DB9. This way the center 2 conductors are not connected in the cable. It’s harder to manufacture but it prevents the CAN bus from running along side the serial signals.


Twisted pair is not necessary for CAN even a 1Mbps. You should not have any problem using 6’ of cable. We have tested using 30’ of cable without any issue. the CAN spec states up to 25 meters of cable may be used at 1mbps. We even removed the termination resistor at the far end of the bus without any CAN errors. In fact when the 2CANS are tested prior to shipping only one termination resistor is used on a bus of 12 2CANs. All can traffic is logged during the test and if ANY CAN errors are detected the unit fails.

I think your problem is probably elsewhere. Check the quality of connection of your termination resistors and cable connectors. If you have access to a CAN tool use it to determine if CAN errors are occurring. If you do not have a CAN tool you may use the 2CAN web dash to determine if there are any errors.

Also you may have CAN id conflict. Have you verified the individual ID’s are in fact discrete by pressing the user button on each Jag?

@Mike: After 48 hours of consistent connection failures between the cRIO and the Jaguar, we’ve now gone the last two hours without a timeout since shortening the cable. My concern about noise is not on the CAN side, but on the serial connection from the cRIO to the Jaguar. We are running on flat wire, and we put the CAN terminator in the DB9 on the cRIO side of the connection. Running the two protocols on parallel wire pairs within the same cable may have caused crosstalk or noise problems on the serial, especially since the serial connection is at such a high bitrate.

@Joe: I really like your suggestion of moving the CAN terminating resistor over to the RJ-12 connector in order to isolate the serial line, or I may even remove the resistor entirely if it turns out that it’s not really necessary (per Mike).

Ahh, I misunderstood your statement about the cable length.

I was not suggesting that you remove one of the resistors, just pointing out that it can work in most cases with only one resistor. We recommend and use both resistors in practice.