LabVIEW RT VIs

MxNet functionality on LabVIEW RT is provided by a DLL (MxNetLabviewRT.dll) with the API to integrate with LabVIEW VIs. 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.

Example.vi Block Diagram.  Click to expand.

The main components of test system implementation are shown in Example.vi:

•Initialization

•Device enumeration

•Open and configure hardware

•Test Execution threads

•Closure of devices and hardware

During initialization, MxInit.vi is executed.  It calls the Init() function in MxNetLabviewRT.dll to initialize MxNet, internal structures, and queues for the test.

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.

Enumeration is done by calling MxEnumerateIO.vi.

Click to expand.

First, digital and analog hardware lines are enumerated. The ‘DAQmx System’ property node returns an array with DeviceNames that correspond to all MIO hardware cards present in the system.

For each found device, the ‘DAQmx Device’ property node returns additional device information such as type, serial number, and number of inputs and outputs for digital and analog lines. This information is fed as inputs to AddMIO.vi, MxEnumDigitalLines.vi, and  MxEnumAnalogChannels.vi

AddMIO.vi is called with the Device/Driver class set to ‘Digital’. This adds and identifies a new device to MxNet Enumeration. A deviceId is returned which identifies this device internally. MxEnumDigitalLines.vi is called twice, once for input and once for output. This specifies how many digital inputs and outputs the current device contains.

AddMIO.vi is called again with the Device/Driver class set to ‘Analog’ and the same as above is done with analog input and output lines (each call to AddMIO.vi creates a new transform in the MxTransIt graph).

Next, CAN devices are enumerated. A set of LabVIEW CAN VIs identify available hardware and type. This information is used as an input to MxEnumAddCan.vi

Each available CAN port/channel has a corresponding transform in the MxTransIt graph.

Next, CCP devices are enumerated. A for-loop executes N times depending on the size of the configuration array and calls MxAddCCP.vi

CAN Transport Protocol devices are done in a similar way.

Custom_Enum_FPGA_Channels.vi is used to enumerate a custom or user-defined device, which means source and destination signals do not belong to the standard digital/analog I/O, CAN, etc.

Enumeration is done by calling MxAddCustom.vi to add the device and then by calling MxEnumAddAnalog.vi for every input and output with a unique name and ‘channel number’.

The name is used to identify the channel inside Mx VDev test case environments. deviceId and channel-ID are used to identify data when it is transferred between test environments.

The example screen shot below shows how a custom device is set up with 5 inputs and 5 outputs:

Click to expand.

MxEnumAddAnalog.vi creates analog channel with the default min and max values of -10.0 and 10.0. In order to create a custom channel with a custom signal info min/max range, create a new vi similar to MxEnumAddAnalog, but instead of calling the MxLV_EnumAddAnalog() function, call MxLV_EnumAddContinuous(mxU32 deviceId, char* name, mxU16 direction, mxF64 min, mxF64 max, mxF64 init), which has the parameters for setting a custom min and max signal range. (Release  3.36.12.25759 or later is required.)

After enumeration, the system needs to know how digital I/O is being used. Some digital cards allow digital lines to be configured as either input or output.

Activate Channels.vi needs to be called for every digital device added to the system.

DeviceID specifies the digital card (this id is returned from calling AddMIO.vi ). An array of Boolean values identifies how the digital lines are used. Setting a value to True marks the channel as Input, and False corresponds to Output. The index of the array specifies the digital channel.

When I/O is enumerated, MxOpenHardware.vi is called to set up the LabVIEW tasks and execute an open command on required hardware channels.

MxGetTasksStrings.vi returns a separate string identifying all tasks for Analog Input, Analog Output, Digital Input, Digital Output, CAN channels and custom/user channels. These strings are the names of physical channels used by LabVIEW. For Analog Input, Analog Output, Digital Input, and Digital Output the string uses commas to split each task, and a vertical bar character (“|”) to split devices. For example, a Digital Input string may look like this: “Dev1/port0/line0, Dev1/port0/line1 |  Dev2/port0/line0”.

Click to expand.

Each string is then processed by the appropriate VI:

MxConfigureAnalogInputs.vi

MxConfigureAnalogOutputs.vi

MxConfigureDigitalInputs.vi

MxConfigureDigitalOutputs.vi

MxConfigureCAN.vi

CAN Transport protocol is configured from the configuration set on the top level VI, by calling MxCanTpConfig.vi

The Task String for a Custom/FPGA device  contains only the number of inputs and outputs separated by a comma, and can be used to initialize a custom device by calling its interface VI at this point.

After the hardware is opened successfully, if the process did not encounter any errors along the way, the main threads are launched. The main-body consists of four threads:

•UDP traffic thread

•CAN traffic thread

•I/O thread

•Utility thread to handle the Stop button.

The MxUDP.vi code relies on a set of functions provided by LabVIEW to handle UDP protocol communication. This VI sets up the UDP communication layer.

Port is the local port which UDP socket is created on. It should match the port number used on the MxVDev side.  

MxUdpOpen.vi is called after a connection was opened, and two separate tasks for UDP Transmit and Receive are launched. MxUdpWrite.vi accesses MxNetLabviewRT.dll and checks if there is any data to be transmitted over UDP. MxUdpRead.vi is called if any data is received on the current UDP socket and transfers the data to the DLL.

UDP receive and transmit threads run continuously inside a LabVIEW while-loop until the Stop button is pressed on utility thread.

MxCanTask.vi launches the threads (MxCanTaskRx.vi, and MxCanTaskTx.vi) to receive and send CAN Messages.

Object Handles for CAN LabVIEW VIs are created during the Hardware Initialization step. Actual CAN message data is passed to and from I/O threads using the LabVIEW RT FIFO queue.

Once the Test is started as indicated by a global flag going to true, Start Action is executed on all open CAN handles, which starts communication on CAN channels and resets the time stamp used by LabVIEW CAN driver.

MxNetTask.vi is the main body of test system. Inside a 1ms timed loop, calls are made into MxNetLabviewRT.dll to exchange data between the system under test and MxVDev via MxNet.  

Click to expand.

•MxConnected.vi checks the status of the connection from remote side.

•MxTestStarted.vi checks the status and signals when the test has begun. At this point the clock is reset.

•MxTickRx.vi and MxTickTx.vi make calls inside DLL to execute Mx Net tasks to receive and transmit data.

•MxReadIO.vi reads the data from all open sources and passes the data inside DLL, which sends it over MxNet to MxVDev. Digital and analog data is read from open hardware channels, CAN data is read from RT FIFO queues which are managed by CAN threads, FPGA/Custom device data is read from a custom interface (in this case FPGA_Interface.vi).

•MxProcessCommands.vi calls DLL to get the next command to execute for the current time. Digital and analog data is written to an array that will be used in MxWriteIO.vi. CAN data is transmitted to RT FIFO to CAN thread, FPGA/Custom device data is written to custom interface (FPGA_Interface.vi).

•MxWriteIO.vi writes the digital and analog channel data to hardware.

This timed loop stops if LabVIEW errors occur during the execution or if the user presses the Stop button.

Utility thread provides the way for the user to stop all threads running on the system.

For debugging purposes, Start Log and Stop Log buttons have been added. When Start Log is pressed, an execution trace of all external DLL functions is performed, if Stop/Write to file is not pressed within few seconds, MxDebugLog.txt is created when the internal buffer fills up. Since there are many functions that are called every 1 ms, the log file fills up to few megabytes in just couple of seconds. DebugLog can be used to look for clues if the system does not behave as predicted.  

MxClose.vi and MxCloseHardware.vi are called to signal DLL to close and clean up used resources and to close used hardware. For proper operation of CAN hardware, LabVIEW relies on proper closure of open handles. Pressing the Stop button ensures that MxCloseHardware.vi is executed. Aborting execution in LabVIEW should be avoided, and most often requires the system or hardware cards to be reset manually.