In-Vehicle Datalogger Reference Application for CompactRIO
Publish Date: Dec 28, 2015
Overview
This reference application presents a software solution for a stand-alone embedded datalogger using Compact RIO hardware.
The feature set of this application is tailored for in-vehicle logging applications, although it is also suitable for other types of
logging. Note that this reference application is a configurable example, not a turn-key application. Most uses of this reference
application require some modification of the code to reflect the individual hardware used.
See the Parts List for this application now (http://sine.ni.com/nipartslist/app/pages/publicview/p/listview/47cbdff8878fd245 )
Table of Contents
Overview
This reference design library was created by the NI Systems Engineering group.
You can give us feedback by posting questions and comments through the CompactRIO In-Vehicle Datalogger Reference
Application discussion thread (http://forums.ni.com/ni/board/message?board.id=EDL&thread.id=1).
Features
Features of this reference application include:
•
Support for multiple scanning rates
•
Support for logging of CAN channels with an appropriate CAN database
•
Support for TDMS files
•
Controller logging indicators and override via LEDs and switches
•
PC host monitor mode and logging override
Component Requirements
In addition to the hardware and software requirements, listed below, this reference application uses the following independent
components, please install both before opening the application:
Simple TCP/IP Messaging (STM) Component (http://zone.ni.com/devzone/cda/epd/p/id/2739)
VI-Based API for Writing TDMS Files (http://zone.ni.com/devzone/cda/tut/p/id/6471)
Advanced CAN Frame to Channel Conversion Example (http://zone.ni.com/devzone/cda/epd/p/id/5826) (install in user.lib)
Architecture
The following diagram provides a detailed look at the operations performed by the datalogger VIs as well as the flow of data
throughout the datalogger.
1/11
www.ni.com
Communication Mechanisms
The following sections describe the communication mechanisms used by the datalogger.
Data Flow (http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/block_diagram_data_flow/)
Data flow is the normal transfer of data between block diagram objects by using wires. Data flow is generally used for transferr
2/11
www.ni.com
Data flow is the normal transfer of data between block diagram objects by using wires. Data flow is generally used for transferr
data between the functions within a loop.
Queue (http://zone.ni.com/reference/en-XX/help/371361D-01/glang/queue_vis/)
Queues transfer buffered data between loops.
Note that the use of Real-Time FIFOs is often encouraged over the use of queues for Real-Time code. This is because queues
allocate memory at run-time, an operation which is non-deterministic. However, in order to maintain determinism, Real-Time
FIFOs enforce a number of requirements which limit the types and size of elements. To remain flexible, the in-vehicle datalogg
must be capable of accepting data packets to log to disk from a variety of sources and at a variety of rates. This necessitates a
flexible inter-loop data transfer mechanism. In addition, the Real-Time segment of the datalogger does not require a great deal
determinism, since the FPGA performs all deterministic operations and does not have any timing dependencies on the
Real-Time code. Therefore, the in-vehicle datalogger intentionally implements inter-loop communication using queues rather th
FIFOs.
Direct Memory Access (DMA) is used to transfer buffered data between the Real-Time operating system and the FPGA on a
CompactRIO. DMA data transfers allow the Real-Time operating system to read all data points while still allowing the FPGA to
execute deterministically without a timing dependency upon the Real-Time code.
The in-vehicle datalogger uses three FPGA->RT DMA channels: one to transfer High-Speed Data, one to transfer Low-Speed
data, and one to transfer CAN messages and other event-based data.
FPGA Control I/O (http://zone.ni.com/reference/en-XX/help/371599C-01/lvfpgaconcepts/pfi_comm/)
Controls and indicators on an FPGA VI can be read and written either from within the FPGA code using local variables or from
Real-Time VI using the Read/Write Control (http://zone.ni.com/reference/en-XX/help/371599C-01/lvfpgahost/readwrite_control/
function.
The in-vehicle datalogger uses FPGA Control I/O to scan and set data items that do not require buffers, such as status and
configuration information.
STM (http://zone.ni.com/devzone/cda/tut/p/id/4095)
The Simple TCP Messaging (STM) component simplifies network communication by establishing a message based protocol fo
transferring data.
The in-vehicle datalogger uses STM messages for all direct communication between the CompactRIO and Windows host.
FTP (http://www.ni.com/support/labview/toolkits/internet/ftp.htm)
File Transfer Protocol (FTP) provides a safe protocol for transferring files across a network.
The Windows host provided for the in-vehicle datalogger uses FTP VIs from the NI LabVIEW Internet Toolkit (
http://sine.ni.com/nips/cds/view/p/lang/en/nid/2501) to programmatically retrieve data and error files from the target. If you do n
have the Internet Toolkit, you can replace these VIs with an alternate FTP implementation, or disable this function of the host a
transfer files manually using an FTP client.
FPGA Calibration VI Details
The FPGA Calibration VI retrieves calibration constants stored on C-Series hardware modules. This VI is separated from the m
FPGA acquisition code because calibration values only need to be retrieved once per acquisition. Separating the calibration co
into a separate VI uses fewer gates for the main VI.
3/11
www.ni.com
The VI reads calibration constants from each acquisition module. You must modify these sections of code to read calibration
constants from the modules you configure in your system.
Calibration data is bundled into weight/offset clusters and then built into arrays for transfer. The arrays must have an entry for
each channel. Channels which do not require calibration, such as digital channels, are represented by a cluster of two zero
values. Front panel indicators transfer the data using FPGA Control I/O. Note that calibration code is not provided for event
based data. If your event based data requires calibration constants, you should implement a separate indicator to transfer the
calibration data.
FPGA Acquisition VI Details
The FPGA Acquisition VI waits for a trigger condition, acquires data from C Series modules until a stop trigger or condition is
detected, and transfers the data to the Real-Time controller.
System Manager Loop
The System Manager Loop checks for stop triggers or a stop command from the Real-Time controller and transfers stop
messages to the other loops in the system.
4/11
www.ni.com
The datalogger allows you to configure both start and stop triggers. You must replace the FPGA I/O nodes which detect extern
triggers with nodes linked to your own trigger channels. If your system does not require external triggers, you may replace the
nodes with constant values and avoid using the digital or analog trigger types.
High-Speed Loop
The High-Speed Loop handles acquisition from timed acquisition modules, such as the 923x series. Alternately, this loop can
scan other modules at a separate sampling rate than the Low-Speed loop.
The loop reads a single data sample from each high-speed channel. Replace the I/O node with one or more I/O nodes configu
for your high-speed channels. You can read data from timed modules, normal modules, or both types of module from within thi
loop. If timed modules are present, the acquisition rate is controlled by the HS Scan Rate control and the HS Scan Period cont
is ignored. Otherwise, the HS Scan Period determines the rate and the HS Scan Rate is ignored.
All data is transferred in raw format via a DMA buffer. You may need to modify the size of the memory buffer in the project to
decrease the chance of overflows or preserve resources on the FPGA. By default, the high-speed DMA is allocated a much lar
buffer than the low-speed DMA to allow for higher scanning rates in the high-speed loop.
Each loop checks to see if the loop executed in the configured time period (overrun), and if there was sufficient room in the
DMA buffer for the data points (overflow). The loop latches any errors so that subsequent iterations will not erase the error
indication before it can be read.
Low-Speed Loop
The Low-Speed Loop handles acquisition from other modules, at a different sampling rate than the high-speed loop.
5/11
www.ni.com
The loop reads a single data sample from each low-speed channel. Replace the I/O node with one or more I/O nodes configur
for your low-speed channels. You can read data from any module that does not use internal timing. The LS Scan Period
determines the acquisition rate.
This loop also uses the DMA Write and Status Check functionality.
Event Loop
The Event Loop acquires messages from CAN channels and can optionally be used to acquire other event-based data.
The loop reads messages from a CAN channel. Link the I/O node to the CAN channel you are reading. Note that the current
code is set to read only a single CAN channel. You can use the timeout case in this loop to handle other event-based channels
Configure the CAN timeout through the advanced module properties in the project explorer. If multiple CAN channels are
required, you will need to modify the code to handle the timeout from each CAN channel individually.
The Event loop transfers data over DMA by constructing packets. Each packet contains an event index, which corresponds to
configured event channel, as well the size of the event data, and the data itself. You may need to modify the size of the memor
buffer in the project to decrease the chance of overflows or preserve resources on the FPGA.
The Event loop checks to see if there was sufficient room in the DMA buffer for the event (overflow). The Event loop does not
check for overrun because there is not an expected loop period. The loop latches any errors so that subsequent iterations will
erase the error indication before it can be read.
RT Controller VI Details
6/11
www.ni.com
RT Controller VI Details
The Real-Time Controller reads the datalogger configuration from a file, acquires data from the FPGA, stores it to disk,
communicates with the Windows Host, and interacts with the user via switches and LEDs.
FPGA Loop
The FPGA Comm loop interfaces with the FPGA and transmits data to and from the rest of the system.
In its Run state, the FPGA Comm loop reads the three DMA channels which transfer measurement data and events from the
FPGA. The loop gathers data read from the DMA channels into packets and transfers it to the File I/O loop using a queue. The
FPGA Comm loop also reads status information from FPGA Front Panel controls. Status information is transferred to other loo
using the Status Manager.
In its Get Calibration state, the FPGA Comm loop reads calibration data from the FPGA Calibration VI using FPGA Front Panel
controls. The loop stores calibration data in the Channel Manager for use by the File I/O loop.
A Status Manager functional global variable stores status information about the system. Multiple loops access this storage
location to read or modify the system status.
A Channel Manager functional global variable stores a list of channels and information about each channel. The channel list is
initialized with data from the Real-Time Controller's configuration file. Calibration information is stored by the FPGA Comm Loo
The File I/O Loop uses the stored information to access channel information and convert raw data to engineering units.
The Real-Time Error Log (RTEL) component provides a simple method for logging errors that takes into account Real-Time
performance considerations such as memory allocation. Although optimized, the component is not safe to use from a truly
deterministic loop because it accesses a file on disk. The RTEL stores errors in a simple ASCII format with a fixed size per line
and a definable maximum file size. After reaching the maximum file size, the RTEL overwrites the oldest errors with new ones.
Note that the errors in a RTEL log file are not necessarily in chronological order for this reason. The host VI includes a utility to
convert RTEL logs to chronological order.
File I/O Loop
The File I/O loop receives raw data from the FPGA Comm Loop, categorizes the data by channel and group, converts the data
7/11
www.ni.com
The File I/O loop receives raw data from the FPGA Comm Loop, categorizes the data by channel and group, converts the data
engineering units, and logs the data to disk.
The File I/O loop can briefly pause logging to allow the safe removal of storage devices. Logging can be paused from a Windo
host, or using a switch on the CompactRIO. Note that when logging is paused, data is still acquired and buffered if the system
triggered. Leaving logging paused for an extended period of time will lead to a buffer overflow. The amount of time you can sa
pause a system depends upon the acquisition rates involved.
The Channel Based File I/O (CBFIO) component is a high-level API for writing channel based data to a file. Currently, this API
stores files in TDMS format, using a VI-based TDMS Implementation (http://zone.ni.com/devzone/cda/tut/p/id/6471). TDMS
provides a flexible file format that can be written from any operating system, and directly accessed by analysis programs, but do
not necessarily provide the fastest streaming rates available. The CBFIO component is designed with the ability to write multip
file types in mind, and additional file formats may be supported in the future.
This loop also uses the Status Manager, Channel Manager, and RTEL functionality.
Switch/LED Control Loop
The Switch/LED Control loop updates LEDs with values from the Status Manager, and sends commands to the File I/O loop via
queue when switches are changed.
The Switch/LED Control loop updates the USER1 LED on the CompactRIO controller. The value of the USER1 LED displays
whether logging is enabled. You can use this LED to determine when it is safe to remove a storage device after disabling loggi
You can also alter the behavior of this VI to display different information to the LED.
Note that the system also updates the FPGA LED which is provided on some CompactRIO systems, but the updates are
performed from the FPGA code. The FPGA LED displays whether data is currently being acquired.
The Switch/LED Control loop monitors the state of the USER1 switch on the CompactRIO controller. When the switch is in the
position, the Loop sends a command to the File I/O Loop via the logging queue to pause logging. When the switch is in the
OFF position, logging is enabled. You can modify the behavior of this VI to change the function of the USER1 switch. For
example, you could make the USER1 switch trigger the acquisition start and stop rather than the log pause and resume.
This loop also uses the Status Manager and RTEL functionality.
8/11
www.ni.com
This loop also uses the Status Manager and RTEL functionality.
Host Communication Loop
The host communication loop accepts connections from an optional Windows host machine. When a connection exists, the loo
updates the host machine with status information and allows the host machine to override the standard behavior of the logger.
Direct communication with the host uses the Simple TCP Messaging (STM) protocol. The host can send messages to reset the
system, pause logging, or change the monitor settings. The target sends messages to transmit status information and monitore
data to the host.
This loop also uses the Status Manager functionality. This loop does not use the RTEL because errors in host communication
expected as connections are lost and reestablished. In addition, the host is an auxiliary element of the system, and therefore e
log space is reserved for more critical system behavior. If you are using the datalogger in a system where the host is an essen
tool, you can add the RTEL to the Host Communication loop and ignore the specific errors associated with lost connections.
Windows Host VI Details
The Windows Host VI provides a user interface for monitoring and managing the datalogger, as well as viewing acquired data.
Event Handler Loop
This loop responds to events from the user interface, and reads STM commands in a timeout event.
9/11
www.ni.com
The Host uses FTP to transfer data files and error logs from the target.
The Host uses STM to send pause, reset, and monitor settings messages. The host receives monitor data and system status
messages.
The host allows the user to configure the target network location, file locations on the target, local locations to store transferred
files, and optionally, an acquisition channel to monitor.
The host allows you to override the target's normal operation by pausing data logging or resetting the target. Note that some
caveats apply to pausing the logging.
The host displays the system status, received from STM messages. This includes whether an acquisition is currently running, a
whether logging is currently paused. It also indicates common errors that may occur on the target.
An FPGA Overflow indicates that the DMA buffer is not large enough to store the transferred data, or the FPGA Comm Loop is
running fast enough to empty the buffer.
An FPGA Overrun error indicates that the acquisition loop cannot run at the desired sample rate. Note that each FPGA I/O nod
takes a minimum amount of clock cycles based upon the channels it reads.
An RT Overflow error indicates that data could not be written to disk fast enough to empty the memory buffer between the FPG
Comm Loop and the File I/O Loop. This indicates that the total system throughput is too high for the current architecture or file
format to support.
The Host can monitor live data updates on a single channel. This is primarily useful for debugging or monitoring purposes, and
may be unavailable if there is not sufficient processor bandwidth on the target. The Host also generates pop-up dialogs to disp
the contents of data files and error logs when they are successfully transferred.
Parts List
See the Parts List for this application now (http://sine.ni.com/nipartslist/app/pages/publicview/p/listview/df8439ee0299e5e5)
Customer Reviews
2 Reviews | Submit your review (
http://zone.ni.com/apps/utf8/nidz_display_comments.create_comment?p_title=In-Vehicle+Datalogger+Reference+Application+
)
10/11
www.ni.com
PRODUCT
SUPPORT
COMPANY
Order status and history (http://www.ni.com/status/) Submit a service request (
https://sine.ni.com/srm/app/myServiceRequests)
Order by part number (
http://sine.ni.com/apps/utf8/nios.store?action=purchase_form
Manuals (http://www.ni.com/manuals/)
)
Drivers (http://www.ni.com/downloads/drivers/)
Activate a product (
http://sine.ni.com/myproducts/app/main.xhtml?lang=en
Alliance Partners (http://www.ni.com/alliance/)
)
About National Instruments (
http://www.ni.com/company/)
Events (http://www.ni.com/events/)
Careers (http://www.ni.com/careers/)
Order and payment information (
http://www.ni.com/how-to-buy/)
MISSION
NI equips engineers and scientists with systems
that accelerate productivity, innovation, and
discovery.
(http://twitter.com/niglobal)
(
http://www.facebook.com/NationalInstruments)
(
http://www.linkedin.com/company/3433?trk=tyah)
(http://www.ni.com/rss/)
(
http://www.youtube.com/nationalinstruments)
Contact Us (http://www.ni.com/contact-us/)
(http://privacy.truste.com/privacy-seal/National-Instruments-Corporation/validation?rid=bc6daa8f-7051-4eea-b7b5-fb24dcd96d95)
Legal (http://www.ni.com/legal/) | © National Instruments. All rights reserved. | Site map (
http://www.ni.com/help/map.htm)
11/11
www.ni.com