Using CAN in a star configuration

Is it possible to use CAN in a star configuration. Like having one output to the PCM and PDP, 1 output to a few talons, and another output to a few other talons. I know you would need termination resistors on each line, but other then that would it work?

Really risky. You’re going to end up with all sorts of reflections on the line that will tend to corrupt the CAN signalling. The signalling really does depend on a properly terminated transmission line of proper characteristic impedance to work properly. There’s a boatload of specs on how to do it properly, most of which are summarized by TI here:

Succinctly, you want a 100 ohm characterisic impedance (twisting wires together does that) and 120 ohm terminations. There are other factors like stub length and number of nodes that the document addresses. But, fundamentally the bus needs to be that differential pair with the 120 ohm terminations at each end and drops along the way for each device.

1 Like

First off, no, you don’t need or want more than 2 termination resistors. If you add more resistors, you’re going to drop the total resistance between the lines, which will cause problems with signal levels.

Second, the recommended topology is a single line terminated at both ends, with the unterminated stubs as short as possible. It is possible to run with unterminated stubs of a non-negligible length, but you need to know some specific details of the CAN drivers to calculate the max length for a single stub, and the max total length of all stubs.

If you were to try such a topology, you’d want the roboRIO at one end of your line, the PDP (with termination resistor) at the other, and you’d want to connect all the other devices directly to the line between the roboRIO and PDP. And keep all the stub lines as short as possible.

Before you try that, though, I think you should look at what you’re doing and why you think you need to do it in a star topology. You whole problem could be solved with a few extra wires and connectors. I can’t think of a reason each of your outputs couldn’t be a line out to (whatever) and then a line back. Your “output to a few Talons” could be line from connection point to a Talon, daisy chain a bunch of Talons, line back to connection point. I don’t think you can actually design a star-topology that couldn’t be converted into an equivalent straight line topology.


According to the research I have had to do when designing CAN interfaces into the circuit boards I am working on, I would have to say that there is no valid reason for you to try to implement a star CAN network. Go focus your energies on improving other areas of your robot instead.

If you have a node, say a motor controller, that is not “conveniently” located near the other nodes, a proper daisy-chain connection scheme would only require an extra pair thin wires. This extra pair of wires can be run next to the other pair of CAN signal wires. Since the two wire pairs carry the same signals, one would not have to be concerned about noise coupling between them.

1 Like

I would think the reason someone would want to run a star topology vs. a single end-to-end would be a desire to retain some control in the event of a failure of a single point of the CAN wiring.

With a daisy chain arrangement with end terminators, the CAN bus cannot survive any physical failure at any point.

With a star arrangement, e.g. with discrete PWM cables, any single PWM cable can be lost and not affect the ability to control any other PWM.

I’m not saying it is possible to run CAN in a star topology. But I observe the move of Ethernet from a single coax bus arrangement with end termination to the current star topology and one of the reasons behind it is robustness.

Keep in mind that ethernet has separate transceivers for every port. You can conceptually do the same with CAN, but most controllers have 1 or 2 CAN ports.

CAN really isn’t all that fragile. It’s used in automobiles, airplanes, automation, etc. It just takes some care during the wiring to make sure you have a bus that is intact and reliable. I would say that this new approach to CAN adopted by FIRST and CTRE using twisted pairs is much more reliable than the 6P6C version we had with the black jaguar. My experience with the old method was that the connectors were the most likely point of failure. Sometimes it was because they weren’t made properly, some times it was because the connector was abused. But, with twisted pairs, if you take your time to get good solid connections and keep your colors straight, I don’t think reliability is that much of a concern.

We spent quite a bit of time discussing the tradeoffs of a star topology with relatively short stubs vs. daisy chain with termination at each end. Many of the things discussed in this thread (robustness, stub length, reflections, risk of single point of failure, etc.) were brought up.

In the end we decided to stick with CAN as it was spec’ed to be - daisy chain, twisted pair, terminated at the ends. Can you get away with stubs several inches long? Probably. Can you get away with loosely twisted or even untwisted pair? Probably. Is it recommended? No. Should you chance it? I dunno - how much of a learning experience do you want? :slight_smile:

1 Like

It may be possible (and probably difficult) to tweak the stub lengths and the termination values to get a star configuration to work reliably. If you then have wiring failure in one of the stubs, your CAN network would likely stop working correctly anyways. A short would kill the signal throughout the network. An open would change the reflections and ringing experienced at each node in the network causing the Signal-to-noise ratio to degrade, making it likely that some or all of the nodes fail to function correctly.

Yes, the daisy-chain configuration is vulnerable to a single wire connection failing. So is much of the rest of your control system. How many robots have sat dead on the field because the power jack popped out of the radio? The proper response to such a vulnerability to take very seriously the task of improving the quality of the construction so that the probability of a failure is acceptably low (longer MTBF). Treat the wiring as seriously as any repairs to the brakes on your car. It is not that hard to and there are people who can help you learn how to do it properly. It would be much easier than forcing a CAN network to work with acceptable reliably in a star configuration.

My reply was not targeted at whether it is worth attempting to twist a CAN bus in to a star-topology.

I accept that the way CAN is designed is that it is a bus and that daisy chaining is the most reasonable physical implementation. I accept that this simplifies things and lowers costs in comparison to Ethernet. I agree that it makes little if any sense to try to wire it other than as a straight bus.

Instead, my reply was targeted at what I read (perhaps between the lines) in the replies prior to mine that seemed to express utter incredulity in why someone would want to do something so foreign.

I understand that there are plenty of other SPoF in the control systems. That doesn’t mean that you like having any of them.

I also understand that CAN is in widespread use in automobiles, etc. But can we agree that automobiles aren’t normally assembled by teenagers in training?

I especially want to thank crake for his amusing and informative reply.

On another project, we’re actually moving from a 100% daisy chain CAN bus to one with some minor stubs.

The most important thing is to make sure that you keep the stub lengths as short as possible. In fact, even with the current daisy chain implementation, you’ll find that there is a very short stub length inside the node (between the CAN transceiver and the tracks between the two CAN cables). We’re using <300mm for stub lengths on a bus that goes ~10m. There is only two termination resistors in this configuration.

It can be done, in our case it’s to allow greater flexibility in pulling out nodes and to clean up wiring. Realistically you should think about the benefit from a star topology and try to work out other ways of achieving that. For robustness, the cables on the Talon SRXs are long enough that you can probably solder the ends together (and heat-shrink), and just cut them off when they need replacing. There are plenty of splice crimps or BP style connectors that can be used quickly in a competition, and a quick wrap of tape will make them quite reliable. This only really leaves the roboRIO, PDP and PCM. Getting really good at the weidermuller connections is one of the only options here (especially for the roboRIO).

This posthas some relevance. It references an NI spec that allows stubs up to a foot. Personally I would stay as close to line to line as possible because I am superstitious & the whole concept of a digital buss is Voodoo (youdoo?) to me.

I appreciate the citing of specs and bold admonitions about signal reflectance voodoo, but a star topology is not all that dangerous or bad for CAN. The physical size of the robots tend to make the overall length of the CAN bus, regardless of topology, far shorter than what is allowed by the specifications.

We all need to keep in mind that FRC is about STEM education. Instead of dispensing absolute expert opinions, we should be encouraging students and mentors to test their ideas to see if they are valid.

Granted the new securely connected 2-wire CAN interface in this year’s control system does make the daisy chain a much more reliable bus topology than in the past. Our team could not successfully utilize CAN Jaguars, without a star topology. The improved in connections this year do not mean that a star or partial star is no longer viable, especially for teams who decide to continue using Jaguars.

In summary, if you are considering using a star or a hybrid, you need to construct your network and test it against a plain daisy chain. You may find no difference, or you could find that parts of your network don’t work. Don’t blindly take the opinions offered here as fact. Very little is absolute when it comes to CAN usage, aside from unique addresses and bus terminatons.

Depends on how you define “valid”. If someone is asking what is the right way to wire a bus, or weld, or grind metal, or design a 3D printed part, or… sure you can just figure it out, and kludge something together, and it might work - maybe it’ll even work the entire season. Many people will do this. Or you can teach best practices, good engineering, and solid design along the way!

The FRC CAN implementation is 1 Mb/s class C, which is very finicky about terminations and stub lengths. You WILL get poorer communications on CAN if you use a star topology without proper terminations, up to and including NO communications.

Go ahead and try it - don’t take my word for it - but be prepared to evaluate performance carefully (I suggest a CANalyzer/similar or perhaps an Oscilloscope) and return to daisy-chain if your results are not satisfactory.

It would be a very bad idea to not properly evaluate performance before going to competition. This is not a place to take an unknown risk.