Mindsenors CAN Splitter

[ollien]

Looks like MindSensors just put up a CAN Splitter. It looks great, because if one CAN device goes down, all other CAN devices don't go down. Has anyone used a similar product (or wiring method that emulates it)? How well do they work?

[Tom Line]

CAN bus is a passthrough circuit. Having a device die will not take down the chain. While a star topology is possible with a device like this, it is not recommended.

[ollien]

Originally Posted by Tom Line

CAN bus is a passthrough circuit. Having a device die will not take down the chain. While a star topology is possible with a device like this, it is not recommended.

I should have been more precise. If we have a chain A-B-C-D, and B goes down, C and D will be inaccessible.

Thank you for your advice regarding the start topology!

[R.C.]

Originally Posted by ollien

I should have been more precise. If we have a chain A-B-C-D, and B goes down, C and D will be inaccessible.

Thank you for your advice regarding the start topology!

It shouldn't go down unless the wire is physically cut and or missing from the chain. Someone correct me if this is wrong, but the way the Talons are designed the wires are physically soldered to the same pad. We've had a few times where a talon went out but the rest of the bus worked fine.

[Jaci]

Originally Posted by ollien

I should have been more precise. If we have a chain A-B-C-D, and B goes down, C and D will be inaccessible.

Thank you for your advice regarding the start topology!

CAN works in parallel. If you open up an SRX (speaking from experience), you'll find that both the in and out CAN wires are soldered together, and then onto the board.

Green and Green are soldered together, then soldered to a pad on the board. Yellow and Yellow are soldered together, then soldered to a pad on the board.

[Lireal]

I believe that this wiring method is called star topology. There has been a couple threads you can search for with more in depth details. Basically, it offers no extra benefits in terms of reliability with SRXs, because the wires of each color are soldered to the exact same location, and there are communication issues that come up with star topology. Here is one thread for reference: https://www.chiefdelphi.com/forums/s...d.php?t=132323

[Ari423]

From everything I've read and understand about CAN, the bus was designed to be used in series, not parallel. According to some other posts by knowledgeable people that I can't find right now because I'm on mobile, using a star topology can introduce noise and bad things into the network and is generally not recommended. Especially considering any good CAN device should have the CAN leads physically connected so the signal is passed through even if it fails. Can someone correct me on this or is this product pretty useless?

[Jaci]

Originally Posted by Ari423

From everything I've read and understand about CAN, the bus was designed to be used in series, not parallel. According to some other posts by knowledgeable people that I can't find right now because I'm on mobile, using a star topology can introduce noise and bad things into the network and is generally not recommended. Especially considering any good CAN device should have the CAN leads physically connected so the signal is passed through even if it fails. Can someone correct me on this or is this product pretty useless?

Honestly, it doesn't make a huge difference.

The CAN bus is, well, a bus. The bus is two wires (CAN-Hi and CAN-Lo) that are connected by a termination resistor (120 ohm) on each end. The CAN-Hi and CAN-Lo signals are equal but opposite, as shown below, so that, when twisted together, they reduce the effects of interference and data corruption.



The termination resistors are put in to prevent signals from 'bouncing back' or 'echoing' inside the bus, such that signals are not repeated or misread.

With this knowledge, you should be able to see what the purpose of these termination resistors are, and why CAN exists in a bus (every 'node' on the network can read and write). You should also notice that the bus is mostly arranged in parallel. See the circuit diagram below.



Something you should notice is that, because of this, it doesn't really matter where you attach a CAN device. You can do it either along a single line, branching off (kinda like a highway), or a single point that branches out to multiple other devices, like a star, with a termination resistor at the end.

Something you should note is that this isn't a true star topology. The RoboRIO has an inbuilt 120 ohm resistor on its CAN bus, which means there must be a 120 ohm resistor on the other end. This functions like a bus, with any devices branched off in a 'star' pattern also belonging to the bus. Despite them all being connected at a single point, it's the same thing as using a bus, but bringing all the connection points closer together. It looks like a star, but in reality it is a bus. The actual name for this arrangement is 'high speed CAN'.

A TRUE star topology is different from a bus in that it doesn't use a termination resistor at all. Instead, it relies on the combined resistance of all of its members. By the ISO 11898-3 spec, the overall resistance should be about 100 ohms, but never less. The actual name for this arrangement is 'low speed, fault tolerant CAN'. This name is misleading as normal CAN is fault tolerant for if devices go down (e.g. an SRX carks it), but the star topology is fault tolerant if a physical connection is severed. You can read more about the differences in this wikipedia document, under 'Architecture'.

All the images in this post were taken from this page.

[Al Skierkiewicz]

Guys,
This has been discussed many times here on CD. The CAN buss is essentially a transmission line with terminations at both ends. The terminations serve to reduce reflections along the line. On an FRC robot, the lines are fairly short and individual reflections may or may not cause interference on the buss as a whole when set up in a star topology. However, do not carry that forward to non-FRC designs in the future.
Any failure in the transceiver circuitry that would short the buss would affect all devices on the buss. Only opening the buss affects those device(s) down stream.

[FrankJ]

Keep in mind the FRC application is not "low speed fault tolerant". FRC Can is running at 1 Mb/sec. The recommended maximum stub length is 1/3 meter (roughly 1 foot). This thread discusses why not to use star topology by people way more knowledgeable than me.

Here is a TI white paper on the CAN physical layer

[Jared Russell]

If I were selling this product, I'd probably update my product page and/or my page about CAN networks to at least mention that if a star topology is used, the stub lengths should be kept as short as possible to minimize the risk of reflection interfering with communications.

Debugging a flaky CAN network is one of the least fun "learning opportunities" in FRC. Having done so in the past, I'd personally be hesitant to deviate from a linear bus without a good reason, and in that case I'd try to keep my deviation as small as possible.

[cbale2000]

We ran our robots CAN in Star Topology last year and didn't have any issues with it. The only problems we did run into were related to wiring and not the network itself (and the wiring issue was fixed when we went through and properly soldered all the connections).

Having previously had a robot where a single faulty CAN connection disabled the entire robot for the match on several occasions (courtesy of ineffective quick-disconnects) I can say I definitely don't mind the redundancy in the system. I'd much rather loose a collector or a single drive motor than have the entire machine parked in the middle of the field for a whole match.

[ollien]

Originally Posted by cbale2000

We ran our robots CAN in Star Topology last year and didn't have any issues with it. The only problems we did run into were related to wiring and not the network itself (and the wiring issue was fixed when we went through and properly soldered all the connections).

Having previously had a robot where a single faulty CAN connection disabled the entire robot for the match on several occasions (courtesy of ineffective quick-disconnects) I can say I definitely don't mind the redundancy in the system. I'd much rather loose a collector or a single drive motor than have the entire machine parked in the middle of the field for a whole match.

Hm. I'm curious as to why you didn't run into reflection issues like others have been suggesting (in both this thread and the other). How long were your wire runs?

[FrankJ]

Originally Posted by ollien

Hm. I'm curious as to why you didn't run into reflection issues like others have been suggesting (in both this thread and the other). How long were your wire runs?

Keep in mind that this is rarely works/doesn't work scenario. Below a certain level it will not show up at all. Then it is a noisy line. You start losing packets. CAN is fault tolerant so they get re-transmitted. Once again you may or may not notice. Especially if you don't have a lot of traffic on the bus. Next you start getting quirky non repeatable issues. That might get attributed to other things.

[cbale2000]

Originally Posted by ollien

Hm. I'm curious as to why you didn't run into reflection issues like others have been suggesting (in both this thread and the other). How long were your wire runs?

All of the Talons we used (about 10 total) were more or less their uncut stock length (with the exception of two which had ~6" extensions soldered on). All other CAN devices (PCM, Rio, PDP, etc.) were connected with CAN wires between 6"-12" in length. We also only used one set of wires from each CAN device (the second set from the Talons were bundled up with zip ties, kept as spares in case the main set broke).

The setup used the standard CAN termination with the roboRio and the PDP with no additional resistors added.
All CAN devices were wired to a pair of grounding bars (one for each color wire) we ordered from McMaster and connected using ring terminals. Also, if I remember correctly, the total bus useage was around 60% (though that may have changed as programmers added features).