• Application Protocol
• CAN:Extended Identifier?
• CAN:I/O Mode
• CAN:Timing Type
• CAN:Transmit Time
• Cluster
• Comment
• Configuration Status
• Default Payload
• FlexRay:Base Cycle
• FlexRay:Channel Assignment
• FlexRay:Cycle Repetition
• FlexRay:In Cycle Repetitions:Channel Assignments
• FlexRay:In Cycle Repetitions:Enabled?
• FlexRay:In Cycle Repetitions:Identifiers
• FlexRay:Payload Preamble?
• FlexRay:Startup?
• FlexRay:Sync?
• FlexRay:Timing Type
• Identifier
• LIN:Checksum
• Mux:Data Multiplexer Signal
• Mux:Is Data Multiplexed?
• Mux:Static Signals
• Mux:Subframes
• Name (Short)
• Payload Length
• PDU References
• PDU Start Bits
• PDU Update Bits
• Signals

Data Type	Direction	Required?	Default
u32	Read/Write	No	Read from Database

XNET Frame

nxPropFrm_ApplicationProtocol

This property specifies the frame's application protocol. It is an enumerated list of two values:

Enumeration	Value	Description
None	0	The default application protocol.
J1939	1	Indicates J1939 frames. The value enables the following features: - Sending/receiving long frames as the SAE J1939 specification specifies, using the J1939 transport protocol. - Using a special notation for J1939 identifiers.

Data Type	Direction	Required?	Default
nxDatabaseRef_t	Read Only	N/A	N/A

XNET PDU

nxPropPDU_ClusterRef

This property returns the reference (nxDatabaseRef_t) to the parent cluster in which the PDU has been created. You cannot change the parent cluster after creating the PDU object.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Cluster I/O Mode

XNET Frame

nxPropFrm_CANioMode

This property specifies the frame's I/O mode.

• nxCANioMode_CAN (0)
• nxCANioMode_CAN_FD (1)
• nxCANioMode_CAN_FD_BRS (2)

This property is used in ISO CAN FD+BRS mode only. In this mode, you can specify every frame to be transmitted in CAN 2.0, CAN FD, or CAN FD+BRS mode. CAN FD+BRS frames require the interface to be in CAN FD+BRS mode; otherwise, it is transmitted in CAN FD mode.

When the interface is in Non-ISO CAN FD or Legacy ISO CAN FD mode, this property is disregarded. In Non-ISO CAN FD and Legacy ISO CAN FD mode, you must use the Interface:CAN:Transmit I/O Mode property to switch the transmit mode.

When the assigned database does not define the property in ISO CAN FD mode, the frames are transmitted with the Interface:CAN:I/O Mode property.

Data Type	Direction	Required?	Default
char *	Read/Write	No	Empty String

XNET Signal

nxPropSig_Comment

Comment describing the signal object.

A comment is a string containing up to 65535 characters.

Data Type	Direction	Required?	Default
i32	Read Only	No	N/A

XNET Signal

nxPropSig_ConfigStatus

The signal object configuration status.

Configuration Status returns an NI-XNET error code. You can pass the value to the nxStatusToString error code input to convert the value to a text description of the configuration problem.

By default, incorrectly configured signals in the database are not returned from the XNET Frame Signals property because they cannot be used in the bus communication. You can change this behavior by setting the XNET Database ShowInvalidFromOpen? property to true. When a signal configuration status becomes invalid after the database is opened, the signal still is returned from the Signals property even if the ShowInvalidFromOpen? property is false.

Examples of invalid signal configuration:

• The signal is specified using bits outside the frame payload.
• The signal overlaps another signal in the frame. For example, two multiplexed signals with the same multiplexer value are using the same bit in the frame payload.
• The frame containing the signal is invalid (for example, a CAN frame is defined with more than 8 payload bytes).

Data Type	Direction	Required?	Default
char *	Read/Write	Yes	Defined in nxdbCreateObject

XNET Subframe

nxPropSubfrm_Name

String identifying a subframe object.

Lowercase letters (a–z), uppercase letters (A–Z), numbers, and the underscore (_) are valid characters for the short name. The space ( ), period (.), and other special characters are not supported within the name. The short name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The short name is limited to 128 characters.

A subframe name must be unique for all subframes in a frame.

This short name does not include qualifiers to ensure that it is unique, such as the database, cluster, and frame name. It is for display purposes.

You can write this property to change the subframe's short name.

Each frame contains an arbitrary number of signals, which are the basic data exchange units on the network. These signals are equivalent to NI-CAN channels.

Some of the signal properties are:

• Start bit: the signal start position within the frame
• Number of bits: the signal length within the frame
• Data type: the data type (signed, unsigned, or float)
• Byte order: little or big endian
• Scaling factor and offset: for converting physical data to binary representation

Data Type	Direction	Required?	Default
bool	Read/Write	No	False

XNET Frame

nxPropFrm_CANExtID

This property determines whether the XNET Frame Identifier property in a CAN cluster represents a standard 11-bit (false) or extended 29-bit (true) arbitration ID.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Event Data (If Not in Database)

XNET Frame

nxPropFrm_CANTimingType

Specifies the CAN frame timing.

Because this property specifies the behavior of the frame's transfer within the embedded system (for example, a vehicle), it describes the transfer between ECUs in the network. In the following description, transmitting ECU refers to the ECU that transmits the CAN data frame (and possibly receives the associated CAN remote frame). Receiving ECU refers to an ECU that receives the CAN data frame (and possibly transmits the associated CAN remote frame).

When you use the frame within an NI-XNET session, an output session acts as the transmitting ECU, and an input session acts as a receiving ECU. For a description of how these CAN timing types apply to the NI-XNET session mode, refer to CAN Timing Type and Session Mode.

The CAN timing types (decimal value in parentheses) are:

nxFrmCANTiming_CyclicData (0)

The transmitting ECU transmits the CAN data frame in a cyclic (periodic) manner. The XNET Frame CAN:Transmit Time property defines the time between cycles. The transmitting ECU ignores CAN remote frames received for this frame.

nxFrmCANTiming_EventData (1)

The transmitting ECU transmits the CAN data frame in an event-driven manner. The XNET Frame CAN:Transmit Time property defines the minimum interval. For NI-XNET, the event occurs when you call nxWrite. The transmitting ECU ignores CAN remote frames received for this frame.

nxFrmCANTiming_CyclicRemote (2)

The receiving ECU transmits the CAN remote frame in a cyclic (periodic) manner. The XNET Frame CAN:Transmit Time property defines the time between cycles. The transmitting ECU responds to each CAN remote frame by transmitting the associated CAN data frame.

nxFrmCANTiming_EventRemote (3)

The receiving ECU transmits the CAN remote frame in an event-driven manner. The XNET Frame CAN:Transmit Time property defines the minimum interval. For NI-XNET, the event occurs when you call nxWriteFrame. The transmitting ECU responds to each CAN remote frame by transmitting the associated CAN data frame.

nxFrmCANTiming_CyclicEvent (4)

This timing type is a combination of the cyclic and event timing. The frame is transmitted when you call the nxWriteFrame, but also periodically sending the last recent values written. The XNET Frame CAN:Transmit Time property defines the cycle period. There is no minimum interval time defined in this mode, so be careful not to write too frequently to avoid creating a high busload.

If you are using a FIBEX or AUTOSAR database, this property is a required part of the XML schema for a frame, so the default (initial) value is obtained from the file.

If you are using a CANdb (.dbc) database, this property is an optional attribute in the file. If NI-XNET finds an attribute named GenMsgSendType, that attribute is the default value of this property. If the GenMsgSendType attribute begins with cyclic, this property's default value is Cyclic Data; otherwise, it is Event Data. If the CANdb file does not use the GenMsgSendType attribute, this property uses a default value of Event Data, which you can change in your application.

If you are using an .ncd database or an in-memory database (XNET Create Frame), this property uses a default value of Event Data. Within your application, change this property to the desired timing type.

Data Type	Direction	Required?	Default
Double	Read/Write	No	0.1 (If Not in Database)

XNET Frame

nxPropFrm_CANTxTime

Specifies the time between consecutive frames from the transmitting ECU.

The data type is 64-bit floating point (DBL). The units are in seconds.

Although the fractional part of the DBL data type can provide resolution of picoseconds, the NI-XNET CAN transmit supports an accuracy of 500 µs. Therefore, when used within an NI-XNET output session, this property is rounded to the nearest 500 µs increment (0.0005).

For an XNET Frame CAN:Timing Type of Cyclic Data or Cyclic Remote, this property specifies the time between consecutive data/remote frames. A time of 0.0 is invalid.

For an XNET Frame CAN:Timing Type of Event Data or Event Remote, this property specifies the minimum time between consecutive data/remote frames when the event occurs quickly. This is also known as the debounce time or minimum interval. The time is measured from the end of previous frame (acknowledgment) to the start of the next frame. A time of 0.0 specifies no minimum (back to back frames allowed).

If you are using a FIBEX or AUTOSAR database, this property is a required part of the XML schema for a frame, so the default (initial) value is obtained from the file.

If you are using a CANdb (.dbc) database, this property is an optional attribute in the file. If NI-XNET finds an attribute named GenMsgCycleTime, that attribute is interpreted as a number of milliseconds and used as the default value of this property. If the CANdb file does not use the GenMsgCycleTime attribute, this property uses a default value of 0.1 (100 ms), which you can change in your application.

If you are using a .ncd database or an in-memory database (XNET Create Frame), this property uses a default value of 0.1 (100 ms). Within your application, change this property to the desired time.

Data Type	Direction	Required?	Default
u8 *	Read/Write	No	Array of All 0 or 0xFF (J1939)

XNET Frame

nxPropFrm_DefaultPayload

The frame default payload, specified as an array of bytes (U8).

The number of bytes in the array must match the XNET Frame Payload Length property.

This property's initial value is an array of all 0, except the frame is located in a CAN cluster with J1939 application protocol, which uses 0xFF by default. For the database formats NI-XNET supports, this property is not provided in the database file.

When you use this frame within an NI-XNET session, this property's use varies depending on the session mode. The following sections describe this property's behavior for each session mode.

Use this property when a frame transmits prior to a call to nxWrite. This can occur when you set the XNET Session AutoStart? property to false and call nxStart prior to nxWrite. When AutoStart? is true (default), the first call to nxWrite also starts frame transmit, so this property is not used.

The following frame configurations potentially can transmit prior to a call to nxWrite:

• XNET Frame CAN:Timing Type of Cyclic Data.
• XNET Frame CAN:Timing Type of Cyclic Remote (for example, a remote frame received prior to a call to nxWrite).
• XNET Frame CAN:Timing Type of Event Remote (for example, a remote frame received prior to a call to nxWrite).
• XNET Frame CAN:Timing Type) of Cyclic.
• LIN frame in a schedule entry of type unconditional.

The following frame configurations cannot transmit prior to a call to nxWrite, so this property is not used:

• XNET Frame CAN:Timing Type of Event Data.
• XNET Frame FlexRay:Timing Type of Event.
• LIN frame in a schedule entry of type sporadic or event triggered.

This property is not used. Transmit is limited to frames provided to nxWrite.

Use this property when a frame transmits prior to a call to nxWrite. Refer to Frame Output Single-Point and Frame Output Queued Modes for a list of applicable frame configurations.

This property is used as the initial payload, then each XNET Signal Default Value is mapped into that payload, and the result is used for the frame transmit.

This property is not used. These modes do not return data prior to receiving frames.

This property is used for frames nxRead returns prior to receiving the first frame.

This property is not used. Each XNET Signal Default Value is used when nxRead is called prior to receiving the first frame.

Data Type	Direction	Required?	Default
u32	Read/Write	Yes	N/A

XNET Frame

nxPropFrm_FlexRayBaseCycle

The first communication cycle in which a frame is sent.

In FlexRay, a communication cycle contains a number of slots in which a frame can be sent. Every node on the bus provides a 6-bit cycle counter that counts the cycles from 0 to 63 and then restarts at 0. The cycle number is common for all nodes on the bus.

NI-XNET has two mechanisms for changing the frame sending frequency:

• If the frame should be sent faster than the cycle period, use In-Cycle Repetition (refer to the XNET Frame FlexRay:In Cycle Repetitions:Identifiers property).
• If the frame should be sent slower than the cycle period, use this property and the XNET Frame FlexRay:Cycle Repetition property.

The second method is called cycle multiplexing. It allows sending multiple frames in the same slot, but on different cycle counters.

If a frame should be sent in every cycle, set this property to 0 and the XNET Frame FlexRay:Cycle Repetition property to 1. For cycle multiplexing, set the FlexRay:Cycle Repetition property to 2, 4, 8, 16, 32, or 64.

Example:

• FrameA and FrameB are both sent in slot 12.
• FrameA: The FlexRay:Base Cycle property is 0 and XNET Frame FlexRay:Cycle Repetition property is 2. This frame is sent when the cycle counter has the value 0, 2, 4, 6, ....
• FrameB: The FlexRay:Base Cycle property is 1 and XNET Frame FlexRay:Cycle Repetition property is 2. This frame is sent when the cycle counter has the value 1, 3, 5, 7, ....

This property is required. If the property does not contain a valid value, and you create an XNET session that uses this frame, the session returns an error. To ensure that the property contains a valid value, you can do one of the following:

• Use a database file (or alias) to create the session.

  The file formats require a valid value in the text for this property.

• Set a value using the nxdbSetProperty function.

  This is needed when you create your own in-memory database (:memory:) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session.

For more information about using database files and in-memory databases, refer to Databases.

Data Type	Direction	Required?	Default
u32	Read/Write	Yes	N/A

XNET Frame

nxPropFrm_FlexRayChAssign

This property determines on which FlexRay channels the frame must be transmitted. A frame can be transmitted only on existing FlexRay channels, configured in the XNET Cluster FlexRay:Channels property.

Frames in the dynamic FlexRay segment cannot be sent on both channels; they must use either channel A or B. Frames in the dynamic segment use slot IDs greater than the number of static slots cluster parameter.

This property is required. If the property does not contain a valid value, and you create an XNET session that uses this frame, the session returns an error. To ensure that the property contains a valid value, you can do one of the following:

• Use a database file (or alias) to create the session.

  The file formats require a valid value in the text for this property.

• Set a value using the nxdbSetProperty function.

  This is needed when you create your own in-memory database (:memory:) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session.

For more information about using database files and in-memory databases, refer to Databases.

Data Type	Direction	Required?	Default
u32	Read/Write	Yes	N/A

XNET Frame

nxPropFrm_FlexRayCycleRep

The number of cycles after which a frame is sent again.

In FlexRay, a communication cycle contains a number of slots in which a frame can be sent. Every node on the bus provides a 6-bit cycle counter that counts the cycles from 0 to 63 and then restarts at 0. The cycle number is common for all nodes on the bus.

NI-XNET has two mechanisms for changing the frame sending frequency:

• If the frame should be sent faster than the cycle period, use In-Cycle Repetition (refer to the XNET Frame FlexRay:In Cycle Repetitions:Identifiers property).
• If the frame should be sent slower than the cycle period, use the XNET Frame FlexRay:Base Cycle property and this property.

The second method is called cycle multiplexing. It allows sending multiple frames in the same slot, but on different cycle counters.

If a frame should be sent in every cycle, set the XNET Frame FlexRay:Base Cycle property property to 0 and this property to 1. For cycle multiplexing, set this property to 2, 4, 8, 16, 32, or 64.

Examples:

• FrameA and FrameB are both sent in slot 12.
• FrameA: The XNET Frame FlexRay:Base Cycle property is set to 0 and FlexRay:Cycle Repetition property is set to 2. This frame is sent when the cycle counter has the value 0, 2, 4, 6, ....
• FrameB: The XNET Frame FlexRay:Base Cycle property is set to 1 and FlexRay:Cycle Repetition property is set to 2. This frame is sent when the cycle counter has the value 1, 3, 5, 7, ....

This property is required. If the property does not contain a valid value, and you create an XNET session that uses this frame, the session returns an error. To ensure that the property contains a valid value, you can do one of the following:

• Use a database file (or alias) to create the session.

  The file formats require a valid value in the text for this property.

• Set a value using the nxdbSetProperty function.

  This is needed when you create your own in-memory database (:memory:) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session.

For more information about using database files and in-memory databases, refer to Databases.

Data Type	Direction	Required?	Default
bool	Read/Write	No	False

XNET Frame

nxPropFrm_FlexRayPreamble

This property determines whether payload preamble is used in a FlexRay frame:

• For frames in the static segment, it indicates that the network management vector is transmitted at the beginning of the payload.
• For frames in the dynamic segment, it indicates that the message ID is transmitted at the beginning of the payload.

Data Type	Direction	Required?	Default
bool	Read/Write	No	False

XNET Frame

nxPropFrm_FlexRayStartup

This property determines whether the frame is a FlexRay startup frame. FlexRay startup frames always are FlexRay sync frames also.

• When this property is set to true, the XNET Frame FlexRay:Sync? property automatically is set to true.
• When this property is set to false, the XNET Frame FlexRay:Sync? property is not changed.
• When the XNET Frame FlexRay:Sync? property is set to false, this property automatically is set to false.
• When the XNET Frame FlexRay:Sync? property is set to true, this property is not changed.

An ECU can send only one startup frame. The startup frame, if an ECU transmits it, is returned from the XNET ECU FlexRay:Startup Frame property.

Data Type	Direction	Required?	Default
bool	Read/Write	No	False

XNET Frame

nxPropFrm_FlexRayStartup

This property determines whether the frame is a FlexRay sync frame. FlexRay startup frames always are FlexRay sync frames also:

• When this property is set to false, the XNET Frame FlexRay:Startup? property is automatically set to false.
• When this property is set to true, the XNET Frame FlexRay:Startup? property is not changed.
• When the XNET Frame FlexRay:Startup? property is set to true, this property is set to true.
• When the XNET Frame FlexRay:Startup? property is set to false, this property is not changed.

An ECU can send only one sync frame.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Cyclic in Static Segment, Event in Dynamic Segment

XNET Frame

nxPropFrm_FlexRayTimingType

Specifies the FlexRay frame timing (decimal value in parentheses):

nxFrmFlexRayTiming_Cyclic (0)

Payload data transmits on every occurrence of the frame's slot.

nxFrmFlexRayTiming_Event (1)

Payload data transmits in an event-driven manner. Within the ECU that transmits the frame, the event typically is associated with the availability of new data.

This property's behavior depends on the FlexRay segment where the frame is located: static or dynamic. If the frame's Identifier (slot) is less than or equal to the cluster's Number Of Static Slots, the frame is static.

Cyclic means no null frame is transmitted. If new data is not provided for the cycle, the previous payload data transmits again.

Event means a null frame is transmitted when no event is pending for the cycle.

This property's default value for the static segment is Cyclic.

Cyclic means the frame transmits in its minislot on every cycle.

Event means the frame transmits in the minislot when the event is pending for the cycle.

This property's default value for the dynamic segment is Event.

For a description of how these FlexRay timing types apply to the NI-XNET session mode, refer to FlexRay Timing Type and Session Mode.

Data Type	Direction	Required?	Default
u32 *	Read/Write	No	Empty Array

XNET Frame

nxPropFrm_FlexRayInCycRepChAssigns

FlexRay channels for in-cycle frame repetition.

A FlexRay frame can be sent multiple times per cycle. The XNET Frame FlexRay:Channel Assignment property defines the first channel assignment in the cycle. This property defines subsequent channel assignments. The XNET Frame FlexRay:In Cycle Repetitions:Identifiers property defines the corresponding slot IDs. Both properties are arrays of maximum three values, determining the slot ID and channel assignments for the frame. Values at the same array position are corresponding; therefore, both arrays must have the same size.

You must set the XNET Frame FlexRay:Channel Assignment property before setting this property. The FlexRay:Channel Assignment is a required property that is undefined when a new frame is created. When FlexRay:Channel Assignment is undefined, setting FlexRay:In Cycle Repetitions:Channel Assignments returns an error.

Data Type	Direction	Required?	Default
bool	Read Only	No	False

XNET Frame

nxPropFrm_FlexRayInCycRepEnabled

FlexRay in-cycle frame repetition is enabled.

A FlexRay frame can be sent multiple times per cycle. The XNET Frame Identifier property defines the first slot ID in the cycle. The XNET Frame FlexRay:In Cycle Repetitions:Identifiers property can define the subsequent slot IDs, and the FlexRay:In Cycle Repetitions:Identifiers property defines the corresponding FlexRay channels. Both properties are arrays of maximum three values determining the slot ID and FlexRay channels for the frame. Values at the same array position are corresponding; therefore, both arrays must have the same size.

This property returns true when at least one in-cycle repetition has been defined, which means that both the FlexRay:In Cycle Repetitions:Identifiers] and XNET Frame FlexRay:In Cycle Repetitions:Channel Assignments arrays are not empty.

This property returns false when at least one of the previously mentioned arrays is empty. In this case, in-cycle-repetition is not used.

Data Type	Direction	Required?	Default
u32 *	Read/Write	No	Empty Array

XNET Frame

nxPropFrm_FlexRayInCycRepIDs

FlexRay in-cycle repetition slot IDs.

A FlexRay frame can be sent multiple times per cycle. The XNET Frame Identifier property defines the first slot ID in the cycle. The FlexRay:In Cycle Repetitions:Identifiers property defines subsequent slot IDs. The XNET Frame FlexRay:In Cycle Repetitions:Channel Assignments property defines the corresponding FlexRay channel assignments. Both properties are arrays of maximum three values, determining the subsequent slot IDs and channel assignments for the frame. Values at the same array position are corresponding; therefore, both arrays must have the same size.

You must set the XNET Frame Identifier property before setting the FlexRay:In Cycle Repetitions:Identifiers property. Identifier is a required property that is undefined when a new frame is created. When Identifier is undefined, setting in-cycle repetition slot IDs returns an error.

Data Type	Direction	Required?	Default
u32	Read/Write	Yes	N/A

XNET Frame

nxPropFrm_ID

Determines the frame identifier.

This property is required. If the property does not contain a valid value, and you create an XNET session that uses this frame, the session returns an error. To ensure that the property contains a valid value, you can do one of the following:

• Use a database file (or alias) to create the session.

  The file formats require a valid value in the text for this property.

• Set a value using the nxdbSetProperty function.

  This is needed when you create your own in-memory database (:memory:) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session.

For more information about using database files and in-memory databases, refer to Databases.

For CAN frames, this is the Arbitration ID.

When the XNET Frame CAN:Extended Identifier? property is set to false, this is the standard CAN identifier with a size of 11 bits, which results in allowed range of 0-2047. However, the CAN standard disallows identifiers in which the first 7 bits are all recessive, so the working range of identifiers is 0–2031.

When the XNET Frame CAN:Extended Identifier? property is set to true, this is the extended CAN identifier with a size of 29 bits, which results in allowed range of 0–536870911.

For FlexRay frames, this is the Slot ID in which the frame is sent. The valid value range for a FlexRay Slot ID is 1–2047.

You also can send a FlexRay frame in multiple slots per cycle. You can define subsequent slot IDs for the frame in the XNET Frame FlexRay:In Cycle Repetitions:Identifiers property. Use this concept to increase a frame's sending frequency. To decrease a frame's sending frequency and share the same slot for different frames depending on the cycle counter, refer to the XNET Frame FlexRay:Base Cycle and XNET Frame FlexRay:Cycle Repetition properties.

The slot ID determines whether a FlexRay frame is sent in a static or dynamic segment. If the slot ID is less than or equal to the XNET Cluster FlexRay:Number of Static Slots property, the frame is sent in the communication cycle static segment; otherwise, it is sent in the dynamic segment.

If the frame identifier is not in the allowed range, this is reported as an error in the XNET Cluster Configuration Status property.

For LIN frames, this is the frame's ID (unprotected). The valid range for a LIN frame ID is 0–63 (inclusive).

Data Type	Direction	Required?	Default
u32	Read Only	N/A	nxFrmLINChecksum_Enhanced

XNET Frame

nxPropFrm_LINChecksum

Determines whether the LIN frame transmitted checksum is classic or enhanced. The enhanced checksum considers the protected identifier when it is generated.

The values (enumeration) for this property are:

nxFrmLINChecksum_Classic	0
nxFrmLINChecksum_Enhanced	1
The checksum is determined from the LIN version of ECUs transmitting and receiving the frame. The lower version of both ECUs is significant. If the LIN version of both ECUs is 2.0 or higher, the checksum type is enhanced; otherwise, the checksum type is classic.

Diagnostic frames (with decimal identifier 60 or 61) always use classic checksum, even on LIN 2.x.

Data Type	Direction	Required?	Default
nxDatabaseRef_t	Read Only	N/A	N/A

XNET PDU

nxPropPDU_MuxDataMuxSigRef

Data multiplexer signal in the PDU.

This property returns the reference to the data multiplexer signal. If data multiplexer is not defined in the PDU, the property returns 0. Use the XNET PDU Mux:Is Data Multiplexed? property to determine whether the PDU contains a multiplexer signal.

You can create a data multiplexer signal by creating a signal and then setting the XNET Signal Mux:Data Multiplexer? property to true.

A PDU can contain only one data multiplexer signal.

Data Type	Direction	Required?	Default
bool	Read Only	No	False

XNET PDU

nxPropPDU_MuxIsMuxed

PDU is data multiplexed.

This property returns true if the PDU contains a multiplexer signal. PDUs containing a multiplexer contain subframes that allow using bits of the payload for different information (signals), depending on the multiplexer value.

Data Type	Direction	Required?	Default
nxDatabaseRef_t *	Read Only	N/A	N/A

XNET PDU

nxPropPDU_MuxStaticSigRefs

Static signals in the PDU.

Returns an array of references to signals in the PDU that do not depend on the multiplexer value. Static signals are contained in every PDU transmitted, as opposed to dynamic signals, which are transmitted depending on the multiplexer value.

You can create static signals by specifying the PDU as the parent object. You can create dynamic signals by specifying a subframe as the parent.

If the PDU is not multiplexed, this property returns the same array as the XNET PDU Signals property.

Data Type	Direction	Required?	Default
nxDatabaseRef_t *	Read Only	N/A	N/A

XNET PDU

nxPropPDU_MuxSubframeRefs

Returns an array of references to subframes in the PDU. A subframe defines a group of signals transmitted using the same[multiplexer value. Only one subframe is transmitted in the PDU at a time.

You can define a subframe by creating a subframe object as a child of a PDU.

Data Type	Direction	Required?	Default
u32	Read/Write	Yes	N/A

XNET PDU

nxPropPDU_PayloadLen

Determines the size of the PDU data in bytes.

This property is required. If the property does not contain a valid value, and you create an XNET session that uses this PDU, the session returns an error. To ensure that the property contains a valid value, you can do one of the following:

• Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property.
• Set a value using the nxdbSetProperty function. This is required when you create your own in-memory database (:memory:) rather than using a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session.

For more information about using database files and in-memory databases, refer to Databases.

Data Type	Direction	Required?	Default
nxDatabaseRef_t *	Read/Write	No	Empty Array

XNET Frame

nxPropFrm_PDURefs

This property maps existing PDUs to a frame. A mapped PDU is transmitted inside the frame payload when the frame is transmitted. You can map one or more PDUs to a frame and one PDU to multiple frames.

Mapping PDUs to a frame requires setting three frame properties. All three properties are arrays of values:

• PDU References: Set this property first to define the sequence of values for the other two properties.
• PDU Start Bits: Defines the start bit of the PDU inside the frame.
• PDU Update Bits: Defines the update bit for the PDU inside the frame. If the update bit is not used, set the value to –1. (Refer to Update Bit for more information.)

Values on the same array position are corresponding. For example, PDUs[0], StartBits[0], and UpdateBits[0] define the mapping for the first PDU in the frame.

Databases imported from FIBEX prior to version 3.0, from DBC, NCD, or LDF files have a strong one-to-one relationship between frames and PDUs. Every frame has exactly one PDU mapped, and every PDU is mapped to exactly one frame.

To unmap PDUs from a frame, set this property to an empty array. A frame without mapped PDUs contains no signals.

NI-XNET supports advanced PDU configuration (multiple PDUs in one frame or one PDU used in multiple frames) only for FlexRay. Refer to the XNET Cluster PDUs Required? property.

For CAN and LIN, NI-XNET supports only a one-to-one relationship between frames and PDUs. For those interfaces, advanced PDU configuration returns an error from the XNET Frame Configuration Status property and nxCreateSession. If you do not use advanced PDU configuration, you can avoid using PDUs in the database API and create signals and subframes directly on a frame.

Data Type	Direction	Required?	Default
u32 *	Read/Write	No	Empty Array

XNET Frame

nxPropFrm_PDUStartBits

This property defines the start bits of PDUs mapped to a frame. A mapped PDU is transmitted inside the frame payload when the frame is transmitted. You can map one or more PDUs to a frame and one PDU to multiple frames.

Mapping PDUs to a frame requires setting of three frame properties. All three properties are arrays of values:

• PDU References: Set this property first to define the sequence of values for the other two properties.
• PDU Start Bits: This property defines the start bit of the PDU inside the frame.
• PDU Update Bits: Defines the update bit for the PDU inside the frame. If the update bit is not used, set the value to –1. (Refer to Update Bit for more information.)

Values on the same array position are corresponding. For example, PDUs[0], StartBits[0], and UpdateBits[0] define the mapping for the first PDU in the frame.

Note  PDUs used in FlexRay I/O are required to have byte-aligned start bits.

Data Type	Direction	Required?	Default
u32 *	Read/Write	No	Empty Array

XNET Frame

nxPropFrm_PDUUpdateBits

This property defines update bits of PDUs mapped to a frame. If the update bit is not used for the PDU, set the value to –1. (Refer to Update Bit for more information.)

Mapping PDUs to a frame requires setting three frame properties. All three properties are arrays of values:

• PDU References: Set this property first to define the sequence of values for the other two properties.
• PDU Start Bits: Defines the start bit of the PDU inside the frame.
• PDU Update Bits: This property defines the update bit for the PDU inside the frame. If the update bit is not used, set the value to –1.

Values on the same array position are corresponding. For example, PDUs[0], StartBits[0], and UpdateBits[0] define the mapping for the first PDU in the frame.