CAN Jaguar: could longer CAN cables cause problems?

[AutoBotAM]

For the last couple days we've been struggling with getting our CAN Jaguar system up and running... We've wired these together plenty of times in the past, we're knowledgeable about the two net ports, and that the input goes into the one labeled "10101" (or something like that). We are using only black jaguars, and have them configured at 2,3,4,5.

The problem for one is that we can only barely access one of our Jaguars via code. BDC-COMM can access #3 and #5 directly (with it plugged directly to the laptop and the terminator on the other NET port). #2 didn't initially work directly and we haven't tried #4. Once we've expanded to other Jaguars (in "2-chain" configurations), we begin to face more issues. Connecting the two Jags together, some of our CAN wires have flat-out refused to run, while some of them are just unreliable, where #3 will appear for a moment and disappear when chained to #5. We've also replaced terminators and CAN-Serial cords without much change in behavior.

Over all we've been facing issues in getting a stable CAN network running. Our mentor Mr. Buchanan mentioned that one of the few things we've done differently this time is that we've been using longer CAN cables. I didn't have enough time to try the shorter cables, but have any of you guys experienced issues with the longer CAN cables? I could see how it would effect it, as a longer distance could cause signal degradation. What are your opinions?

[codes02]

Some relevent documentation: http://digital.ni.com/public.nsf/all...25795A000FC025

Essentially, it says that unless you have over 40 meters of cable there shouldn't be an issue (I'm assuming the highest bitrate to provide a lower bound), but also notes that the resistance of the resistor should be changed depending on the cable length.

However, the reality on an FRC bot might be different. I've seen people complain quite a bit about the lack of reliability from CAN on FRC bots and from Jaguars controlled via CAN. I didn't find anything with a quick search, but I expect there are threads from past years that could be useful.

[Cecil]

The first thing I would check is that your cables are made right. Do you make your own, or did you buy them pre-made? If they are pre-made and from somewhere like AndyMark, you should be fine. If you make them yourselves, make sure that they are correct (only the middle 4 pins of the 6 place connectors should be used and wire 1 should go to pin 1 on both connectors).

Also, check inside the CAN ports of the Jaguars themselves. There have been problems with the internal pins going down but not having enough spring to make contact with the connectors. With the power off, inspect the internal pins and see if they are pressed down too far.

Have you flashed the firmware on all of your Jaguars? Try doing it one at a time with BDC-Comm, remembering to have the terminating resistor in place.

[AutoBotAM]

Codes02:
This seems like a reasonable explanation considering the circumstances. I seem to remember having problems with longer wires beforehand as well. So it sounds like the resistors on both ends have to increase... In this case they are the same types we've used with the small wires, so I think that is the problem. That would cause the erratic behavior. We will try the smaller wires tomorrow or Saturday and report back with results. Thanks for the link, I'm going to print this and add it to the team's reference

Cecil:
Our mentor Mr. Buchanan custom made some of the cables. Some of the others, I don't know where they came. I'm pretty confident he wired the custom ones correctly but not positive. If our shorter cords don't do it, we'll try looking at the CAN ports as you recommend. I am not sure if all of these Jags have been updated to 107, I will report back with results on Saturday.

Thanks for the responses!

[Joe Ross]

Originally Posted by codes02

Some relevent documentation: http://digital.ni.com/public.nsf/all...25795A000FC025

Essentially, it says that unless you have over 40 meters of cable there shouldn't be an issue (I'm assuming the highest bitrate to provide a lower bound), but also notes that the resistance of the resistor should be changed depending on the cable length.

That is for the NI CAN modules, which we don't use. Per the Jaguar Datasheet, the total cable length shouldn't exceed 20ft.

[AutoBotAM]

Alright, I'm fairly certain ours don't exceed 20 ft, not sure though. Isn't 120 ohms the standard resistance for the CAN Jaguar chains? I'm fairly sure ours are set to that, and if they're less than 20 ft, wouldn't 120 ohms be sufficient? I will try the smaller wires we've used before. We might check the ports as well, but it seems unlikely to me because we have been able to connect to the single Jaguars #3 and #5 individually, its when we try to chain them up that problems happen. The output NET port might not be springing back, but probably not the input NET port. (and if the output were loose, that would probably cause a single connection to fail too, due to a lack of resistance)

EDIT:

Another question I thought of. By "total cable length" are they referring to the length of the whole CAN network, or just the length of one cable between Jaguars?

[nuttle]

Originally Posted by AutoBotAM

By "total cable length" are they referring to the length of the whole CAN network, or just the length of one cable between Jaguars?

The former -- the whole network, but not counting the first serial cable, so the length from the first Jag to the last. This assumes a linear single string and that you don't have a 2CAN but the serial adapter.

[Kevin Selavko]

We were having problems last year with our CAN network until we shortened the network, ours was not 20 feet but most of our problems were solved by shortening the network and a fresh termination resistor.

[buchanan]

In the course of many swaps of single cables leaving everything else unchanged, we thought we had identified some cables that almost always worked and some that usually didn't. For the most part this testing was 2 jags connected to BDC-Comm, with "works" defined as both units showing up in the program's device menu. However, the cables weren't 100% consistent. Sometimes a "good" one failed to pass, and I'm not positive the "bad" ones always failed. But clearly some worked more often than others. When we tried to put together all four with the better cables, we got all four to show up once, after that never got the last one to appear. Reordering the chain moved the failure to whichever one was last, though we stopped testing before running through all combinations. A few days ago I was able to get all four to show up in BDC-Comm, then got errors trying to access them from a program.

These modular crimp connectors seem pretty foolproof to me. Other than simply getting them backwards, which I'm sure we didn't do, is there any way to mess them up? We have used this same bunch (we have ten or so) of jags many years without any such issues, and now they're suddenly all flaky. The only thing obviously different is the physical layout (usually we put them all in a close group) and the wires. Using generic part-swapping troubleshooting methods, we've been having a terrible time isolating the problem to any particular device or cable, and it just doesn't make sense to suppose simultaneous failure in many parts that have worked so well for so long. It seems like it just HAS to be the cables, but I'm baffled as to where and how; they seem so simple.

Inspecting the connectors inside the Jaguars is an idea we hadn't had, though we did do a little "wiggle" testing to no apparent effect. That will be first on the todo list when we hit it tomorrow.

Thanks to everyone for the ideas and suggestions. We're on the verge of pulling the whole blasted thing and dropping in some old-school PWM Victors, but this problem has to have a solution, and one hates to admit defeat before even taking the field

Edit: A general shortening of the wires sounds like a good thing to try too. We've been testing with a big pile of cables, most of which are 3' long or so. We could probably cut the total chain length in half by cutting to exact lengths. It would still be longer than we've used in the past, but much shorter than what we've been trying.

[Cecil]

In addition to checking the pins inside the Jaguars, check your termination resistor closely. Make sure it isn't shorting against itself, and make sure it is also in pins 2 and 3 of the connector. Good luck troubleshooting!

[zbrozek]

If you attach a multimeter across CANH and CANL you should consistently measure 50 ohms as you wiggle various connectors.

If you have an oscilloscope, you can watch CANH and CANL versus GND. They should sit at around 2.5V when the bus is idle. If all's well you should see something that looks a bit like this.

If you see inconsistent high/low levels or a super consistent message (50% high/low jabber) then something is wrong.

Terminators aside, it's very easy to crimp an RJ-12 terminated cable upside down and swap CANH and CANL. That'll instantly break a bus. If you hold the two ends of the cable up next to each other and look at the wire colors inside the plug, they should be in exactly the same positions on both sides. If they're not, re-crimp it correctly or throw it away.

CAN is normally implemented as a twisted-pair network. Most telephone cable is untwisted. If you're simply picking up too much differential noise across CANH and CANL, you could consider using CAT5 wiring. You should also move your CAN cabling away from wires going to/from motor controllers and batteries. Lack of twisting is why TI specified the max length to be so much shorter than the CAN specification for a 1 mbps bus.

If you post a scope trace of CANH and CANL, I can probably help you debug your circuit remotely.

-Sasha

[nuttle]

If you made your own serial adapter (it sounds as though this is what you are using), be sure you included a termination resistor in it...

[Al Skierkiewicz]

About 90% of all CAN issues I have seen are traceable to the termination loads. Remember that the wiring is a transmission line just like coax to an antenna. Without the correct loading, there are a lot of reflections of signal along the line. The CAN bus requires a termination at both ends of the line so if you made your own RS232 interface, this requires a resistor as well. The termination resistor is 100 ohms. Using something other than 100 ohms is almost as bad as no termination. The flat cable that the phone company uses in lengths of 20 feet or less, emulate a twisted pair transmission line at 1MHz just fine. Yes, it is not hard to make your own RJ11 plugs but you can screw it up too. Just be careful and follow the instructions. The Jaguar Getting Started Guide on the FIRST website or IFI site has some great instructions in Chapter 6.

[codes02]

Originally Posted by Joe Ross

That is for the NI CAN modules, which we don't use. Per the Jaguar Datasheet, the total cable length shouldn't exceed 20ft.

No, the link I provided describes the length limitations of standard CAN. that said , I'm not supprised that the jaguars aren't up to spec.

[Al Skierkiewicz]

Auto,
It doesn't matter since the wire is the same (as described in the linked doc for the jaguar) on the RS232 side as the CAN side. It is just a little more convenient when using the cable mod in the document. I would not reuse the resistors. They are so cheap why would you add another issue when you are starting over anyway. The bus is terminated at both ends effectively giving it a distributed 50 ohm impedance. This is low enough that outside noise is usually not a problem and variables in the cable tend to minimize. But think about it in terms of RF transmission line. If one of the terminations goes open (actually anything greater than 200 ohms), the bus now goes to 100 ohms (the other resistor) and the open end becomes an antenna and mismatched load. At that point, noise starts to become a problem, and reflections start to mount. Where the reflections (that is a signal pulse that bounces back from the unterminated end) become a problem as the CAN device doesn't know if the reflection is noise and should be ignored or whether it is a valid pulse and interpret it as such. CAN was developed for harsh environments so a short run on a robot should pose no big issues.
Diagnosing cable should not need a scope. Just remove all but the first device and move the termination to that output port. See if you can communicate with the device and control it. If it works take out the known good cable and add a different one until you have tested all the cable and know they are good. Then add a second device and move the termination and repeat the test. Sooner or later, you are going to find one or more bad cables and one or more bad devices. Using known good parts and substitution gets you to the root of the problem pretty quickly without fancy test equipment. The assumption is "it works for other teams so there must be a bad cable, termination, or device in my robot."