That’s a key difference in our problems then. Driving all 4 drive motors at full speed via BDC-COMM makes no difference, so unless there is a interference problem with idle motors that only shows in the small gap between the cRIO and the black jag, there’s something going on in software.
I’m fairly sure there is something weird that makes our setup different from NI’s since I can find no evidence of a heartbeat signal being sent by the cRIO over the network even though Wind River shows FRC_JaguarHeartbeatTask (or whatever it’s called) on the cRIO (though it’s always shows as [delay])
and Al, this is a different problem. All the jaguars seem to fail independently of eachother, something a watchdog would not do (the new per-motor watchdogs have been disabled in my test program)
This sounds very similar to a communication problem that I was having with my Jaguars. I built my serial cable/CAN terminator to the manual’s specs which included putting the terminating resister in the shell of the DB9 connector on the cRIO side. This meant that the serial traffic and CAN traffic were running on parallel wire pairs for the length of the cable between the cRIO and the first Jaguar.
I learned from Joe H. that the BlackJag plugin forces the serial connection at 115200bps, which is pretty fast and is more susceptible to noise than slower bitrates. I suspect that CAN traffic was crosstalking with the serial traffic, since I’m using flat wire, and causing the serial connection to fail. My solution was to shorten the serial/CAN cable from 6ft to 2ft, and I haven’t had any connection problems since then.
Joe also suggested moving the terminating resistor from the DB9 end of the cable over to the RJ-12 end. This would remove all CAN traffic from that cable and further decrease the potential for crosstalk or CAN-induced noise on the serial bus.
As far as I can tell that’s not the case. Set commands are considered trusted and therefore can keep a jaguar alive. I’ve also never seen anything in the plugin to run the heartbeat.
In terms of my cables I haven’t found anything wrong with them. Again it works fine in BDC-COMM all the way up to pulling the serial connector from the cRIO and plugging it into the laptop, leaving all the cables in the same configuration. I’ve checked that all connectors are seated properly, and there is no correlation between failure and physical location on the bus.
While the idea of interference occurring between the CAN and serial cables is reasonable, again BDC-COMM has shown no issues in communication in an identical setup (minus the cRIO), and under the (non-FRC version) source code runs under the same settings as the cRIO.
That is true. The Jaguar CAN Driver handles the heartbeats, but it also monitors the trusted commands. If you have sent a trusted command recently enough, then the heartbeat isn’t sent. However, if you just tell the Jag to go to position X one time, the heartbeat will be sent every 75 - 90ms to keep the Jag running in the absence of trusted commands.
Are you running much other code on the robot at the time? Can you use the System Manager in LabVIEW under the Tools menu >> Real-Time Module >> System Manager to look at the processor utilization while the Jags are having this problem? I’m interested if this could be the cRIO being too busy with other things to keep up with all the Jags.
Remember that the BDC-COMM does not put as much traffic on the CAN bus as the cRIO does, because the BDC-COMM usually sends messages to one Jaguar at a time, and only when you update a value. In contrast, your code is probably sending messages to four Jaguars every 20ms. (In my testing this took about 10-12ms for 4 Jaguars, but it may take longer if there are errors. I don’t know what CAN does for error prevention, but I do know it has good error detection.)
Joe, must EACH Jaguar receive a trusted message to stay enabled, or will a trusted message to one Jaguar keep all of them alive?
Ah, that makes more sense. For some reason though that wasn’t happening on last year’s autonomous code. I’ll check if there’s a similar problem going on w/ v25. I assume the heartbeat is sent on a per-jaguar basis in this system?
Are you running much other code on the robot at the time? Can you use the System Manager in LabVIEW under the Tools menu >> Real-Time Module >> System Manager to look at the processor utilization while the Jags are having this problem? I’m interested if this could be the cRIO being too busy with other things to keep up with all the Jags.
Thanks,
-Joe
I’ll check when I get to the robot today, but this is happening under minimal code. The teleop loop is literally “leftA.Set(stickA.GetY());”. I’ve also tried killing processes that seemed less important via Wind River (FTP task, RSL control, netconsole, etc) with no change.
I was also able to successfully connect through BDC-COMM but not through the cRIO. I suspect that BDC-COMM connects with the Jaguars at a slower bitrate and is thus more tolerant of noise/crosstalk.
Here’s the discussion thread where I outlined my problem and eventually found resolution via a shortened cable. Do my symptoms seem similar to your issue?
You need to enable the VI Server. Right click on the RT CompactRIO Target in your project and select Properties. Under VI Server: Configuration, turn on TCP/IP and leave it on port 3363. You should then be able to connect with the System Monitor.