|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
||||
|
||||
|
Re: CAN troubles with Black Jaguars
FYI, this jag can still be used, just not as the first one in the chain.
Also kinda weird... it came with a board ID of 3. They are supposed to come with a board ID of 1. |
|
#17
|
||||
|
||||
|
Re: CAN troubles with Black Jaguars
When i had the issue of not getting the chain to work, i tried switching the CAN cable ports, as in the wire coming off the previous jaguar went into the port on left, i switched it to right, etc. That seemed to fix my problem. My question is, as long as it works does it matter where the cables are going?
|
|
#18
|
||||
|
||||
|
Re: CAN troubles with Black Jaguars
CAN cables don't care which port they connect to, as long as the chain is terminated. The CAN bus is a party line, where all modules are listening at all times.
There is no directionality to the bus. If a cable and port appear problematic, then you should treat that connection as suspect. Check the cables and ports thoroughly, as something is wrong in that link. If you move the cables to other ports, and the problem goes away, you may have just delayed the problem, and hid it somewhere else. Last edited by Levansic : 31-01-2012 at 01:53. |
|
#19
|
||||
|
||||
|
Re: CAN troubles with Black Jaguars
We have more probably 20 Jaguars in our shop, and used CAN extensively this year and last.
We recently discovered that two of our Jaguars had bad CAN ports (RJ-12 plugs), with either bent or missing pins. I don't know the cause, because I don't think we "abused" them. But we do crimp our own CAN cables. It's possible a person may not have crimped the pins in the connector all the way down. Inserting a connector with pins not completely crimped down is likely a quick way to wreck a CAN port. |
|
#20
|
|||
|
|||
|
Re: CAN troubles with Black Jaguars
Sorry that I haven't replied sooner just been busy. So we are using the 2CAN and we're programming in C++. So for us, the points on the chain that can be an issue are the 2CAN, the Jaguars, and the port on the cRIO, and all the software in between. Most of which is not mine.
I've two platform that I'm testing on. The first is a drive base, and the second is a prototype shooter. The shooter is running the Jaguars in speed control mode, the drive base is running in the default mode, %V I think. Both are seeing timeout, although the shooter is having more issues than the drive base. Both are using CIM motors. Although I suspect that the load on the drive base is higher than on the shooter. The code is pretty clean in that I'm not doing a whole lot. Tank drive on the base, and taking analog input on the driver station to drive the shooter. Updates to the motors are in TeleopPeriodic, and there just aren't that many knobs that need to be tweaked to make that work. What we've seen is that on the shooter, sometimes during the boot up, the 2CAN get's very unhappy. Flashing red/yellow. Sometimes it boots just fine. If we make it past the boot problems, it tends to stay clean. Then while shooting, it sometimes completely drops out CAN bus communications is completely gone, and the console log if full of timeout messages. The only recovery is reboot. The failure mode on the drive base is periodic timeout messages. Usually just a few off and on. I have seen it have the cascade failure but only once. We do have the version 2 of the 2CAN, and the latest firmware on it, and the Jaguars. I've already connected to each of the Jaguars using BD Comm, and flashed, set ids and so I'm kinda at a loss to understand what is going wrong. The sync groups change didn't seem to have any affect. I guess I can try the LabVIEW code to see if it behaves differently @techhelpbb - more than willing to work together on this. I'd like to get a better understanding of the failure modes and figure out some way to solve the problems. |
|
#21
|
||||
|
||||
|
Re: CAN troubles with Black Jaguars
I have a little follow-up on our original discovery and fixes. Tonight, I was setting up a new 2CAN, and only had one of our 2012 KOP black jaguars connected, when I noticed that my status readings dropped to all zeros.
Up until this point, this unit was always the first in the chain, and acted as the serial to CAN bridge. After fixing the RJ-11 port, I hadn't had any connectivity issues. I had to repair both of the ports in the second 2012 KOP black jaguar, but I thought this one was OK. I wiggled the cable (4-conductor CAN-only) in the RJ-12 port, and I got intermittent status on the web dash board. So I popped the cable out of the RJ-12 port, and I see that pin 3 and pin 5 wires are almost flat, as I described above. I disconnected the power, did my tweezer trick on both of the wires, and hooked everything back up. The result was rock-solid communications over that port. How did I miss this? Well, this was the unit I used to bridge all of the others with, when I fixed the others. Pin 1 and 6 were fine, giving a good serial connection. With small cable runs and only two nodes on the bus when I was testing, I didn't see any termination issues. I'm sure that if I used this unit to connect four or more jaguars using the serial bridge, we probably would have had maddening missing termination issues as this port jiggled. The constant connection to this bridging jaguar (over serial) would have masked this problem and pointed to the next in the chain or the last in the chain. In summary, I now know that 100% of our CAN ports (RJ-11 & RJ-12) on our 2012 black jaguars had quality issues that prevented them from working reliably out of the box. You have to test all ports in pure CAN communication, so that you make sure that your bus actually is terminated on both ends. The fix is easy, if you are careful and patient. If you are afraid of breaking the ports, recruit a dentist as a mentor. ![]() |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|