Correct, one set of wires from the speed controllers would not get used.
As to how to wire it, here’s a pair of diagrams I made a while back for this:
One would have to ensure that the ends of the two unused wires are suitably insulated so they don’t short on something. If they do, it will take down the whole CAN network.
This is really a response to the last post by @Chadfrom7226.
Yes, this is correct. In the past we simply left the female PWM connectors that the controllers come with on the unused set of wires and spooled them up to avoid any issues (technically, you could just trim off the extra wires, but we kept them as spares in case something happened to the pair we were using). Covering the unused wires/connectors with electrical tape is also a good practice.
1 Like
On my younger son’s team, we used these latching connectors from Hansen Hobbies, or possibly the same part from DigiKey. We used the same crimping tool as for crimping the contacts onto PWM cables. We had zero problems with these in the recommended daisy-chain CAN configuration.
Those worried about a CAN connection going bad and disabling part of their robot need to see if they really need to improve their electrical construction standards. It does not take much effort to get connections with a level of reliability that far exceeds what is needed for an FRC robot. If the quality of the workmanship is such that one is worried about losing even one peripheral (motor controller, PCM, PDP) then one should be worried about the connection at the Roborio where a failure means one loses everything.
2 Likes
Note that FRC CAN is a bus topology – if you open up a talon, the two yellow wires are directly connected to each other, as are the two green wires. The electrical connection from there to the guts of the talon is short, but it’s still a bus. (There is no forwarding or filtering of data on the bus from one pair of wires to the other – that’s just a direct electrical connection.)
Once the distance of the connections from the bus to you CAN device starts to be long enough, you do start having problems with things like signal reflection, termination and so on. But, short connections should not be an issue. (How short? Dunno. I’ve read that a foot is fine.)
We’ve used lever nuts for a few years with success
Is there a benefit to using a Bus over a Daisy Chain or vice versa. Is the amount of cable management the same? Also, does anyone have a picture of how you would use the pwm connectors that come with the esc?
So, technically speaking, the daisy chain topology used by CTRE (and Rev?) is actually a bus. Both wires of each color are terminated in the same location inside each device. So daisy chaining then together forms the trunk of the bus.
That being said, this bus implementation ends up largely sacrificing one of the key advantages of a bus topology (the ability to lose connections to an individual node without compromising the entire bus). So teams have used other bus implementations in order to centralize their bus trunks further.
I’m on mobile currently, so I can’t really create a diagram to help explain further at the moment. But we use wire taps in our implementation, and others have used other bus products.
Is this legal? I thought the Robot Inspectors always looked to make sure things were daisy chained
If I could make it a bus, it would have saved me a bunch of headache from last year. I could more easily swap out motor controllers/devices
1 Like
Yes, it’s legal.
Sweet, Thanks! In that case, I would definitely buy some of those CAN bus strip things for my team if you were to make them @zog
It is legal, but make sure to do some reading on best practices for bus-style wiring. Most important is that any branch off the main bus should be no longer than ~12”. There’s plenty of discussion on here about the pros and cons of bus vs daisy-chain and how to make a bus properly.
So I was looking through the falcon 500 manual and noticed that it said that they recommend using the daisy chain style connection. You can use the bus style but they recommend daisy chain style. I’d say after reading this it’s best to see what the manufacturer suggests as well.
That’s because daisy chains are hard to mess up - go from the RIO to the PDB, the terminating resistor stays in the default position, and the wires can be as long as you want at each step.
Because you’re not designing any branches off the bus, you can’t mess up any branch designs.
Bus architectures are easy to mess up. Branches shouldn’t be over 11", and you still need terminating resistors at each end of the bus. If the CANbus runs several feet up into a manipulator structure, for example, you want* the terminating resistor to be up somewhere in that structure rather than the default PDB location.
*(you might be able to get away with longer branches and alternate locations of termination resistors, as long as there are exactly two resistors in the system. However, this is risky; the CAN system is digital and fairly noise-tolerant until it completely fails - and failure due to bad CAN architecture will take a long time to diagnose and fix.)
I normally explain it with a “hallway” analogy - all the devices are connected to a single electrical “hallway”, and they all shout messages into that shared hallway (marked by termination resistors). In a daisy chain, the doors all open directly into the hall. In a bus, there’s a bit of a corridor before you get to the door of the device; if the corridor is too long (iirc over ~11"? Something about 1Mhz waveforms? I’m not an EE, I just play one on the Internet), it gets hard for a device to hear and be heard.
3 Likes
The CAN network (redundant I know as the N in CAN means network) is designed for a “true” bus topology, which is to say, a daisy-chain topology, where the network consists of two wires, and each device is directly connected to that network through short (ideally zero-length, but accepting up to 12in/30cm/1ns stubs) connections. The “bus” topologies claimed here are really “star” topologies, especially if the nodes along the bus are separated by distances shorter than or comparable to the “spur” lengths. They’ll work great until they don’t, at which point your robot won’t work; I don’t know exactly where that point is, but I certainly don’t want it on my critical path. YMMV.
Bottom line: daisy chain, unless you make a true long bus with really short spurs.
4 Likes
The point at which it stops working is somewhere around 10 meters of total bus length. I can give a super geeky explanation as to why, but the general rule is that the shorter the bus the less topology matters.
If you keep the cable short (like less than 3-5 meters total length including all the stubs), you can pretty much use any topology you want. Reflections happen but they don’t last long enough to cause issues.
Ideally, of course, you’d want one daisy chain, starting at the RIO and ending at a 120 ohm resistor, with everything else in between. But don’t sweat it if it’s not ideal.
Where you get into trouble with CAN is:
- forgetting to put the 120 ohm resistors on the bus, or putting too many (there’s one in the RIO, and the PDP has one that you can enable or disable. If you disable the one in the PDP, you need one somewhere else. If the PDP one is enabled - don’t add any more!)
- swapping CANH and CANL anywhere (it’s particularly hard to find if they get swapped twice, ask me how I know)
- not having good solid connections
- not twisting CANH and CANL together
- accidental shorts of CANH or CANL to another signal or each other
- having two (or more!) devices with the same CAN ID
4 Likes
Just chiming in to say that this isn’t a hard restriction that will guarantee robot failure if you break it or anything. In general “long” CAN connections in FRC are a lot more robust than people give them credit for.
3 Likes
This is an overgeneralized statement, and is not really true. The second diagram posted by @cbale2000 shows something resembling a “star topology,” but that is not the only bus layout possible. And even that layout may well meet the standards as a bus, so long as branch lengths are maintained.
This is a diagram of a CANbus
That style bus is fully achievable WITHOUT daisy chaining components together. CTRE’s daisy chain implementation of that bus is only one of many possible implementations, and ends up creating numerous additional connections (aka potential failure points) along the trunk of the bus. It is fully possible to create a bus layout (and one that complies with (and that complies with ISO 11898-2) without daisy chaining components together.
One such implementation is by use of wire taps, which allow you to branch off a the trunk of the bus running between the roboRio and the PDP. This perfectly mirrors the diagram I posted above as a CANbus, and is NOT a star topology. The user still has to accept responsibility for managing branch lengths, but so long as they’re not adding extenders beyond the pigtails provided by CTRE or Rev, they will comply with the maximum branch length specified by Table 11 in 11898-2*
*It’s also worth noting that the notes in that table specify that other topologies may be used so long as the Vdiff is maintained at each node.
1 Like
Lil_Lavery,
The wire taps you linked to look really nice - have you used them before? We tried the AndyMark ones (https://www.andymark.com/products/connector-t-tap-22-16-awg-red-qty-10) and had issues with the wire getting damaged by the vampire connection.
We used the taps I linked on our robot in 2019, and had no issues with them. It is likely that we will use them again in 2020. You do have to be mindful of the force required to install them, but we didn’t have any damaged wires that I am aware of.
I wasn’t aware AndyMark carried any wire taps until your post, actually.
1 Like