RE: CAN Inspector: a CAN node to sample the CAN bus waveforms
"John Dammeyer" <[email protected]> Sun, 13 Mar 2016 10:38:18 -0700
| Newsgroups | gmane.comp.hardware.bus.can |
|---|---|
| Message-ID | <[email protected]> |
Hi Michael, It's possible, depending on the environment and failure modes, that you will get a warning that something is wrong. Putting the Error counter information or whether a node is Error Passive as part of periodic status messages will certainly help. Like the other's though, I lean to an external device. Here's why. I just purchased 3 sets of 50 ring lights from the BC Government Asset Recovery. http://www.autoartisans.com/rings/Barge1a.jpg Each came with a cable that had 50 connectors Tee'd off in the last 35m of cable. I laid 50 out on my deck over Christmas and re-addressed lights so they had the ID's 2 .. 51 and connected them to a small dsPIC based controller I designed for a number of different kinds of lights. Once January 1, 2016 arrived I set the intensity output to 0 but left them powered. About two weeks ago as we were driving away I noticed the string of lights was all a dim green. That's the value I'd programmed the lights to be if they lost CAN communications. On the Rings Project regardless of the default colour every lamp was a dim white so we'd know if a lamp filled up with water or failed in some other way because it would either be dark or dim white while the others were coloured. When we got back that night the lights were all off again. A few days later it happened again and this time it stayed. We'd had a lot of rain so clearly either a lamp or a connection had water ingress along with temperature changes to cause the CAN bus to die. To eliminate the controller I connected a lamp in place of the long cable. It worked so it wasn't my controller. I measured the resistance of the cable connections and found around 10 Ohms to ground on the CAN_H line and about 130 Ohms to ground on the CAN_L so clearly there is a short on CAN_H that disabled CAN communications. I removed all the lamps, after I pulled back the insulation on the termination resister for inspection. No luck. The defect is somewhere in the cable. Next I replaced one lamp at the end by the termination resistor and it was still green when it should have been off. I then started flexing the cable one connection at a time and about halfway down the system started working again so I have a rough idea of where the problem lies. It's now been functional for a week. My next step, once it stops raining, is to bring out my R&S 3GHz spectrum analyzer and try the TDR feature to see if I can see anything. The problem will be a long 25m cable with no defects and then 50 T connections. I'm not sure I'll be able to detect a short circuit that has vanished. I could add software to the master to periodically query nodes error status. The protocol is master/slave so the nodes don't send unless queried. Perhaps there will be a hint of problems to come with one or two nodes that have problems but a 35m bus with a problem in the middle isn't easy to fix. John Dammeyer > -----Original Message----- > From: Michael Ashley [mailto:[email protected]] > Sent: March-13-16 1:36 AM > To: John Dammeyer > Cc: [email protected] > Subject: Re: [CANLIST] CAN Inspector: a CAN node to sample the CAN bus > waveforms > > > Hi John, > > Thanks for your comments. > > > The first question I'd ask would be who gets this information and how do > > they get it? > > My CAN bus connects to a Linux computer that has an Iridium modem, so > this gives me contact from the outside world. > > > and there's no way to add functionality to it in the form of > > an scope module? > > Well, I could add a scope module. Maybe that is the smart thing to do. I just > like the idea of a simple CAN node to do the job. And our CAN nodes (based > on the AT90CAN128) survive cold-soaking to -80C. > > > The problem you face is if your CAN bus is crippled due to a physical issue > > any scope device that is on the same CAN bus becomes useless. > > Yes, that's true, but so far all my issues have been loss of redundancy, not > outright failure. > > > Perhaps you could add some details as to how you would report the bus > > information? > > After grabbing 1 kB of bus waveform, the CAN node could be instructed to > download it across the CAN bus 8 bytes at a time. The CAN node would need > some moderately clever software, e.g., perhaps repeatedly grabbing 1 kB > samples until one of them happens to contain the leading/trailing edge of a > bit. I'm also thinking of incorporating a high-speed pulse generator to make > a "poor man's TDR" (or perhaps it should be called a "crazy man's TDR" if this > project gets out of hand!). > > Regards, > Michael > -- > Professor Michael Ashley Department of Astrophysics > University of New South Wales http://www.phys.unsw.edu.au/~mcba -- Archives and useful links: http://groups.yahoo.com/group/CANbus Subscribe and unsubscribe at www.vector.com/canlist/ Report any problems to <[email protected]>