Skip to content

NI XNET XNET Session Interface Properties

Jump to bottom
PALASH KHARE edited this page Mar 7, 2022 · 5 revisions

XNET Session Interface Properties

Interface:64bit Baud Rate

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

Property Class

XNET Session

Property ID

nxPropSession_IntfBaudRate64

Description

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.

CAN

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.

Formulas

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)

LIN

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.

Interface:Adjust Local Time

Data Type Direction Required? Default
u64 Write Only No 0

Property Class

XNET Session

Property ID

nxPropSession_IntfAdjustLocalTime

Description

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.

Interface:Bus Error Frames to Input Stream?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfBusErrToInStrm

Description

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.

Interface:Echo Transmit?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEchoTx

Description

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.

Interface:I/O Name

Data Type Direction Required? Default
string Read Only — —

Property Class

XNET Session

Property ID

nxPropSession_IntfIoName

Description

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.

Interface:Output Stream List

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

Property Class

XNET Session

Property ID

nxPropSession_IntfOutStrmList

Description

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.

Interface:Output Stream List By ID

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

Property Class

XNET Session

Property ID

nxPropSession_IntfOutStrmListById

Description

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

Interface:Output Stream Timing

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

Property Class

XNET Session

Property ID

nxPropSession_IntfOutStrmTimng

Description

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

Runtime Behavior

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.

Loss of Network Synchronization (Ethernet Only)

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.

Special Considerations for LIN

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.

Restrictions on Other Sessions

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.

Interface:Start Trigger Frames to Input Stream?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfStartTrigToInStrm

Description

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.

Interface:CAN:External Transceiver Config

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

Property Class

XNET Session

Short Name

nxPropSession_IntfCANExtTcvrConfig

Description

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

Examples

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.

Interface:CAN:I/O Mode

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCanIoMode

Description

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.

Interface:CAN:Listen Only?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCANLstnOnly

Description

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.

Interface:CAN:Pending Transmit Order

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCANPendTxOrder

Description

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.

Interface:CAN:Single Shot Transmit?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCANSingShot

Description

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.

Interface:CAN:Termination

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCANTerm

Description

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

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.

Low-Speed/Fault-Tolerant CAN

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

Single-Wire CAN

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

Interface:CAN:Transceiver State

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCANTcvrState

Description

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

Normal

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.

Sleep

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.

Single Wire Wakeup

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.

Single Wire High-Speed

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.

Interface:CAN:Transceiver Type

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCANTcvrType

Description

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:

High-Speed

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.

Low-Speed/Fault-Tolerant

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

Single Wire

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

External

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.

Disconnect

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.

Interface:CAN:Transmit I/O Mode

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCanTxIoMode

Description

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.

Interface:CAN:FD ISO Mode

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCanFdIsoMode

Description

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.

Interface:CAN:Enable Edge Filter

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCanEdgeFilter

Description

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

Interface:CAN:Transmit Pause

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCanTransmitPause

Description

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.

Interface:CAN:Disable Protocol Exception Handling

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

Property Class

XNET Session

Property ID

nxPropSession_IntfCanDisableProtExceptionHandling

Description

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.

Interface:Ethernet:IPv4 Address

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetIpV4Address

Description

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.

Interface:Ethernet:Link Speed

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetLinkSpeed

Description

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.

Interface:Ethernet:Link Speed Configured

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetLinkSpeedConf

Description

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.

Interface:Ethernet:Jumbo Frames

Data Type Direction Required? Default
u32 Read Only No Disabled

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetJumboFrames

Description

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.

Interface:Ethernet:MAC Address

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetMacAddress

Description

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.

Interface:Ethernet:Operational Status

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetOperationalStatus

Description

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.

Interface state

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

Read behavior

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.

Write behavior

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.

Interface:Ethernet:OS Network Adapter Name

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetOsNetworkAdapterName

Description

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.

Interface:Ethernet:OS Network Adapter Description

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetOsNetworkAdapterDescription

Description

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.

Interface:Ethernet:Output Stream Timescale

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetOutStrmTimescale

Description

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.

Interface:Ethernet:PHY Power Mode

Data Type Direction Required? Default
u32 Read Only No Normal

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetPhyPowerMode

Description

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.

Interface:Ethernet:PHY State

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetPhyState

Description

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.

Interface:Ethernet:Port Mode

Data Type Direction Required? Default
u32 Read Only Yes Direct

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetPortMode

Description

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.

Interface:Ethernet:Signal Quality

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetSignalQuality

Description

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.

Interface:Ethernet:Sleep Capability

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetSleepCapability

Description

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.

Interface:Ethernet:Trigger PPS Synced?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTriggerPpsSynced

Description

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.

Interface:Ethernet:Statistics:PHY:Counter Values

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetStatsPhyCounterValues

Description

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.

Interface:Ethernet:Statistics:PHY:Wake Up Pulse Count

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetStatsPhyWakeupPulse

Description

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.

Interface:Ethernet:Statistics:PHY:Wake Up Request Count

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetStatsPhyWakeupRequest

Description

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.

Interface:Ethernet:Statistics:PHY:Low Power Sleep Count

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetStatsPhyLowPowerSleep

Description

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.

Interface:Ethernet:Statistics:PHY:Wake Up Failure Count

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetStatsPhyWakeupFailure

Description

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

Interface:Ethernet:Statistics:PHY:Sleep Failure Count

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

Property Class

XNET Interface

Property ID

nxPropSession_IntfEnetStatsPhySleepFailure

Description

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

Interface:Ethernet:Endpoint:Receive Filter

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetEptReceiveFilter

Description

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.

Interface:Ethernet:Endpoint:Transmit Bandwidth

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetEptTransmitBandwidth

Description

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.

Interface:Ethernet:Time Sync:Protocol

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeProtocol

Description

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.

Interface:Ethernet:Time Sync:Protocol Enabled?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeProtocolEnabled

Description

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.

Interface:Ethernet:Time Sync:BMCA Enabled?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeBMCAEnabled

Description

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.

Interface:Ethernet:Time Sync:Offset From Master

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeOffsetFromMaster

Description

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.

Interface:Ethernet:Time Sync:Clock ID

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeClkID

Description

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.

Interface:Ethernet:Time Sync:Clock Class

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeClkClass

Description

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.

Interface:Ethernet:Time Sync:Clock Accuracy

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeClkAccuracy

Description

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.

Interface:Ethernet:Time Sync:Clock Offset Scaled Log Variance

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeClkOffsetVar

Description

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.

Interface:Ethernet:Time Sync:Priority1

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePriority1

Description

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.

Interface:Ethernet:Time Sync:Priority2

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePriority2.html

Description

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.

Interface:Ethernet:Time Sync:Steps to Grandmaster

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeStepsToGM

Description

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.

Interface:Ethernet:Time Sync:Grandmaster Clock ID

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeGMClkID

Description

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.

Interface:Ethernet:Time Sync:Grandmaster Clock Class

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeGMClkClass

Description

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.

Interface:Ethernet:Time Sync:Grandmaster Clock Accuracy

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeGMClkAccuracy

Description

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.

Interface:Ethernet:Time Sync:Grandmaster Clock Offset Scaled Log Variance

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeGMClkOffsetVar

Description

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.

Interface:Ethernet:Time Sync:Grandmaster Priority1

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeGMPriority1

Description

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.

Interface:Ethernet:Time Sync:Grandmaster Priority2

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeGMPriority2

Description

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.

Interface:Ethernet:Time Sync:Adjust Network Time

Data Type Direction Required? Default
u64 Write Only No 0

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimeAdjustNetworkTime

Description

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.

Interface:Ethernet:Time Sync:Port:Port State Configured

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStateConfigured

Description

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.

Interface:Ethernet:Time Sync:Port:Port State

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortState

Description

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.

Interface:Ethernet:Time Sync:Port:Propagation Delay

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortPropDelay

Description

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.

Interface:Ethernet:Time Sync:Port:Propagation Delay Configured

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortPropDelayConfigured

Description

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

Interface:Ethernet:Time Sync:Port:Propagation Delay Threshold

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortPropDelayThreshold

Description

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.

Interface:Ethernet:Time Sync:Port:Pdelay Enabled?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortPdelayEnabled

Description

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.

Interface:Ethernet:Time Sync:Port:Log Pdelay_Req Interval Configured

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortLogPdelayIntervalConfigured

Description

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.

Interface:Ethernet:Time Sync:Port:Log Pdelay_Req Interval

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortLogPdelayInterval

Description

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

Interface:Ethernet:Time Sync:Port:Log Sync Interval Configured

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortLogSyncIntervalConfigured

Description

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.

Interface:Ethernet:Time Sync:Port:Log Sync Interval

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortLogSyncInterval

Description

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

Interface:Ethernet:Time Sync:Port:Sync Receipt Timeout

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortSyncReceiptTimeout

Description

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.

Interface:Ethernet:Time Sync:Port:Log Announce Interval Configured

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortLogAnnounceIntervalConfigured

Description

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.

Interface:Ethernet:Time Sync:Port:Log Announce Interval

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortLogAnnounceInterval

Description

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

Interface:Ethernet:Time Sync:Port:Announce Transmit Enabled?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortAnnounceTransmitEnabled

Description

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.

Interface:Ethernet:Time Sync:Port:Announce Receipt Timeout

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortAnnounceReceiptTimeout

Description

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.

Interface:Ethernet:Time Sync:Port:AS Capable?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortASCapable

Description

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.

Interface:Ethernet:Time Sync:Port:Synced?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortSynced

Description

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.

Interface:Ethernet:Time Sync:Port:Statistics:Counter Names

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStatsCounterNames

Description

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.

Interface:Ethernet:Time Sync:Port:Statistics:Counter Values

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStatsCounterValues

Description

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.

Interface:Ethernet:Time Sync:Port:Statistics:Rx Sync Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStatsRxSync

Description

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.

Interface:Ethernet:Time Sync:Port:Statistics:Rx Announce Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStatsRxAnnounce

Description

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.

Interface:Ethernet:Time Sync:Port:Statistics:Rx Pdelay Request Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStatsRxPdelayRequest

Description

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.

Interface:Ethernet:Time Sync:Port:Statistics:Tx Sync Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStatsTxSync

Description

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.

Interface:Ethernet:Time Sync:Port:Statistics:Tx Announce Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStatsTxAnnounce

Description

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.

Interface:Ethernet:Time Sync:Port:Statistics:Tx Pdelay Request Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortStatsTxPdelayRequest

Description

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.

Interface:FlexRay:Accepted Startup Range

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

Property Class

XNET Session

Property ID

nxPropSession_IntfFlexRayAccStartRng

Description

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.

Interface:LIN:Break Delimiter Length

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINBreakDelimiterLength

Description

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

Interface:LIN:Break Length

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINBreakLength

Description

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.

Interface:LIN:DiagP2min

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINDiagP2min

Description

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.

Interface:LIN:DiagSTmin

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINDiagSTmin

Description

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.

Interface:LIN:Master?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINMaster

Description

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

Interface:LIN:Output Stream Slave Response List By NAD

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINOStrSlvRspLstByNAD

Description

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.

Interface:LIN:Sleep

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINSleep

Description

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.

Sleep/Wake Action for Master

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.

Sleep/Wake Action for Slave

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.

Interface:LIN:Start Allowed without Bus Power?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINAlwStartWoBusPwr

Description

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.

Interface:LIN:Termination

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINTerm

Description

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.

Interface:LIN:No Response Frames to Input Stream?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINNoResponseToInStrm

Description

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.

Interface:LIN:Checksum to Input Stream?

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINChecksumToInStrm

Description

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.

Interface:Source Terminal:Start Trigger

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

Property Class

XNET Session

Property ID

nxPropSession_IntfSrcTermStartTrigger

Description

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.

Interface:Ethernet:Statistics:Counter Names

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetStatsCounterNames

Description

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.

Interface:Ethernet:Statistics:Counter Values

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetStatsCounterValues

Description

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.

Interface:Ethernet:Statistics:Rx Bytes Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetStatsRxBytes

Description

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.

Interface:Ethernet:Statistics:Rx Good Frames Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetStatsRxGoodFrames

Description

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

Interface:Ethernet:Statistics:Rx Bad Frames Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetStatsRxBadFrames

Description

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.

Interface:Ethernet:Statistics:Tx Bytes Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetStatsTxBytes

Description

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.

Interface:Ethernet:Statistics:Tx Good Frames Count

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetStatsTxGoodFrames

Description

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

Interface:Ethernet:Time Sync:Port:Sync Stat

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

Property Class

XNET Session

Property ID

nxPropSession_IntfEnetTimePortSyncStatus

Description

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.

Interface:LIN:Schedule Names

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

Property Class

XNET Session

Property ID

nxPropSession_IntfLINSchedNames

Description

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.

Table of Contents

Home

Internal Development

Creating and Setting Up a gRPC Server

Server Security Support

Creating a gRPC Client

gRPC Client Examples

Session Utilities API Reference

Driver Documentation

gRPC API Differences From C API

Sharing Driver Sessions Between Clients

C API Docs
NI-DAQmx
NI-DCPOWER
NI-DIGITAL PATTERN DRIVER
NI-DMM
NI-FGEN
NI-FPGA
NI-RFmx Bluetooth
NI-RFmx NR
NI-RFmx WCDMA
NI-RFmx GSM
NI-RFmx CDMA2k
NI-RFmx Instr
NI-RFmx LTE
NI-RFmx SpecAn
NI-RFmx TD-SCDMA
NI-RFmx WLAN
NI-RFSA
NI-RFSG
NI-SCOPE
NI-SWITCH
NI-TCLK
NI-XNET
Clone this wiki locally