Danlaw MxVDev integrates with LabVIEW utilizing the MxNet networking infrastructure, which consists of a high-speed data streaming and queuing mechanism. A set of custom LabVIEW VIs with an API implements the MxNet protocol over UDP/IP and provides I/O device and channel enumeration and data transition scheduling for LabVIEW. A complementary signal transform (inserted into the MxTransIt transform graph) enumerates and provides access to the LabVIEW I/O from MxVDev. Data transitions are then received by, queued, and executed on the LabVIEW system via the MxNet dispatcher (protocol machine).
MxNet employs a reliable positive-acknowledgment UDP-based protocol designed for use on a high-bandwidth LAN. For production use, it is recommended that a dedicated and isolated physical network connection be used to connect the system running MxVDev with the system running the LabVIEW VIs, because it is ideal to promoting real-time behavior and avoiding performance degradation from a corporate network.
The MxNet protocol works by time-shifting the time-stamps of data transitions into the future so that they are queued up for execution by the LabVIEW environment relative to the LabVIEW clock. This transformation of time provides a real-time buffer between the PC clock and the LabVIEW system clock, and enacts “glitchless” execution of the test-case waveforms, thus overcoming the inherit lack of real-time capabilities of Windows.
The VIs are organized into two sets:
•A set of low-level API calls that can be used to integrate with a highly customized LabVIEW testing solution.
•A set of high-level, turn-key, example VIs that create a functional hardware-in-the-loop tester with minimal configuration and modifications. For example, if CAN hardware is present, the CAN configuration must be updated.
These sets of VIs implement back end HIL tester functionality that MxTransIt connector transforms for LabVIEW communicate with (via the MxNet protocol). They expose the available hardware device and I/O channels to MxVDev.
To achieve real-time performance, LabVIEW Real-Time is required, but LabVIEW on Windows is also supported. You can run both MxVDev and LabVIEW simultaneously on one computer, or share the load with MxVDev on one computer, and LabVIEW on another. You can use the same VIs as for the Real-Time system. When you connect to them, instead of a remote IP address, use the IP address of your local machine or 'localhost'. Some things could be removed, for example you might not need Tasks that Send or Receive CAN messages.
If you get this error: "Time structures aren’t allowed in time critical VIs" for a VI, go to ‘VI properties’ and change ‘Execution Properties’ priority to ‘normal priority’.
See Example.vi for a top-level of an MxNet on LabVIEW.
“Enumeration” is the process of identifying available hardware I/O and associating cards and ports of each type with unique identifiers. This occurs when the VI initializes before any other action is taken. The process of enumeration is:
•MxNet is initialized.
•A set of VIs determines the available devices and channels and feeds this information to the MxNet data stores.
•The “active channels” are selected from the list of total available I/O.
•The active channels and corresponding hardware are opened and passed forward into the main loop.
The main-body consists of four threads:
•The UDP traffic thread
•The CAN traffic thread
•An I/O thread
•A utility thread to handle the Stop button
The UDP packet sending and receiving mechanism is divided into separate I/O threads to prevent being “stuck” if the VIs are pending an operation. This ensures that performance is maintained for the main VI and that any hiccups that occur during IP packet processing do not affect the real-time analog and digital I/O.
Similar to UDP packet processing threads, the CAN message transmission and reception is divided into separate LabVIEW tasks for performance reasons. Some of the CAN VIs are blocking calls that have been known to degrade performance of the overall system when they are inline with the I/O logic. This setup will cause a few millisecond delay in CAN messages transmission and processing of incoming messages, but experiments show that this provides the highest quality of service that the existing NI-CAN sub-system is capable of providing.
The I/O thread is the most time-critical part of the system. This thread processes the MxNet packets to queue CAN messages, queue UDP packets, and process the MxNet transition queue to change the state of the digital and analog I/O pins.
The stop button has its own thread solely for "plumbing" reasons so that it is responsive while the other threads are executing.
The LabVIEW connector transform provides the bridge between the MxVDev Transform infrastructure and the LabVIEW or LabVIEW RT MxNet HIL system. The LabVIEW connector transform is a web that houses additional LabVIEW transforms to communicate with specific I/O sub-systems. The supported sub-systems at this time are MIO, CAN, CAN Transport, and CCP.
In MxTransIt, select the NI LabVIEW/LabVIEW-RT Transform from the Toolbox.
The LabVIEW connector connects to either a Windows-based LabVIEW system or a Pharlap-based LabVIEW Real-time system.
Debug Logging - Normally this property should set to None unless a requested by a developer.
The MxNet VIs are designed and tested to execute on the LabVIEW Real-Time platform. For supported versions, see Compatibility.
A nominal cycle time of 1ms is achievable with a 2GHz dual-core system.
Data Transfer Rate Performance
100 transitions per millisecond (50 Stimulus and 50 response transitions) are reliably transmitted between the PC running MxSuite and a PXI chassis running the LabVIEW Real-Time OS. In testing, we observed:
•PC: Win7, Intel Xeon CPU W3530 (4 cores) @ 2.80 GHz, 6 GB RAM. CPU utilization averaged at about 25%
•LabVIEW Real-Time: LV2011RT, PXI-8108 CORE 2 DUO 2.53 GHz, 2 GB RAM, both cores were 20% busy on average
•Data transmission was via UDP over Ethernet operating at one Gigabit transmission rate. The physical connection was a dedicated Ethernet cable between the two computers.
•MxNet force sends packets at least every 100ms. Even if there is no data to be sent, ‘Keep Alive’ and ‘Acknowledgment’ packets are sent.
•1476 bytes in the UDP packet are available to MxNet to use. When it fills up before the timer expires, we force send it and fill up the next packet.
•Some packet sizes based on transition type:
oAnalog/Digital I/O: 40 bytes
oCAN message: 48 bytes
oCCP: 60 bytes
oXCP: 68 bytes
When installing a new version of the MxSuite, the matching DLL must be used with LabVIEW Real-Time. The installation wizard copies the DLL into the MxSuite install directory, for example:
C:\Program Files (x86)\MicroMax\MxSuite 188.8.131.5214\Harness\MxNet\LabViewRT\MxNetLabviewRT.dll
Copy this DLL into the directory with your LabVIEW VIs to be deployed on the Real-Time system.
To prevent LabVIEW from reusing an old DLL, use this procedure when deploying a LabVIEW project as a start-up application:
1.Browse to /ni-rt/startup/data/ on the LabVIEW RT system.
You can do this using FTP or LabVIEW Real-Time browser utilities.
The sample VIs provided by Danlaw are designed to work with CAN-card-supporting NI-CAN drivers. To use new NI-XNET cards with the same code, please install: