Automotive and Embedded Networks
Difference between xnet and ni-can
- last edited on by
Content Cleaner
The cheap 8473 has no hardware timed retransmit, and it has no built in support for channel (signal) API. It is essentially a dummy device similar to a serial port where you can read things, and write things immediatly. If you don't have tight timing on frames that must be sent out, say once every 100ms and if it were 150ms things would be fine, then you might be able to get away with it but you'll need another library to convert from frames to channels and back. Luckily there exists one already.
https://forums.ni.com/t5/Example-Code/CAN-Frame-Signal-Conversion/ta-p/3534000
The more expensive XNET option is much more flexible. Allowing for importing databases into the hardware which handles the conversion, there are multiple ways to read and write frames or signals and multiple sessions can be open for the hardware at the same time. There's hardware filtering, cool buffering for reading/writing.
Here is a presentation I did recently for a user group going over some of the differences but it is more meant to be a into to CAN as much as an into to XNET.
If it were me I would not use the 8473 for any project that is supposed to be scalable. I realize it is much more costly but it comes with the benefits that make developing and upgrading it easier. But if you are unfamiliar with the API you may want to get your feet wet with some examples. It does things in a different way than the older NI-CAN does and that takes a little getting used to.
Hello and thanks for answering 
I tend to consider that going the path to learning another library (NI-CAN) and trying to pack your conversion tool into a DLL to call in CVI (including installing all necessary software like that VIPM you mention as a prerequiiste) takes me more than the extra cost of using the XNET device 
One item I would like to discuss a bit is timing: the system I am to manage communicates with a device at a time (actually they're battery managers - BMS) which sends 3-4 different frames each scheduled on 100 msec. I'm not interested in operating in XY or waveform, I can stand with single point but I must honour the scheduling, while maintaining control on my equipment on the same time. Is the 9862 capable of acknowledging the frames from the BMS or has the ACK to be issued from my program? That's just to understand how much care is needed in designing the system. Messages from me to the BMS are very rare, if any.
Acks of a frame are handled by the hardware, the CAN tranceiver will tell the other nodes on the bus that the message was seen. Then that message will sit in a buffer waiting for a read from your software. Then an array of frames will be returned, which is the frames that came in since the last read.
If there is more hand shaking involved neither hardware gives you a good solution, simply because software timing is then involved. Like lets say a node sends a frame as a request, and you need to send a reply which is another frame within some amount of time. Your PC will need to be polling the bus looking for frames, and sending the frames that it was requested to send. The only way around this is a real time or FPGA system that is embedded.
I have not yet decided on the hardware to choose but I went to my customer and he said that part of the deveices he wants to connect are CANOpen 
Does the 9862 module handle CANOpen protocol too? Do I need a different device or an additional software library or what? And does it exist a module that handles both protocols (not contemporary, of course)? Sorry for bothering you, but I stumbled into this CANOpen new and I'm a bit lost at this!
