|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
||||
|
||||
|
Re: Com wire
Quote:
The seller admitted the mistake and is resenting the wire. You should be okay. |
|
#17
|
|||||
|
|||||
|
Re: Com wire
???
|
|
#18
|
||||
|
||||
|
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. |
|
#19
|
|||||
|
|||||
|
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. |
|
#20
|
||||
|
||||
|
Re: Com wire
Quote:
![]() CAN is pretty robust. |
|
#21
|
|||
|
|||
|
Re: Com wire
Quote:
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. |
|
#22
|
|||||
|
|||||
|
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.
|
|
#23
|
||||
|
||||
|
Re: Com wire
Quote:
-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 Last edited by Sparks333 : 14-01-2016 at 19:37. |
|
#24
|
||||
|
||||
|
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. |
|
#25
|
||||
|
||||
|
Re: Com wire
Do you have a source for this? Particarly one that delves into more of the specifics of the FRC CAN protocol?
|
|
#26
|
||||
|
||||
|
Re: Com wire
Quote:
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. |
|
#27
|
||||
|
||||
|
Re: Com wire
Quote:
|
|
#28
|
||||
|
||||
|
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. |
|
#29
|
|||
|
|||
|
Re: Com wire
Quote:
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. |
|
#30
|
|||
|
|||
|
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. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|