Re: Com wire
 

The seller admitted the mistake and is resenting the wire. You should be okay.

Re: Com wire
 

???

Re: Com wire
 

You want to ensure that both lengths of the positive and negative wires in the differential pair are the same.

It's common practice to ensure you don't have data skew.

Re: Com wire
 

Kiet,
At higher data rates that is true. At 1 MPS, the wavelength is approaching 1000 ft. so you would have to fudge the twist by several feet to skew the data.

Re: Com wire
 

Definitely true. I've been working on much higher speed busses for too long :)

CAN is pretty robust.

Re: Com wire
 

Given the length of wiring in FRC robots, reflections are not an issue. Large industrial systems are another matter.

As for twisting and external noise, running the wires together is what allows it to be robust and to cancel out the noise with the differential receiver, not the twisting. The twisting creates an inductance in the line, running the wire in parallel (twisted or not) creates capacitance between the two. The inductance added by the twisting helps to cancel this out.

Re: Com wire
 

At 1 MPS, the wire all by itself has inductance. The series inductance and the parallel capacitance sets the line impedance. I use twisted pair shielded cable for a variety of applications, mostly audio. Typical cable has an impedance that is approaching 60 ohms with a parallel capacitance of ~23pf per foot. Ironically, a low impedance transmitter sending into the bus will "see" a 60 ohm load when the bus is terminated at both ends. This is similar to the twisted pair the phone company has used for more than a century. They found that terminating in 600 ohms (about 10 times the actual line impedance) they were able to minimize line loss while getting a flat response if they maintained a source impedance of the same load. I linked a TI CAN document in another thread that shows the waveform distortion with mis-matched loads.

Re: Com wire
 

Hate to disagree with you, Al, but CAN as a standard is supposed to be a multidrop communications protocol - it's specifically designed to be wired in parallel. In fact, most CAN devices don't have termination built in; they expect termination to be included at either end of the bus. Now for the caveat: I believe the variation of CAN FIRST uses is called Falut-Tolerant CAN, which has terminations at every endpoint, and expects the daisy - chained connection topology implied by the in/out ports of the speed controllers. This means there is a termination at every endpoint, which, when wired in parallel, drastically reduces the overall bus resistance and causes the voltage swing to drop (CAN, like most differential signalling schemes, is current driven instead of voltage level driven). So, while I agree FIRST teams should definitely not connect their devices in parallel, CAN in pretty much any other application is designed to be used as such. Just so none of our bright young minds gets the wrong idea about CAN.

-Sparks
Edit: The Talon SRX manual recommends a parallel linear wiring topology. They're not doing any crazy - just vanilla CAN. Absolutely wire your CAN in parallel

Re: Com wire
 

FRC CAN is DW_CAN (aka Dual wire CAN, ISO11898 ).
There are only two termination points, each end of the cable (120ohm).
This means one long transmission line, where each ECU taps in (with a small stub length).

FRC CAN is NOT LSFT-CAN(aka Fault Tolerant CAN, Low Speed Fault Tolerant). Fault-tolerant means something very specific.

The two green wires (Talon) and two green connectors (PCM/PDP) are common. Same is true for yellow. So this produces one long bus-harness that each device taps into (albeit internally, but it is a tap). That's kinda why I never really liked the term daisy-chain, but as far as the person wiring it all, it does all hookup in that fashion, so I'm okay with it.

Sure we could put one single small pigtail on every CTRE CAN Device and force teams to create a bus harness (like in a car) but I think the solution we have now is more robust.

Re: Com wire
 

Do you have a source for this? Particarly one that delves into more of the specifics of the FRC CAN protocol?

Re: Com wire
 

http://www.ctr-electronics.com/pcm.h...abs_tech_specs
http://www.ctr-electronics.com/contr...abs_tech_specs

Look at the technical specifications.

More detailed information would be great. I'm thinking of adding a CAN device to the bus, but I'm having trouble getting the timing just right for 1Mbps.

Re: Com wire
 

A lot of the phone wire usage has stopped with the new CAN interface. Before 2015, the only option for CAN motor controllers, the Jaguar, required you to use phone cable-esque connectors, hence the use of phone wire. Last season, with the new CAN interface used on the Talon SRX, we just used some yellow and green 22AWG stranded core wire, twisted together by hand. The beauty of CAN is that it's not overly sensitive, as long as you have it terminated properly. If you're looking for a way to connect CAN lines together, I suggest these. They are tool-less, easy to use, and they hold well.

Re: Com wire
 

The first documentation in the Crio days suggested regular 6 wire flat phone cable for the canbus. Only two wires is needed for the CAN but the RS232/can converter was in the first Jaguar in the chain so you needed 3 wires for the RS232 to the Crio. (unless you where using the Cross the Road ethernet/can convector) The CAN physical layer standard (CIA 102) allows flat or twisted pairs. Both NI and TI have application papers saying that short stub lengths connecting the devices to the daisy chain is OK. I know a lot of people blamed the com wiring for motor control problems back in the day, but I expect it was more programming issues. The FRC implementation of CAN had a lot of gotchas in it. Not yet mentioned is stranded wire is better than solid from a physical stand point.

So what is my point? The com wiring is pretty forgiving, especially the short length in you typical FRC robot. But if you do right from the start, it is not one the things you have to trouble shoot when having robot problems. You can use flat or twist pairs. My preference is for twisted. You can get away stub lengths that approach what looks like a star configuration. My preference is to keep it flat as possible. You want to avoid running the CANBUS parallel to the motor control wires. You want to securely splice the CANBUS wire together either using connectors or terminals. Loose wires will cause com errors.

Re: Com wire
 

You mean other than my faint memories?

You can get all of the published documentation, including the protocol documentation:
1. Goto http://www.ti.com/tool/rdk-bdc24-cd, click the 'Get Software' red button, fill out the export regulatory stuff, and download the last distribution.
2. In the Folder, you should find Software > StellarisWare > docs > SW-RDK-BDC24-UG-xxxx.pdf (where xxxx was the last release #).

Section 4.1 contains the partitioning of the 29-bit MessageID. Note that since the most-significant bits of the message contain Device Type and Manufacturer, CTRE can, and probably has, defined their own API. The APIs in that document were for Jaguar.

Re: Com wire
 

We used a high quality 22 gauge stranded wire that we twisted ourselves, the CTRE CAN connector and crimped ferrules with reasonable strain relief using shrink tubing. Zero problems to date. While the CTRE connectors are a bit unwieldy, the familiarity with the Weidmueller connectors made that choice clear for us.

We used short stubs to the bus per this diagram that I just found which pretty much summarizes all that I learned in the below documentation.

I found several helpful resources just surfing around the internet.

Honestly, the Wikipedia article is pretty good.

One in particular that I really found helpful was Understanding and Using the Controller Area Network by Marco Di Natale posted at berkley.edu It is long, but it references many standards documents and gives a good understanding of how it all works.

If you really want to get your geek on try http://www.can-wiki.info/ which has an excellent network of links.