One of my clients needs to measure the loading on a CAN bus. Right now the best way I have to do this is to eyeball it on an oscilloscope, but that's not a very good measure. They're using the free analyzer software from Kvasser which measures bus loading, but in this one area the software is worth just exactly what they paid for it.
We're in a big discussion about whether they need to keep all the traffic on one bus, or split it into two for a newer product, so the loading is important.
Does anyone have any experience with doing this measurement? Got any suggestions for instruments that will do the job reliably?
Thanks.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
I didn't work with CAN lately so I'm not updated about related products, some time ago I used Vector CANalyzer and I found it a very good product. Give a look
formatting link
Quite expensive too, as far as I remember
-- bikerfab
Viaggi in bicicletta, report foto e informazioni Travelling by bicycle, report, pics and information
OP would not need oscilloscope for electrical, would he? Ohmeter seems pretty sufficient for that and it does not need to be continuously monitored since it does not change.
I understand he is asking for communication loading.
How about continuously pushing a frame with lower priority than any other real frame on the bus. Loading 0% will result in instant average tranmsmitt, loading 100% will never be able to transmitt.
If you are only interested in some loading percentage, the oscilloscope might not be a good tool, but if you are interested in congestion and latencies, the oscilloscope can give a quite good picture.
If you have a long sequence of back to back frames, then some transmission attempts are deferred due to active transmissions and with more than two frames back to back, there are most likely delays also due to lost arbitrations.
If in general, there are at least a few bit time gaps between frames, the latencies remain quite low.
---
While CAN handles nicely the arbitration between devices, there can be nasty situations within a device, when there are multiple nodes on the bus and there is a hard congestion. If a node wants to send a low priority frame and later on a high priority one, the high priority one may be severely delayed, if the low priority message in the transmitter constantly looses the arbitration to congested high priority traffic from other nodes. The high priority message will be sent only until the low priority frame finally wins the arbitration and will be sent.
To detect such situations, I have used a very simple dump program that reads a frame from the transceiver, timestamps it e.g. using the RDTSC instruction on x86, calculates the time since the previous frame was received. The printout consist of the time difference, CAN identifier and number of bytes. It is quite easy to detect back to back frames and looking at the CAN identifiers, it is easy to determine if the next transmission request was activated while an other frame was already transmitted (CAN IDs are in more or less random order and the delay time usually less than one frame time), however, if the CAN IDs are in increasing order, there are most likely quite a lot lost arbitrations (i.e. frames delayed by multiple frame times).
If there is a long sequence of increasing CAN IDs, followed immediately by a very low priority (high CAN ID) frame and followed immediately by a high priority (low CAN ID) frame from the _same_ node as the low priority frame, this high priority frame might have been delayed by quite a few frame times.
Actually, it depends on the speed of the bus. For high speed buses, you might want to hook it up to a VNA or a TDR, both of which could be considered scopes.
Communications -- we want to know how much more traffic we can lard in there before it all bursts.
--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com
Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
They're using the TI '2812, which has prioritized transmit mailboxes. The messages are sorted into priority classes, with one transmit mailbox per class.
So that shouldn't happen.
--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com
Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
One cheap and dirty idea is to take a single input pin of a micro to the CAN signal (maybe on the output side of the receiver) and write a small loop to scan the pin. If you count how many scans you made, and how many times the bus was in dominant state, and what percentage of of time a typical message drives the bus dominant I imagine you can arrive at a decent number. That last part probably isn't trivial. You could just guess at 50%, or use the scope to get a better idea.
Thanks Daniel. They have an ancient version of the software -- the next time I'm there I'll try a newer one.
Do you know how accurate the measurements are if the interface _doesn't_ have the built-in CPU? I know that most of the interface cards they're using are PCI cards that have (I think) just the Intel CAN chip and not much more -- how can I tell that an interface has its own CPU without ripping it apart?
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
You can see the hardware type in the Device Manager, or in Kvaser Hardware (in the Control Panel). PCIcan and PCIcanx have no CPUs, just an FPGA (or an AMCC5920) and the SJA1000 controllers. PCIcan II and PCIcanx II, otoh, have on-board CPUs.
The accuracy of the busload measurement when using PCIcan (or PCIcanx) is probably +-5% (i.e. if you read 30% the real value should be between
25 and 35 %) but it's in the hands of Windows... If the values are consistent and don't jump up and down they are probably better than that.
Sounds like they have not done proper averaging of the measured values. If you have a 1 Mbit/s system, the frame is about 100 us long. If you sample this every 200 us and there are occasionally two frames back to back, you would sometimes conclude that there is 100 % loading and at other times 50 % or 0 % load. Averaging over say 1 s, would give a better picture of the average load (but of course not about latencies).
With SJA1000 type controllers with 64 byte FIFO, no frames will be lost, even if the interrupt would not be serviced within 7 ms at 1 Mbit/s and 100 % bus load. When the application finally empties the FIFO and while doing so timestamps the messages, it would appear that all messages would have been received within a millisecond or less indicating over 100 % bus load. However, the next time the FIFO is examined, there might be no or only a single frame, dropping the load.
For timing analysis the use of CPU on the PCI card does not help a lot, unless the reception is timestamped at the card and the time stamps are available to the analysing software.
However, if the timestamps are not available to the analysing program, but instead the application has to take the time stamp, this is just a controller with a huge FIFO (several kilobytes) from timing analysis point of view.
When no frames are lost, the simple SJA1000 or a PCI card with a separate CPU is used, the bus load averages would be the same, with a sufficiently long averaging period.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.