Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Electrical (http://www.chiefdelphi.com/forums/forumdisplay.php?f=53)
-   -   Intermittent connection on field only (http://www.chiefdelphi.com/forums/showthread.php?t=104713)

techhelpbb 11-05-2012 18:04

Re: Intermittent connection on field only
 
http://www.ti.com/lit/ds/symlink/sn65hvd1050.pdf

The application note for the CAN bus transceiver indicates that it has a dominant-time-out circuit that should stop a software error from simply holding the open-collector CAN transmission circuit down to ground and stopping all communication on the CAN bus. (IE the microcontroller crashes and stops doing anything of value and locks up the entire CAN bus.)

However this protection circuit has a fault. It only stops the Jaguar from stomping on the CAN bus if the TXD pin from the microcontroller goes to a logic low and stays there. It does not stop the Jaguar from going crazy and simply randomly stomping on the bus by changing the logic state of the TXD pin at bad moments. (IE the microcontroller gets overwhelmed by say interrupts from the encoder and starts running around speaking gibberish on the CAN bus.)

A quote from that datasheet:
"A dominant-time-out circuit in the SN65HVD1050 prevents the driver from blocking network communication with a hardware or software failure. The time-out circuit is triggered by a falling edge on TXD (pin 1). If no rising edge is seen before the time-out constant of the circuit expires, the driver is disabled. The circuit is then reset by the next rising edge on TXD."

If something can overwhelm the Jaguar's internal processing (like the encoder can) and cause it misunderstand it's timing on the CAN bus it could still stomp out the communications of other Jaguars occasionally or even sufficiently to lock the entire bus if the Jaguar's microcontroller can just keep picking the right moments to fail to run silent on the bus.

Dropping even a few bits here and there randomly from the protocol should be sufficient to render the expected functions of the entire CAN bus essentially erratic.

More advanced CAN solutions eliminate this possibility because they are not merely drivers. They are themselves peripherals designed not to fail in this application. If your processor were to crash while driving a controller like this (and I've done it plenty of times) the CAN bus would continue to operate regardless of that failure.

For example:
http://ww1.microchip.com/downloads/e...doc/21801d.pdf

The CAN solution in the Jaguar per the datasheet:
http://www.ti.com/lit/ds/spms047g/spms047g.pdf

Does implement a controller, but it's interrupt based. So if the processing unit is overwhelmed it may not realize that it's failed to meet it's timing requirements and then bad news (from page 569):

"15.3.14 Bit Timing Configuration Error Considerations
Even if minor errors in the configuration of the CAN bit timing do not result in immediate failure, the
performance of a CAN network can be reduced significantly. In many cases, the CAN bit
synchronization amends a faulty configuration of the CAN bit timing to such a degree that only
occasionally an error frame is generated. In the case of arbitration, however, when two or more
CAN nodes simultaneously try to transmit a frame, a misplaced sample point may cause one of the
transmitters to become error passive. The analysis of such sporadic errors requires a detailed
knowledge of the CAN bit synchronization inside a CAN node and of the CAN nodes' interaction on
the CAN bus."

Also the CAN solution in the Jaguar is adaptive for timing so if you start spewing badly timed bits onto the bus then this can cause you issues (page 559):
"Once the CAN module is initialized and the INIT bit in the CANCTL register is cleared, the CAN module synchronizes itself to the CAN bus and starts the message transfer. As each message is received, it goes through the message handler's filtering process, and if it passes through the filter, is stored in the message object specified by the MNUM bit in the CAN IFn Command Request (CANIFnCRQ) register."

mjcoss 11-05-2012 19:24

Re: Intermittent connection on field only
 
This seems like the exact situation that we had. We had one of Jaguars on our shooter motor at the Rutgers competition flood the CAN bus, and since we were/are an all CAN bus robot, we were dead in the water. Why and how it got in that state, and stayed there is not clear. Power cycling the robot did not clear it. We replaced the offending Jaguar, after we replaced the 2CAN because as far as we could tell, the whole bus was dead.

linuxboy 12-05-2012 00:55

Re: Intermittent connection on field only
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1168796)
Oliver,
Still learning myself. Considering the actual implementation was for cars, I would suspect that the protocol would allow for devices to go off line without killing the whole thing. So I am wondering what actually would cause the effect described above with a loss of a single device. Having seen the internal destruction on some Jaguars, it is always possible that an internal failure could have taken out the transceiver and shut down (shorted) the bus. In that condition, I would guess it is possible for the Crio to keep attempting to transmit data and do nothing else. I do not have any data to suggest that is what happened, just that it is possible. I bet Jim Zondag would know or at least could render an opinion.

It isn't a CAN protocol problem, it is a cRIO problem that causes the problems on the CAN bus to affect the entire robot. If you take a look at the traces on the Jaguar PCB you should actually see that the two RJ12 ports actually have traces connecting the pins on both (pass thorough) such that even with a unpowered jaguar the CAN signal should still be passed through (although you will still get timeout errors).

The reason the cRIO causes problems is the error handling is expensive processor time wise especially if the errors are not handled correctly (printing lots of errors to the console and such).

Al Skierkiewicz 12-05-2012 08:38

Re: Intermittent connection on field only
 
Oliver,
If we go on the assumption that the CAN is echoed through the serial port, it is not hard to imagine that something is confusing the traffic flow there. I can't tell you the priority the Crio takes when handling serial port issues but I would guess it would be one of the more important tasks. A big flaw in the Jaguar in my opinion, is the CAN connectors facing up and having a rather large target for all kinds of trash. I have seen more than a few with aluminum fluff and usually advise the team to clean out the Jag and tape over the connector. It is of course possible for stray conducting material to simulate a dominant condition from a Jag if it gets into the right places.
If I would to have any input on a rebuild on the Jag, I would add a dip switch or jumper to turn on a terminating resistor. The current method leaves a lot to be desired on such a critical item as buss termination. I have seen far more scary teminators than good ones.

Levansic 12-05-2012 16:21

Re: Intermittent connection on field only
 
Quote:

Originally Posted by linuxboy (Post 1168763)
I have seen pictures of CAN splitters (there is a discussion about them on here somewhere), but they need terminators on each branch, and I believe the more branches you have the shorter each cable must be.

Whoa a second. The splitters change the physical topology from a daisy chain to a star. This doesn't change the party line nature, nor the end of run requirement of the terminating resistors. You still need only two 100 ohm resistors. Adding more would degrade the signal.

The resistors are there to separate the potential of CAN high and CAN low signal lines. The signal is carried by the differential of these two lines. Add too many terminators, and the signal voltage bleeds off too quickly. Remember how resistors in parallel work. 100 ohm is lower than the 120 ohm CAN spec. This helps to artificially limit cable length. If you add a terminator on every split out jaguar, your cables would have to be very short.

If you use a splitter for a more robust connection (we did), only terminate at the end of the backbone (as Mikets did) or the other side of the jaguar with the longest cable. We did the latter, because our shooter cable was longer than the rest of our backbone. The other end of the bus will be terminated by the serial adapter or a 2CAN.

-- Len

linuxboy 12-05-2012 23:05

Re: Intermittent connection on field only
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1168900)
Oliver,
If we go on the assumption that the CAN is echoed through the serial port, it is not hard to imagine that something is confusing the traffic flow there. I can't tell you the priority the Crio takes when handling serial port issues but I would guess it would be one of the more important tasks. A big flaw in the Jaguar in my opinion, is the CAN connectors facing up and having a rather large target for all kinds of trash. I have seen more than a few with aluminum fluff and usually advise the team to clean out the Jag and tape over the connector. It is of course possible for stray conducting material to simulate a dominant condition from a Jag if it gets into the right places.
If I would to have any input on a rebuild on the Jag, I would add a dip switch or jumper to turn on a terminating resistor. The current method leaves a lot to be desired on such a critical item as buss termination. I have seen far more scary teminators than good ones.

CAN is not echoed on the Serial Port, the way the Serial bridge works is the cRIO communicates with the first Jaguar in the chain using the RS232 protocol (so the first one in the chain must be powered to do the conversion). Following Jaguars converse using CAN, but all the data that goes between the cRIO and the first jaguar is in fact transfered using rs232, however, the control flow lines are not connected, only the TX, RX, and GND lines are connected, however there are both TX and RX lines so I imagine flow control isn't too much of a problem.

I agree that the vertical ports can be a pain but I can't think of a better way to do it.

I would love to see a switch for termination, I'm doing some work with DMX and all the parts I've looked at that use that have switches for termination. There are a lot of ways for a external terminator to fail, I'd like to avoid seeing that happen.

Quote:

Originally Posted by Levansic (Post 1168941)
Whoa a second. The splitters change the physical topology from a daisy chain to a star. This doesn't change the party line nature, nor the end of run requirement of the terminating resistors. You still need only two 100 ohm resistors. Adding more would degrade the signal.

The resistors are there to separate the potential of CAN high and CAN low signal lines. The signal is carried by the differential of these two lines. Add too many terminators, and the signal voltage bleeds off too quickly. Remember how resistors in parallel work. 100 ohm is lower than the 120 ohm CAN spec. This helps to artificially limit cable length. If you add a terminator on every split out jaguar, your cables would have to be very short.

If you use a splitter for a more robust connection (we did), only terminate at the end of the backbone (as Mikets did) or the other side of the jaguar with the longest cable. We did the latter, because our shooter cable was longer than the rest of our backbone. The other end of the bus will be terminated by the serial adapter or a 2CAN.

-- Len

Good info, thanks! As you can probably tell I don't know too much about using a CAN backbone, so this was an excellent read.

- Oliver

Al Skierkiewicz 13-05-2012 09:23

Re: Intermittent connection on field only
 
Oliver,
The data is still in a string from CAN to Serial and back again. They don't act independently is what I was getting at. The DMX termination is as much for noise immunity as for correct operation of the serial data. We have DMX running throughout our big studio (85 x 105) using self raising battens. Each batten has DMX running through it to the next batten in line. The DMX terminates in several places around the studio so that we can connect in controllers where needed. We have 92 battens.

DonRotolo 13-05-2012 12:44

Re: Intermittent connection on field only
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1168719)
Oliver,
From what I understand, the resistors are an integral part of CAN signaling in addition to terminating the bus. With an intermittent resistor, CAN devices cannot signal when they want to transmit data to the bus.

The terminating resistors are essential to address signal reflections, just like you'd get if you had an unterminated antenna wire.

An open circuit (=high impedance) allows the signal wave to reflect back onto the wires. These reflections can interfere with the actual data. As data rates increase, the interference has a greater impact on the data. Without the terminating resistors, eventually all the echoes would increase the bit error rate beyond acceptable.
Quote:

Originally Posted by Levansic (Post 1168941)
Whoa a second. The splitters change the physical topology from a daisy chain to a star. This doesn't change the party line nature, nor the end of run requirement of the terminating resistors. You still need only two 100 ohm resistors. Adding more would degrade the signal.

The natural topology of CAN is a star, where everyone hears everything. For arbitration to work, each transmitter must be able to hear itself as it transmits, so these are full duplex transceivers. Putting them into a daisy-chain topology is just a poor implementation method.

The resistors need to add up to about 60 Ohms. Two 120's in parallel, four 240's in parallel, the bus doesn't care. In cars, there is a central "star" node which carries a single 60 Ohm resistor in it.

If you go with a class A CAN implementation, which is very slow, you don't even need terminations, but a Class C (e.g., 1 Mb/s) is very sensitive to them.

EricVanWyk 13-05-2012 13:06

Re: Intermittent connection on field only
 
Quote:

Originally Posted by DonRotolo (Post 1169064)
The natural topology of CAN is a star, where everyone hears everything. For arbitration to work, each transmitter must be able to hear itself as it transmits, so these are full duplex transceivers. Putting them into a daisy-chain topology is just a poor implementation method.

The resistors need to add up to about 60 Ohms. Two 120's in parallel, four 240's in parallel, the bus doesn't care. In cars, there is a central "star" node which carries a single 60 Ohm resistor in it.

This doesn't match my understanding of CAN topology or signal lines. Can you provide a link to a description of the star topologies in cars? All of the systems I've used CAN in were daisy chained or vampire tapped.

Al Skierkiewicz 13-05-2012 16:47

Re: Intermittent connection on field only
 
Don,
I was suggesting that the resistors have a dual purpose, both termination and signalling. Ironically, a standard twisted pair cable has a characteristic impedance of about 120 ohms. Assuming a transmission line model, the transmitter then would see two lines (in parallel) terminated in 120 ohms in most cases. There is a famous AES paper by Jim Brown for audio twisted pairs that describes this.

EricVanWyk 13-05-2012 18:27

Re: Intermittent connection on field only
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1169095)
Don,
I was suggesting that the resistors have a dual purpose, both termination and signalling. Ironically, a standard twisted pair cable has a characteristic impedance of about 120 ohms. Assuming a transmission line model, the transmitter then would see two lines (in parallel) terminated in 120 ohms in most cases. There is a famous AES paper by Jim Brown for audio twisted pairs that describes this.

Not ironic at all! You are exactly correct. The termination resistor needs to match the characteristic impedance of the line.

If there is interest, I could write a small white paper on CAN bus reflections. I think I even have access to the right software for it now that NI has acquired AWR and their excellent simulators.

linuxboy 13-05-2012 19:33

Re: Intermittent connection on field only
 
Quote:

Originally Posted by EricVanWyk (Post 1169112)
Not ironic at all! You are exactly correct. The termination resistor needs to match the characteristic impedance of the line.

If there is interest, I could write a small white paper on CAN bus reflections. I think I even have access to the right software for it now that NI has acquired AWR and their excellent simulators.

I'd love to see a white paper on CAN bus reflections, although I'm sure it would mostly be over my head.

Al Skierkiewicz 14-05-2012 08:38

Re: Intermittent connection on field only
 
Oliver,
What we are discussing are basic transmission lines. Lines do tend to behave in certain ways dependent on the frequency in use and the characteristic of the line. When a line has a characteristic impedance (in this case 120 ohms) and the termination at the end of the line does not match the impedance of the line, some of the energy is reflected from the termination (load) back towards the source (generator). Depending on the system in use, these reflections can add and subtract with the original signal or in this case be interpreted as additional data. For our use, the length of the line is so short that reflections, when they occur, travel on the line at almost the same instant as the generator that produced them.
Where this gets complicated is we are talking complex impedance which is different than resistance (although both use the common term 'ohm' as a unit value). At the frequency we are using for discussion (1 Mb/s or 1 MHz) and the distances we are using on a typical robot, (a few feet at most) much of the complex calculations fall out. Things don't start to get hairy until the line length gets about 1/4 wavelength and above which in our case would be more than 60 feet long.

DonRotolo 18-05-2012 20:59

Re: Intermittent connection on field only
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1169202)
At the frequency we are using for discussion (1 Mb/s or 1 MHz)

Your comments are spot on Al, but don't confuse data rate with frequency, since CAN is a bursty mode. (That means CAN transmitters don't transmit all the time, but in shorter bursts of data, with some quiet time between). Our Class C automotive CAN has a fundamental at about 1.2 MHz (meaning that's the dominant frequency) with sidebands out to 9 MHz (meaning there is enough energy of higher harmonic (multiplied) frequencies to worry about), bringing critical length down to well under 10 feet.

Still not as big a problem for our robots, but you can't ignore reflections even here.

DonRotolo 18-05-2012 21:33

Re: Intermittent connection on field only
 
3 Attachment(s)
Quote:

Originally Posted by EricVanWyk (Post 1169069)
This doesn't match my understanding of CAN topology or signal lines. Can you provide a link to a description of the star topologies in cars? All of the systems I've used CAN in were daisy chained or vampire tapped.

Since CAN is a multicast / multi-master system with arbitration (see here) any network topology where everyone hears everyone is OK.

Vampire-tap is just a star network with a really long hub...

I can't give you any public documentation of how it is implemented in practice, but attached are two pieces of wiring diagram for a certain automobile with which I am very familiar that uses CAN.

In the 'white' image, the "hub" at the bottom (X30/7) is physically about 2 inches long with 10 'taps' for twisted pairs that run out to each node (I have included a small photo). The hub is used only on the low-speed* bus (125 kb/s).

For the high speed bus (500 kb/s) illustrated in the 'black' image, the 'hubs' are actually solder splices(Z37/x), which physically are a bunch of wires with their ends twisted together, crimped with a ring, and soldered.

Some implementations have termination resistors integrated in the hub, but most have them in two control units somewhere on the Bus.

*I call it Low-speed, but it is Class B, therefore "Mid-speed".

Don


All times are GMT -5. The time now is 17:53.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi