Stream

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 node responds to this input according to standard error behavior.

Standard Error Behavior

Default value: No error

The node produces this output according to standard error behavior.

Standard Error Behavior