|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
My advice would just be to not do that. I get that you might have one talon on one end of your bot, and another talon on the other end. But can wire is so thin anyway, just run a really long strip. No point in introducing points of failure into an already relatively "fragile" system.
|
|
#2
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
When you split a terminated bus like this you create the probability of reflections. If you look up a tool called TDR:
https://en.wikipedia.org/wiki/Time-domain_reflectometer It is not recommended to do this. Certain patterns of communication traffic might become garbled. Resulting in intermittent errors you can't see a cause for. Leaving an end unterminated is actually worse, as well would be using the wrong value terminators. Last edited by techhelpbb : 24-09-2016 at 15:40. |
|
#3
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
Quote:
Generally RF rules apply if you're at high frequency (such as CAN, ethernet, or Wifi/Bluetooth) or you're over a massively long distance (such as a 10 mile power transmission line). TLDR: Don't branch CAN wires, while it seems like it will work in reality it's asking for trouble. |
|
#4
|
|||||
|
|||||
|
Re: Can I branch the CAN to go to two separate places?
If the entire collection of CAN devices and wiring is physically small enough, you can get away with just about any topology without it breaking.
My advice: don't tempt fate. Use the system as specified and as designed, with a single "chain" of devices each having their own internal very short tap on the bus. Troubleshooting will be much more straightforward. |
|
#5
|
|||
|
|||
|
Re: Can I branch the CAN to go to two separate places?
The CAN standards allow "star" configurations for low data rates over long distances. For your peace of mind, it is probably best to avoid using the star configuration if it can be avoided. With the (low) quality of the wiring I have seen in many FRC robots, a bad connection is at least as likely to be the real cause of their CAN Bus problems.
It is the high edge-rate (short rise-time and fall-time) of the signal that directly leads to reflections, not the data rate. Of course, as the data rate rises, faster edge-rates are required to maintain signal integrity. Many of the CAN transceiver chips have the ability to reduce the edge-rate to minimize reflections when running at lower data rates. Without looking at CTRE and NI's schematics, it is difficult to know if they are using such a feature. The length of the various line lengths determines whether a reflection causes interference or not. With the rule-of-thumb signal propagation delay of 2 nsec/foot, your CAN wiring would have to be pretty long (in the order of 100 ft.) for it to have an effect on a 1 Mbps signal, longer than one could reasonably put on an FRC robot. If one wires the CAN Bus with the PDP "at the end of the chain" then one should always have the terminations. With a star configuration (or multi-star), the PDP should still be the furthest from the RoboRio. Quote:
|
|
#6
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
Do NOT do this! Your goal is to make the robot as robust as possible. One way to make the robot more robust is to wire the power, sensors and control lines per the recommendations of the relevant standards committees or OEMs. Use the correct tools and the correct techniques then test everything over and over again.
Could you get lucky? Sure Is it worth it? No, a hundred times no Is it a "professional" thing to do? No buyer would sign off and pay you for something wired incorrectly. You might be thinking "if it works then who cares"? This is where engineering ethics comes in - you are not compliant and you know it. So fix it! That is my two cents. I've delivered many dozens of high performance systems. And I've been on the receiving end of non-compliant subsystems and made them fix everything (using their own money). |
|
#7
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
QFT - I should have mentioned this. But on the roboRio the CANbus is running near full-speed. You would have to slow the bus down and all kinds of things might stop working (PCM control loops not closing, not enough bandwidth to query/set Talons etc).
|
|
#8
|
|||
|
|||
|
Re: Can I branch the CAN to go to two separate places?
Quote:
What do you mean by "slow the bus down"? Do you mean a slower data-rate or do you mean a slower edge-rate? |
|
#9
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
That's how I was taught in Electromagnetics class. Of course resistance is still present, but it's not 100% of the picture and looking at it alone will lead to results more puzzling that the statements I made.
Quote:
Quote:
Otherwise, obviously I agree. |
|
#10
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
Quote:
Since CAN signals are NRZ digital (with the 1&0 voltages dependent on the PHY layer design) they represent a typical digital square wave of odd-integer harmonics with differential signal. The issue, and the TDR neatly demonstrates this concept, is that an analysis over time (not at any given instant) can produce reflections when the termination or legs (even the legs of the circuit inside the devices) get too long. So it's not merely the real component of the terminator resistance at work. It's the capacitance, inductance and impedance of the circuit as a whole. (Active AC components tend to introduce mathematical imaginary or polar numbers into circuit analysis so when I say real resistance I mean DC resistance.) Long story short - I don't think anyone in the last few posts disagrees that students shouldn't follow the guidelines. No one wants to have intermittent phantom problems that only happen when a certain pattern of traffic is sent over that CAN bus. I don't think I've ever seen a FRC team test their CAN bus with a BERD/BERT even though the speed is pretty high on that circuit (a T1 digital telephone circuit is basically 1.544Mbps and these are usually tested with something like a T-BERD). There's limited rational reason in the last few years of robots that the CAN bus configuration as recommended can't be achieved. Even if you somehow put a Talon 14 feet up an end-effector you could avoid doubling back with the CAN buss wire (which given you'd be running the power up there seems sort of strange) by simply ending the buss up there. There are some good examples of why a star configuration has advantages if you suspect your devices might fail to be connected. However, like in computer networking, how far does one want to go to get a star network without the circuit implications? Active CAN hubs? How about a CAN switch? (NOTE: I am making no suggesting the 2 links I provided are FRC legal or even recommended, just pointing out that such devices exist with evidence.) Last edited by techhelpbb : 27-09-2016 at 09:51. |
|
#11
|
|||
|
|||
|
Re: Can I branch the CAN to go to two separate places?
Quote:
Related notes, from discussions with CTRE and beta testing the CAN BUS is fixed at 1Mbps (raw rate, not payload) and will not auto negotiate down. I don't think this has changed since then. Related note if I'm understanding the CAN spec correctly, if a star configuration is used, the termination resistor values need to change so the effective resistance is still ~100 ohms. This would be interesting in conjunction with the fixed values inside the roboRIO & PDP. |
|
#12
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
Quote:
one implies the other (but not really sure what you mean by edge rate) |
|
#13
|
|||
|
|||
|
Re: Can I branch the CAN to go to two separate places?
Quote:
Most of the CAN transceiver chips, like the ones I am using at work, are rated by their manufacturers for operation up to a maximum data-rate of 1 Mbps but that does not mean the system they are installed in are running at that data-rate. Data-rate is a measure (bits per second) of the instantaneous rate at which the data is transmitted over the bus, when there is data. One can also measure the average data-rate taking into account the time when the bus is inactive (unused) and any error correction made necessary due to noise or other problems (resending of packets). Edge-rate is a measure (volts per microsecond) of how fast the high-to-low and low-to-high state transitions take place. It is the high frequency energy contained in fast transitions that causes reflections. It is possible to have a CAN bus system with a low data-rate (say 1 bit per second) that has significant reflections because there are impedance mismatches AND the edge-rate is very high (the parts I am using have a spec of 35 nsec. minimum). Once a CAN Bus system is assembled, the line lengths, actual line characteristic impedances, actual termination resistance values, impedance mismatches and actual edge-rates are what determine what the peak voltage and the duration of the reflections will be. The characteristics of the reflections will generally remain constant unless the system is changed in some way. The CAN Bus receivers are connected to a circuit (usually incorporated in the microprocessor) that roughly synchronizes with the bit edges. The state of each bit is sampled in the middle of the bit period, often multiple times. As long as the reflections after a bit transition has died down by the middle of the bit period, the detected state of the bit will be accurate. This technique was developed a long time ago to make it easier for communication systems like CAN Bus to minimize the effects of reflections in the system. Many of the CAN transceiver chips can be set to produce lower edge-rates, often using an external resistor. This allows the system/circuit designer to reduce the energy in the reflections (and hence their peak voltage and duration) in the system based on his/her knowledge of the length of the transmission lines (bus length), the amount of impedance mismatch expected and the maximum data-rate required. The long and the short of it is that the CAN Bus standards were set up with the ability to tolerate some amount of reflections since the people developing the standards understood that the world is not perfect and that the systems will not be manufactured and installed perfectly. Therefore, while it is best to avoid using the star configuration since it is non-ideal, it is not "certain death" to use a star configuration or to add a branch as long as one is taking some simple precautions. Because of the inherent robustness, CAN Bus systems have found many applications outside of the original intended use in cars. Last edited by philso : 27-09-2016 at 11:01. Reason: missed a few words |
|
#14
|
|||||
|
|||||
|
Re: Can I branch the CAN to go to two separate places?
From looking at the CANbus driver code
Quote:
Quote:
Quote:
Quote:
Quote:
|
|
#15
|
||||
|
||||
|
Re: Can I branch the CAN to go to two separate places?
Quote:
Quote:
Quote:
Quote:
For an example, consider a branch on a CAN Bus that is 10 ft long to reach a Talon SRX that is mounted on some arm on the robot using the same wire as the rest of the system. With a 1 Mbps data-rate, the bit time is 1000 nsec. With a rule of thumb value for the propagation time for a pulse down the transmission line of 2 nsec/ft, a 10 ft long branch would cause a reflection that returns in 40 nsec. after the bit transition that caused it. Assuming that the proper termination resistances at the RoboRio and the PDP are in place, it is reasonable to expect that the amplitude of the reflections would have diminished to become insignificant by the middle of the bit time, 500 nsec. after the bit transition. Based on the calculation shown above, I would determine that the risk of using the 10 ft long branch is minimal. Since each person/team is willing to accept different levels of risk, I can understand if you choose not to use such a branch. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|