XNET Create Session (Frame Input » Stream) (G Dataflow)

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.

The XNET Interface to use for this session.

Error conditions that occur before this node runs.

The node responds to this input according to standard error behavior.

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

The created session.

Error information.

The node produces this output according to standard error behavior.

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.