So In Part 1 we talked about the various differences in CAN, from the physical perspective, and the communications differences. We also talked about some NI and non-NI hardware options. In Part 2 we talked about the CAN Frame, and other basic features of CAN. And then in Part 3 we talked about the basic NI APIs of NI-CAN and NI-XNet. In this post we're going to talk about non-NI hardware and what their APIs look like for reading and writing CAN frames.
The three types of CAN hardware discussed here will occasionally reference some CAN drivers I am providing here as the Hooovahh CAN Drivers Package, or available on the downloads page for this blog series. Install these VIs through VIPM by installing the VIP file for your version of LabVIEW, and you will have a Hooovahh palette on the block diagram under Addons. This palette of provides cleaned up drivers already available on the internet for the hardware discussed here.
So it's no surprise that LabVIEW developers have been wanting to use Vector hardware for a while in their test applications. Vector saw this and realized they should make a LabVIEW toolkit so you can use their hardware in LabVIEW. The problem is their toolkit sucks! No one who uses CAN should consider buying the CAN Driver for LabVIEW from Vector. Why? Because this API does not allow you to read and write raw CAN frames, the process of using the toolkit is cumbersome, and has features that may result in not reading correct data. If a device on the CAN bus is transmitting a signal which is a temperature of 25C, the Vector toolkit can (possibly) read this signal. But if the device stops transmitting CAN, or turns off entirely, the toolkit will continue to return 25C, with no way of knowing that the signal isn't there anymore.
So why am I talking about Vector at all if they suck? Well they don't suck, the poorly made toolkit from 10+ years ago sucks. But luckily Vector also provides a low level DLL called XL-Driver which does allow for reading and writing raw frames. And someone in the community has already cleaned it up and wrote VIs for you. This code will work with several Vector CAN hardware like CANCase, CANCard, CANBoard, VN2600, VN3300, VN3600, and several others. This API also adds support for some LIN hardware and a few other features like analog inputs. I've used it on CANCases, and a VN1630 with plenty of success.
I've taken the drivers devloped by TroyK and polished them up a bit, and they are available as part of my Hooovahh CAN Drivers package. After downloading and installing it navigate to the Vector Drivers palette.
Here we have all the basic building blocks of an application communicating with Vector hardware with the basic example seen below.
Here we find all hardware, open the first one we find, configure it for 500K baud, start any DAQ hardware we find, then loop where we read DAQ and CAN data, and optionally read the Chip State, or send raw frames. Some other functions not shown in the example relate to setting frame ID filtering. A common feature of CAN transceivers is being able to ignore frames based on their IDs, on the hardware level. Because the drivers are built around XL wrappers there are also many functions that aren't CAN related, such as the LIN, DAQ, and FlexRay functions. These are not on the palette, but are installed with the package in the user.lib.
To use either TroyKs wrappers, or my updated drivers you must first have the hardware be detected by your computer, which requires downloading and installing the Windows drivers for your hardware type from Vector. Most of their software suites like CANalyzer come with device drivers as a separate installer.
And here is the provided example.
This example is based on a state machine but has similar functionality as the Vector example. Run the VI and then click Open First Device, then click Get Messages, or Transmit to read or write raw frames. In addition to this the Intrepid neoVI drivers also supports reading various analog inputs, and writing single wire high voltage wake-up messages for hardware that support it.
And the updated example on reading and writing frames is also included. The Kvaser drivers have similar ID filtering functions like the Vector ones, and a few other useful functions like the waiting on a frame in a read with a timeout like the XNet read.
The three types of CAN hardware discussed here will occasionally reference some CAN drivers I am providing here as the Hooovahh CAN Drivers Package, or available on the downloads page for this blog series. Install these VIs through VIPM by installing the VIP file for your version of LabVIEW, and you will have a Hooovahh palette on the block diagram under Addons. This palette of provides cleaned up drivers already available on the internet for the hardware discussed here.
Vector Hardware
Vector is probably the most common CAN hardware you will find in Automotive. They have some pretty solid hardware options, and have off the shelf software that works with their hardware pretty well. Their most common hardware is the CANCaseXL, a two port USB CAN device. And their most popular software is CANAlyzer which has reading and writing CAN frames, reading and writing CAN signals, logging, graphing, and a scripting language of sorts, CAPL. They also have other CAN software such as CANape, CANoe, and vFlash which all works quite well in their ecosystem if you don't mind the price tag.So it's no surprise that LabVIEW developers have been wanting to use Vector hardware for a while in their test applications. Vector saw this and realized they should make a LabVIEW toolkit so you can use their hardware in LabVIEW. The problem is their toolkit sucks! No one who uses CAN should consider buying the CAN Driver for LabVIEW from Vector. Why? Because this API does not allow you to read and write raw CAN frames, the process of using the toolkit is cumbersome, and has features that may result in not reading correct data. If a device on the CAN bus is transmitting a signal which is a temperature of 25C, the Vector toolkit can (possibly) read this signal. But if the device stops transmitting CAN, or turns off entirely, the toolkit will continue to return 25C, with no way of knowing that the signal isn't there anymore.
So why am I talking about Vector at all if they suck? Well they don't suck, the poorly made toolkit from 10+ years ago sucks. But luckily Vector also provides a low level DLL called XL-Driver which does allow for reading and writing raw frames. And someone in the community has already cleaned it up and wrote VIs for you. This code will work with several Vector CAN hardware like CANCase, CANCard, CANBoard, VN2600, VN3300, VN3600, and several others. This API also adds support for some LIN hardware and a few other features like analog inputs. I've used it on CANCases, and a VN1630 with plenty of success.
I've taken the drivers devloped by TroyK and polished them up a bit, and they are available as part of my Hooovahh CAN Drivers package. After downloading and installing it navigate to the Vector Drivers palette.
Here we have all the basic building blocks of an application communicating with Vector hardware with the basic example seen below.
Here we find all hardware, open the first one we find, configure it for 500K baud, start any DAQ hardware we find, then loop where we read DAQ and CAN data, and optionally read the Chip State, or send raw frames. Some other functions not shown in the example relate to setting frame ID filtering. A common feature of CAN transceivers is being able to ignore frames based on their IDs, on the hardware level. Because the drivers are built around XL wrappers there are also many functions that aren't CAN related, such as the LIN, DAQ, and FlexRay functions. These are not on the palette, but are installed with the package in the user.lib.
To use either TroyKs wrappers, or my updated drivers you must first have the hardware be detected by your computer, which requires downloading and installing the Windows drivers for your hardware type from Vector. Most of their software suites like CANalyzer come with device drivers as a separate installer.
Intrepid
Intrepid provides LabVIEW drivers for their CAN hardware. The drivers aren't great but they get the job done, and just like the Vector drivers they leverage a Windows compiled DLL for communicating with the hardware. And again just like Vector ones, Windows drivers are required before the device will be recognized. These drivers are currently available from Intrepid's site at this link. And also like the Vector drivers I've cleaned them up a bit and placed them on the palette of the Hooovahh CAN Drivers Package. Once installed the palette will look like the image below, which again mirrors the Vector palette.And here is the provided example.
This example is based on a state machine but has similar functionality as the Vector example. Run the VI and then click Open First Device, then click Get Messages, or Transmit to read or write raw frames. In addition to this the Intrepid neoVI drivers also supports reading various analog inputs, and writing single wire high voltage wake-up messages for hardware that support it.
Kvaser
Kvaser also provides a set of basic drivers that communicate with the hardware through a Windows DLL. This is how the palette looks for the Kvaser drivers on the Hooovahh CAN Drivers Package palette.And the updated example on reading and writing frames is also included. The Kvaser drivers have similar ID filtering functions like the Vector ones, and a few other useful functions like the waiting on a frame in a read with a timeout like the XNet read.
Commonality
All of these drivers (and others like them) have the ability to read all frames that have been sitting in a hardware buffer, and have the ability to send frames immediately placing them on a write queue. Some more advanced APIs allow for hardware timed writes, database signal scaling, an other more advanced functions.
Not all APIs support all of the same features. Being able to query the size of the write buffer for instance is something that NI-CAN and Vector APIs, are not able to do, but several other APIs can. The majority of these features aren't used often but can be useful on advanced applications.
Not all APIs support all of the same features. Being able to query the size of the write buffer for instance is something that NI-CAN and Vector APIs, are not able to do, but several other APIs can. The majority of these features aren't used often but can be useful on advanced applications.