1. Getting Started
Within a LabVIEW project, you can create NI-XNET sessions used within a VI to read or write network data.
Using LabVIEW project sessions is best suited for static applications, in that the network data does not change from one execution to the next. Even if your application is more dynamic, a LabVIEW project is an excellent introduction to NI-XNET concepts.
To get started, open a new LabVIEW project, right-click My Computer, and select New»NI-XNET Session. In the resulting dialog, the window on the left provides an introduction to the NI-XNET session in the LabVIEW project. The introduction links to help topics that describe how to create a session in the project, including a description of the session modes.
NI-XNET includes LabVIEW examples that demonstrate a wide variety of use cases. The examples build on the basic concepts to demonstrate more in-depth use cases. Most of the examples create a session at run time rather than a LabVIEW project.
To view the NI-XNET examples, select Find Examples... from the LabVIEW Help menu. When you browse examples by task, NI-XNET examples are under Hardware Input and Output. The examples are grouped by protocol in CAN, FlexRay, and LIN folders. Although you can write NI-XNET applications for either protocol, and each folder contains shared examples, this organization helps you to find examples for your specific hardware product.
After learning the fundamentals of NI-XNET with a LabVIEW project and the examples, you can begin to write your own application.
The NI-XNET functions palette includes nodes that you drag to your VI block diagram. When your VI block diagram is open, this palette is in the Measurement I/O»XNET functions palette.
Basic Programming Model
The LabVIEW block diagram in the following figure shows the basic NI-XNET programming model.
Complete the following steps to create this block diagram:
- Create an NI-XNET session in a LabVIEW project. The session name is MyInputSession, and the mode is Signal Input Single-Point.
- Create a new VI in the project and open the block diagram.
- Drag a while loop to the block diagram. Right-click the loop condition (the stop sign) and create a control (stop button)
- Drag the NI-XNET session from a LabVIEW project to the while loop. This creates the XNET session wired to the corresponding XNET Read.vi.
- Right-click the data output from XNET Read.vi and create an indicator.
- Run the VI. View the received signal values. Stop the VI when you are done.
When you complete the preceding steps, you have created a fully functional NI-XNET application.
You can create sessions for other input or output modes using the same technique. When you drag an output session to the diagram, NI-XNET creates a constant for data and wires that constant to XNET Write.vi. You can enter constant values to write, or to change the data at run time, right-click the constant and select Change to Control.
NI-XNET enables you to create sessions for multiple hardware interfaces. For each interface, you can use multiple input sessions and multiple output sessions simultaneously. The sessions can use different modes. For example, you can use a Signal Input Single-Point Mode session at the same time you use a Frame Input Stream Mode session. The NI-XNET functions palette includes nodes that extend this programming model to perform tasks such as:
- Creating a session at run time (instead of a LabVIEW project).
- Controlling the configuration and state of a session.
- Browsing and selecting a hardware interface.
- Managing and browsing database files.
- Creating frames or signals at run time (instead of using a database file).
The following sections describe the fundamental concepts used within NI-XNET. Each section explains how to perform extended programming tasks.
What Is an Interface?
The interface represents a single CAN, FlexRay, or LIN connector on an NI hardware device. Within NI-XNET, the interface is the object used to communicate with external hardware described in the database. Each interface name uses the following syntax:
The <protocol> is either CAN for a CAN interface, FlexRay for a FlexRay interface, or LIN for a LIN interface.
The number <n> identifies the specific interface within the <protocol> scope. The numbering starts at 1. For example, if you have a two-port CAN device, a two-port FlexRay device, and a two-port LIN device in your system, the interface names are CAN1, CAN2, FlexRay1, FlexRay2, LIN1, and LIN2, respectively. Although you can change the interface number <n> within Measurement & Automation Explorer (MAX), the typical practice is to allow NI-XNET to select the number automatically. NI-XNET always starts at 1 and increments for each new interface found. If you do not change the number in MAX, and your system always uses a single two-port CAN device, you can write all your applications to assume CAN1 and CAN2. For as long as that CAN card exists in your system, NI-XNET uses the same interface numbers for that device, even if you add new CAN cards.
NI-XNET also uses the term port to refer to the connector on an NI hardware device. The difference between the terms is that port refers to the hardware object (physical), and interface refers to the software object (logical). The benefit of this separation is that you can use the interface name as an alias to any port, so that your application does not need to change when your hardware configuration changes. For example, if you have a PXI chassis with a single CAN PXI device in slot 3, the CAN port labeled Port 1 is assigned as interface CAN1.
How Do I View Available Interfaces?
Measurement & Automation Explorer (MAX)
Use MAX to view your available NI-XNET hardware, including all devices and interfaces. To view hardware in your local Windows system, select Devices and Interfaces under My System.
Select each NI-XNET device to view its physical ports. Each port is listed with the current interface name assignment, such as FlexRay1. When you select a port, the right window shows a picture of the device with the port circled and the port LED blinking. The blinking LED assists in identifying a specific port when your system contains multiple instances of the same hardware product (for example, a chassis with five CAN devices).
In the selected port’s window on the right, you can change one property: the interface name. Therefore, you can assign a different interface name than the default. For example, you can change the interface for physical port 2 of a PCI-8517 to FlexRay1 instead of FlexRay2.
To view hardware in a remote LabVIEW Real-Time system, find the desired system under Remote Systems and select Devices and Interfaces under that system. The features of NI-XNET devices and interfaces are the same as the local system.
When you create a session at run time, you pass the desired interface to XNET Create Session.vi. The interface uses the XNET Interface I/O Name type. The XNET Interface I/O name has a drop-down list of all available NI-XNET interfaces. This list matches the list of interfaces shown in MAX. You select a specific interface from the list for use with XNET Create Session.vi.
By right-clicking the XNET Create Session.vi interface input, you can create a constant or control for the XNET Interface I/O name. The constant is placed on your block diagram. You typically use a constant when you have only a single NI-XNET device, to use fixed names such as CAN1 and CAN2. The control is placed on your front panel. You typically use a
control when you have a large number of NI-XNET devices and want the VI end user to select from available interfaces.
When you create a session in a LabVIEW project, you enter the interface in the session dialog. This dialog has a list of available interfaces, in a manner similar to the XNET Interface I/O name. If you are creating a session in a LabVIEW project and do not yet have NI-XNET hardware in your system, you can type an interface name such as CAN1 in the dialog. This enables you to create sessions and program VIs prior to installing the hardware.
In some cases, you may need to provide features similar to MAX within your own application. For example, if you distribute your LabVIEW application to end users who are not familiar with MAX, you may need to display a similar view within the application itself. Within the NI-XNET functions palette Advanced subpalette, NI-XNET provides property
nodes to query for available hardware.
The block diagram in the figure above shows a very simple example using the XNET system node. In the example, we look at each XNET device in the system and if the interface is a PXI form factor, we read the name of the interface and which protocol is supported.
What Is a Database?
For the NI-XNET interface to communicate with hardware products on the external network, NI-XNET must understand the communication in the actual embedded system, such as the vehicle. This embedded communication is described within a standardized file, such as CANdb (.dbc) for CAN, FIBEX (.xml) for FlexRay, or LIN Description File (.ldf) for LIN. Within NI-XNET, this file is referred to as a database. The database contains many object classes, each of which describes a distinct entity in the embedded system.
- Database: Each database is represented as a distinct instance in NI-XNET. Although the database typically is a file, you also can create the database at run time (in memory).
- Cluster: Each database contains one or more clusters, where the cluster represents a collection of hardware products connected over a shared cabling harness. In other words, each cluster represents a single CAN, FlexRay, or LIN network. For example, the database may describe a single vehicle, where the vehicle contains one CAN cluster Body, another CAN cluster Powertrain, one FlexRay cluster Chassis, and a LIN cluster PowerSeat.
- ECU: Each Electronic Control Unit (ECU) represents a single hardware product in the embedded system. The cluster contains one or more ECUs connected over a CAN, FlexRay, or LIN cable. It is possible for a single ECU to be contained in multiple clusters, in which case it behaves as a gateway between the clusters.
- Frame: Each frame represents a unique unit of data transfer over the cluster cable. The frame bits contain payload data and an identifier that specifies the data (signal) content. Only one ECU in the cluster transmits (sends) each frame, and one or more ECUs receive each frame.
- Signal: Each frame contains zero or more values, each of which is called a signal. Within the database, each signal specifies its name, position, length of the raw bits in the frame, and a scaling formula to convert raw bits to/from a physical unit. The physical unit uses a LabVIEW double-precision floating-point numeric type.
- Other object classes include the Subframe, LIN Schedule, and LIN Schedule Entry.
For more information about FIBEX database, please look at FIBEX and the NI-XNET Database Editor.
What Is an Alias?
When using a database file with NI-XNET, you can specify the file path or an alias to the file. The alias provides a shorter, easier-to-read name for use within your application. For example, for the file path
C:\Documents and Settings\All Users\Documents\Vehicle5\MyDatabase.DBC
you can add an alias named MyDatabase.
In addition to improving readability, the alias concept isolates your LabVIEW application from the specific file path. For example, if your application uses the alias MyDatabase and you change its file path to
your LabVIEW application continues to run without change.
The alias concept is used in most NI-XNET features for the database classes. The XNET I/O Names for database classes include features for adding a new alias, viewing existing aliases, deleting an alias, and so on. You also can perform these tasks at run time, using the VIs available in the NI-XNET functions palette Database»File Mgt subpalette.
After you create an alias, it exists until you explicitly delete it. If you exit and relaunch LabVIEW, the aliases from the previous use remain. If you uninstall NI-XNET, the aliases are deleted; however, if you reinstall (upgrade) NI-XNET, the aliases from the previous installation remain. Deleting an alias does not delete the database file itself, but merely the
association within NI-XNET.
An alias is required for deploying databases to LabVIEW Real-Time (RT) targets. When you deploy to a LabVIEW RT target, the large text file is compressed to an optimized binary format, and that binary file is transferred to the target. For more information about databases with LabVIEW RT, refer to Using LabVIEW Real-Time.
The NI-XNET software provides various methods for creating your application database
configuration. The following figure shows a process for deciding the database source.
A description of each step in the process follows the flowchart.
Already Have File?
If you are testing an ECU used within a vehicle, the vehicle maker (or the maker’s supplier) already may have provided a database file. This file likely would be in CANdb, FIBEX, or LDF format. When you have this file, using NI-XNET is relatively straightforward.
Can Use File As Is?
Is the file up to date with respect to your ECU(s)? If you do not know the answer to this question, the best choice is to assume Yes and begin using NI-XNET with the file. If you encounter problems, you can use the techniques discussed in Edit and Select to update your application without significant redesign.
Select From File
There are three options for selecting the database objects to use for NI-XNET sessions: a LabVIEW project, I/O names, and property nodes.
The NI-XNET session in a LabVIEW project assumes that you have a database file. The configuration dialog includes controls to browse to your database file, select a cluster to use, and select a list of frames or signals. For example, if you create a Signal Input Single-Point session, you enter the database and cluster to use, then select one or more signals to read.
If you create sessions at run time, you need to wire objects from the database file to XNET Create Session.vi. The easiest way to do this is to use I/O names for the objects that you need. For example, assume that you want to create a Signal Input Single-Point session and want the VI end user to select signals from the front panel. First, drag XNET Create Session.vi from the NI-XNET functions palette. Change the VI selector to Signal Input Single-Point. Right-click the signal list input and select Create»Control. This creates an array of XNET Signal I/O names on your front panel. Right-click the signal list control and select Browse for Database File to find the database file.
For a CANdb file, you can click the drop-down list for each array element to select from available signals in the file. For a FIBEX or LDF file, right-click signal list and Select Database to select a specific cluster within the file, then click the drop-down list to select signals. After you browse to the file and select a cluster, that information is saved with the VI, so you need to select only signal names from that point onward. Most NI-XNET examples use I/O names to select objects (frames or signals). As a default, the NI-XNET example VIs use an example database file installed with NI-XNET. You can change this file to a different file using the previous steps.
If you create a session at run time, you may want to implement your own front panel controls to select objects from the database, rather than use I/O names. Although the programming is more advanced than I/O names, you can do this using property nodes for the database classes. These property nodes are found in the NI-XNET functions palette Database subpalette.
For example, assume you want a tree control on the VI front panel. The tree shows the frames and signals within a selected cluster. The VI user selects signals from this tree control. The tree control block diagram uses a programming model similar to the Advanced System Example Using Property Nodes. You can look at the Browse Database with Tree.vi example included with NI-XNET for more on this.
Edit and Select
There are two options for editing the database objects for the NI-XNET session: edit in memory and edit the file.
Edit in Memory
First, you select the frames or signals for the NI-XNET session using one of the options described in Select From File. Next, you wire the selected objects to the corresponding property node and set properties to change the value. When you edit the object using its property node, this changes the representation in memory, but does not save the change to the file. When you pass the object into XNET Create Session.vi, the changes in memory (not the original file) are used.
Edit the File The NI-XNET Database Editor is a tool for editing database files for use with NI-XNET. Using this tool, you open an existing file, edit the objects, and save those changes. You can save the changes to the existing file or a new file.
When you have a file with the changes you need, you select objects in your application as described in Select From File.
Want to Use a File?
If you do not have a usable database file, you can choose to create a file or avoid files
altogether for a self-contained application.
Create New File Using the Database Editor
You can use the NI-XNET Database Editor to create a new database file. Once you have a file, you select objects in your application as described in Select From File. As a general rule, for FlexRay applications, using a FIBEX file is recommended. FlexRay communication configuration requires a large number of complex properties, and storage in
a file makes this easier to manage. The NI-XNET Database Editor has features that facilitate this configuration.
Note The current version of NI-XNET supports import of LDF files for LIN, but does not yet support export (save) of a LIN database. Therefore, the NI-XNET Database Editor does not yet support LIN. To view the objects in a LIN LDF file, refer to the NI-XNET examples.
For more information about FIBEX database, please look at FIBEX and the NI-XNET Database Editor.
Create in Memory
You can use XNET Database Create Object.vi to create new database objects in memory. Using this technique, you can avoid files entirely and make your application self contained. You configure each object you create using the property node. Each class of database object contains required properties that you must set (refer to Required Properties). Because CAN is a more straightforward protocol, it is easier to create a self-contained application. For example, you can create a session to transmit a CAN frame with only two objects. For more information, please look at the Creating Database Dynamically.vi example that is included with NI-XNET.
What Is a Session?
The NI-XNET session represents a connection between your National Instruments CAN/FlexRay/LIN hardware and hardware products on the external network. As discussed in Basic Programming Model, your application uses sessions to read and write I/O data. Each session configuration includes:
- Interface: This specifies the National Instruments hardware to use.
- Database objects: These describe how external hardware communicates.
- Mode: This specifies the direction and representation of I/O data.
In addition to read/write of I/O data, you can use the session to interact with the network in other ways. For example, XNET Read.vi includes selections to read the state of communication, such as whether communication has stopped due to error detection defined by the protocol standard.
You can use sessions for multiple hardware interfaces. For each interface, you can use multiple input sessions and multiple output sessions simultaneously. The sessions can use different modes. For example, you can use a Signal Input Single-Point session at the same time you use a Frame Input Stream session.
The limitations on sessions relate primarily to a specific frame or its signals. For example, if you create a Frame Output Queued session for frameA, then create a Signal Output Single-Point session for frameA.signalB (a signal in frameA), NI-XNET returns an error. This combination of sessions is not allowed, because writing data for the same frame with
two sessions would result in inconsistent sequences of data on the network.
The session mode specifies the data type (signals or frames), direction (input or output), and how data is transferred between your application and the network. The mode is an enumeration of the following:
- Signal Input Single-Point Mode: Reads the most recent value received for each signal. This mode typically is used for control or simulation applications, such as Hardware In the Loop (HIL).
- Signal Input Waveform Mode: Using the time when the signal frame is received, resamples the signal data to a waveform with a fixed sample rate. This mode typically is used for synchronizing XNET data with DAQmx analog/digital input channels.
- Signal Input XY Mode: For each frame received, provides its signals as a value/ timestamp pair. This is the recommended mode for reading a sequence of all signal values.
- Signal Output Single-Point Mode: Writes signal values for the next frame transmit. This mode typically is used for control or simulation applications, such as Hardware In the Loop (HIL).
- Signal Output Waveform Mode: Using the time when the signal frame is transmitted according to the database, resamples the signal data from a waveform with a fixed sample rate. This mode typically is used for synchronizing XNET data with DAQmx analog/digital output channels.
- Signal Output XY Mode: Provides a sequence of signal values for transmit using each frame’s timing as the database specifies. This is the recommended mode for writing a sequence of all signal values.
- Frame Input Stream Mode: Reads all frames received from the network using a single stream. This mode typically is used for analyzing and/or logging all frame traffic in the network.
- Frame Input Queued Mode: Reads data from a dedicated queue per frame. This mode enables your application to read a sequence of data specific to a frame (for example, CAN identifier).
- Frame Input Single-Point Mode: Reads the most recent value received for each frame. This mode typically is used for control or simulation applications that require lower level access to frames (not signals).
- Frame Output Stream Mode: Transmits an arbitrary sequence of frame values using a single stream. The values are not limited to a single frame in the database, but can transmit any frame.
- Frame Output Queued Mode: Provides a sequence of values for a single frame, for transmit using that frame’s timing as the database specifies.
- Frame Output Single-Point Mode: Writes frame values for the next transmit. This mode typically is used for control or simulation applications that require lower level access to frames (not signals).
How Do I Create a Session?
There are two methods for creating a session: a LabVIEW project and XNET Create Session.vi. You typically use only one method to create all sessions for your application.
Using LabVIEW project sessions is best suited for applications that are static, in that the network data does not change from one execution to the next. Refer to Getting Started for a description of creating a session in a LabVIEW project.
When you configure the session in a LabVIEW project, you select the interface, mode, and database objects with the NI-XNET user interface. The database objects (cluster, frames, and signals) must exist in a file. If you do not already have a database file, you can create one using the NI-XNET Database Editor, which you can launch from NI-XNET user interface.
XNET Create Session.vi
You can use XNET Create Session.vi to create NI-XNET sessions at run time. This run-time creation has advantages over a LabVIEW project, because the end user of your application can configure sessions from the front panel. The disadvantage is that the VI diagram is more complex.
If your application is used for a specific product (for example, an instrument panel for a specific make/model/year car), and the front panel must be simple (for example, a test button with a pass/fail LED), a LabVIEW project is the best method to use for NI-XNET sessions. Because the configuration does not change, a LabVIEW project provides the easiest
If your application is used for many different products (for example, a test system for an engine in any make/model/year car), XNET Create Session.vi is the best method to use for NI-XNET sessions. On the front panel, the application end user can provide a database file and select the specific frames or signals to read and/or write. XNET Create Session.vi takes inputs for the interface, mode, and database objects. You select the interface using techniques described in How Do I View Available Interfaces?. The database objects depend on the mode (for example, Signal Input Waveform requires an array of signals). You select the database objects using techniques described in Database Programming.
5. Using CAN
This section summarizes some useful NI-XNET features specific to the CAN protocol.
Please look at Controller Area Network (CAN) Overview for more on the CAN protocol.
Understanding CAN Frame Timing
When you use an NI-XNET database for CAN, the properties of each CAN frame specify the CAN data transfer timing. To understand how the CAN frame timing properties apply to NI-XNET sessions, refer to CAN Timing Type and Session Mode in the NI-XNET Hardware and Software Manual.
Configuring Frame I/O Stream Sessions
As described in Database Programming, you typically need to specify database objects when creating an NI-XNET session.
The CAN protocol supports an exception that makes some applications easier to program. In sessions with Frame Input Stream or Frame Output Stream mode, you can read or write arbitrary frames. Because these modes do not use specific frames, only the database cluster properties apply. For CAN, the only required cluster property is the baud rate.
Although the CAN baud rate applies to all hardware on the bus (cluster), NI-XNET also provides the baud rate as an interface property. You can set this interface property using the session property node.
If your application uses only Frame I/O Stream sessions, no database object is required (no cluster). You simply can call XNET Create Session.vi and then set the baud rate using the session property node. The following figure shows an example diagram that creates a Frame Input Stream session and sets the baud rate to 500 kbps.
6. Using FlexRay
This section summarizes some useful NI-XNET features specific to the FlexRay protocol.
Please look at FlexRay Automotive Communication Bus Overview for more on the FlexRay protocol.
FlexRay is a Time Division Multiple Access (TDMA) protocol, which means that all hardware products on the network share a synchronized clock. Slots of time for that clock determine when each frame transmits. To start communication on FlexRay, the first step is to start the synchronized network clock. In the FlexRay database, two or more hardware products are designated to transmit a special startup frame. These products (nodes) are called coldstart nodes. Each coldstart node uses the startup frame to contribute its local clock as part of the shared network clock.
Because at least two coldstart nodes are required to start FlexRay communication, your NI-XNET FlexRay interface may need to act as a coldstart node, and therefore transmit a special startup frame. The properties of each startup frame (including the time slot used) are specified in the FlexRay database.
The following scenarios apply to FlexRay startup frames:
- Port to port: When you get started with your NI-XNET FlexRay hardware, you can connect two FlexRay interfaces (ports) to run simple programs, such as the NI-XNET examples. Because this is a cluster with two nodes, each NI-XNET interface must
transmit a different startup frame.
- Connect to existing cluster: If you connect your NI-XNET FlexRay interface to an existing cluster (for example, a FlexRay network within a vehicle), that cluster already must contain coldstart nodes. In this scenario, the NI-XNET interface should not transmit a startup frame.
- Test single ECU that is coldstart: If you connect to a single ECU (and nothing else), and that ECU is a coldstart node, the NI-XNET interface must transmit a startup frame. The NI-XNET interface must transmit a startup frame that is different than the startup frame the ECU transmits.
- Test single ECU that is not coldstart: If you connect to a single ECU (and nothing else), and that ECU is not a coldstart node, you must connect two NI-XNET interfaces. The ECU cannot communicate without two coldstart nodes (two clocks). According to the FlexRay specification, a single FlexRay interface can transmit only one startup frame.
Therefore, you need to connect two NI-XNET FlexRay interfaces to the ECU, and each NI-XNET interface must transmit a different startup frame.
NI-XNET has two options to transmit a startup frame:
- Key Slot Identifier: The NI-XNET session property node includes a property called Interface:FlexRay:Key Slot Identifier. This property specifies the static slot that the session interface uses to transmit a startup frame. The property is zero by default, meaning that no startup frame transmits. If you set this property, the value specifies the static slot (identifier) to transmit as a coldstart node. The startup frame transmits automatically when the interface starts, and its payload is null (no data). The session can be input or output, and the startup frame is not required in the session’s list of
- Output Startup Frame: If you create an NI-XNET output session, and the session’s list of frames/signals uses a startup frame, the NI-XNET interface acts as a coldstart node. To find startup frames in the database, look for a frame with the FlexRay:Startup? property true. You can use that frame name for an output session or use its identifier as the key slot.
When selecting a startup frame, avoid selecting one that the ECUs you connect to already transmit.
Understanding FlexRay Frame Timing
When you use an NI-XNET database for FlexRay, the properties of each FlexRay frame specify the FlexRay data transfer timing. To understand how the FlexRay frame timing properties apply to NI-XNET sessions, refer to FlexRay Timing Type and Session Mode in the NI-XNET Hardware and Software Manual. In LabVIEW Real-Time, NI-XNET provides a timing source you can use to synchronize your LabVIEW VI with the timing of frames. For more information, refer to Using LabVIEW Real-Time.
7. Using LIN
This section summarizes some useful NI-XNET features specific to the LIN protocol.
Please look at Introduction to the Local Interconnect (LIN) Bus for more on the LIN protocol.
Changing the LIN Schedule
LIN networks (clusters) always include a single ECU in the system called the master. The master transmits a schedule of frame headers. Each frame header is a remote request for a specific frame ID. For each header, a single ECU in the network (slave) responds by transmitting the payload for the requested ID. The master ECU also can respond to a specific header, and thus the master can transmit payload data for the slave ECUs to receive. Unlike some other scheduled protocols such as FlexRay, LIN allows the master ECU to change the schedule of frame headers. For example, the master can initially use a “normal” schedule that requests IDs 1, 2, 3, 4, and then the master can change to a “diagnostic” schedule that requests IDs 60 and 61.
With NI-XNET, you change the LIN schedule using XNET Write (State LIN Schedule Change).vi. When you want the NI-XNET interface to act as a master on the network, you must call this XNET Write VI at least once, to specify the schedule to run. When you write a schedule change, this automatically configures NI-XNET as master (the XNET Session Interface:LIN:Master? property is set to true). As a LIN master, NI-XNET handles all real-time scheduling of frame headers for you, using the LIN interface hardware onboard processor.
If you do not write a schedule change, NI-XNET leaves the interface at its default configuration of slave. As a LIN slave, you still can write signal or frame values to an output session, but NI-XNET waits for each frame’s header to arrive before transmitting payload data.
Understanding LIN Frame Timing
Because LIN is a scheduled network, the headers that the master transmits determine the timing of all frames. To understand how and when each frame transmits, you must examine the entries in each schedule. Each entry transfers one frame (or possibly multiple frames). For more information, refer to the XNET LIN Schedule Entry Type property.
Because it is possible to use a single frame in multiple schedules and schedule entries, the overall timing for an individual frame can be complex. Nevertheless, each LIN schedule entry generally fits the concepts of cyclic and event timing that are common for other protocols such as CAN and FlexRay. For more information about how these concepts apply to LIN, refer to Cyclic and Event Timing in the NI-XNET Hardware and Software Manual.
8. Using LabVIEW Real-Time
The LabVIEW Real-Time (RT) module combines LabVIEW graphical programming with the power of a real-time operating system, enabling you to build real-time applications. NI-XNET provides features and performance specifically designed for LabVIEW RT.
High Priority Loops
Many real-time applications contain at least one loop that must execute at the highest priority. This high-priority loop typically contains code to read inputs, execute a control algorithm, and then write outputs. The high-priority loop executes at a fast period, such as 500 μs (2 kHz). To ensure that the loop diagram executes within the period, the average execution time (cost) of read and write VIs must be low. The execution time also must be consistent from one loop iteration to another (low jitter).
Within NI-XNET, the session modes for single-point I/O are designed for use within high-priority loops. This applies to all four single-point modes: input, output, signal, or frame. XNET Read.vi and XNET Write.vi provide fast and consistent execution time, and they avoid access to shared resources such as the memory manager.
The session modes other than single-point all use queues to store data. Although you can use the queued session modes within a high priority loop, those modes use a variable amount of data for each read/write. This requires a variable amount of time to process the data, which can introduce jitter to the loop. When using the queued modes, measure the performance of your code within the loop to ensure that it meets your requirements even when bus traffic is
variable. When XNET Read.vi and XNET Write.vi execute for the very first loop iteration, they often perform tasks such as auto-start of the session, allocation of internal memory, and so on. These tasks result in high cost for the first iteration compared to any subsequent iteration. When you measure performance of XNET Read.vi and XNET Write.vi, discard the first iteration from the measurement.
For another VI or property node (not XNET Read.vi or XNET Write.vi), you must assume it is not designed for use within high priority loops. The property nodes are designed for configuration purposes. VIs that change state (for example, XNET Start.vi) require time for hardware/software configuration. Nevertheless, there are exceptions for which certain properties and VIs support high-priority use. Refer to the help for the specific features you want to use within a high priority loop. This help may specify an exception.
For more information about Embedded Networks Performance, please look at this document.
XNET I/O Names
You can use a LabVIEW project to program RT targets. When you open a VI front panel on an RT target, that front panel accesses the target remotely (over TCP/IP). When you use an XNET I/O name on a VI front panel on LabVIEW RT, the remote access provides the user interface features of that I/O name. For example, the drop-down list of an XNET Interface provides all CAN, FlexRay, and LIN interfaces on the RT target (for example, a PXI chassis). For the remote access to operate properly, you must connect the LabVIEW RT target using a LabVIEW project. To connect the target, right-click the target in a LabVIEW project and select Connect. The target shows a green LED in project, and the user interface of I/O names is operational. If the RT target is disconnected in a LabVIEW project, each I/O name displays the text (target disconnected) in its drop-down list.
When you create an NI-XNET application for LabVIEW RT, you must assign an alias to your database file. When you deploy to the RT target, the text database file is compressed to an optimized binary format, and that binary file is transferred to the target. When you create NI-XNET sessions using a LabVIEW project, you assign the alias within
the session dialog (for example, Browse for Database File). When you drag the session to a VI under the RT target, then run that VI, NI-XNET automatically deploys the database file to the target.
When you create NI-XNET sessions at run time, you must explicitly deploy the database to the RT target. There are two options for this deployment:
- XNET I/O Names: If you are using I/O names for database objects, you can click on an I/O name and select Manage Database Deployment. This opens a dialog you can use to assign new aliases and deploy them to the RT target.
- File Management Subpalette VIs: To manage database deployment from a VI running on the host (Windows computer), use VIs in the NI-XNET File Management palette. This palette includes VIs to add an alias and deploy the database to the RT target. To delete the database file from the RT target after execution of a test, you perform this undeploy using either option described above.
FlexRay Timing Source
FlexRay is a deterministic protocol, which means it enables ECUs to synchronize code execution and data exchange. When you use LabVIEW to test an ECU that uses these deterministic features, you typically need to synchronize the LabVIEW VI to the FlexRay communication cycle. For example, to validate that the ECU transmits a different value each
FlexRay cycle, you must read that frame every FlexRay cycle. NI-XNET provides XNET Create Timing Source (FlexRay Cycle).vi to create a LabVIEW timing source. You wire this timing source to a LabvIEW timed loop to execute LabVIEW code synchronized to the FlexRay cycle. Because the length of time for each FlexRay cycle is a few milliseconds, LabVIEW RT provides the required real-time execution.
Creating a Built Real-Time Application
NI-XNET supports creation of a real-time application, which you can set to run automatically when you power on the RT target. Create the real-time application by right-clicking Build Specifications under the RT target, then selecting New»Real-Time Application. If you created NI-XNET sessions in a LabVIEW project, those sessions are deployed to the RT target in the same manner as running a VI. Deployment of databases for a real-time application is the same as running a VI.
9. More Information
Please refer to the NI-XNET hardware and Software Manual for more detailed information.