Tips for CAN: Dynamic Frame Definition with National Instruments NI-CAN

Tips for CAN:  Dynamic Frame Definition with National Instruments NI-CAN

Back in the stone age (i.e. NI-CAN 1.2), us LabVIEW 6 programmers had to write our own parsing routines for dynamically-specified data inside a CAN frame. At the driver layer, we were locked-in to only one layer of arbitration. An oft-overlooked but extremely powerful feature in contemporary versions of the NI-CAN drivers handle this automatically.

Example: a BMS (battery managment system) for a hybrid automotive battery broadcasts status information. Status information will always be available on the same Arbitration ID, but-- this is the important part-- the interpretation of those bytes can vary, depending on other information in the frame. If you have to read Byte 1 to tell you what Bytes 2-8 actually mean, this is the tool you need. Here, Byte 1 is defined as a Mode, and the remaining bytes are decoded according to a lookup definition that is set in MAX. These definitions are portable-- they can be created, distributed, and deployed on Windows-based or Real-Time targets.

CAN channel multiplexing drastically simplifies the previously-programmatic solution of sorting out data that can be broadcasted within the same Arbitration ID. Alas, that extra degree of freedom is here.

More information on NI-CAN and multiplexing can be found here at the National Instruments website.


Brent Hoerman
# Brent Hoerman
Excellent Blog Post Darren.... this feature is a huge time saver! How else would you want to extract hundreds of temperature and voltage readings from the one CAN bus message ID sent out by your BMS.

Another point to make is that non-programmers can also use the GUI interface within NI MAX to easily change the definitions of the CAN message ID, Mode, and multiplexed channels. Which saves you programming time and generally makes end users very happy.

Post a comment

Name (required)

Email (required)

Enter the code shown above:

Related Blog Posts