|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
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); System.out.println(jag.getFirmwareVersion()); } catch(Exception e) { e.printStackTrace(); } Timer.delay(1); } } } ================================== Here's the NetConsole output from a deploy of this code (with the cRIO "Console Out" DIP switch set to OFF): [cRIO] VxWorks [cRIO] [cRIO] Copyright 1984-2006 Wind River Systems, Inc. [cRIO] [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 Comm Type: WDB_COMM_END [cRIO] WDB: Ready. [cRIO] [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] [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] [cRIO] [cRIO] [OTA Server] Version: 2011 FRC, Jan 6 2011, 09:47:42 [cRIO] [cRIO] [cRIO] Welcome to LabVIEW Real-Time 8.6.1f3 [cRIO] [cRIO] [Squawk VM] Version: 2011 FRC, Jan 17 2011, 16:12:19 [cRIO] [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.chec kStatus(CANExceptionFactory.java:38) [cRIO] at edu.wpi.first.wpilibj.can.JaguarCANDriver.receiveM essage(JaguarCANDriver.java:67) [cRIO] at edu.wpi.first.wpilibj.CANJaguar.receiveMessage(CAN Jaguar.java:579) [cRIO] at edu.wpi.first.wpilibj.CANJaguar.receiveMessage(CAN Jaguar.java:584) [cRIO] at edu.wpi.first.wpilibj.CANJaguar.getTransaction(CAN Jaguar.java:634) [cRIO] at edu.wpi.first.wpilibj.CANJaguar.getFirmwareVersion (CANJaguar.java:1192) [cRIO] at edu.wpi.first.wpilibj.CANJaguar.initCANJaguar(CANJ aguar.java:240) [cRIO] at edu.wpi.first.wpilibj.CANJaguar.<init>(CANJaguar.j ava:267) [cRIO] at edu.wpi.first.wpilibj.templates.CANTestBot.robotIn it(CANTestBot.java:27) [cRIO] at edu.wpi.first.wpilibj.IterativeRobot.startCompetit ion(IterativeRobot.java:73) [cRIO] at edu.wpi.first.wpilibj.RobotBase.startApp(RobotBase .java:154) [cRIO] in virtual method #10 of javax.microedition.midlet.MIDlet(bci=17) [cRIO] at javax.microedition.midlet.MIDletTunnelImpl.callSta rtApp(64) [cRIO] at com.sun.squawk.imp.MIDletMainWrapper.main(110) [cRIO] in virtual method #95 of com.sun.squawk.Klass(bci=25) [cRIO] at com.sun.squawk.Isolate.run(1506) [cRIO] at java.lang.Thread.run(231) [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. |
|
#2
|
|||
|
|||
|
Re: Consistent CANTimeoutException via CAN-serial interface
Quote:
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. -Joe |
|
#3
|
|||
|
|||
|
Re: Consistent CANTimeoutException via CAN-serial interface
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? |
|
#4
|
|||
|
|||
|
Re: Consistent CANTimeoutException via CAN-serial interface
Quote:
-Joe |
|
#5
|
|||
|
|||
|
Re: Consistent CANTimeoutException via CAN-serial interface
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. Thanks! |
|
#6
|
|||
|
|||
|
Re: Consistent CANTimeoutException via CAN-serial interface
Quote:
-Joe |
|
#7
|
||||
|
||||
|
Re: Consistent CANTimeoutException via CAN-serial interface
Quote:
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. |
|
#8
|
||||
|
||||
|
Re: Consistent CANTimeoutException via CAN-serial interface
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?
|
|
#9
|
|||
|
|||
|
Re: Consistent CANTimeoutException via CAN-serial interface
@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). |
|
#10
|
||||
|
||||
|
Re: Consistent CANTimeoutException via CAN-serial interface
Quote:
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. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|