Last Modified: September 16, 2019
Creates an XNET session at run time for the Frame Input Stream mode.
.gvi.png)
cluster
The XNET Cluster I/O Name to use for interface configuration. The default value is
:memory:, the in-memory database.
There are six options:
-
Empty in-memory database: cluster is unwired, and the in-memory database is empty (XNET Database Create Object is not used). This option is supported for CAN
only (not FlexRay or LIN). After you create the session, you must set the XNET Session Interface:64bit Baud Rate property
using a Session node. You must set the baud rate prior to starting the session.
-
Pre-defined CAN FD in-memory database: Pass in special in-memory databases :can_fd: and :can_fd_brs:, as the cluster (XNET Database Create Object is not used).
These databases are similar to the empty in-memory database (:memory:), but configure the cluster in either CAN FD or CAN
FD+BRS mode, respectively. After you create the session, you must set the XNET Session Interface:64bit Baud Rate and Interface:CAN:64bit
FD Baud Rate properties using a Session node. You must set these baud rates prior to starting the session.
-
Pre-defined SAE J1939 Database: Pass in the special in-memory database :can_j1939:. This database is similar to the empty in-memory database (:memory:),
but configures the cluster in CAN SAE J1939 application protocol mode. After you create the session, you must set the XNET
Session Interface:64bit Baud Rate property using a Session node. You must set this baud rate prior to starting the session.
-
Cluster within database file: cluster specifies a cluster within a database file. This is the most common option used with FlexRay. The cluster within the FIBEX
database file contains all required properties to configure the interface. For CANdb files, although the file itself does
not specify a CAN baud rate, you provide this when you add an alias to the file within NI-XNET. For LIN, the LDF file format
already specifies the baud rate.
-
Nonempty in-memory database: Call XNET Database Create Object to create a cluster within the in-memory database, use the XNET Cluster property node to
set properties (such as baud rate), then wire from the Cluster node to this cluster.
-
Subordinate: Wire in cluster of :subordinate:. A subordinate session uses the cluster and interface configuration from other sessions. For example, you may have a test
application with which the end user specifies the database file, cluster, and signals to read/write. You also have a second
application with which you want to log all received frames (input stream), but that application does not specify a database.
You run this second application using a subordinate session, meaning it does not configure or start the interface, but depends
on the primary test application. For a subordinate session, start and stop of the interface (using XNET Start) is ignored.
The subordinate session reads frames only when another nonsubordinate session starts the interface.
interface
The XNET Interface to use for this session.
error in
Error conditions that occur before this node runs.
The node responds to this input according to standard error behavior.
Many nodes provide an error in input and an error out output so that the node can respond to and communicate errors that occur while code is running. The value of error in specifies whether an error occurred before the node runs. Most nodes respond to values of error in in a standard, predictable way.
error in does not contain an error
|
error in contains an error
|
 |
 |
If no error occurred before the node runs, the node begins execution normally.
If no error occurs while the node runs, it returns no error. If an error does occur while the node runs, it returns that
error information as error out.
|
If an error occurred before the node runs, the node does not execute. Instead, it returns the error in value as error out.
|
Default: No error
error out
Error information.
The node produces this output according to standard error behavior.
Many nodes provide an error in input and an error out output so that the node can respond to and communicate errors that occur while code is running. The value of error in specifies whether an error occurred before the node runs. Most nodes respond to values of error in in a standard, predictable way.
error in does not contain an error
|
error in contains an error
|
 |
 |
If no error occurred before the node runs, the node begins execution normally.
If no error occurs while the node runs, it returns no error. If an error does occur while the node runs, it returns that
error information as error out.
|
If an error occurred before the node runs, the node does not execute. Instead, it returns the error in value as error out.
|
Where This Node Can Run:
Desktop OS: Windows
FPGA: Supported
Web Server: Not supported in VIs that run in a web application
Recently Viewed Topics