NI XNET XNET Frame Properties

XNET Frame Properties

• 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

Application Protocol

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

Property Class

XNET Frame

Property ID

nxPropFrm_ApplicationProtocol

Description

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.

Cluster

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

Property Class

XNET PDU

Property ID

nxPropPDU_ClusterRef

Description

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.

CAN:I/O Mode

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

Property Class

XNET Frame

Property ID

nxPropFrm_CANioMode

Description

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.

Comment

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

Property Class

XNET Signal

Property ID

nxPropSig_Comment

Description

Comment describing the signal object.

A comment is a string containing up to 65535 characters.

Configuration Status

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

Property Class

XNET Signal

Property ID

nxPropSig_ConfigStatus

Description

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).

Name (Short)

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

Property Class

XNET Subframe

Property ID

nxPropSubfrm_Name

Description

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.

Signals

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

CAN:Extended Identifier?

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

Property Class

XNET Frame

Property ID

nxPropFrm_CANExtID

Description

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.

CAN:Timing Type

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

Property Class

XNET Frame

Property ID

nxPropFrm_CANTimingType

Description

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.

CAN:Transmit Time

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

Property Class

XNET Frame

Property ID

nxPropFrm_CANTxTime

Description

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.

Default Payload

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

Property Class

XNET Frame

Property ID

nxPropFrm_DefaultPayload

Description

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.

Frame Output Single-Point and Frame Output Queued Modes

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.

Frame Output Stream Mode

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

Signal Output Single-Point, Signal Output Waveform, and Signal Output XY Modes

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.

Frame Input Stream and Frame Input Queued Modes

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

Frame Input Single-Point Mode

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

Signal Input Single-Point, Signal Input Waveform, and Signal Input XY Modes

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

FlexRay:Base Cycle

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayBaseCycle

Description

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.

FlexRay:Channel Assignment

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayChAssign

Description

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.

FlexRay:Cycle Repetition

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayCycleRep

Description

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.

FlexRay:Payload Preamble?

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayPreamble

Description

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.

FlexRay:Startup?

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayStartup

Description

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.

FlexRay:Sync?

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayStartup

Description

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.

FlexRay:Timing Type

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayTimingType

Description

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.

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.

Dynamic

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.

FlexRay:In Cycle Repetitions:Channel Assignments

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayInCycRepChAssigns

Description

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.

FlexRay:In Cycle Repetitions:Enabled?

Data Type	Direction	Required?	Default
bool	Read Only	No	False

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayInCycRepEnabled

Description

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.

FlexRay:In Cycle Repetitions:Identifiers

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

Property Class

XNET Frame

Property ID

nxPropFrm_FlexRayInCycRepIDs

Description

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.

Identifier

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

Property Class

XNET Frame

Property ID

nxPropFrm_ID

Description

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.

CAN

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.

FlexRay

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.

LIN

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

LIN:Checksum

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

Property Class

XNET Frame

Property ID

nxPropFrm_LINChecksum

Description

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.

Mux:Data Multiplexer Signal

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

Property Class

XNET PDU

Property ID

nxPropPDU_MuxDataMuxSigRef

Description

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.

Mux:Is Data Multiplexed?

Data Type	Direction	Required?	Default
bool	Read Only	No	False

Property Class

XNET PDU

Property ID

nxPropPDU_MuxIsMuxed

Description

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.

Mux:Static Signals

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

Property Class

XNET PDU

Property ID

nxPropPDU_MuxStaticSigRefs

Description

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.

Mux:Subframes

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

Property Class

XNET PDU

Property ID

nxPropPDU_MuxSubframeRefs

Description

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.

Payload Length

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

Property Class

XNET PDU

Property ID

nxPropPDU_PayloadLen

Description

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.

PDU References

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

Property Class

XNET Frame

Property ID

nxPropFrm_PDURefs

Description

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.

PDU Start Bits

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

Property Class

XNET Frame

Property ID

nxPropFrm_PDUStartBits

Description

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.

PDU Update Bits

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

Property Class

XNET Frame

Property ID

nxPropFrm_PDUUpdateBits

Description

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.