12-09-2010 04:58 AM
12-09-2010 07:59 AM
I use the USB-8473 to simulate (and log all CAN bus data) as many 15 ECUs (J1939 at 250 Kbps), but regarding CPU usage, it depends on how you write your code. A modem low-grade dual-core computer can easily handle a 100% loaded 1Mbps CAN bus, but it depends on your code...polling in a tight loop w/o any delay will waste CPU time, and what you do with the data (i.e. screen updates) will affect CPU usage.
I have experienced problems with all NI high-speed non-XNET CAN devices in regards to reliably sending out data for an extended period of time. With my simulations (and a simplified version I sent NI), the CAN messages would run w/o problems for only for a few hours, then stop sending messages for no reason at all (no error codes). I worked around the bug by detecting when the transmit buffer would fill-up, at which point I would reset the card. NI was able to duplicate this but as far as I know, has not fixed the issue.
If you must use NI, it would be best to use an XNET card unless you can work around this NI-CAN problem.
BTW, NI CAN devices are only supported under Windows, and if CAN bus-off happens, you have to recover from the error yourself (other devices, even $5 PIC micros do this automatically).
I hope this helps,
Todd
12-10-2010 07:18 AM
Thanks Todd for sharing your experience.
I need to have my interface that suits Laptops and Desktops.
May be XNET will have to sit on the PCI / PXI.
I am also asking NI if they have closed such open issues in their subsequent releases.
cheers,
TCP
01-03-2014 08:15 AM
If you open CAN port and handle references via loop Registers you shouldn't have any problem with USB-8473.
I run my code for weeks without any problems. "ref in -> ref. out"
01-03-2014 08:52 AM
@labviewman wrote:
BTW, NI CAN devices are only supported under Windows, and if CAN bus-off happens, you have to recover from the error yourself (other devices, even $5 PIC micros do this automatically).
Note, it is a violation of the spec to have the interface automatically recover from CAN bus-off.
Per ISO 11898,
section 4.14 "bus off"
A nodes is in the state "bus off" when it is switched off from the bus due to a request of fault confinement entity. In the "bus off" state, a node can neither send nor receive any frams. A node can leave the "bus off" state only upon a user request.