Updated CAN Jaguar Issue

[jhersh]

Originally Posted by drakesword

We would also advise that you run PWM cables to your jags so if the CANBUS goes down you can still control your motors. Just have a reduced functionality mode.

That is disallowed by the rules. Rule R58-A

The Jaguar must receive signals via either a PWM cable -OR- a CAN-bus connection. Both may not be used simultaneously.

-Joe

[Alexander Meyer]

Alright, I tried looping the Jag initialization in Java until the exception went away..we let it go for about a minute then figured it wasn't going to fix anything. We reflashed the cRio for C++, wrote some test code, loaded it, and voila! Working robot. We figured all our problems were solved, shut off the robot, and continued where we left off. BUT..

..next time we powered up, we got the same exception. Drat. We checked the code, redeployed, and still nothing. We rebooted via the driver station a couple more times..and the third or fourth time, it worked. Weird. It continued functioning well for about an hour through numerous code changes/redeploys/reboots, then crapped out on us again. We hard rebooted via the breaker, then rebooted twice via the driver station, and we had control again.

So..we're still scratching our heads. Any ideas?

[jhersh]

Originally Posted by Alexander Meyer

So..we're still scratching our heads. Any ideas?

And all of this was while using C++?

Can you try power-cycling the Jags in the case where it fails? I'd like to identify if the jags that stop responding or what.

Thanks,
-Joe

[Alexander Meyer]

Originally Posted by jhersh

And all of this was while using C++?

Can you try power-cycling the Jags in the case where it fails? I'd like to identify if the jags that stop responding or what.

Thanks,
-Joe

Yes.

We tried that multiple times, and it never worked. The only time it worked is when we soft-rebooted the cRio a couple times after a power cycle.

[jhersh]

Please double check your termination and wiring.

[Alexander Meyer]

Originally Posted by jhersh

Please double check your termination and wiring.

Will do.

[Alexander Meyer]

We triple-checked the wiring, and everything seemed to be fine. We are getting a new error, though (-63194), which from a cursory look in CANJaguar.cpp is caused by a mismatch in firmware versions, even though all the firmware versions are the same (we double-checked).

Still scratching our heads..

[msk]

We are having a similar UncleanStatusException -52007 from the JaguarCANDriver class when we try to run our JAVA code. We just updated the firmware on all of the jaguars and also updated crio, netbeans, etc.

Our code was running okay on our robot before the updates....

Any ideas?

Thanks.

[jhersh]

Originally Posted by Alexander Meyer

We triple-checked the wiring, and everything seemed to be fine. We are getting a new error, though (-63194), which from a cursory look in CANJaguar.cpp is caused by a mismatch in firmware versions, even though all the firmware versions are the same (we double-checked).

Still scratching our heads..

I guess there must be an issue in the way the Java code is calling out to C++ land. I'll try to reproduce the issue.

-Joe

[Shadow24]

We are also getting this problem using Java. All of the Jaguars are updated to v92 firmware and seem to be wired correctly.

[dyanoshak]

Just to be absolutely sure:

Check the wiring to make sure that pin 1 on one connector goes to pin 1 on the other. When held flat and stretched out, the modular connectors on each end of the cable will be oppositely oriented from each other.

See the diagrams in the Cable Assembly sections of the Jaguar (or Black Jaguar) getting started guides at www.luminarymicro.com/jaguar

Sorry to repeat what others have suggested, but I have seen weird errors when a perfectly crimped cable actually crosses the signals.

-David

[Shadow24]

We had our electrical team check it over several times and it works fine when tested in BDC_COMM (same as the other team experiencing these issues). They wired it the same way as last year so unless that changed....

[jhersh]

Originally Posted by Shadow24

We had our electrical team check it over several times and it works fine when tested in BDC_COMM (same as the other team experiencing these issues). They wired it the same way as last year so unless that changed....

Sounds to me like that's a good validation of the wiring. I'll look into the Java software for issues.

[Shadow24]

Just for reference. This is the last section of the compiler/deployment output that I get. The most pertinent code is in the last 20 or so lines:

(Sorry that this is obnoxiously long, just trying to help out with troubleshooting)

------------------------------------------------------------------


init:
init:
No to.jar.file specified.
Using "suite\3173_Alpha_v1.0_1.0.0.jar"
Deleting directory C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\build
Deleting directory C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\suite
Deleting directory C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\j2meclasses
clean:
Created dir: C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\build
Compiling 1 source file to C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\build
compile:
Created dir: C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\j2meclasses
preverify:
Created dir: C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\suite
Building jar: C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\suite\3173_Alpha_v1.0_1.0.0.jar
jar-app:
Using "suite\3173_Alpha_v1.0_1.0.0.jar"
CompilerOracle: exclude com/sun/squawk/Method.getParameterTypes
CompilerOracle: exclude com/sun/squawk/SymbolParser.getSignatureTypeAt
CompilerOracle: exclude com/sun/squawk/SymbolParser.stripMethods
[translating suite image [closed: false, parent: squawk] ...]
### Excluding compile: com.sun.squawk.Method::getParameterTypes
### Excluding compile: com.sun.squawk.SymbolParser::getSignatureTypeAt
[Including resource: META-INF/MANIFEST.MF]
Romizer processed 90 classes and generated these files:
C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\image.sym
C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\image.suite
C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\image.suite.metadata
C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\image.suite.api
Expanding: C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\suite\3173_Alpha_v1.0_1.0.0.jar into C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\suite
Moving 1 file to C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\suite
Moving 1 file to C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\suite
Moving 1 file to C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\suite
Deleting: C:\Users\Nick\Documents\NetBeansProjects\3173_Alph a_v1.0\image.suite.api
target IP: 10.31.73.2
Network interfaces on host:
Realtek PCIe GBE Family Controller: address: 10.31.73.6 netmask: 255.255.255.255
WARNING: Host is not on same subnet as robot. May not be able to complete all communication with robot.
Connecting FTP @10.31.73.2
upgrade:
Sending local file image.suite
flashapp:
deploy:
init:
[cRIO] [OTA Server] ********* REBOOTING cRIO *********
[cRIO]
Waiting for cRIO to reboot (1s)
Waiting for cRIO to reboot (2s)
Waiting for cRIO to reboot (3s)
Waiting for cRIO to reboot (4s)
Waiting for cRIO to reboot (5s)
Waiting for cRIO to reboot (6s)
Waiting for cRIO to reboot (7s)
[cRIO]
[cRIO] -> * Loading StartupDlls: debug
[cRIO] Entering debug.o StartupLibraryInit
[cRIO] Debugging is up, target server mounted at /tsfs
[cRIO]
[cRIO]
[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 0xecc5c8 (PAL00f9d9c0) deleted: errno=0 (0) status=0 (0)
[cRIO] NI-RIO Server 3.2 started successfully.
[cRIO] task 0xc47a68 (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 0x1af5680 (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 0xe4abd8 (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 6 2011, 09:58:39
[cRIO]
[cRIO] [Squawk VM] Version: 2011 FRC, Jan 6 2011, 09:58:39
[cRIO] FPGA Hardware GUID: 0x2eaa5e59caf1a8a966853a011b61cc91
[cRIO] FPGA Software GUID: 0x2eaa5e59caf1a8a966853a011b61cc91
[cRIO] Uncaught exception in Thread.run():
[cRIO] on thread edu.wpi.first.wpilibj.templates.RobotTemplate - main
[cRIO] edu.wpi.first.wpilibj.util.UncleanStatusException: In JaguarCANDriver::receiveMessage, fatal status code detected: -52007
[cRIO] at edu.wpi.first.wpilibj.can.JaguarCANDriver.receiveM essage(JaguarCANDriver.java:59)
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.receiveMessage(CAN Jaguar.java:518)
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.setTransaction(CAN Jaguar.java:542)
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.enableControl(CANJ aguar.java:827)
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.enableControl(CANJ aguar.java:809)
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.initCANJaguar(CANJ aguar.java:254)
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.<init>(CANJaguar.j ava:271)
[cRIO] at edu.wpi.first.wpilibj.templates.RobotTemplate.<ini t>(RobotTemplate.java:31)
[cRIO] in virtual method #11 of com.sun.squawk.Klass(bci=53)
[cRIO] at com.sun.squawk.imp.MIDletMainWrapper.main(99)
[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)

[Shadow24]

Apparently we would periodically have the same error last year when we were using C++, however it would simply allow us to ignore this error and all of the motors would end up working just fine...


We would attempt to code it in C++ again, but our kit didn't come with a WindRiver disc and I can't for the life of me figure out how else to get it. I tried using last year's disc but the licensing refuses to work...