• Interface:64bit Baud Rate
• Interface:Adjust Local Time
• Interface:Echo Transmit?
• Interface:I/O Name
• Interface:Output Stream List
• Interface:Output Stream List By ID
• Interface:Output Stream Timing
• Interface:Start Trigger Frames to Input Stream?
• Interface:Bus Error Frames to Input Stream?
• Interface:CAN:64bit FD Baud Rate
• Interface:CAN:Disable Protocol Exception Handling
• Interface:CAN:Enable Edge Filter
• Interface:CAN:External Transceiver Config
• Interface:CAN:FD ISO Mode
• Interface:CAN:I/O Mode
• Interface:CAN:Listen Only?
• Interface:CAN:Pending Transmit Order
• Interface:CAN:Single Shot Transmit?
• Interface:CAN:Termination
• Interface:CAN:Transceiver State
• Interface:CAN:Transceiver Type
• Interface:CAN:Transmit I/O Mode
• Interface:CAN:Transmit Pause
• Interface:Ethernet:IPv4 Address
• Interface:Ethernet:Link Speed
• Interface:Ethernet:Link Speed Configured
• Interface:Ethernet:Jumbo Frames
• Interface:Ethernet:MAC Address
• Interface:Ethernet:Operational Status
• Interface:Ethernet:OS Network Adapter Name
• Interface:Ethernet:OS Network Adapter Description
• Interface:Ethernet:Output Stream Timescale
• Interface:Ethernet:PHY Power Mode
• Interface:Ethernet:PHY State
• Interface:Ethernet:Port Mode
• Interface:Ethernet:Signal Quality
• Interface:Ethernet:Sleep Capability
• Interface:Ethernet:Trigger PPS Synced?
• Interface:Ethernet:Statistics:Counter Names
• Interface:Ethernet:Statistics:Counter Values
• Interface:Ethernet:Statistics:Rx Bytes Count
• Interface:Ethernet:Statistics:Rx Good Frames Count
• Interface:Ethernet:Statistics:Rx Bad Frames Count
• Interface:Ethernet:Statistics:Tx Bytes Count
• Interface:Ethernet:Statistics:Tx Good Frames Count
• Interface:FlexRay:Accepted Startup Range
• Interface:Ethernet:Statistics:PHY:Counter Values
• Interface:Ethernet:Statistics:PHY:Low Power Sleep Count
• Interface:Ethernet:Statistics:PHY:Sleep Failure Count
• Interface:Ethernet:Statistics:PHY:Wake Up Failure Count
• Interface:Ethernet:Statistics:PHY:Wake Up Pulse Count
• Interface:Ethernet:Statistics:PHY:Wake Up Request Count
• Interface:Ethernet:Endpoint:Receive Filter
• Interface:Ethernet:Endpoint:Transmit Bandwidth
• Interface:Ethernet:Time Sync:Protocol
• Interface:Ethernet:Time Sync:Protocol Enabled?
• Interface:Ethernet:Time Sync:BMCA Enabled?
• Interface:Ethernet:Time Sync:Offset From Master
• Interface:Ethernet:Time Sync:Clock ID
• Interface:Ethernet:Time Sync:Clock Class
• Interface:Ethernet:Time Sync:Clock Accuracy
• Interface:Ethernet:Time Sync:Clock Offset Scaled Log Variance
• Interface:Ethernet:Time Sync:Priority1
• Interface:Ethernet:Time Sync:Priority2
• Interface:Ethernet:Time Sync:Steps to Grandmaster
• Interface:Ethernet:Time Sync:Grandmaster Clock ID
• Interface:Ethernet:Time Sync:Grandmaster Clock Class
• Interface:Ethernet:Time Sync:Grandmaster Clock Accuracy
• Interface:Ethernet:Time Sync:Grandmaster Clock Offset Scaled Log Variance
• Interface:Ethernet:Time Sync:Grandmaster Priority1
• Interface:Ethernet:Time Sync:Grandmaster Priority2
• Interface:Ethernet:Time Sync:Adjust Network Time
• Interface:Ethernet:Time Sync:Port:Port State Configured
• Interface:Ethernet:Time Sync:Port:Port State
• Interface:Ethernet:Time Sync:Port:Propagation Delay
• Interface:Ethernet:Time Sync:Port:Propagation Delay Configured
• Interface:Ethernet:Time Sync:Port:Propagation Delay Threshold
• Interface:Ethernet:Time Sync:Port:Pdelay Enabled?
• Interface:Ethernet:Time Sync:Port:Log Pdelay_Req Interval Configured
• Interface:Ethernet:Time Sync:Port:Log Pdelay_Req Interval
• Interface:Ethernet:Time Sync:Port:Log Sync Interval Configured
• Interface:Ethernet:Time Sync:Port:Log Sync Interval
• Interface:Ethernet:Time Sync:Port:Sync Receipt Timeout
• Interface:Ethernet:Time Sync:Port:Log Announce Interval Configured
• Interface:Ethernet:Time Sync:Port:Log Announce Interval
• Interface:Ethernet:Time Sync:Port:Announce Transmit Enabled?
• Interface:Ethernet:Time Sync:Port:Announce Receipt Timeout
• Interface:Ethernet:Time Sync:Port:AS Capable?
• Interface:Ethernet:Time Sync:Port:Synced?
• Interface:Ethernet:Time Sync:Port:Sync Stat
• Interface:Ethernet:Time Sync:Port:Statistics:Counter Names
• Interface:Ethernet:Time Sync:Port:Statistics:Counter Values
• Interface:Ethernet:Time Sync:Port:Statistics:Rx Sync Count
• Interface:Ethernet:Time Sync:Port:Statistics:Rx Announce Count
• Interface:Ethernet:Time Sync:Port:Statistics:Rx Pdelay Request Count
• Interface:Ethernet:Time Sync:Port:Statistics:Tx Sync Count
• Interface:Ethernet:Time Sync:Port:Statistics:Tx Announce Count
• Interface:Ethernet:Time Sync:Port:Statistics:Tx Pdelay Request Count
• Interface:Ethernet:Time Sync:Port:Statistics:Counter Names
• Interface:Ethernet:Time Sync:Port:Statistics:Counter Values
• Interface:Ethernet:Time Sync:Port:Statistics:Rx Sync Count
• Interface:Ethernet:Time Sync:Port:Statistics:Rx Announce Count
• Interface:Ethernet:Time Sync:Port:Statistics:Rx Pdelay Request Count
• Interface:Ethernet:Time Sync:Port:Statistics:Tx Sync Count
• Interface:Ethernet:Time Sync:Port:Statistics:Tx Announce Count
• Interface:Ethernet:Time Sync:Port:Statistics:Tx Pdelay Request Count
• Interface:LIN:Break Delimiter Length
• Interface:LIN:Break Length
• Interface:LIN:DiagP2min
• Interface:LIN:DiagSTmin
• Interface:LIN:Master?
• Interface:LIN:No Response Frames to Input Stream?
• Interface:LIN:Checksum to Input Stream?
• Interface:LIN:Output Stream Slave Response List By NAD
• Interface:LIN:Schedule Names
• Interface:LIN:Sleep
• Interface:LIN:Start Allowed without Bus Power?
• Interface:LIN:Termination
• Interface:Source Terminal:Start Trigger

Data Type	Direction	Required?	Default
u64	Read/Write	Yes (If Not in Database)	0 (If Not in Database)

XNET Session

nxPropSession_IntfBaudRate64

Note  You can modify this property only when the interface is stopped.

Note  This property replaces the former 32-bit property. You still can use the baud rate values used with the 32-bit property. The custom 64-bit baud rate setting requires using values greater than 32 bit. The Interface:64bit Baud Rate property sets the CAN, FlexRay, or LIN interface baud rate. The default value for this interface property is the same as the cluster's baud rate in the database. Your application can set this interface baud rate to override the value in the database, or when no database is used.

When the upper nibble (0xF0000000) is clear, this is a numeric baud rate (for example, 500000).

NI-XNET CAN hardware currently accepts the following numeric baud rates: 33333, 40000, 50000, 62500, 80000, 83333, 100000, 125000, 160000, 200000, 250000, 400000, 500000, 800000, and 1000000.

Note  The 33333 baud rate is supported with single-wire transceivers only.

Note  Baud rates greater than 125000 are supported with high-speed transceivers only. When the upper nibble of the lower 32 bit is set to 0xA (that is, 0xA0000000), the remaining bits provide fields for more custom CAN communication baud rate programming. The fields are shown in the following table:

**	63..32	31..28	27..0
Normal	Res	b0000	Baud Rate (33.3 k–1 M)

**	63..46	45..32	31..28	27..23	22..16	15..8	7	6..0
Custom 64 Bit	Res	Tq	b1010	Res	NSJW	NTSEG1	Res	NTSEG2

• Time quantum (Tq), which is used to program the baud rate prescaler.
  • Valid values are 25–12800, in increments of 0x19 (25 decimal).
  • This is the time quantum from ISO 11898-1, 12.4.1 Bit Encoding/Decoding.
• (Re-)Synchronization Jump Width (NSJW)
  • Valid values are 0–127.
  • The actual hardware interpretation of this value is one more than the programmed value.
• Time Segment 1 (NTSEG1), which is the time segment before the sample point.
  • Valid values are 1–0xFF (1–255 decimal).
  • This is the NTSEG1 value from the Bosch M_CAN Controller Area Network User's Manual, version 3.2.1.
  • The actual hardware interpretation of this value is one more than the programmed value.
• Time Segment 2 (NTSEG2), which is the time segment after the sample point.
  • Valid values are 0–0x7F (0–127 decimal).
  • This is the NTSEG2 value from the Bosch M_CAN Controller Are a Network User's Manual, version 3.2.1.
  • The actual hardware interpretation of this value is one more than the programmed value.

For the former 32-bit baud rate property, the following table is valid.

When the upper nibble is set to 0x8 (that is, 0x80000000), the remaining bits provide fields for more custom CAN communication baud rate programming. Additionally, if the upper nibble is set to 0xC (that is, 0xC0000000), the remaining bits provide fields for higher-precision custom CAN communication baud rate programming. The higher-precision bit timings facilitate connectivity to a CAN FD cluster.

**	31..28	27..26	25..24	23	22..20	19..16	15..14	13..12	11..8	7..4	3..0
Custom	b1000	Res	SJW (0–3)	TSEG2 (0–7)		TSEG1 (1–15)	Res	Tq (125–0x3200)
High Precision	b1100	SJW (0–15)		TSEG2 (0–15)		TSEG1 (1–63)		Tq (25–0x3200)

• (Re-)Synchronization Jump Width (SJW)

  • Valid programmed values are 0–3 in normal custom mode and 0–15 in high-precision custom mode.
  • The actual hardware interpretation of this value is one more than the programmed value.

• Time Segment 2 (TSEG2), which is the time segment after the sample point.

  • Valid programmed values are 0–7 in normal custom mode and 0–15 in high-precision custom mode.
  • This is the Phase_Seg2 time from ISO 11898–1, 12.4.1 Bit Encoding/Decoding.
  • The actual hardware interpretation of this value is one more than the programmed value.

• Time Segment 1 (TSEG1), which is the time segment before the sample point.

  • Valid programmed values are 1–0xF (1–15 decimal) in normal custom mode and 1–0x3F (1–63 decimal) in high-precision custom mode.
  • This is the combination of the Prop_Seg and Phase_Seg1 time from ISO 11898–1, 12.4.1 Bit Encoding/Decoding.
  • The actual hardware interpretation of this value is one more than the programmed value.

• Time quantum (Tq), which is used to program the baud rate prescaler

  • Valid programmed values are 125–12800, in increments of 0x7D (125 decimal) ns for normal custom mode and 25–12800, in increments of 0x19 (25 decimal) ns for high-precision custom mode.
  • This is the time quantum from ISO 11898–1, 12.4.1 Bit Encoding/Decoding.

An advanced baud rate example is 0x8014007D. This example breaks down into the following values:

• SJW = 0x0 (0x01 in hardware, due to the + 1)
• TSEG2 = 0x1 (0x02 in hardware, due to the + 1)
• TSEG 1 = 0x4 (0x05 in hardware, due to the + 1)
• Tq = 0x7D (125 ns in hardware)

Each time quanta is 125 ns. From IS0 11898–1, 12.4.1.2 Programming of Bit Time, the nominal time segments length is Sync_Seg (Fixed at 1) + (Prop_Seg + Phase_Seg1)(B) + Phase_Seg2(C) = 1 + 2 + 5 = 8. So, the total time for a bit in this example is 8 * 125 ns = 1000 ns = 1 µs. A 1 µs bit time is equivalent to a 1 MHz baud rate.

Baud rate = 1/(Bit time) = [Tq (Sync_seg + TSEG1 + TSEG2)]-1

where Tq = (m)(Tq_min) = (BRP)(minimum time quantum)

Sample Point = (TSEG1 + Sync_Seg) / (TSEG1 + Sync_Seg + TSEG2)

When the upper nibble (0xF0000000) is clear, you can set only baud rates within the LIN-specified range (2400 to 20000) for the interface.

When the upper nibble is set to 0x8 (0x80000000), no check for baud rate within LIN-specified range is performed, and the lowest 16 bits of the value may contain the custom baud rate. Any custom value higher than 65535 is masked to a 16-bit value. As with the non-custom values, the interface internally calculates the appropriate divisor values to program into its UART. Because the interface uses the Atmel ATA6620 LIN transceiver, which is guaranteed to operate within the limits of the LIN 2.0 specification, there are some special considerations when programming custom baud rates for LIN:

• The ATA6620 transceiver incorporates a TX dominant timeout function to prevent a faulty device it is built into from holding the LIN dominant indefinitely. If the TX line into the transceiver is held in the dominant state for too long, the transceiver switches its driver to the recessive state. This places a limit on how long the break field of a LIN header transmitted by the interface may be, and thus limits the lowest baud rate that may be set. At the point the baud rate or break length is set for the interface, it internally uses the baud rate bit time and break length settings to calculate the resulting break duration, and returns an error if that duration would be long enough to trigger the TX dominant timeout.
• At the other end of the baud range, the ATA6620 is specified to work up to 20000 baud. While the custom bit allows rates higher than that to be programmed, the transceiver behavior operating above that rate is not guaranteed.

Data Type	Direction	Required?	Default
u64	Write Only	No	0

XNET Session

nxPropSession_IntfAdjustLocalTime

A write of this property applies a positive or negative phase adjustment, in nanoseconds, to the local time that is used to timestamp frames (see nxReadFrame). This adjustment can be used to align the local time with another timescale.

As an example for using this property, consider an application that synchronizes a DAQmx and XNET device using a start trigger signal. The start trigger signal ensures that the hardware devices begin their I/O simultaneously, but the resulting timestamps (e.g., t0 in waveforms) might appear different because each driver initializes its time from the operating system at a different time. The difference in appearance is cosmetic, as the I/O is actually synchronized. In order to mitigate this difference, you can retrieve the timestamp of the start trigger from DAQmx and XNET, subtract one from the other, and write that difference to this property.

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

XNET Session

nxPropSession_IntfBusErrToInStrm

Note  Only CAN and LIN interfaces currently support this property. The nxPropSession_IntfBusErrToInStrm property configures the hardware to place a CAN or LIN bus error frame into the Stream Input queue after it is generated. A bus error frame is generated when the hardware detects a bus error. For more information about the bus error frame, refer to Special Frames.

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

XNET Session

nxPropSession_IntfEchoTx

The Interface:Echo Transmit? property determines whether Frame Input or Signal Input sessions contain frames that the interface transmits.

When this property is true, and a frame transmit is complete for an Output session, the frame is echoed to the Input session. Frame Input sessions can use the Flags field to differentiate frames received from the bus and frames the interface transmits. When using nxReadFrame with the raw frame format, you can parse the Flags field manually by reviewing the Raw Frame Format section. Signal Input sessions cannot differentiate the origin of the incoming data.

Note  Echoed frames are placed into the input sessions only after the frame transmit is complete. If there are bus problems (for example, no listener) such that the frame did not transmit, the frame is not received.

Data Type	Direction	Required?	Default
string	Read Only	—	—

XNET Session

nxPropSession_IntfIoName

The I/O Name property returns a reference to the interface used to create the session.

You can pass this I/O into an XNET Interface property node to retrieve hardware information for the interface, such as the name and serial number. The I/O Name is the same reference available from the XNET System property node, which is used to read information for all XNET hardware in the system.

You can use this property on the diagram to:

• Display a string that contains the name of the interface as shown in Measurement and Automation Explorer (MAX).
• Provide a refnum you can wire to a property node to read information for the interface.

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

XNET Session

nxPropSession_IntfOutStrmList

Note  Only CAN and LIN interfaces currently support this property.

The Output Stream List property provides a list of frames for use with the replay feature (Interface:Output Stream Timing property set to nxOutStrmTimng_ReplayExclusive or nxOutStrmTimng_ReplayInclusive). In Replay Exclusive mode, the hardware transmits only frames that do not appear in the list. In Replay Inclusive mode, the hardware transmits only frames that appear in the list. For a LIN interface, the header of each frame written to stream output is transmitted, and the Exclusive or Inclusive mode controls the response transmission. Using these modes, you can either emulate an ECU (Replay Inclusive, where the list contains the frames the ECU transmits) or test an ECU (Replay Exclusive, where the list contains the frames the ECU transmits), or some other combination.

This property's data type is an array of database handles to frames. If you are not using a database file or prefer to specify the frames using CAN arbitration IDs or LIN unprotected IDs, you can use Interface:Output Stream List By ID instead of this property.

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

XNET Session

nxPropSession_IntfOutStrmListById

Note  Only CAN and LIN interfaces currently support this property.

The Output Stream List By ID property provides a list of frames for use with the replay feature Interface:Output Stream Timing property set to nxOutStrmTimng_ReplayExclusive or nxOutStrmTimng_ReplayInclusive).

This property serves the same purpose as Interface:Output Stream List, in that it provides a list of frames for replay filtering. This property provides an alternate format for you to specify the frames by their CAN arbitration ID or LIN unprotected ID. The property's data type is an array of unsigned 32-bit integer (U32). Each integer represents a CAN or LIN frame's identifier, using the same encoding as the Raw Frame Format.

Within each CAN frame ID value, bit 29 (hex 20000000) indicates the CAN identifier format (set for extended, clear for standard). If bit 29 is clear, the lower 11 bits (0–10) contain the CAN frame identifier. If bit 29 is set, the lower 29 bits (0–28) contain the CAN frame identifier. LIN frame ID values may be within the range of possible LIN IDs (0–63).

Data Type	Direction	Required?	Default
u32	Read/Write	No	Immediate

XNET Session

nxPropSession_IntfOutStrmTimng

The Output Stream Timing property configures how the hardware transmits frames queued using a Frame Output Stream session. The following table lists the accepted values:

Enumeration	Value	Description
nxOutStrmTimng_Immediate	0	Frames are dequeued from the queue and transmitted immediately to the bus. The hardware transmits all frames in the queue as fast as possible. Frame timestamps are ignored.
nxOutStrmTimng_ReplayExclusive	1	Hardware evaluates the frame timestamps and attempts to maintain the original transmission times as the timestamp stored in the frame indicates. The hardware only transmits frames that do not appear in the list (specified via the Interface:Output Stream List property).
nxOutStrmTimng_ReplayInclusive	2	Hardware evaluates the frame timestamps and attempts to maintain the original transmission times as the timestamp stored in the frame indicates. The hardware transmits only frames that do appear in the list (specified via the Interface:Output Stream List property).

Note  For Replay modes, the actual transmission time is based on the relative time difference between the first dequeued frame and the time contained in the dequeued frame.

Note  Replay modes are not supported on the PXIe-8521.

When in one of the Replay modes, the frame list is specified via the Interface:Output Stream List property (for CAN and LIN only). This property contains an array of database frame references. Its default value is an empty array.

The Replay modes enable you to emulate an ECU (nxOutStrmTimng_ReplayInclusive, where the list contains the frames the ECU transmits) or test an ECU (nxOutStrmTimng_ReplayExclusive, where the list contains the frames the ECU transmits), or some other combination. You can replay all frames by using nxOutStrmTimng_ReplayExclusive without setting any list.

Note that Ethernet does not support databases, and therefore the Interface:Output Stream List property is not supported. Instead, Ethernet uses the Ethernet:Filtering:Frame Filter property to specify the "list" of frames to use with the replay modes. This allows the user to filter in/out arbitrary frames for replay (e.g., gPTP frames for 802.1AS).

When the hardware is in a replay mode, the first frame received from the application is considered the start time, and all subsequent frames are transmitted at the appropriate delta from the start time. For example, if the first frame has a timestamp of 12:01.123, and the second frame has a timestamp of 12:01.456, the second frame is transmitted 333 ms after the first frame.

If a frame's time is identical or goes backwards relative to the first timestamp, this is treated as a new start time, and the frame is transmitted immediately on the bus. Subsequent frames are compared to this new start time to determine the transmission time. For example, assume that the application sends the hardware four frames with the following timestamps: 12:01.123, 12:01.456, 12:01.100, and 12:02.100. In this scenario, the first frame transmits immediately, the second frame transmits 333 ms after the first, the third transmits immediately after the second, and the fourth transmits one second after the third. Using this behavior, you can replay a logfile of frames repeatedly, and each new replay of the file begins with new timing.

A frame whose timestamp goes backwards relative to the previous timestamp, but still is forward relative to the start time, is transmitted immediately. For example, assume that the application sends the hardware four frames with the following timestamps: 12:01.123, 12:01.456, 12:01.400, and 12:02.100. In this scenario, the first frame transmits immediately, the second frame transmits 333 ms after the first, the third transmits immediately after the second, and the fourth transmits 544 ms after the third.

When a frame with an nxFrameType_Special_Delay frame type is received, the hardware delays for the requested time. The next frame to be dequeued is treated as a new first frame and transmitted immediately. You can use a Delay Frame with a time of 0 to restart time quickly. If you replay a logfile of frames repeatedly, you can insert a Delay Frame at the start of each replay to insert a delay between each iteration through the file.

When a frame with an nxFrameType_Special_StartTrigger frame type is received, the hardware treats this frame as a new first frame and uses the absolute time associated with this frame as the new start time. Subsequent frames are compared to this new start time to determine the transmission time. Using a Start Trigger is especially useful when synchronizing with data acquisition products so that you can replay the first frame at the correct time relative to the start trigger for accurate synchronized replay. Note  Ethernet devices do not support Start Trigger frames. See Synchronized Replay for more information about synchronizing replay across XNET devices.

When Network Time is used for the replay timescale, it is possible for devices to lose time synchronization while the replay streams are started and actively running -- if a device loses connectivity to the time sync master, for example. Additionally, the time sync master can instantaneously cause a large time discontinuity while replay streams are started, by snapping network time either forward or backward. This would cause the time sync slaves to momentarily lose synchronization while snapping and synchronizing with the new network time, jumping in time either into the past or the future.

In either case, replay streams will continue outputting frames unimpeded, using the latest view of network time on each respective device. When synchronization is lost, the network time counter on each device will continue to advance (and thus is still valid to use for replay), but network time will begin to drift relative to other devices. This, in turn, will cause the timing of replayed frames to also drift and become unsynchronized.

When network time synchronization is restored, the network time counter will either correct gradually (for a small drift) or abruptly snap by a large amount forward or backwards (if the drift was large or the time sync master snapped). The replay frame timing will automatically synchronize again once network time synchronization is restored. For gradual corrections, there are no time discontinuities and no substantive impact on frame timing. In effect, frame output was simply not synchronized for a period of time.

If a time snap occurs when synchronization is restored, the specific replay frame timing around the snap depends on whether the shift was backwards or forwards in time.

• Forward Time Snap: After the snap, the next queued output frame will have a timestamp that is either (a) nearer in the future, (b) equal to the current time, or (c) suddenly in the past. Both (b) and (c) cause the frame to be output immediately. For (a), hardware still waits to output the next frame, but it waits a shorter period of time since the frame is suddenly nearer in the future. For example, if at the moment of snap the next frame was 10 ms in the future, and then there is a snap forward 6 ms, the next frame will be output 4 ms later.
• Backwards Time Snap: After the snap, the next queued output frame will have a timestamp that is further into the future. Thus, the hardware will wait longer before outputting the next frame. For example, if at the moment of snap, the next frame was 10 ms in the future, and then there is a snap backwards 6 ms, the next frame will be output 16 ms later. Snapping backwards to a time before the original start time does not reset the start time.

In all cases, you can monitor whether Network Time is synchronized with the Interface:Ethernet:Time Sync:Port:Synced? property. With this property, an application can detect periods of time when replayed frames might not be fully synchronized.

Only LIN interface as Master supports stream output. You do not need to set the interface explicitly to Master if you want to use stream output. Just create a stream output session, and the driver automatically sets the interface to Master at interface start.

You can use immediate mode to transmit a header or full frame. You can transmit only the header for a frame by writing the frame to stream output with the desired ID and an empty data payload. You can transmit a full frame by writing the frame to stream output with the desired ID and data payload. If you write a full frame for ID n to stream output, and you have created a frame output session for frame with ID n, the stream output data takes priority (the stream output frame data is transmitted and not the frame output data). If you write a full frame to stream output, but the frame has not been defined in the database, the frame transmits with Enhanced checksum. To control the checksum type transmitted for a frame, you first must create the frame in the database and assign it to an ECU using the LIN specification you desire (the specification number determines the checksum type). You then must create a frame output object to transmit the response for the frame, and use stream output to transmit the header. Similarly, to transmit n corrupted checksums for a frame, you first must create a frame object in the database, create a frame output session for it, set the transmit n corrupted checksums property, and then use stream output to transmit the header.

Regarding event-triggered frame handling for immediate mode, if the hardware can determine that an ID is for an event-triggered frame, which means an event-triggered frame has been defined for the ID in the database, the frame is processed as if it were in an event-triggered slot in a schedule. If you write a full frame with event-triggered ID, the full frame is transmitted. If there is no collision, the next stream output frame is processed. If there is a collision, the hardware executes the collision-resolving schedule. The hardware retransmits the frame response at the corresponding slot time in the collision resolving schedule. If you write a header frame with an event-triggered ID and there is no collision, the next stream output frame is processed. If there is a collision, the hardware executes the collision-resolving schedule.

You can mix use of the hardware scheduler and stream output immediate mode. Basically, the hardware treats each stream output frame as a separate run-once schedule containing a single slot for the frame. Transmission of a stream output frame may interrupt a run-continuous schedule, but may not interrupt a run-once schedule. Transmission of stream output frames is interleaved with run-continuous schedule slot executions, depending on the application timing of writes to stream output. Stream output is prioritized to the equivalent of the lowest priority level for a run-once schedule. If you write one or more run-once schedules with higher-than-lowest priority and write frames to stream output, all the run-once schedules are executed before stream output transmits anything. If you write one or more run-once schedules with the lowest priority and write frames to stream output, the run-once schedules execute in the order you wrote them, and are interleaved with stream output frames, depending on the application timing of writes to stream output and writes of run-once schedule changes.

In contrast to the immediate mode, neither replay mode allows for the concurrent use of the hardware scheduler, and an error is reported if you attempt to do so. Event-triggered frame handling is different for the replay modes. If the hardware can determine that an ID is for an event-triggered frame, which means an event-triggered frame has been defined for the ID in the database, the frame is transmitted as if it were being transmitted during the collision-resolving schedule for the event triggered frame. The full frame is transmitted with the Data[0] value (the underlying unconditional frame ID), copied into the header ID. If a frame cannot be found in the database, it is transmitted with Enhanced checksum. Otherwise, it is transmitted with the checksum type defined in the database.

The reply modes provide an easy means to replay headers only, full frames only, or some mix of the two. For either replay mode, the header for each frame is always transmitted and the slot delay is preserved. For replay inclusive, if you want only to replay headers, leave the Interface:Output Stream List property empty. To replay some of the responses, add their frames to Interface:Output Stream List. For frames that are not in Interface:Output Stream List, you are free to create frame output objects for them, for which you can change the checksum type or transmit corrupted checksums.

There is another consideration for the replay of diagnostic slave response frames. Because the master always transmits only the diagnostic slave response header, and a slave transmits the response if its NAD matches the one transmitted in the preceding master request frame, an array of frames for replay might include multiple slave response frames (each having the same slave response header ID) transmitted by different slaves (each having a different NAD value in the data payload). If you are using inclusive mode, you can choose not to replay any slave response frames by not including the slave response frame in Interface:Output Stream List. You can choose to replay some or all of the slave response frames by first including the slave response frame in Interface:Output Stream List, then including the NAD values for the slave responses you want to play back, in Interface:LIN:Output Stream Slave Response List By NAD. In this way, you have complete control over which slave responses are replayed (which diagnostic slaves you emulate). Replay of a diagnostic master request frame is handled like replay of any other frame; the header is always transmitted. Using the inclusive mode as an example, the response may or may not be transmitted depending on whether or not the master request frame is in Interface:Output Stream List.

When you use Immediate mode, there are no restrictions on frames that you use in other sessions.

When you use Replay Inclusive mode, you can create output sessions that use frames that do not appear in the Interface:Output Stream List property. Attempting to create an output session that uses a frame from the Interface:Output Stream List property results in an error. Input sessions have no restrictions.

When you use Replay Exclusive mode, you cannot create any other output sessions. Attempting to create an output session returns an error. Input sessions have no restrictions.

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

XNET Session

nxPropSession_IntfStartTrigToInStrm

The nxPropSession_IntfStartTrigToInStrm property configures the hardware to place a start trigger frame into the Stream Input queue after it is generated. A Start Trigger frame is generated when the interface is started. The interface start process is described in Interface Transitions.

The start trigger frame is especially useful if you plan to log and replay CAN data.

Data Type	Direction	Required?	Default
u32	Write Only	No	0x00000007

XNET Session

nxPropSession_IntfCANExtTcvrConfig

This property allows you to configure XS series CAN hardware to communicate properly with your external transceiver. The connector on your XS series CAN hardware has five lines for communicating with your transceiver.

Line	Direction	Purpose
Ext_RX	In	Data received from the CAN bus.
Ext_TX	Out	Data to transmit on the CAN bus.
Output0	Out	Generic output used to configure the transceiver mode.
Output1	Out	Generic output used to configure the transceiver mode.
NERR	In	Input to connect to the nERR pin of your transceiver to route status back from the transceiver to the hardware.
The Ext_RX and Ext_TX lines are self explanatory and provide for the transfer of CAN data to and from the transceiver. The remaining three lines are for configuring the transceiver and retrieving status from the transceivers. Not all transceivers use all pins. Typically, a transceiver has one or two lines that can configure the transceiver mode. The NI-XNET driver natively supports five transceiver modes: Normal, Sleep, Single Wire Wakeup, Single Wire High Speed, and Power-On. This property configures how the NI-XNET driver sets the outputs of your external transceiver for each mode.

The configuration is in the form of a U32 written as a bitmask. The U32 bitmask is defined as:

31	30..15	14..12	11..9	8..6	5..3	2..0
nERR Connected	Reserved	PowerOn Configuration	SWHighSpeed Configuration	SWWakeup Configuration	Sleep Configuration	Normal Configuration
Where each configuration is a 3-bit value defined as:

2	1	0
State Supported	Output1 Value	Output0 Value
The Interface:CAN:Transceiver State property changes the transceiver state. Based on the transceiver configuration, if the state is supported, the configuration determines how the two pins are set. If the state is not supported, an error is returned, because you tried to set an invalid configuration. Note that all transceivers must support a Normal state, so the State Supported bit for that configuration is ignored.

Other internal state changes may occur. For example, if you put the transceiver to sleep and a remote wakeup occurs, the transceiver automatically is changed to the normal state. If nERR Connected is set, the nERR pin into the connector determines a transceiver error. It is active low, meaning a value of 0 on this pin indicates an error. A value of 1 indicates no error. If this line is connected, the NI-XNET driver monitors this line and reports its status via the Transceiver Error field of nxReadState (StateID = nxState_CANComm).

TJA1041 (HS): To connect to the TJA1041 transceiver, connect Output0 to the nSTB pin and Output1 to the EN pin. The TJA1041 does have an nERR pin, so that should be connected to the nERR input. The TJA1041 supports a power-on state, a sleep state, and a normal state. As this is not a single wire transceiver, it does not support any single wire state. For normal operation, the TJA1041 uses a 1 for both nSTB and EN. For sleep, the TJA1041 uses the standby mode, which uses a 0 for both nSTB and EN. For power-on, the TJA1041 uses a 1 for nSTB and a 0 for EN. The final configuration is 0x80005027.

TJA1054 (LS): You can connect and configure the TJA1054 identically to the TJA1041.

AU5790 (SW): To connect to the AU5790 transceiver, connect Output0 to the nSTB pin and Output1 to the EN pin. The AU5790 does not support any transceiver status, so you do not need to connect the nERR pin. The AU5790 supports all states. For normal operation, the AU5790 uses a 1 for both nSTB and EN. For sleep, the AU5790 uses a 0 for both nSTB and EN. For Single Wire Wakeup, the AU5790 requires nSTB to be a 0 and EN to be a 1. For Single Wire High-Speed, the AU5790 requires nSTB to be a 1, and EN to be a 0. For power-on, the sleep state is used so there is less interference on the bus. The final configuration is 0x00004DA7.

Data Type	Direction	Required?	Default
u32	Read Only	—	Same as XNET Cluster CAN:I/O Mode

XNET Session

nxPropSession_IntfCanIoMode

This property indicates the I/O Mode the interface is using. It is an enumerated list of three values, as described in the following table:

Enumeration	Value	Description
CAN	0	This is the default CAN 2.0 A/B standard I/O mode as defined in ISO 11898-1:2003. A fixed baud rate is used for transfer, and the payload length is limited to 8 bytes.
CAN FD	1	This is the CAN FD mode as specified in the CAN with Flexible Data-Rate specification, version 1.0. Payload lengths are allowed up to 64 bytes, but they are transmitted at a single fixed baud rate (defined by the XNET Cluster 64bit Baud Rate or XNET Session Interface:64bit Baud Rate properties.
CAN FD+BRS	2	This is the CAN FD mode as specified in the CAN with Flexible Data-Rate specification, version 1.0, with the optional Baud Rate Switching enabled. The same payload lengths as CAN FD mode are allowed; additionally, the data portion of the CAN frame is transferred at a different (higher) baud rate (defined by the XNET Cluster CAN:64bit FD Baud Rate or XNET Session Interface:CAN:64bit FD Baud Rate properties).
The value is initialized from the database cluster when the session is created and cannot be changed later. However, you can transmit standard CAN frames on a CAN FD network. Refer to the Interface:CAN:Transmit I/O Mode property.

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

XNET Session

nxPropSession_IntfCANLstnOnly

Note  You can modify this property only when the interface is stopped.

The Listen Only? property configures whether the CAN interface transmits any information to the CAN bus.

When this property is false, the interface can transmit CAN frames and acknowledge received CAN frames.

When this property is true, the interface can neither transmit CAN frames nor acknowledge a received CAN frame. The true value enables passive monitoring of network traffic, which can be useful for debugging scenarios when you do not want to interfere with a communicating network cluster.

Data Type	Direction	Required?	Default
u32	Read/Write	No	As Submitted

XNET Session

nxPropSession_IntfCANPendTxOrder

Note  You can modify this property only when the interface is stopped.

Note  Setting this property causes the internal queue to be flushed. If you start a session, queue frames, and then stop the session and change this mode, some frames may be lost. Set this property to the desired value once; do not constantly change modes.

The Pending Transmit Order property configures how the CAN interface manages the internal queue of frames. More than one frame may desire to transmit at the same time. NI-XNET stores the frames in an internal queue and transmits them onto the CAN bus when the bus is idle.

This property modifies how NI-XNET handles this queue of frames. The following table lists the accepted values:

Enumeration	Value
nxCANPendTxOrder_AsSubmitted	0
nxCANPendTxOrder_ByIdentifier	1
When you configure this property to be nxCANPendTxOrder_AsSubmitted, frames are transmitted in the order that they were submitted into the queue. There is no reordering of any frames, and a higher priority frame may be delayed due to the transmission or retransmission of a previously submitted frame. However, this mode has the highest performance.

When you configure this property to be nxCANPendTxOrder_ByIdentifier, frames with the highest priority identifier (lower CAN ID value) transmit first. The frames are stored in a priority queue sorted by ID. If a frame currently being transmitted requires retransmission (for example, it lost arbitration or failed with a bus error), and a higher priority frame is queued in the meantime, the lower priority frame is not immediately retried, but the higher priority frame is transmitted instead. In this mode, you can emulate multiple ECUs and still see a behavior similar to a real bus in that the highest priority message is transmitted on the bus. This mode may be slower in performance (possible delays between transmissions as the queue is re-evaluated), and lower priority messages may be delayed indefinitely due to frequent high-priority messages.

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

XNET Session

nxPropSession_IntfCANSingShot

Note  You can modify this property only when the interface is stopped.

Note  Setting this property causes the internal queue to be flushed. If you start a session, queue frames, and then stop the session and change this mode, some frames may be lost. Set this property to the desired value once; do not constantly change modes.

The Single Shot Transmit? property configures whether the CAN interface retries failed transmissions.

When this property is false, failed transmissions retry as specified by the CAN protocol (ISO 11898-1, 6.11 Automatic Retransmission). If a CAN frame is not transmitted successfully, the interface attempts to retransmit the frame as soon as the bus is idle again. This retransmit process continues until the frame is successfully transmitted.

When this property is true, failed transmissions do not retry. If a CAN frame is not transmitted successfully, no further transmissions are attempted.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Off (0)

XNET Session

nxPropSession_IntfCANTerm

Notes  You can modify this property only when the interface is stopped.

This property does not take effect until the interface is started.

The Termination property configures the onboard termination of the NI-XNET interface CAN connector (port). The enumeration is generic and supports two values: Off and On. However, different CAN hardware has different termination requirements, and the Off and On values have different meanings, as described below.

High-Speed CAN networks are typically terminated on the bus itself instead of within a node. However, NI-XNET allows you to configure termination within the node to simplify testing. If your bus already has the correct amount of termination, leave this property in the default state of Off. However, if you require termination, set this property to On.

Value	Meaning	Description
Off	Disabled	Termination is disabled.
On	Enabled	Termination (120 Ω) is enabled.

Every node on a Low-Speed CAN network requires termination for each CAN data line (CAN_H and CAN_L). This configuration allows the Low-Speed/Fault-Tolerant CAN port to provide fault detection and recovery.In general, if the existing network has an overall network termination of 125 Ω or less, select the default 4.99 kΩ option. Otherwise, you should turn on termination to enable the 1.11 kΩ option.

Value	Meaning	Description
Off	4.99 kΩ	Termination is set to 4.99 kΩ.
On	1.11 kΩ	Termination is set to 1.11 kΩ.

The ISO standard requires Single-Wire transceivers to have a 9.09 kΩ resistor, and no additional configuration is supported.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Normal (0)

XNET Session

nxPropSession_IntfCANTcvrState

The Transceiver State property configures the CAN transceiver and CAN controller modes. The transceiver state controls whether the transceiver is asleep or communicating, as well as configuring other special modes. The following table lists the accepted values.

Enumeration	Value
Normal	0
Sleep	1
Single Wire Wakeup	2
Single Wire High-Speed	3

This state sets the transceiver to normal communication mode. If the transceiver is in the Sleep mode, this performs a local wakeup of the transceiver and CAN controller chip.

This state sets the transceiver and CAN controller chip to Sleep (or standby) mode. You can set the interface to Sleep mode only while the interface is communicating. If the interface has not been started, setting the transceiver to Sleep mode returns an error.

Before going to sleep, all pending transmissions are transmitted onto the CAN bus. Once all pending frames have been transmitted, the interface and transceiver go into Sleep (or standby) mode. Once the interface enters Sleep mode, further communication is not possible until a wakeup occurs. The transceiver and CAN controller wake from Sleep mode when either a local wakeup or remote wakeup occurs.

A local wakeup occurs when the application sets the transceiver state to either Normal or Single Wire Wakeup.

A remote wakeup occurs when a remote node transmits a CAN frame (referred to as the wakeup frame). The wakeup frame wakes up the NI-XNET interface transceiver and CAN controller chip. The CAN controller chip does not receive or acknowledge the wakeup frame. After detecting the wakeup frame and idle bus, the CAN interface enters Normal mode.

When the local or remote wakeup occurs, frame transmissions resume from the point at which the original Sleep mode was set.

You can use nxReadState to detect when a wakeup occurs. To suspend the application while waiting for the remote wakeup, use nxWait.

For a remote wakeup to occur for Single Wire transceivers, the node that transmits the wakeup frame first must place the network into the Single Wire Wakeup Transmission mode by asserting a higher voltage.

This state sets a Single Wire transceiver into the Single Wire Wakeup Transmission mode, which forces the Single Wire transceiver to drive a higher voltage level on the network to wake up all sleeping nodes. Other than this higher voltage, this mode is similar to Normal mode. CAN frames can be received and transmitted normally.

If you are not using a Single Wire transceiver, setting this state returns an error. If your current mode is Single Wire High-Speed, setting this mode returns an error because you are not allowed to wake up the bus in high-speed mode.

The application controls the timing of how long the wakeup voltage is driven. The application typically changes to Single Wire Wakeup mode, transmits a single wakeup frame, and then returns to Normal mode.

This state sets a Single Wire transceiver into Single Wire High-Speed Communication mode. If you are not using a Single Wire transceiver, setting this state returns an error.

Single Wire High-Speed Communication mode disables the transceiver's internal waveshaping function, allowing the SAE J2411 High-Speed baud rate of 83.333 kbytes/s to be used. The disadvantage versus Single Wire Normal Communication mode, which allows only the SAE J2411 baud rate of 33.333 kbytes/s, is degraded EMC performance. Other than the disabled waveshaping, this mode is similar to Normal mode. CAN frames can be received and transmitted normally.

This mode has no relationship to High-Speed transceivers. It is merely a higher speed mode of the Single Wire transceiver, typically used to download data when the onboard network is attached to an offboard tester ECU.

The Single Wire transceiver does not support use of this mode in conjunction with Sleep mode. For example, a remote wakeup cannot transition from sleep to this Single Wire High-Speed mode. Therefore, setting the mode to Sleep from Single Wire High-Speed mode returns an error.

Data Type	Direction	Required?	Default
u32	Read/Write	No	High-Speed (0) for High-Speed and XS Hardware; Low-Speed (1) for Low-Speed Hardware

XNET Session

nxPropSession_IntfCANTcvrType

Note  You can modify this property only when the interface is stopped.

For XNET hardware that provides a software-selectable transceiver, the Transceiver Type property allows you to set the transceiver type. Use the XNET Interface CAN.Tranceiver Capability property to determine whether your hardware supports a software-selectable transceiver.

You also can use this property to determine the currently configured transceiver type.

The following table lists the accepted values:

Enumeration	Value
High-Speed (HS)	0
Low-Speed (LS)	1
Single Wire (SW)	2
External (Ext)	3
Disconnected (Disc)	4
The default value for this property depends on your type of hardware. If you have fixed-personality hardware, the default value is the hardware value. If you have hardware that supports software-selectable transceivers, the default is High-Speed.

This attribute uses the following values:

This configuration enables the High-Speed transceiver. This transceiver supports baud rates of 40 kbaud to 1 Mbaud. When using a High-Speed transceiver, you also can communicate with a CAN FD bus.

This configuration enables the Low-Speed/Fault-Tolerant transceiver. This transceiver supports baud rates of 40–125 kbaud.

This configuration enables the Single Wire transceiver. This transceiver supports baud rates of 33.333 kbaud and 83.333 kbaud.

This configuration allows you to use an external transceiver to connect to your CAN bus. Refer to the XNET SessionInterface:CAN:External Transceiver Config property for more information.

This configuration allows you to disconnect the CAN controller chip from the connector. You can use this value when you physically change the external transceiver.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Same as Interface:CAN:I/O Mode

XNET Session

nxPropSession_IntfCanTxIoMode

This property specifies the I/O Mode the interface uses when transmitting a CAN frame. By default, it is the same as the XNET Cluster CAN:I/O Mode property. However, even if the interface is in CAN FD+BRS mode, you can force it to transmit frames in the standard CAN format. For this purpose, set this property to CAN.

Note  This property is not supported in CAN FD+BRS ISO mode. If you are using ISO CAN FD mode, you define the transmit I/O mode in the database with the I/O Mode property of the frame. (When a database is not used (for example, in frame stream mode), define the transmit I/O mode with the frame type field of the frame data.) Note that ISO CAN FD mode is the default mode for CAN FD in NI-XNET.

Note  This property affects only the transmission of frames. Even if you set the transmit I/O mode to CAN, the interface still can receive frames in FD modes (if the XNET Cluster CAN:I/O Mode property is configured in an FD mode).

The Transmit I/O mode may not exceed the mode set by the XNET Cluster CAN:I/O Mode property.

Data Type	Direction	Required?	Default
u32	Read/Write	No	ISO

XNET Session

nxPropSession_IntfCanFdIsoMode

This property is valid only when the interface is in CAN FD(+BRS) mode. It specifies whether the interface is working in the ISO CAN FD standard (ISO standard 11898-1:2015) or non-ISO CAN FD standard (Bosch CAN FD 1.0 specification). Two ports using different standards (ISO CAN FD vs. non-ISO CAN FD) cannot communicate with each other.

When you use a CAN FD database (DBC or FIBEX file created with NI-XNET), you can specify the ISO CAN FD mode when creating an alias name for the database. An alias is created automatically when you open a new database in the NI-XNET Database Editor. The specified ISO CAN FD mode is used as default, which you can change in the session using this property.

Note  In ISO CAN FD mode, for every transmitted frame, you can specify in the database or frame header whether a frame must be sent in CAN 2.0, CAN FD, or CAN FD+BRS mode. In the frame type field of the frame header, received frames indicate whether they have been sent with CAN 2.0, CAN FD, or CAN FD+BRS. You cannot use the Interface:CAN:Transmit I/O Mode property in ISO CAN FD mode, as the frame defines the transmit mode.

Note  In Non-ISO CAN FD mode, CAN data frames are received at CAN data typed frames, which is either CAN 2.0, CAN FD, or CAN FD+BRS, but you cannot distinguish the standard in which the frame has been transmitted.

Note  You also can set the mode to Legacy ISO mode. In this mode, the behavior is the same as in Non-ISO CAN FD mode (Interface:CAN:Transmit I/O Mode is working, and received frames have the CAN data type). But the interface is working in ISO CAN FD mode, so you can communicate with other ISO CAN FD devices. Use this mode only for compatibility with existing applications.

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

XNET Session

nxPropSession_IntfCanEdgeFilter

When this property is enabled, the CAN hardware requires two consecutive dominant tq for hard synchronization.

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

XNET Session

nxPropSession_IntfCanTransmitPause

When this property is enabled, the CAN hardware waits for two bit times before transmitting the next frame. This allows other CAN nodes to transmit lower priority CAN messages while this CAN node is transmitting high-priority CAN messages with high speed.

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

XNET Session

nxPropSession_IntfCanDisableProtExceptionHandling

A protocol exception occurs when the CAN hardware detects an invalid combination of bits on the CAN bus reserved for a future protocol expansion. NI-XNET allows you to define how the hardware should behave in case of a protocol exception:

• When this property is enabled (false, default), the CAN hardware stops receiving frames and starts a bus integration.
• When this property is disabled (true), the CAN hardware transmits an error frame when it detects a protocol exception condition.

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

XNET Session

nxPropSession_IntfEnetIpV4Address

Indicates the IPv4 address that is configured on the the XNET interface in the network by the OS stack. The IPv4 address is returned as a string in dotted-decimal notation. For example, 192.0.2.1.

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

XNET Session

nxPropSession_IntfEnetLinkSpeed

Indicates the current link speed on the interface or shows if the link is down. This property is an enumerated list of values, as described in the following table:

Enumeration	Value	Description
nxEnetLinkSpeed_LinkDown	0	The link for the Ethernet interface is down.
nxEnetLinkSpeed_100Mbps	1	The Ethernet interface is operating at 100 Mb/s (Fast Ethernet) capability.
nxEnetLinkSpeed_1000Mbps	2	The Ethernet interface is operating at 1000 Mb/s (Gigabit Ethernet) capability.

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

XNET Session

nxPropSession_IntfEnetLinkSpeedConf

Indicates the link speed that is configured for the Ethernet interface. This property is configured using MAX or the System Configuration property Link Speed Configured. This property is an enumerated list of values, as described in the following table:

Enumeration	Value	Description
nxEnetLinkSpeed_100Mbps	1	The Ethernet interface is configured for 100 Mb/s (Fast Ethernet) capability.
nxEnetLinkSpeed_1000Mbps	2	The Ethernet interface is configured for 1000 Mb/s (Gigabit Ethernet) capability.

Data Type	Direction	Required?	Default
u32	Read Only	No	Disabled

XNET Session

nxPropSession_IntfEnetJumboFrames

Indicates the jumbo frame setting for the interface. Use NI-MAX or the System Configuration XNET:Interface:Ethernet:Jumbo Frames property to change the Jumbo Frames property.

This property is an enumerated list of values, as described in the following table:

Enumeration	Value	Description
nxEnetJumboFrames_Disabled	0	Jumbo frames will not be received on the monitor path. Jumbo frames will not be transmitted or received on the OS stack path.
nxEnetJumboFrames_9018Bytes	1	Jumbo frames up to 9018 bytes can be received on the monitor path. Jumbo frames up to 9018 bytes can be transmitted or received on the OS stack path.

Note  The network interface must independently be configured for jumbo frames in the OS in order to use jumbo frames through the OS stack.

Note  Jumbo frames are not supported on the Endpoint path.

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

XNET Session

nxPropSession_IntfEnetMacAddress

Indicates the MAC address that uniquely identifies the XNET Interface in the network. This MAC address applies to the endpoint as well as the OS stack. The MAC address is an individual (unicast) EUI-48 MAC address that is assigned to the hardware according to the requirements of IEEE Std 802.

The MAC address is returned as a string of six octets. Each octet consists of two hexadecimal (0-9, A-F) digits; the octets are separated by colon. For example, 00:80:2F:AB:CD:EF.

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

XNET Session

nxPropSession_IntfEnetOperationalStatus

Indicates the operational status of the interface (that is, communicating or not). It is an enumerated list as described in the following table:

Enumeration	Value	Description
nxEnetOperationalStatus_Down	0	The interface cannot transmit or receive frames (packets).
nxEnetOperationalStatus_Up	1	The interface is ready to transmit and receive frames (packets).
This property corresponds to interface operational status as specified in IETF management standards like RFC 2863 and RFC 8343.

The XNET interface Communicating state behaves differently for Ethernet compared to other XNET protocols, such as CAN. The OS stack provides a network interface, and the operating system brings its network interface to communicating state ("link up") at power on. The operating system keeps the interface in communicating state until it is powered off. Therefore, the Ethernet interface is communicating at its physical layer (PHY) before and after the existence of any XNET session.

XNET interface states) have a limited context; they control the transfer of frames to/from the XNET endpoint and monitor paths, but they do not control the actual communicating state ("link up" or "link down") of the interface. The Operational Status property returns the actual communicating state of the interface.

As a consequence of this state behavior, it is possible to enable the time sync protocol prior to starting the XNET interface because the time sync protocol operates independently from the endpoint and monitor paths (like the OS stack).

Although the link is up prior to XNET interface start, if a frame is received prior to the initial XNET start and would normally be received by endpoint or monitor, nxRead will not return the frame.

The nxStart discards all unread frames from the receive queue.

The nxStop function has no effect on the receive queue, and link down/up events have no effect on the receive queue. If frames are received but not read, and your application stops the interface without restarting, XNET Read will return the previously received frames.

All unread frames are discarded from the receive queue when the XNET session is cleared.

When the nxStop is invoked, or when the link goes down, pending frames in the XNET transmit queues are discarded.

nxWrite ignores the operational status of the link when the XNET interface is not running. If you invoke XNET Write prior to starting the XNET interface, the frame is queued regardless of the operational status. If the link is up when nxStart is invoked, those queued frames are transmitted. If the link is down when nxStart is invoked, those queued frames are discarded.

If you invoke nxWrite on a started XNET interface and the link is down, the frame is not queued and an error is returned. After the link comes back up, when you invoke nxWrite again, frames are queued for transmission (with no need to restart the XNET interface).

You can use nxWait (Transmit Complete) to ensure that frames are transmitted before you clear the XNET session.

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

XNET Session

nxPropSession_IntfEnetOsNetworkAdapterName

On NI-XNET Ethernet hardware, each port can be accessed as an XNET interface, or using operating system (OS) APIs for Ethernet. The OS Network Adapter Name property returns the name of the Ethernet interface for this XNET session as the interface is represented in the OS.

• On Windows, this is the network adapter name.
• On Linux, this is the network interface name.

This name is used in applications such as Wireshark.

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

XNET Session

nxPropSession_IntfEnetOsNetworkAdapterDescription

On NI-XNET Ethernet hardware, each port can be accessed as an XNET interface, or using operating system (OS) APIs for Ethernet. The OS Network Adapter Description property returns the description of the Ethernet interface for this XNET session as the interface is represented in the OS.

• In NI MAX, this name is shown on the Network Settings tab for the system, listed under Network Adapters.
• On Windows, this is the network adapter description in network properties.
• On Linux, this is the network interface name and is the same as the OS Network Adapter Name property.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Disabled

XNET Interface

nxPropSession_IntfEnetOutStrmTimescale

Defines which timescale (Local Time or Network Time) is used for Output Stream Timing. This configures which timestamp the hardware uses when evaluating whether to output a frame.

Note  This property is Ethernet-specific; it does not apply to CAN or LIN protocols.

This property is an enumerated type with the following possible values:

Enumeration	Value
Local Time	0
Network Time	1

Note  This property cannot be changed after the output stream is started.

Data Type	Direction	Required?	Default
u32	Read Only	No	Normal

XNET Interface

nxPropSession_IntfEnetPhyPowerMode

Indicates the current power mode of the PHY. If the XNET device supports the sleep/wake capability, the PHY Power Mode can be changed by calling the nxState_EthernetSleep and nxState_EthernetWake VIs. Devices that do not support this capability will return 0 (Normal) when this property is read.

This property is a ring (enumerated list) with the following values:

Enumeration	Value	Description
Normal	0	The PHY is awake and fully functional.
Sleep	1	The PHY is in a low power sleep mode.

Note  The sleep/wake capability is based on the OPEN Alliance TC10 Sleep/Wake 2.0 specification and is only supported on the PXIe-8523. The port must be configured for a link speed of 100 Mbps and a port mode of Direct to use the sleep/wake capability.

Note  If an interface is in Sleep mode and then configured in a way that does not support the sleep/wake capability, the interface will automatically wake up.

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

XNET Session

nxPropSession_IntfEnetPhyState

Indicates the master/slave state that the interface is using for the Ethernet PHY. This property is configured using NI MAX or the System Configuration property PHY State Configured. This property is an enumerated list of values, as described in the following table:

Enumeration	Value	Description
nxEnetPhyState_Slave	0	Slave state as defined in IEEE Std 802.3.
nxEnetPhyState_Master	1	Master state as defined in IEEE Std 802.3.
nxEnetPhyState_Auto	2	Auto-Negotiation as defined in IEEE Std 802.3.
Two PHYs that are physically connected must use opposing PHY States. In other words, one PHY must be configured to be the master, and the other PHY must be configured to be the slave. Devices that use standard Ethernet interfaces support only an auto-negotiated master/slave state. Devices with Automotive Ethernet interfaces must be configured statically as either master or slave; the state is typically determined by the PHY State setting of the ECU to which the interface is connected.

Data Type	Direction	Required?	Default
u32	Read Only	Yes	Direct

XNET Session

nxPropSession_IntfEnetPortMode

Indicates the hardware connectivity for the port. This property is configured using NI MAX or the System Configuration API property XNET:Interface:Ethernet:Port Mode. This property uses an enumerated list with the following values:

Enumeration	Value	Description
nxEnetPortMode_Direct	0	The port is directly connected; frames received and transmitted on the port have no relationship to any other port on the XNET device. Input and output sessions are supported in Direct mode.
nxEnetPortMode_Tap	1	This port is connected to another port on the XNET device using a Tap, as shown in Using Ethernet. The pair of connected ports are referred to as Tap partners. A frame received on one Tap partner is immediately transmitted out the other Tap partner, to mimic behavior of an Ethernet cable. When an input session is created using an XNET interface for either Tap partner, and the monitor suffix is used with the XNET interface, the session reads frames received on both Tap partners. Output sessions are not supported in Tap mode. When you set Tap on this port, the Port Mode of its Tap partner is automatically set to Tap as well.
For the PXIe-8521, physical port numbers 1 and 2 are Tap partners, and physical port numbers 3 and 4 are Tap partners. This property cannot be changed while an XNET session is started on the port. When this property is changed and Save Changes is invoked on the hardware resource, the link is brought down and back up in order to configure the change.

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

XNET Interface

nxPropSession_IntfEnetSignalQuality

Indicates the signal quality of the interface. For NI PXI Automotive Ethernet Interface modules, this value is similar to the Signal Quality Index (SQI) as defined in the OPEN Alliance TC1 standard; 7 indicates the best link quality, while 0 indicates the lowest link quality. When the link is down, the signal quality value is 0.

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

XNET Interface

nxPropSession_IntfEnetSleepCapability

Indicates whether the sleep capability is enabled or disabled/not available for the interface.

This property is a ring (enumerated list) with the following values:

Enumeration	Value	Description
Disabled/Not Available	0	The sleep capability is either disabled or not available for this device or interface configuration.
Enabled	1	The sleep capability is enabled for this interface.
Use the System Configuration property XNET:Interface:Ethernet:Sleep Capability Configured to enable the sleep capability. However, if the sleep capability is not supported by the interface configuration (e.g., the interface is configured for 1000 Mbps), querying the Sleep Capability property will always return 0 (Disabled / Not Available).

Note  The sleep/wake capability is based on the OPEN Alliance TC10 Sleep/Wake 2.0 specification. and is only supported on the PXIe-8523. The port must be configured for a link speed of 100 Mbps and a port mode of Direct to use the sleep/wake capability.

Note  If an interface is in Sleep mode and then configured in a way that does not support the sleep/wake capability, the interface will automatically wake up.

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

XNET Session

nxPropSession_IntfEnetTriggerPpsSynced

When the interface is set up using the nxConnectTerminals with a source terminal value of PXI_Trigx (where x is a number from 0 to 7) and a destination terminal value of NetworkTimePPS, this property indicates if the PXI_Trigx line carrying a pulse per second (PPS) has synchronized the network timekeeper on this interface.

Synchronized means the XNET clock adjustment algorithm (servo) is in its final stage (calibrated). A sufficient number of pulses have been timestamped and compared such that synchronization quality is unlikely to improve significantly, but no fixed metric is applied as a threshold.

This property is false if the interface's network time is not sourced locally (i.e., Protocol Enabled? is true and Port State is nxEnetTimePortState_Slave) or if PXI_Trigx has not been connected to NetworkTimePPS.

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

XNET Interface

nxPropSession_IntfEnetStatsPhyCounterValues

This property returns the counter value of each Ethernet statistics PHY property supported by XNET. Each counter value is returned as a string for display, but the internal counter uses a 64-bit unsigned integer (U64) data type to avoid rollover. The counter resets to zero when the system powers up or the device is reset, and increments according to the description in Ethernet Statistics PHY Properties.

The counter value at a specific index corresponds to the name at the same index in Counter Names. The array of strings for this property is the same size as the Counter Names array of strings. Refer to Ethernet Statistics PHY Properties for a description of each counter value.

The array of counters are not provided as a single snapshot in time. For example, it is possible that a new frame is received as the values are returned, such that index 3 does not count the new frame, and index 4 does count the new frame.

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

XNET Interface

nxPropSession_IntfEnetStatsPhyWakeupPulse

Count of the number of Wake Up Pulse (WUP) commands the local port's PHY has observed. The count includes both the sent and received WUP commands.

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

XNET Interface

nxPropSession_IntfEnetStatsPhyWakeupRequest

Count of the number of Wake Up Request (WUR) commands the local port's PHY has observed. This count only includes the WUR commands received from the remote port.

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

XNET Interface

nxPropSession_IntfEnetStatsPhyLowPowerSleep

Count of the number of Low Power Sleep (LPS) commands the local port's PHY has observed. This count includes both the sent and received LPS commands.

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

XNET Interface

nxPropSession_IntfEnetStatsPhyWakeupFailure

Count of the number of wake up failures as reported by the PHY.

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

XNET Interface

nxPropSession_IntfEnetStatsPhySleepFailure

Count of the number of sleep failures as reported by the PHY.

Data Type	Direction	Required?	Default
nxEptRxFilter_Element_t*	Read/Write	No	Refer to Description

XNET Session

nxPropSession_IntfEnetEptReceiveFilter

Each frame that is received by the interface is forwarded to either the XNET endpoint or the OS stack (not both). The Receive Filter property configures zero, one, or two identification elements (filters) for this forwarding decision.

The following C language pseudo-code describes how XNET forwards each received frame to either the XNET endpoint or the OS stack:

// TRUE forwards to XNET endpoint, FALSE forwards to OS stack

boolean forwardFrameToEndpoint = FALSE;

for (int i = 0; i < 2; i++)

{

boolean endpointMatch =

( RxFilter[i].useVID || RxFilter[i].usePriority || RxFilter[i].useDestinationMAC );

if ( RxFilter[i].useVID && (RxFilter[i].VID != frameVID)

endpointMatch = FALSE;

if ( RxFilter[i].usePriority && (RxFilter[i].Priority != framePriority) )

endpointMatch = FALSE;

if ( RxFilter[i].useDestinationMAC && (RxFilter[i].DestinationMAC != frameDestinationMAC) )

endpointMatch = FALSE;

// Only one element must match in order to forward to XNET endpoint.

forwardFrameToEndpoint = forwardFrameToEndpoint || endpointMatch;

}

The default value is:

RxFilter[0].UseVID = TRUE, RxFilter[0].VID = 2, RxFilter[0].UsePriority = TRUE, RxFilter[0].Priority = 3, RxFilter[0].UseDestinationMAC = FALSE, RxFilter[1].UseVID = TRUE, RxFilter[1].VID = 2, RxFilter[1]UsePriority = TRUE, RxFilter[1].Priority = 2, RxFilter[1].UseDestinationMAC = FALSE

This default value corresponds to AVB traffic (SR class A and B) using the defaults specified for the credit-based shaper in IEEE Std 802.1Q.

If an XNET input session is not started for the interface's endpoint (e.g., Frame Input Stream session on "ENET1"), all frames are forwarded to the OS stack. As described in Using Ethernet), an XNET input session for the interface's monitor (e.g., Frame Input Stream session on "ENET1/monitor") receives all frames regardless of the value of this property.

If you write this property with fewer than two elements, the missing element is configured with all three "use" flags set to false. For example, if you write zero elements (an empty array), all traffic is forwarded to the OS stack.

IEEE Std 802.1Q specifies that VLAN ID (VID) and destination MAC address can be used for forwarding decisions. The VID is typically used for a type of traffic, and destination MAC address is used for a specific stream (flow). The Priority Code Point (PCP) determines how the frame travels through transmit queues in the network. The PCP is commonly known as priority.

The data type for VID is U16. Each VID value ranges from 1 to 4094. The VID in this property applies only to a tagged frame. The tagged frame must use a Tag Protocol Identification (TPID) of hex 8100, which is the Customer VLAN Tag (C-TAG) format commonly known as a VLAN tag. This property's VID value is compared to the VID value in the Tag Control Info of the frame. An untagged frame has an implicit VID of 1, but if this property's UseVID is true and VID is 1, the untagged frame forwards to the OS stack.

The data type for priority is U8. Each priority value ranges from 0 to 7. The priority in this property applies only to a tagged frame. The tagged frame must use a Tag Protocol Identification (TPID) of hex 8100, which is the Customer VLAN Tag (C-TAG) format commonly known as a VLAN tag. This property's priority value is compared to the Priority Code Point (PCP) value in the Tag Control Info of the frame. An untagged frame has an implicit priority of 0, but if this property's UsePriority is true and Priority is 0, the untagged frame forwards to the OS stack.

The destination MAC address is a string of six octets. Each octet consists of two hexadecimal (0-9, A-F) digits. The octets are separated by colon. For example: 00:80:2F:AB:CD:EF.

Data Type	Direction	Required?	Default
u64	Read/Write	No	Refer to Description

XNET Session

nxPropSession_IntfEnetEptTransmitBandwidth

This property configures the maximum bandwidth for the credit-based shaper algorithm specified in IEEE Std 802.1Q, which is used for all transmissions from the endpoint. The value is in units of bits per second.

This property applies when you call nxWriteFrame to transmit frames using an endpoint session. The endpoint is the highest importance for transmit, and the OS stack is lower importance. This property corresponds to the adminIdleSlope parameter as described in IEEE Std 802.1Q. The default value corresponds to 75% of the default link speed. On devices that support multiple link speeds, the Transmit Bandwidth will be coerced to the closest valid value when the link speed changes to a speed less than the Transmit Bandwidth.

Data Type	Direction	Required?	Default
u32	Read/Write	No	IEEE Std 802.1AS-2011 (0)

XNET Session

nxPropSession_IntfEnetTimeProtocol

This property configures the time synchronization protocol that the clock is using. This protocol is indicated in all time sync messages that are transmitted by the session's interface (port). This property uses an enumerated list with the following values:

Enumeration	Value	Description
nxEnetTimeProtocol_IEEE8021as	0	IEEE Standard 802.1AS-2011: Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks.

Note  This property currently supports only one protocol; in future releases, it may be expanded to support additional protocols.

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

XNET Session

nxPropSession_IntfEnetTimeProtocolEnabled

This property enables (runs) or disables the time synchronization protocol:

• When this property is true, the protocol transmits and receives messages in order to synchronize time with its neighboring ports.
• When this property is false, the protocol does not transmit messages, and messages received for the protocol are ignored.

This property must be written to false prior to changing the value of the Protocol property. All other writable Time Sync properties can be changed while this property is true.

The Protocol Enabled? property is created only when at least one XNET Session exists on the Ethernet interface; therefore, this property is effectively false when no XNET Session is created. The time synchronization protocol does not run outside the context of XNET sessions.

This property is not associated with the state of input/output on the session (see State Models). It is possible to enable the time synchronization protocol prior to starting the session (e.g., to wait for Synced to equal true prior to timestamping received frames). It is also possible to start the session with the time synchronization protocol disabled, in which case frames from nxReadFrame contain a network synced? flag of false.

For the Protocol of IEEE Std 802.1AS-2011, a property value of true corresponds to running the clock's protocol, as described in 7.4 of IEEE Std 802.1AS-2011. A property value of true does not necessarily indicate that time is synchronized with the neighboring port. The AS Capable property is used to determine if the neighboring port is running 802.1AS.

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

XNET Session

nxPropSession_IntfEnetTimeBMCAEnabled

Enables (runs) the Best Master Clock Algorithm (BMCA) of the time synchronization Protocol. The BMCA dynamically exchanges messages over the network to select the best grandmaster in the network, and to change all port states in order to transfer timing messages from the selected grandmaster to slaves.

When this property is true, Protocol runs the BMCA. The Port State property is determined from operation of the BMCA. The XNET interface is capable of acting as a grandmaster. Therefore, the BMCA can set the Port State property to Slave (i.e., XNET interface receives time) or Master (XNET interface sends time). The Port State Configured property is not used while the BMCA is enabled. The BMCA uses the following properties in order for its selection of grandmaster (with exceptions for topology):

• Priority1
• Clock Class
• Clock Accuracy
• Clock Offset Scaled Log Variance
• Priority2
• Clock ID

When this property is false, the BMCA is not operational. The false value is useful for in-vehicle applications in which the topology for time synchronization is considered to be part of the vehicle's static design. The Port State Configured property must be written in order to specify the Master or Slave state for the port. The read-only Port State property reflects Port State Configured.

This property becomes read only when a port is in Tap mode.

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

XNET Session

nxPropSession_IntfEnetTimeOffsetFromMaster

This property provides the positive or negative offset in time between this clock and the grandmaster. Offset From Master can be used to determine when this XNET interface is sufficiently synchronized to the grandmaster in order to continue.

The time synchronization protocol specifies that this offset is received by a slave port, and that offset is used to compute the offset that transmits on a master port to the next clock in the network. Technically, the offset is relative to the previous master port (i.e., nearest neighbor); but practically, the offset is relative to the grandmaster. This offset does not account for clock inaccuracies in the communication path from grandmaster to slave (e.g., switches).

When Port State is Master, this XNET interface acts as grandmaster, and therefore this property returns 0.0.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the offsetFromMaster parameter as described in 14.3.2 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimeClkID

This property uniquely identifies the clock in the network.

The Clock ID is formed by taking the MAC address assigned to the clock and mapping it to an array of eight bytes, according to rules in the IEEE Std 802 EUI-48 standard. The best master clock algorithm (BMCA) uses this property as a tie-breaker among clocks that would otherwise be equal.

The Clock ID is returned as a string of eight octets. Each octet consists of two hexadecimal (0-9, A-F) digits. The octets are separated by colon. For example, 00:80:2F:AB:CD:EF:00:01

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the clockIdentity parameter as described in 14.2.1 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimeClkClass

This property provides the traceability of time or frequency distributed by the clock when it is the grandmaster.The value for this property is an integer.

Integer	Clock Class Specification
6	The clock is synchronized to a primary time reference. The distributed timescale is PTP. A clock in this class cannot be a slave to another clock in the domain.
7	The clock has previously been designated as Clock Class 6, but has lost the ability to synchronize to a primary time reference. A clock in this class is in holdover mode and operates within holdover specifications. The distributed timescale is PTP. A clock in this class cannot be a slave to another clock in the domain.
13	The clock is synchronized to an application-specific time source. The distributed timescale is ARB. A clock in this class cannot be a slave to another clock in the domain.
14	The clock has previously been designated as Clock Class 13, but has lost the ability to synchronize to an application-specific time source. A clock in this class is in holdover mode and operates within holdover specifications. The distributed timescale is ARB. A clock in this class cannot be a slave to another clock in the domain.
52	The clock is degradation alternative A for a Clock Class 7 clock that is not within holdover specification. A clock in this class cannot be a slave to another clock in the domain.
58	The clock is degradation alternative A for a Clock Class 14 clock that is not within holdover specification. A clock in this class cannot be a slave to another clock in the domain.
68—122	The clock uses an alternate PTP profile.
133—170	The clock uses an alternate PTP profile.
187	The clock is degradation alternative B for a Clock Class 7 clock that is not within holdover specification. A clock in this class can be a slave to another clock in the domain.
193	The clock is degradation alternative B for a Clock Class 14 clock that is not within holdover specification. A clock of this class can be a slave to another clock in the domain.
216—232	The clock uses an alternate PTP profile.
248	The default Clock Class. This class is used if none of the other class definitions apply.
255	The clock is a slave-only clock.
The best master clock algorithm (BMCA) uses this property in its comparison of clock quality.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the clockClass parameter as described in 14.2.3 of IEEE Std 802.1AS-2011, which in turn references 7.6.2.4 of IEEE Std 1588-2008, which describes the clock class specification.

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

XNET Session

nxPropSession_IntfEnetTimeClkAccuracy

This property provides the accuracy of the hardware clock (e.g., oscillator) distributed by the clock when it is the grandmaster. This property uses an enumerated list with the following values:

Enumeration	Value	Description
nxEnetTimeClkAccuracy_Within25nsec	32	Time is accurate to within 25 ns
nxEnetTimeClkAccuracy_Within100nsec	33	Time is accurate to within 100 ns
nxEnetTimeClkAccuracy_Within250nsec	34	Time is accurate to within 250 ns
nxEnetTimeClkAccuracy_Within1usec	35	Time is accurate to within 1 µs
nxEnetTimeClkAccuracy_Within2500nsec	36	Time is accurate to within 2500 ns
nxEnetTimeClkAccuracy_Within10usec	37	Time is accurate to within 10 µs
nxEnetTimeClkAccuracy_Within25usec	38	Time is accurate to within 25 µs
nxEnetTimeClkAccuracy_Within100usec	39	Time is accurate to within 100 µs
nxEnetTimeClkAccuracy_Within250usec	40	Time is accurate to within 250 µs
nxEnetTimeClkAccuracy_Within1msec	41	Time is accurate to within 1 ms
nxEnetTimeClkAccuracy_Within2500usec	42	Time is accurate to within 2500 µs
nxEnetTimeClkAccuracy_Within10msec	43	Time is accurate to within 10 ms
nxEnetTimeClkAccuracy_Within25msec	44	Time is accurate to within 25 ms
nxEnetTimeClkAccuracy_Within100msec	45	Time is accurate to within 100 ms
nxEnetTimeClkAccuracy_Within250msec	46	Time is accurate to within 250 ms
nxEnetTimeClkAccuracy_Within1sec	47	Time is accurate to within 1 s
nxEnetTimeClkAccuracy_Within10sec	48	Time is accurate to within 10 s
nxEnetTimeClkAccuracy_GreaterThan10sec	49	Time accuracy is greater than 10 s
nxEnetTimeClkAccuracy_Unknown	254	Clock is not synchronized
The best master clock algorithm (BMCA) uses this property in its comparison of clock quality.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the clockAccuracy parameter as described in 14.2.4 of IEEE Std 802.1AS-2011, which in turn references 7.6.2.5 of IEEE Std 1588-2008, which describes clock accuracy values.

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

XNET Session

nxPropSession_IntfEnetTimeClkOffsetVar

This property provides an estimate of the precision of the timestamping that the clock uses for the protocol. This estimate depends on the stability of the hardware clock (e.g., oscillator), as well as any error introduced in the timestamping process. The estimate is a second-order statistic on the variation of the frequency of the hardware clock. Valid values range from 0 to 65535.

The best master clock algorithm (BMCA) uses this property in its comparison of clock quality.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the offsetScaledLogVariance attribute, specified in 14.2.5 of IEEE Std 802.1AS-2011, which in turn references 7.6.3 of IEEE Std 1588-2008.

Data Type	Direction	Required?	Default
u32	Read/Write	No	246

XNET Session

nxPropSession_IntfEnetTimePriority1

The best master clock algorithm (BMCA) uses this property as the first comparison to determine the grandmaster. Lower values take precedence. Valid values range from 0 to 255. The value 255 specifies that the clock is not grandmaster-capable (slave only). For example, if you write this property to zero, and all other clocks in the network have a Priority1 greater than zero, this clock is likely to be selected as grandmaster.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the priority1 attribute, specified in 14.2.6 of IEEE Std 802.1AS-2011.

Data Type	Direction	Required?	Default
u32	Read/Write	No	248

XNET Session

nxPropSession_IntfEnetTimePriority2.html

The best master clock algorithm (BMCA) uses this property as a secondary comparison, after comparing the properties for clock quality, and before using Clock ID as a tie-breaker. Lower values take precedence. Valid values range from 0 to 255.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the priority2 attribute, specified in 14.2.7 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimeStepsToGM

This property provides the number of steps that this clock is removed from the grandmaster. For example, if there is a single Ethernet cable that connects this clock to the grandmaster, this property returns the value 1.

The best master clock algorithm (BMCA) uses this property for topology analysis. If two potentially equal grandmasters provide the same timescale, the BMCA can select the one that is closer, with the rationale that each step has an adverse effect on accuracy.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the stepsRemoved attribute, specified in 14.3.1 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimeGMClkID

This property provides the Clock ID of the currently selected grandmaster for this clock.

The Grandmaster Clock ID is returned as a string of eight octets. Each octet consists of two hexadecimal (0-9, A-F) digits. The octets are separated by colon. For example, 00:80:2F:AB:CD:EF:00:12.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the grandmasterIdentity attribute, specified in 14.4.3 of IEEE Std 802.1AS-2011. This property also uses the gmPresent Boolean specified in 10.2.3.13 of IEEE Std 802.1AS-2011. If gmPresent is true, this property returns the Clock ID of the grandmaster. If gmPresent is false, this property returns the Clock ID of the XNET Interface. If grandmaster information has not been received (e.g., Protocol Enabled is false, or BMCA is disabled and the slave does not receive announce messages), this property returns the invalid value of all zeroes.

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

XNET Session

nxPropSession_IntfEnetTimeGMClkClass

This property provides the Clock Class of the currently selected grandmaster for this clock.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to grandmasterClockClass, specified in 14.4.4 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimeGMClkAccuracy

This property provides the Clock Accuracy of the currently selected grandmaster for this clock.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the grandmasterClockAccuracy attribute, specified in 14.4.5 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimeGMClkOffsetVar

This property provides the Clock Offset Scaled Log Variance of the currently selected grandmaster for this clock.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the grandmasterOffsetScaledLogVariance attribute, specified in 14.4.6 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimeGMPriority1

This property provides the Priority1 of the currently selected grandmaster for this clock.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the grandmasterPriority1 attribute, specified in 14.4.7 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimeGMPriority2

This property provides the Priority2 of the currently selected grandmaster for this clock.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the grandmasterPriority2 attribute, specified in 14.4.8 of IEEE Std 802.1AS-2011.

Data Type	Direction	Required?	Default
u64	Write Only	No	0

XNET Session

nxPropSession_IntfEnetTimeAdjustNetworkTime

When this clock is the grandmaster (that is, the Grandmaster Clock ID equals the Clock ID), a write of this property applies a positive or negative adjustment to the time distributed to the network. This can be used to align network time with another timescale.

When this clock is a slave (not the grandmaster), a write of this property has no effect (error returned); the adjustment will be overridden when time is received from the grandmaster.

This property corresponds to the lastGmPhaseChange parameter of the ClockSourceTime.invoke function, specified in the IEEE Std 802.1AS-2011.

Note  This property can also be written when Protocol Enabled? Is false.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Slave

XNET Session

nxPropSession_IntfEnetTimePortStateConfigured

This property configures the Port State when BMCA Enabled? is false. Valid values are nxEnetTimePortState_Master and nxEnetTimePortState_Slave. If BMCA Enabled? is true, the value in this property is ignored.

This property becomes read only when a port is in Tap mode.

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

XNET Session

nxPropSession_IntfEnetTimePortState

Provides the current state of the port. This property uses an enumerated list with the following values:

Enumeration	Value	Description
nxEnetTimePortState_Disabled	3	The protocol is disabled on the port. No protocol messages are transmitted in this state. The port discards received messages for the protocol. The port is in this state when Protocol Enabled? is false.
nxEnetTimePortState_Master	6	Port is sending time. If the clock has only one port, the port is acting as grandmaster.
nxEnetTimePortState_Passive	7	Port is exchanging messages to measure Propagation Delay but is not sending time (Master) or receiving time (Slave).
nxEnetTimePortState_Slave	9	Port is receiving time. In IEEE Std 802.1AS, the port is not necessarily synchronized (calibrated). In IEEE Std 1588, the port is assumed to be synchronized.
For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the portRole parameter, specified in 14.6.3 of IEEE Std 802.1AS-2011, which in turn references 8.2.5.3.1 of IEEE Std 1588-2008. The only valid values for IEEE Std 802.1AS-2011 are Disabled, Master, Slave, and Passive.

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

XNET Session

nxPropSession_IntfEnetTimePortPropDelay

This property provides the propagation delay for the Ethernet cable between this clock and its neighboring clock. Propagation delay is the time it takes for a single bit to travel along the wire (i.e., PHY to PHY). Propagation delay is a fundamental measurement that is required for time synchronization.

This property uses a double-precision floating-point, and the value is provided in seconds, which is typically used for relative times. To convert the value to nanoseconds, multiply this property value by 1,000,000,000.

The propagation speed for copper wires is close to 2 * 10^8 meters/second (5 nanoseconds/meter). Therefore, multiplying this property value by 200,000,000 provides a close approximation of the cable length in meters. For example, 800 nanoseconds of propagation delay occurs with approximately 160 meters of copper cable.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the neighborPropDelay attribute, specified in 14.6.7 of IEEE Std 802.1AS-2011.

Data Type	Direction	Required?	Default
f64	Read/Write	No	0

XNET Session

nxPropSession_IntfEnetTimePortPropDelayConfigured

Configures the Propagation Delay when Pdelay Enabled? is false. If Pdelay Enabled? is true, the value in this property is ignored.

Data Type	Direction	Required?	Default
f64	Read/Write	No	0.0000008 (800 ns)

XNET Session

nxPropSession_IntfEnetTimePortPropDelayThreshold

For IEEE Std 802.1AS, if the Propagation Delay exceeds the threshold in this property, the protocol assumes that a switch or router that is not 802.1AS-capable exists between this clock and the neighboring 802.1AS-capable clock. The resulting asymmetries would have an adverse effect on time synchronization accuracy, so this port sets AS Capable? to false. If Pdelay Enabled? is false, this property is ignored.

This property uses a double-precision floating-point, and the value is provided in seconds, which is typically used for relative times. To convert the value to nanoseconds, multiply this property value by 1000000000 (for read).

The propagation speed for copper wires is close to 2 * 10^8 meters/second (5 nanoseconds/meter). Therefore, multiplying this property value by 200000000 provides a close approximation of the cable length in meters. For example, 800 nanoseconds of propagation delay occurs with approximately 160 meters of copper cable.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the neighborPropDelayThresh parameter, specified in 14.6.8 of IEEE Std 802.1AS-2011. The default value is specified in IEEE Std 802.1AS-2011/Cor1-2013.

This property becomes read only when a port is in Tap mode.

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

XNET Session

nxPropSession_IntfEnetTimePortPdelayEnabled

Enables the exchange of Pdelay (peer-to-peer delay) messages, as a means of measuring Propagation Delay.

When this property is true, the port transmits Pdelay request messages (Pdelay_Req) to the neighboring clock and processes received Pdelay response messages (Pdelay_Resp). The port also processes received Pdelay request messages and transmits Pdelay response messages. The Propagation Delay is measured using this message exchange. The Propagation Delay Configured property is not used while Pdelay is enabled.

When this property is false, Pdelay messages are not transmitted, and received Pdelay messages are ignored. The false value is useful for in-vehicle applications in which the topology for time synchronization is considered to be part of the vehicle's static design. The Propagation Delay Configured property must be used in order to specify the propagation delay for the port. The read-only Propagation Delay property reflects Propagation Delay Configured.

For the Protocol of IEEE Std 802.1AS-2011, a property value of true corresponds to propagation delay measurement as described in 11.1.2 of IEEE Std 802.1AS-2011. A property value of false is not specified in IEEE Std 802.1AS-2011. Behavior analogous to a property value of false is specified for 802.1AS as part of the AUTOSAR Specification of Time Synchronization over Ethernet, and the Avnu Automotive Ethernet AVB Functional and Interoperability Specification.

Data Type	Direction	Required?	Default
u32	Read/Write	No	1 second (0)

XNET Session

nxPropSession_IntfEnetTimePortLogPdelayIntervalConfigured

If Pdelay Enabled? is true, this property configures the interval between successive transmissions of the Pdelay_Req message by this port.

According to the standards, a message transmission interval is a signed integer in the range -128 to 127, represented as the logarithm to the base 2 of the time interval measured in seconds. For example, value 0 is 1 second, and value -3 is 125 milliseconds. The interval is provided as an enumerated list for usability:

Enumeration	Value	Description
nxEnetTimePdelayReqInterval_125ms	-3	Message transmission interval of 125 milliseconds.
nxEnetTimePdelayReqInterval_250ms	-2	Message transmission interval of 250 milliseconds.
nxEnetTimePdelayReqInterval_500ms	-1	Message transmission interval of 500 milliseconds. This value is supported on all NI products.
nxEnetTimePdelayReqInterval_1s	0	Message transmission interval of 1 second. This value is supported on all NI products.
nxEnetTimePdelayReqInterval_2s	1	Message transmission interval of 2 seconds. This value is supported on all NI products.
The enumerated list is limited to values that are practical in implementation, but not all values are supported for all NI products. All NI products support the values listed as such in the table.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the initialLogPdelayReqInterval parameter as described in 14.6.18 of IEEE Std 802.1AS-2011. The initialLogPdelayReqInterval parameter is used for the initial transmit interval of Pdelay_Req, but afterward the interval can only be changed by receiving a special Signaling message from the neighboring clock (see 10.5.4.3 of IEEE Std 802.1AS-2011). The Signaling message is optional, and if not used in the network, this property configures the interval exclusively.

This property becomes read only when a port is in Tap mode.

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

XNET Session

nxPropSession_IntfEnetTimePortLogPdelayInterval

If Pdelay Enabled? is true, this property provides the current interval used for successive transmissions of the Pdelay_Req message by this port.

According to the standards, a message transmission interval is a signed integer in the range -128 to 127, represented as the logarithm to the base 2 of the time interval measured in seconds. For example, value 0 is 1 second, and value -3 is 125 milliseconds. The interval is provided as an enumerated list for usability:

Enumeration	Value	Description
nxEnetTimePdelayReqInterval_125ms	-3	Message transmission interval of 125 milliseconds.
nxEnetTimePdelayReqInterval_250ms	-2	Message transmission interval of 250 milliseconds.
nxEnetTimePdelayReqInterval_500ms	-1	Message transmission interval of 500 milliseconds. This value is supported on all NI products.
nxEnetTimePdelayReqInterval_1s	0	Message transmission interval of 1 second. This value is supported on all NI products.
nxEnetTimePdelayReqInterval_2s	1	Message transmission interval of 2 seconds. This value is supported on all NI products.
The enumerated list is limited to values that are practical in implementation, but not all values are supported for all NI products. All NI products support the values listed as such in the table.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the currentLogPdelayReqInterval parameter as described in 14.6.19 of IEEE Std 802.1AS-2011. If the optional Signaling message is used in the network, the currentLogPdelayReqInterval parameter can be different from its initial value (see Log Pdelay_Req Interval Configured).

Data Type	Direction	Required?	Default
u32	Read/Write	No	125 milliseconds (-3)

XNET Session

nxPropSession_IntfEnetTimePortLogSyncIntervalConfigured

If Port State is Master, this property configures the interval between successive transmissions of the sync message by this port.

According to the standards, a message transmission interval is a signed integer in the range -128 to 127, represented as the logarithm to the base 2 of the time interval measured in seconds. For example, value 0 is 1 second, and value -3 is 125 milliseconds. The interval is provided as an enumerated list for usability:

Enumeration	Value	Description
nxEnetTimeSyncInterval_125ms	-3	Message transmission interval of 125 milliseconds.
nxEnetTimeSyncInterval_250ms	-2	Message transmission interval of 250 milliseconds.
nxEnetTimeSyncInterval_500ms	-1	Message transmission interval of 500 milliseconds. This value is supported on all NI products.
nxEnetTimeSyncInterval_1s	0	Message transmission interval of 1 second. This value is supported on all NI products.
nxEnetTimeSyncInterval_2s	1	Message transmission interval of 2 seconds. This value is supported on all NI products.
The enumerated list is limited to values that are practical in implementation, but not all values are supported for all NI products. All NI products support the values listed as such in the table.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the initialLogSyncInterval parameter as described in 14.6.14 of IEEE Std 802.1AS-2011. The initialLogSyncInterval parameter is used for the initial transmit interval of Synch, but afterward the interval can only be changed by receiving a special Signaling message from the neighboring clock (see 10.5.4.3 of IEEE Std 802.1AS-2011). The Signaling message is optional, and if not used in the network, this property configures the interval exclusively.

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

XNET Session

nxPropSession_IntfEnetTimePortLogSyncInterval

If Port State is Master, this property provides the current interval used for successive transmissions of the sync message by this port.

According to the standards, a message transmission interval is a signed integer in the range -128 to 127, represented as the logarithm to the base 2 of the time interval measured in seconds. For example, value 0 is 1 second, and value -3 is 125 milliseconds. The interval is provided as an enumerated list for usability:

Enumeration	Value	Description
nxEnetTimeSyncInterval_125ms	-3	Message transmission interval of 125 milliseconds.
nxEnetTimeSyncInterval_250ms	-2	Message transmission interval of 250 milliseconds.
nxEnetTimeSyncInterval_500ms	-1	Message transmission interval of 500 milliseconds. This value is supported on all NI products.
nxEnetTimeSyncInterval_1s	0	Message transmission interval of 1 second. This value is supported on all NI products.
nxEnetTimeSyncInterval_2s	1	Message transmission interval of 2 seconds. This value is supported on all NI products.
The enumerated list is limited to values that are practical in implementation, but not all values are supported for all NI products. All NI products support the values listed as such in the table.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the currentLogSyncInterval parameter as described in 14.6.15 of IEEE Std 802.1AS-2011. If the optional Signaling message is used in the network, the currentLogSyncInterval parameter can be different from its initial value (see Log Sync Interval Configured).

Data Type	Direction	Required?	Default
u32	Read/Write	No	3

XNET Session

nxPropSession_IntfEnetTimePortSyncReceiptTimeout

If Port State is Slave, this property configures the number of sync intervals (see Log Sync Interval) to wait without receiving a sync message before assuming that the neighboring Master is no longer available and that the best master clock algorithm (BMCA) needs to run, if enabled.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the syncReceiptTimeout parameter as described in 14.6.16 of IEEE Std 802.1AS-2011.

Data Type	Direction	Required?	Default
u32	Read/Write	No	1 second (0)

XNET Session

nxPropSession_IntfEnetTimePortLogAnnounceIntervalConfigured

If Announce Transmit Enabled? is true, this property configures the interval between successive transmissions of the announce message by this port.

According to the standards, a message transmission interval is a signed integer in the range -128 to 127, represented as the logarithm to the base 2 of the time interval measured in seconds. For example, value 0 is 1 second, and value -3 is 125 milliseconds. The interval is provided as an enumerated list for usability:

Enumeration	Value	Description
nxEnetTimeAnnounceInterval_125ms	-3	Message transmission interval of 125 milliseconds.
nxEnetTimeAnnounceInterval_250ms	-2	Message transmission interval of 250 milliseconds.
nxEnetTimeAnnounceInterval_500ms	-1	Message transmission interval of 500 milliseconds. This value is supported on all NI products.
nxEnetTimeAnnounceInterval_1s	0	Message transmission interval of 1 second. This value is supported on all NI products.
nxEnetTimeAnnounceInterval_2s	1	Message transmission interval of 2 second. This value is supported on all NI products.
The enumerated list is limited to values that are practical in implementation, but not all values are supported for all NI products. All NI products support the values listed as such in the table.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the initialLogAnnounceInterval attribute as described in 14.6.11 of IEEE Std 802.1AS-2011. The initialLogAnnounceInterval parameter is used for the initial transmit interval of Announce, but afterward the interval can only be changed by receiving a special Signaling message from the neighboring clock (see 10.5.4.3 of IEEE Std 802.1AS-2011). The Signaling message is optional, and if not used in the network, this property configures the interval exclusively.

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

XNET Session

nxPropSession_IntfEnetTimePortLogAnnounceInterval

If Announce Transmit Enabled? is true, this property provides the current interval used for successive transmissions of the announce message by this port.

According to the standards, a message transmission interval is a signed integer in the range -128 to 127, represented as the logarithm to the base 2 of the time interval measured in seconds. For example, value 0 is 1 second, and value -3 is 125 milliseconds. The interval is provided as an enumerated list for usability:

Enumeration	Value	Description
nxEnetTimeAnnounceInterval_125ms	-3	Message transmission interval of 125 milliseconds.
nxEnetTimeAnnounceInterval_250ms	-2	Message transmission interval of 250 milliseconds.
nxEnetTimeAnnounceInterval_500ms	-1	Message transmission interval of 500 milliseconds. This value is supported on all NI products.
nxEnetTimeAnnounceInterval_1s	0	Message transmission interval of 1 second. This value is supported on all NI products.
nxEnetTimeAnnounceInterval_2s	1	Message transmission interval of 2 seconds. This value is supported on all NI products.
The enumerated list is limited to values that are practical in implementation, but not all values are supported for all NI products. All NI products support the values listed as such in the table.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the currentLogAnnounceInterval parameter as described in 14.6.12 of IEEE Std 802.1AS-2011. If the optional Signaling message is used in the network, the currentLogAnnounceInterval parameter can be different from its initial value (see Log Announce Interval Configured).

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

XNET Session

nxPropSession_IntfEnetTimePortAnnounceTransmitEnabled

Enables the transmit of announce messages, which provide properties of this port as a potential grandmaster. Announce messages are required for proper operation of the best master clock algorithm (BMCA), so this property is ignored when BMCA Enabled? is true.

When this property is true, the port transmits announce messages. This value is the default behavior as specified in the protocol standard.

When this property is false, the port does not transmit announce messages. When this property is false in the grandmaster, slave ports will not receive information about that grandmaster (e.g. properties like Grandmaster Clock Accuracy). Therefore, the false value is useful for in-vehicle applications in which each slave assumes properties for its grandmaster as part of the vehicle's static design.

For the Protocol of IEEE Std 802.1AS-2011, a property value of true corresponds to announce message transmission as described in 10.3 of IEEE Std 802.1AS-2011. A property value of false is not specified in IEEE Std 802.1AS-2011. Behavior analogous to a property value of false is specified for 802.1AS as part of the AUTOSAR Specification of Time Synchronization over Ethernet, and the Avnu Automotive Ethernet AVB Functional and Interoperability Specification.

This property becomes read only when a port is in Tap mode.

Data Type	Direction	Required?	Default
u32	Read/Write	No	3

XNET Session

nxPropSession_IntfEnetTimePortAnnounceReceiptTimeout

If Port State is Slave, this property configures the number of announce intervals (see Log Announce Interval) to wait without receiving an announce message before assuming that the neighboring Master is no longer available and that the best master clock algorithm (BMCA) needs to run, if enabled.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the announceReceiptTimeout parameter as described in 14.6.13 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimePortASCapable

This property is specific to the IEEE Std 802.1AS Protocol. It returns true if the neighboring port is running the protocol according to the requirements in the standard; it returns false otherwise.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the asCapable parameter as described in 14.6.6 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimePortSynced

This property indicates whether the clock using the time synchronization protocol is successfully synchronized to other clocks in the network.

For the Protocol of IEEE Std 802.1AS-2011, this property is true when AS Capable is true and the following conditions apply:

• If Port State is Slave, XNET clock adjustment algorithm (servo) is in its final stage (calibrated). Sufficient messages have been exchanged such that synchronization quality (e.g., Offset From Master) is unlikely to improve significantly, but no fixed metric is applied as a threshold.
• If Port State is Master and best master clock algorithm (BMCA) is enabled, at least two announce intervals have elapsed. Master state means that the XNET port is acting as grandmaster (the source of time in the network), so Synced? would normally be true immediately. When using the BMCA, the XNET port initializes assuming that it is a potential grandmaster (Master), but when it receives an announce message from a better grandmaster, the Port State changes to Slave. By waiting up to two announce intervals, the XNET port avoids reporting a false-positive from Synced? (i.e., true because it was Master upon initialization, then false when a better grandmaster is detected, and then true again after slave calibration).
• If Port State is Master and BMCA is disabled, Synced? is true immediately. As BMCA is disabled, this XNET port will act as the Master (grandmaster) indefinitely.

In the IEEE 1588-2008 standard (on which IEEE Std 802.1AS-2011 is based), this Synced? flag is analogous to transition out of the UNCALIBRATED state. For 802.1AS, behavior similar to this property is specified as the AVB_Sync state of the Avnu Automotive Ethernet AVB Functional and Interoperability Specification.

Note  Time synchronization occurs independently from start of the interface. For example, you can read and write Ethernet frames when time sync is not enabled, or when the time sync protocol is not synced.

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

XNET Session

nxPropSession_IntfEnetTimePortStatsCounterNames

This property returns the name of each Ethernet statistics property supported by XNET. The name uses uppercase for the first letter of each word, with space as a separator between words.

The name at a specific index corresponds to the counter at the same index in Counter Values. The array of strings for this property is the same size as the Counter Values array of strings.

The Counter Names and Counter Values properties are intended to be used together to display all statistics on the front panel. These properties do not require knowledge of specific property names. For example, if a new version of NI-XNET adds a statistic property (to the end of the arrays), the new property will display without change to your application.

Statistics are grouped as receive (rx) and transmit (tx).

When the Port Mode of the session's interface is set to Direct, receive and transmit are relative to that interface.

When the Port Mode is set to Tap, receive statistics refer to this session's interface, and all transmit statistics are zero. If you want to get statistics for frames received by the Tap partner, use a session with the Tap partner's interface.

All statistics reset to zero when the system powers up or the device is reset.

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

XNET Session

nxPropSession_IntfEnetTimePortStatsCounterValues

This property returns the counter value of each Time Sync Port statistics property supported by XNET. Each counter value is returned as a string for display, but the internal counter uses a 64-bit unsigned integer (U64) data type to avoid rollover. The counter resets to zero when the system powers up or the device is reset, and increments according to the description in Counter Names.

The counter value at a specific index corresponds to the name at the same index in Counter Names. The array of strings for this property is the same size as the Counter Names array of strings. Refer to Counter Names for a description of each counter value.

The array of counters are not provided as a single snapshot in time. For example, it is possible that a new frame is received as the values are returned, such that index 3 does not count the new frame, and index 4 does count the new frame.

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

XNET Session

nxPropSession_IntfEnetTimePortStatsRxSync

A count of the number of Sync messages received.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the rxSyncCount parameter as described in 14.7.2 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimePortStatsRxAnnounce

A count of the number of announce messages received.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the rxAnnounceCount parameter as described in 14.7.7 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimePortStatsRxPdelayRequest

A count of the number of Pdelay_Req messages received.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the rxPdelayRequestCount parameter as described in 14.7.4 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimePortStatsTxSync

A count of the number of Sync messages transmitted.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the txSyncCount parameter as described in 14.7.12 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimePortStatsTxAnnounce

A count of the number of announce messages transmitted.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the txAnnounceCount parameter as described in 14.7.17 of IEEE Std 802.1AS-2011.

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

XNET Session

nxPropSession_IntfEnetTimePortStatsTxPdelayRequest

A count of the number of Pdelay_Req messages transmitted.

For the Protocol of IEEE Std 802.1AS-2011, this property corresponds to the txPdelayRequestCount parameter as described in 14.7.14 of IEEE Std 802.1AS-2011.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Calculated from Cluster Settings

XNET Session

nxPropSession_IntfFlexRayAccStartRng

Range of measure clock deviation allowed for startup frames during node integration. This property corresponds to the pdAcceptedStartupRange node parameter in the FlexRay Protocol Specification.

The range for this property is 0–1875 MT.

You can overwrite the default value by writing a value within the specified range to this property prior to starting the FlexRay interface.

Data Type	Direction	Required?	Default
u32	Read/Write	No	0

XNET Session

nxPropSession_IntfLINBreakDelimiterLength

This property determines the length of the delimiter placed between the break and sync in the frame header.

This length is in addition to the length internally added by the hardware serial UART, which is approximately equal to one bit time at a baud rate equal to (9 / break bit length) × bus baud rate.

The value is specified in bit times at the bus baud rate. As shown in the following table, the maximum value varies per the break length value in order to keep the overall break transmit time below the maximum specified for LIN (1.4 × 14 bit times).

Break Bit Length	Break Delimiter Length (Max)
10	8
11	7
12	6
13	5
14	4
15	2
16	1
17 or greater	0

Data Type	Direction	Required?	Default
u32	Read/Write	No	13

XNET Session

nxPropSession_IntfLINBreakLength

This property determines the length of the serial break used at the start of a frame header (schedule entry). The value is specified in bit-times.

The valid range is 10–36 (inclusive). The default value is 13, which is the value the LIN standard specifies.

At baud rates below 9600, the upper limit may be lower than 36 to avoid violating hold times for the bus. For example, at 2400 baud, the valid range is 10–14.

This property is applicable only when the interface is the master.

Data Type	Direction	Required?	Default
Double	Read/Write	No	0.05

XNET Session

nxPropSession_IntfLINDiagP2min

When the interface is the slave, this is the minimum time in seconds between reception of the last frame of the diagnostic request message and transmission of the response for the first frame in the diagnostic response message by the slave.

This property applies only to the interface as slave. An attempt to write the property for interface as master results in error nxErrInvalidPropertyValue being reported.

Data Type	Direction	Required?	Default
Double	Read/Write	No	0

XNET Session

nxPropSession_IntfLINDiagSTmin

When the interface is the slave, this property sets the minimum time in seconds it places between the end of transmission of a frame in a diagnostic response message and the start of transmission of the response for the next frame in the diagnostic response message.

When the interface is the master, this property sets the minimum time in seconds it places between the end of transmission of a frame in a diagnostic request message and the start of transmission of the next frame in the diagnostic request message.

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

XNET Session

nxPropSession_IntfLINMaster

Note  You can set this property only when the interface is stopped. This Boolean property specifies the NI-XNET LIN interface role on the network: master (true) or slave (false).

In a LIN network (cluster), there always is a single ECU in the system called the master. The master transmits a schedule of frame headers. Each frame header is a remote request for a specific frame ID. For each header, typically a single ECU in the network (slave) responds by transmitting the requested ID payload. The master ECU can respond to a specific header as well, and thus the master can transmit payload data for the slave ECUs to receive.

The default value for this property is false (slave). This means that by default, the interface does not transmit frame headers onto the network. When you use input sessions, you read frames that other ECUs transmit. When you use output sessions, the NI-XNET interface waits for the remote master to send a header for a frame in the output sessions, then the interface responds with data for the requested frame.

If you call the nxWriteState function to request execution of a schedule, that implicitly sets this property to true (master). You also can set this property to true using nxSetProperty, but no schedule is active by default, so you still must call the nxWriteState function at some point to request a specific schedule.

Regardless of this property's value, you use can input and output sessions. This property specifies which hardware transmits the scheduled frame headers: NI-XNET (true) or a remote master ECU (false).

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

XNET Session

nxPropSession_IntfLINOStrSlvRspLstByNAD

The Output Stream Slave Response List by NAD property provides a list of NADs for use with the replay feature (Interface:Output Stream Timing property set to Replay Exclusive or Replay Inclusive).

For LIN, the array of frames to replay might contain multiple slave response frames, each with the same slave response identifier, but each having been transmitted by a different slave (per the NAD value in the data payload). This means that processing slave response frames for replay requires two levels of filtering. First, you can include or exclude the slave response frame or ID for replay using Interface:Output Stream List or Interface:Output Stream List By ID. If you do not include the slave response frame or ID for replay, no slave responses are transmitted. If you do include the slave response frame or ID for replay, you can use the Output Stream Slave Response List by NAD property to filter which slave responses (per the NAD values in the array) are transmitted. This property is always inclusive, regardless of the replay mode (inclusive or exclusive). If the NAD is in the list and the response frame or ID has been enabled for replay, any slave response for that NAD is transmitted. If the NAD is not in the list, no slave response for that NAD is transmitted. The property's data type is an array of unsigned 32-bit integer (u32). Currently, only byte 0 is required to hold the NAD value. The remaining bits are reserved for future use.

Data Type	Direction	Required?	Default
u32	Write Only	No	N/A

XNET Session

nxPropSession_IntfLINSleep

Use the Sleep property to change the NI-XNET LIN interface sleep/awake state and optionally to change remote node (ECU) sleep/awake states.

The following table lists the accepted values:

String	Value	Description
nxLINSleep_RemoteSleep	0	Set interface to sleep locally and transmit sleep requests to remote nodes
nxLINSleep_RemoteWake	1	Set interface to awake locally and transmit wakeup requests to remote nodes
nxLINSleep_LocalSleep	2	Set interface to sleep locally and not to interact with the network
nxLINSleep_LocalWake	3	Set interface to awake locally and not to interact with the network
The property is write only. Setting a new value is effectively a request, and the property node returns before the request is complete. To detect the current interface sleep/wake state, use nxReadState.

The LIN interface maintains a state machine to determine the action to perform when this property is set (request). The following sections specify the action when the interface is master and slave.

Request	Current Local State
	Sleep	Awake
nxLINSleep_RemoteSleep	No action	Change local state; pause scheduler; transmit go-to-sleep request frame
nxLINSleep_RemoteWake	Change local state; transmit master wakeup pattern (serial break); resume scheduler	No action
nxLINSleep_LocalSleep	No action	Change local state
nxLINSleep_LocalWake	Change local state; resume scheduler	No action
When the master's scheduler pauses, it finishes the pending entry (slot) and saves its current position. When the master's scheduler resumes, it continues with the schedule where it left off (entry after the pause).

The go-to-sleep request is frame ID 60, payload length 8, payload byte 0 has the value 0, and the remaining bytes have the value 0xFF.

If the master is in the Sleep state, and a remote slave (ECU) transmits the slave wakeup pattern, this is equivalent to setting this property to Local Wake. In addition, a pending nxWait for nxCondition_IntfRemoteWakeup returns. This nxWait does not apply to setting this property, because you know when you set it.

Request	Current Local State
	Sleep	Awake
nxLINSleep_RemoteSleep	Error	Error
nxLINSleep_RemoteWake	Transmit slave wakeup pattern; change local state when first break from master is received	No action
nxLINSleep_LocalSleep	No action	Change local state
nxLINSleep_LocalWake	Change local state	No action
According to the LIN protocol standard, Remote Sleep is not supported for slave mode, so that request returns an error.

If the slave is in Sleep state, and a remote master (ECU) transmits the master wakeup pattern, this is equivalent to setting this property to Local Wake. In addition, a pending nxWait for nxCondition_IntfRemoteWakeup returns. This nxWait does not apply to setting this property, because you know when you set it.

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

XNET Session

nxPropSession_IntfLINAlwStartWoBusPwr

Note  You can modify this property only when the interface is stopped. The Start Allowed Without Bus Power? property configures whether the LIN interface does not check for bus power present at interface start, or checks and reports an error if bus power is missing.

When this property is true, the LIN interface does not check for bus power present at start, so no error is reported if the interface is started without bus power.

When this property is false, the LIN interface checks for bus power present at start, and nxErrMissingBusPower is reported if the interface is started without bus power.

Data Type	Direction	Required?	Default
u32	Read/Write	No	Off (0)

XNET Session

nxPropSession_IntfLINTerm

Notes  You can modify this property only when the interface is stopped.

This property does not take effect until the interface is started. The Termination property configures the NI-XNET interface LIN connector (port) onboard termination. The enumeration is generic and supports two values: Off (disabled) and On (enabled).

The following table lists the accepted values:

String	Value
nxLINTerm_Off	0
nxLINTerm_On	1
Per the LIN 2.1 standard, the Master ECU has a ~1 ktermination resistor between Vbat and Vbus. Therefore, use this property only if you are using your interface as the master and do not already have external termination.

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

XNET Session

nxPropSession_IntfLINNoResponseToInStrm

This property configures the hardware to place a LIN no response frame into the Stream Input queue after it is generated. A no response frame is generated when the hardware detects a header with no response.

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

XNET Session

nxPropSession_IntfLINChecksumToInStrm

This property configures the hardware to place the received checksum for each LIN Data frame into the Event ID (Info) field. When false, the Event ID field contains 0 for all LIN Data stream input frames.

Data Type	Direction	Required?	Default
string	Read/Write	No	(Disconnected)

XNET Session

nxPropSession_IntfSrcTermStartTrigger

This property specifies the name of the internal terminal to use as the interface Start Trigger. The data type is NI Terminal (DAQmx terminal), represented as a string.

This property is supported for C Series modules in a CompactDAQ chassis, cRIO-904x, cRIO-905x, and sbRIO-9603/96x8/96x9. It is not supported for CompactRIO, PXI, or PCI (refer to nxConnectTerminals for those platforms).

The digital trigger signal at this terminal is for the Start Interface transition, to begin communication for all sessions that use the interface. This property routes the start trigger, but not the timebase (used for timestamp of received frames and cyclic transmit of frames). Routing the timebase is not required for CompactDAQ, because all modules in the chassis automatically use a shared timebase.

Use this property to connect the interface Start Trigger to triggers in other modules and/or interfaces. When you read this property, you specify the interface Start Trigger as the source of a connection. When you write this property, you specify the interface Start Trigger as the destination of a connection, and the value you write represents the source. For examples that demonstrate use of this property to synchronize NI-XNET and NI-DAQmx hardware, refer to the Synchronization category within the NI-XNET examples.

The connection this property creates is disconnected when you clear (close) all sessions that use the interface.

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

XNET Session

nxPropSession_IntfEnetStatsCounterNames

This property returns the name of each Ethernet statistics property supported by XNET. The name uses uppercase for the first letter of each word, with space as a separator between words.

The name at a specific index corresponds to the counter at the same index in Counter Values. The array of strings for this property is the same size as the Counter Values array of strings.

The Counter Names and Counter Values properties are intended to be used together to display all statistics on the front panel. These properties do not require knowledge of specific property names. For example, if a new version of NI-XNET adds a statistic property (to the end of the arrays), the new property will display without change to your application.

Statistics are grouped as receive (rx) and transmit (tx).

When the Port Mode of the session's interface is set to Direct, receive and transmit are relative to that interface.

When the Port Mode is set to Tap, receive statistics refer to this session's interface, and all transmit statistics are zero. If you want to get statistics for frames received by the Tap partner, use a session with the Tap partner's interface.

All statistics reset to zero when the system powers up or the device is reset.

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

XNET Session

nxPropSession_IntfEnetStatsCounterValues

This property returns the counter value of each Ethernet statistics property supported by XNET. Each counter value is returned as a string for display, but the internal counter uses a 64-bit unsigned integer (U64) data type to avoid rollover. The counter resets to zero when the system powers up or the device is reset, and increments according to the description in Ethernet Statistics MAC Properties.

The counter value at a specific index corresponds to the name at the same index in Counter Names. The array of strings for this property is the same size as the Counter Names array of strings. Refer to Ethernet Statistics MAC Properties for a description of each counter value.

The array of counters are not provided as a single snapshot in time. For example, it is possible that a new frame is received as the values are returned, such that index 3 does not count the new frame, and index 4 does count the new frame.

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

XNET Session

nxPropSession_IntfEnetStatsRxBytes

This is a count of the number of bytes (octets) received. The count for each frame is its frame length. Bad frames are counted in addition to good frames. Reading this counter twice can be used to obtain an estimate of received bandwidth over the time between the two reads.

This statistic is analogous to the etherStatsOctets parameter as described in RFC 2819.

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

XNET Session

nxPropSession_IntfEnetStatsRxGoodFrames

This is a count of error-free frames received. This count is equal to (Rx Good Unicast + Rx Good Multicast + Rx Good Broadcast).

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

XNET Session

nxPropSession_IntfEnetStatsRxBadFrames

This is a count of frames received with an error detected by the Ethernet MAC and/or PHY. This statistic is analogous to the ifInErrors parameter as described in RFC 2863.

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

XNET Session

nxPropSession_IntfEnetStatsTxBytes

This is a count of the number of bytes (octets) transmitted. The count for each frame is its frame length. Reading this counter twice can be used to obtain an estimate of transmitted bandwidth over the time between the two reads.

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

XNET Session

nxPropSession_IntfEnetStatsTxGoodFrames

This is a count of error-free frames transmitted. This count is equal to (Tx Good Unicast + Tx Good Multicast + Tx Good Broadcast).

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

XNET Session

nxPropSession_IntfEnetTimePortSyncStatus

This property provides the current synchronization status of the time synchronization protocol. This property uses an enumerated list with the following values:

Enumeration	Value	Description
nxEnetTimePortSyncStatus_Synced	0	The clock using the time synchronization protocol is successfully synchronized with other clocks in the network.
nxEnetTimePortSyncStatus_EnetLinkDown	1	The interface cannot transmit or receive frames (packets).
nxEnetTimePortSyncStatus_ProtocolDisabled	2	Time synchronization protocol is disabled.
nxEnetTimePortSyncStatus_MeasuringPropDelay	3	The port is exchanging messages to measure Propagation Delay, but the port is not sending time (master) or receiving time (slave).
nxEnetTimePortSyncStatus_MasterPendingAnnounce	4	The Port State is master with the BMCA enabled and is waiting until at least two Announce Intervals have elapsed before declaring the port synchronized. This avoids reporting a false-positive when the best master clock algorithm (BMCA) has not finished electing the best master.
nxEnetTimePortSyncStatus_WaitingForMaster	5	The Port State is slave and a sync message has not been received from the master.
nxEnetTimePortSyncStatus_SyncingToMaster	6	The Port State is slave and the XNET clock adjustment algorithm (servo) has not reached its final state (calibrated). A sufficient number of messages need to be exchanged so that synchronization quality (e.g., Offset From Master) is unlikely to improve significantly, but no fixed metric is applied as a threshold.
nxEnetTimePortSyncStatus_PeerNotProtoCapable	7	The time synchronization protocol is not detecting a neighbor that is running the protocol according to the requirements in the standard.
nxEnetTimePortSyncStatus_PropDelayExceedsTreshold	8	For IEEE Std 802.1AS, the measured propagation delay exceeds the value specified by the property Propagation Delay Threshold. As a result, the time synchronization protocol sets the AS Capable?property to false.
nxEnetTimePortSyncStatus_SyncReceiptTimeout	9	The Port State is slave and the time synchronization protocol has not received a sync message from the Master in at least the number of sync intervals specified by the Sync Receipt Timeout property.
nxEnetTimePortSyncStatus_FrequencyOutOfRange	10	The Port State is slave and the grandmaster clock has exceeded the frequency range of the XNET clock (±100 ppm).
nxEnetTimePortSyncStatus_SyncIntervalOutOfRange	11	The Port State is slave and the master is sending sync messages outside of the supported sync interval range.
nxEnetTimePortSyncStatus_MultipleMastersDetected	12	The Port State is configured as master with the BMCA disabled and another master has been detected by the time synchronization protocol.

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

XNET Session

nxPropSession_IntfLINSchedNames

This property returns a comma-separated list of schedules for use when the NI-XNET LIN interface acts as a master (Interface:LIN:Master? is true). When the interface is master, you can pass the index of one of these schedules to the nxWriteStatefunction to request a schedule change.

When the interface does not act as a master, you cannot control the schedule, and the nxWriteState function returns an error if it cannot set the interface into master mode (for example, if the interface already is started).

This list of schedules is the same list the XNET Cluster LIN:Schedules property used to configure the session.