Interfaces associated with a physical hardware device.
Blinks LEDs for the XNET interface to identify its physical port in the system.
Each XNET device contains one or two physical ports. Each port is labeled on the hardware as Port 1 or Port 2. The XNET device also provides two LEDs per port. For a two-port board, LEDs 1 and 2 are assigned to Port 1, and LEDs 3 and 4 are assigned to physical Port 2.
When your application uses multiple XNET devices, this function helps to identify each interface to associate its software behavior to its hardware connection (port). Prior to running your XNET sessions, you can call this function to blink the interface LEDs.
For example, if you have a system with three PCI CAN cards, each with two ports, you can use this function to blink the LEDs for interface CAN4, to identify it among the six CAN ports.
- The LEDs of each port support two states:
- Blink LEDs to identify the physical port assigned to the interface.
- In Use:
- LED behavior that XNET sessions control.
Identification LED State
You can use the
blinkfunction only in the Identification state. If you call this function while one or more XNET sessions for the interface are open (created), it returns an error, because the port’s LEDs are in the In Use state.
In Use LED State
When you create an XNET session for the interface, the LEDs for that physical port transition to the In Use state. If you called the
blinkfunction previously to enable blinking for identification, that LED behavior no longer applies. The In Use LED state remains until all XNET sessions are cleared. This typically occurs when the application terminates. The patterns that appear on the LEDs while In Use are documented in LEDs.
Parameters: moodifier (
Controls LED blinking
Both LEDs blink green (not red). The blinking rate is approximately three times per second.
Indicates whether the XNET interface can terminate the CAN bus.
Signal reflections on the CAN bus can cause communication failure. To prevent reflections, termination can be present as external resistance or resistance the XNET board applies internally. This property determines whether the XNET board can add termination to the bus.
The oldest driver version compatible with the connected Transceiver Cable’s firmware.
The number is relative to the first driver version that supported the Transceiver Cable, starting with 1 for the original revision.
- ..note:: A Transceiver Cable running an updated firmware version may
- require a later XNET driver than the version it shipped with for operation.
The oldest driver version compatible with the connected Transceiver Cable’s hardware revision.
The number is relative to the first driver version that supported the particular Transceiver Cable model, starting with 1 for the original revision.
A Transceiver Cable hardware revision might require a later XNET driver than the version that introduced support for this model for operation.
The connected Transceiver Cable’s firmware revision number.
Indicates the connected Transceiver Cable’s type.
Dongle-Less Design indicates this interface is not a Transceiver Cable but a regular XNET expansion card, cDAQ Module, and so on.
The connected Transceiver Cable’s hardware revision number.
Indicates the connected Transceiver Cable’s state.
Some Transceiver Cable types require external power from the network connector for operation. Refer to the hardware-specific manual for more information.
The unique number associated with the XNET interface.
The XNET driver assigns each port connector in the system a unique number XNET driver. This number, plus its protocol name, is the interface name.
Physical port number printed near the connector on the XNET device.
The port numbers on an XNET board are physically identified with numbering. Use this property, along with the XNET Device Serial Number property, to associate an XNET interface with a physical (XNET board and port) combination.