Okay so in Part 1 we discussed the various types of CAN, how they differ from serial, and some hardware options. In Part 2 we talked more about the data that is sent to and from devices called Frames. And we also talked about why CAN is so robust of a bus, with built in support for message priority, CRCs, and acknowledgements. In Part 3 we are going to talk about NI's two main APIs for reading and writing CAN data, NI-CAN and NI XNet. XNet is a large topic, and will also be covered in more detail later.
Here we see that we first open a session to the hardware to perform a Frame In Stream. Then configure the interface, and then we sit in a loop reading the data, and displaying it as an array of frames, and then convert it to a more easily viewable table. Notice the 100ms loop rate which doesn't cause lost frames, because the frames that are read in those 100ms will be sitting in the hardware buffer, and transferred over on the next read. This read has several optional inputs that make for some useful use cases, like setting the number of frames to 1 and timeout to 100ms. This will cause the read to take at most 100ms, but it will return sooner if a frame is seen by the hardware.
The frame out example is quite similar.
Here we again configure the session for a Frame Out Stream, configure the interface, and then once every 100ms we send out 2 frames. This is using software timing, and the actual amount of time between writes may vary since this write will write it as soon as the bus is idle.
NI-XNet is a pretty advanced API. Which is why I'm going to dedicate an entire post on the API and some of the cool custom things it can do later. But for now just know this is really just the tip of the iceberg when it comes to what this API can do. Database management, signal and frame conversion, LIN, FlexRay, and sessions types are some of the other topics that you can go into when discussion XNet. Some of these topics will be covered in much more detail later. XNet also supports things like echoing written frames, single shot transmission, and high voltage wake-up all through property nodes on the sessions that are opened, or the interface being used.
The example is pretty straight forward and a great starting point for a more complicated application. You'll notice that the NI-CAN API can write a single frame, at a time as shown here, or has a couple of other functions for sending multiple frames as fast as the bus will allow. As for the read the technique here is pretty common, where we query how many frames are in the buffer, and then choose to read that many. Other options include using the ncWaitForState.vi which can wait until a frame is available, before returning, similar to what the XNet Read is capable of.
When looking on the palette NI-CAN is broken up into two separate subpalettes. Channel API, and Frame API. Everything we've mentioned so far all falls under the Frame API. However, not all functions under the Channel API work on all NI-CAN hardware. The unsupported functions can be replicated with software but is obviously more efficient if the hardware supports it. Since we haven't covered what the Signal (or Channel) means for CAN yet, just stick with the Frame API which reads from a hardware buffer, and writes to the bus as soon as it is idle.
A few other major differences with NI-CAN and XNet is that XNet has many database functions which make importing, parsing and using database files possible, but might not be intuitive to new developers. You'll also notice that with NI-CAN only one session can be open to a piece of hardware at a time, while NI-XNet supports having multiple sessions open at once.
The bus monitor initializes the hardware when opening it, so you may start to see raw frames come in immediately. Stop the interface and you'll be able to go to the options and configure a few more things. The most common thing I use is the Stream To Disk option which logs raw frames as a CSV file with time stamps of when the frames were seen by the hardware. This is a very useful tool in seeing the playback of what was seen by the hardware. I wouldn't recommend having end uses use this software, but for debugging issues in communication it works great.
Basic NI-XNet Example
With all of that finally out of the way, lets talk about the NI-XNet example on how to read and write frames. Just like the serial example mentioned earlier, the best place to start is in the Example Finder. First lets look at a Frame Input Stream which will return all frames read into the buffer since the last read.Here we see that we first open a session to the hardware to perform a Frame In Stream. Then configure the interface, and then we sit in a loop reading the data, and displaying it as an array of frames, and then convert it to a more easily viewable table. Notice the 100ms loop rate which doesn't cause lost frames, because the frames that are read in those 100ms will be sitting in the hardware buffer, and transferred over on the next read. This read has several optional inputs that make for some useful use cases, like setting the number of frames to 1 and timeout to 100ms. This will cause the read to take at most 100ms, but it will return sooner if a frame is seen by the hardware.
The frame out example is quite similar.
Here we again configure the session for a Frame Out Stream, configure the interface, and then once every 100ms we send out 2 frames. This is using software timing, and the actual amount of time between writes may vary since this write will write it as soon as the bus is idle.
NI-XNet is a pretty advanced API. Which is why I'm going to dedicate an entire post on the API and some of the cool custom things it can do later. But for now just know this is really just the tip of the iceberg when it comes to what this API can do. Database management, signal and frame conversion, LIN, FlexRay, and sessions types are some of the other topics that you can go into when discussion XNet. Some of these topics will be covered in much more detail later. XNet also supports things like echoing written frames, single shot transmission, and high voltage wake-up all through property nodes on the sessions that are opened, or the interface being used.
NI-CAN Example
Earlier I mentioned NI has an older CAN API called NI-CAN. The most common NI-CAN hardware that uses this API is the NI USB 8473. This has recently been replaced by the XNet equivalent NI USB-8502 which is an XNet card. But before then if you wanted a cheap NI USB solution it was going to be the 8473, which uses the older NI-CAN API. Here is the shipping example which can read frames, and write them using the same session in a similar way to the XNet which would use two sessions.The example is pretty straight forward and a great starting point for a more complicated application. You'll notice that the NI-CAN API can write a single frame, at a time as shown here, or has a couple of other functions for sending multiple frames as fast as the bus will allow. As for the read the technique here is pretty common, where we query how many frames are in the buffer, and then choose to read that many. Other options include using the ncWaitForState.vi which can wait until a frame is available, before returning, similar to what the XNet Read is capable of.
When looking on the palette NI-CAN is broken up into two separate subpalettes. Channel API, and Frame API. Everything we've mentioned so far all falls under the Frame API. However, not all functions under the Channel API work on all NI-CAN hardware. The unsupported functions can be replicated with software but is obviously more efficient if the hardware supports it. Since we haven't covered what the Signal (or Channel) means for CAN yet, just stick with the Frame API which reads from a hardware buffer, and writes to the bus as soon as it is idle.
A few other major differences with NI-CAN and XNet is that XNet has many database functions which make importing, parsing and using database files possible, but might not be intuitive to new developers. You'll also notice that with NI-CAN only one session can be open to a piece of hardware at a time, while NI-XNet supports having multiple sessions open at once.
Manual Panels
But deploying any actual code, you probably want to know that your hardware is working, and the best place to start is the same place you would go to troubleshoot NI DAQ hardware, MAX. MAX (Measurement and Automation Explorer) is installed with just about all NI hardware and both XNet and NI-CAN hardware have simple test panels for reading and logging frames, and write in the case of XNet.NI-CAN Bus Monitor
For NI-CAN you'll want to navigate to the hardware in MAX and then go to the properties first. The Bus Monitor doesn't change the baud rate and so it must be set before opening it. Once set open the Bus Monitor.
The bus monitor initializes the hardware when opening it, so you may start to see raw frames come in immediately. Stop the interface and you'll be able to go to the options and configure a few more things. The most common thing I use is the Stream To Disk option which logs raw frames as a CSV file with time stamps of when the frames were seen by the hardware. This is a very useful tool in seeing the playback of what was seen by the hardware. I wouldn't recommend having end uses use this software, but for debugging issues in communication it works great.
NI XNet Bus Monitor
The XNet Bus Monitor is newer, and a bit more mature. Open it just like the NI-CAN one from MAX, and configure the hardware. Here you can specify the baud rate, termination, and optionally specify a database for signal conversion. Logging is also possible here which will log into a TDMS file that can be converted to other formats later.