Reference Design Content

This LabVIEW reference library allow you to convert an arbitrary  LabVIEW data structure to and from a human-readable XML string (or  file).  The reference library (GXML) uses a custom data schema which  emphasizes data hierarchy and makes the XML easier to read.   Code: vipm://ni_lib_gxml Discussion Forum:https://forums.ni.com/t5/Components/Reference-Library-for-Converting-Between-LabVIEW-and-XML-Data/td-p/1041232    

The System Management and Information (SMI) Library is recommended for new designs using LabVIEW 2013 or later. SMI retains all of the features of CRI, however palette member VIs are not "drop-in" replaceable. The CRI Library has been deprecated, and no future versions are planned for release.   The development of advanced and dynamic CompactRIO (cRIO) applications sometimes requires the ability to detect the current configuration of a CompactRIO system. The CompactRIO Information (CRI) library provides functions to retrieve information about a local or remote cRIO controller, backplane, and modules, including the type and serial number of each of these system components. It can be used with CompactRIO, Single-Board RIO (sbRIO), myRIO, MXI-Express RIO, and EthernetRIO, for reporting the configuration information of RIO hardware controller, chassis, and modules for local or remote targets.   Functionality   The CRI library provided with this tutorial allows you to programmatically retrieve information about the components of a CompactRIO (cRIO) system. It provides access to the following information:   Controller Model Name Model Code Serial Number MAC Address Host Name IP Address   Backplane Model Name Model Code Serial Number   Modules Module ID Vendor Name Model Name Serial Number   The CRI library includes two sets of VIs, one set to run directly on a cRIO controller targeted with LabVIEW Real-Time, the other set to run remotely to retrieve the configuration of any cRIO system on the network.   Using the CRI Library   The CRI installer will add the CRI function palette to the User Library function palette. All of the CRI VIs are located in the main palette.   Figure 1: cRIO Information (CRI) function palette     The CRI library includes a high-level function (Get cRIO System Info) to retrieve the complete system configuration of a CompactRIO chassis. This VI returns information about the controller, backplane and modules.   Note:   In order to retrieve information about the modules located in the cRIO backplane the function must load a custom bitstream onto the FPGA. This bitstream will replace any existing bitstream or LabVIEW FPGA VI running on the FPGA. Use this function carefully if the cRIO system and FPGA may be monitoring or controlling any external hardware.   Figure 2: CRI Get cRIO System Info.vi   The remote version of this VI allows you to retrieve the information from a cRIO system on the network by specifying the system IP address or network name. In order for this function to work properly the remote cRIO system must be configured with a compatible version of LabVIEW, NI-RIO, NI-VISA and the NI-VISA server.   Figure 3: CRI Get Remote cRIO System Info.vi   Controller and Backplane Information The high-level function CRI contains three individual VIs to retrieve information about the controller, backplane and modules. Using these VIs individually you can customize these operations in your application as necessary.     The controller and backplane information are read directly from drivers and registers in the controller and backplane. The VI is run while targeted to the cRIO controller.   Figure 4: Retrieving the controller and backplane information   Modules The VIs included in the CRI library for retrieving information about the individual modules in a chassis deploy a custom bitstream to the FPGA in order to retrieve information from EEPROM memory on each individual C series module. This custom bitstream aborts and replaces any other bitstream or LabVIEW FPGA VI currently running on the FPGA. Therefore you must use this function carefully to avoid causing any problems with devices and actuators connected to the physical I/O of the system.     To retrieve the current module configuration you must specify the type of cRIO backplane used in the system so that the correct bitstream is downloaded to the FPGA.     To retrieve information about the modules in a remote cRIO system, specify the system IP address or network name.   Figure 5: CRI Get Remote cRIO Modules Info.vi     The list of supported backplanes of each version of the CRI library is provided in the VI package description.   The CRI library includes a separate FPGA bitstream for each of these targets. If the Get cRIO Modules Info VI is targeted to the LabVIEW Real-Time controller of a cRIO system, all bitstreams referenced in the VI are downloaded to the program memory of the cRIO system even though the current system only contains one possible cRIO backplane. This can use up a significant portion of the cRIO program memory (RAM). In order to optimize your application and reduce memory usage, the CRIO library includes individual VIs for each of the cRIO backplanes which only include the bitstream for one of the cRIO backplanes/FPGA targets. You can use these if you know during development which of the cRIO backplanes will be employed in the deployed application.   Note: If a C series module is removed from a running system, the first time the module configuration is read using the CRI library, the vendor and model ID returned from the now empty slot may not be 0. It may be returned as a non-0 value and the module name will be <Undefined>. On the next operation it will return a vendor and model ID of 0.   Implementation   This section provides some additional information about the implementation of the CRI functions, which may be useful in customizing these VIs or implementing similar operations in your application.   Controller and Backplane   The VIs provided to retrieve controller and backplane information use standard LabVIEW Real-Time and NI-RIO functions  to retrieve the information.    The CRI Get cRIO Controller Info VI uses a modified version of the RT Ping Controllers VI to retrieve the information. This function may also be used to retrieve information from a PXI or Compact FieldPoint LabVIEW Real-Time controller.   The CRI Get cRIO Backplane Info VI uses functions from the NI-RIO driver to retrieve information about the backplane. The model code of the backplane is converted to an enumerated value representing the  backplane model name. The conversion is performed in the cri_Parse Backplane ID subVI using a lookup table containing  the list of backplanes and their model codes.   Figure 6: Block diagram of CRI Get cRIO Backplane Info.vi   The lookup table containing the list of available backplanes is stored in and provided by cri_cRIO Vendor and Components Library.vi. This VI contains a list of all current cRIO devices and vendors and their IDs and is used in a number of CRI VIs. The list of devices is stored in the default value of a series of front panel indicators. Any new cRIO devices may be added to these lists.   Figure 7: cri_cRIO Vendor and Components Library.vi: Lookup tables of cRIO components and vendors   Modules   The information about each individual module is stored in an EEPROM located on the module and includes the module and vendor ID and the module serial number. This information can be read in any LabVIEW FPGA VI using the I/O property node.   Figure 8: LabVIEW FPGA diagram and indicator used to retrieve information from four C series (cRIO) modules     The CRI library uses a simple LabVIEW FPGA VI to retrieve this information from all slots in the backplane. A unique FPGA VI is used for each backplane type. These FPGA VIs are compiled and the resulting bitstream (*.lvbit) is provided with the CRI libraryVIs.   The source code and project for these FPGA VIs is not included in the installed CRI library, as it is not required to retrieve the module information. Only the compiled bitstreams are required. The source code and project is provided in a separate download ZIP file if desired.   The project used to generate the FPGA bitstreams includes a separate FPGA target for each of the cRIO backplanes. For each target, a cRIO module is configured for each slot in the backplane to read the module information from the EEPROM of each module. The project uses a NI 9203 for each slot in the configuration, but the software allows you to retrieve the module information from any module regardless of the module type. This technique is used to retrieve the module information from all slots in the backplane regardless of the type of module in each slot. Figure 9: LabVIEW project used to generate the FPGA bitstreams for retrieving module information   After the module information is retrieved for each module, it is returned to the host VI running either on the cRIO controller or on a networked target. In the host VI (e.g. CRI Get cRIO-9101 Modules Info.vi) the module ID is converted to the vendor name and module name using the lookup tables contained in cri_cRIO Vendor and Components Library.vi.   Figure 10: CRI Get cRIO-9101 Modules Info.vi: Retrieving and converting module information on the host     Applications   The CRI library can be used to add advanced functionality to many different types of cRIO-based application. Here are a few examples of how the CRI library may be used.   Logging of System Configuration   In many applications where data is recorded or logged it is necessary to also record information about the recording system being used in order to meet certain standards requirements. Using the CRI librarycyou can retrieve information about all of the cRIO components used in the system including their serial numbers and can record this information in a file or database along with the data being recorded. When components are replaced in a system it is easy to track these changes. A more advanced system may record the calibration intervals for each module in a database and notify the user if individual modules will require re-calibration in the near future.    Dynamic FPGA Code Selection   Due to the nature of FPGAs, a LabVIEW VI performing I/O operations is developed and compiled for a specific configuration of module types in the backplane. A bitstream generated from a LabVIEW FPGA VI for one configuration of  modules cannot be used with a different configuration of I/O modules. For example if you have configured a NI 9215 analog input module during the compile process, you can not run the bitstream using a NI 9201 analog input module instead. However, you can configure and compile multiple FPGA VIs, one for each possible module configuration, and then select the proper FPGA VI or bitstream at run-time to match the current configuration of modules.    Using the CRI component you can detect the current configuration of modules in the backplane and can then select the proper FPGA bitstream to download and run. This detection and selection of the FPGA bitstream will be part of LabVIEW Real-Time application running on the cRIO controller.   Application Licensing   In some cases you may want to apply a license to an application and link it to a specific set of hardware. This would prevent a user to move the application/code from one cRIO system to another system containing the same hardware. Using the CRI library you can uniquely identify each system component using its serial number, as well as the MAC address of the controller, and can build a licensing solution that links the application to the specific set of hardware.   The process of creating a license key and linking the application to the hardware is not handled by the CRI library and must be implemented separately.   Download and Installation   The current version of CRI (v2015.0.0.1) is available through the LabVIEW Tools Network using VI Package Manager (VIPM). It includes support for MXI-Express RIO and EthernetRIO expansion chassis, in addition to existing support for myRIO and select sbRIO targets. VIPM also contains older versions of CRI, compatible with previous versions of LabVIEW. You can install them using the Install Other Version.... option in VIPM, although they may not include support for all of the latest controllers and backplanes.   Support and Feedback   Please post questions, comments and suggestions for the CRI library in the CRI discussion forum.

The Configuration Editor Framework (CEF) is a starting point for creating a custom configuration editor in  LabVIEW for your application. The framework consists of a tree control and subpanel API, a LabVIEW project template, and two abstract LabVIEW classes.

Following are my observations and findings while using Unicode in a LabVIEW UI application. The purpose of using Unicode in this application is to localize the UI on the fly in any language without having to change the Computer locale. The application provides a settings page which allows the user to select the language of the UI. Based on this setting all UI components (controls and indicators) are localized into the selected language. The resource strings for all controls/indicators and languages are read from a text file containing Unicode strings.   Disclaimer:   LabVIEW for Windows has limited support for Unicode strings in the front panel controls and indicators. This is not an offically supported feature, meaning that it is not as fully tested as other released parts of the development and run-time environment. In addition this feature is not covered under standard product support and parts of this feature may change in future releases of LabVIEW, i.e. any code developed on this feature may require changes when upgrading to a newer version of LabVIEW. If you have any feedback or questions about using Unicode in LabVIEW post them as comments on this document or in the Developer Zone discussion forums.   The code posted as part of this document has been developed and tested in LabVIEW 2009 running on Windows XP SP3 (English). The VIs are saved back to LabVIEW 8.6. Earlier versions of LabVIEW did not include all of this Unicode support and it is suggested that you upgrade to LabVIEW 8.6 or later if you want to use Unicode in your application development.   This code has not been tested with other operating systems and I assume it will not work on non-Windows OSs, though I expect it should work in Windows Vista and Windows 7. What is Unicode?   The answer to this question could cover many pages by itself so I will not attempt to provide a detailed or comprehensive explanation of the Unicode standard and its different character encodings. Please consult other online sources for this information. It will be helpful to be familiar with what Unicode is before proceeding with the rest of this document.   What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text http://en.wikipedia.org/wiki/Unicode http://en.wikipedia.org/wiki/UCS-2   Unicode and LabVIEW   Unicode is not officially supported by the LabVIEW environment, but there is basic support of Unicode available as described in this document. Unicode can support a wide range of characters from many different languages in the same application.   Windows XP (Vista, 7) is fundamentally built on Unicode and uses Unicode strings internally, but it also supports non-Unicode applications. By default LabVIEW on Windows (English) does not use Unicode strings, but rather uses Multibyte Character Strings (MBCS). The interpretation of MBCS is based on the current code page selected in the operating system. The current code page is set using the regional settings of the OS and determines how the bytes in the strings are rendered into characters on the screen. The most common code page is 1252 used by English Windows as well as several other Western languages and comprises the commonly known extended ASCII character set.   http://en.wikipedia.org/wiki/Windows-1252   When the regional settings in Windows are changed the OS may switch to a different code page for rendering strings. For example if you switch to Japanese, code page 932 will be used. Using different code pages allows LabVIEW to have localized versions of the development environment. All code pages include support for the basic ASCII characters used in the English language, as well as a local set of characters. Therefore if you have code page 932 selected, the operating system can still render ASCII characters as well as Japanese.   Using Unicode instead of MBCS, an application can render characters from many different alphabets or scripts without switching code pages/regional settings. In fact all of the language scripts supported in the legacy code pages are included in Unicode and Unicode keeps being expanded with more characters every release. Because Unicode does support more than 65535 characters nowadays, a concept of planes was introduced in conjunction with surrogate pairs. Most of the characters covered by the code pages are included in Plane 0 of the Unicode standard and fit on a 2-byte representation, but more complex characters for mathematics or ancient scripts have been located on higher planes and thus use surrogate pairs as they code point value (and are thus coded on 4 bytes).   http://en.wikipedia.org/wiki/Mapping_of_Unicode_character_planes   A common encoding form of the Unicode character set is UTF-16. UTF-16, depending on byte order is called Big Endian or Little Endian. Unicode in LabVIEW is handled as little endian, also called UTF-16LE. This is important to know when looking at the hexadecimal representation of strings or working with Unicode text files.   Character ASCII (hex) UTF-16 (hex) UTF-16LE (hex) - LabVIEW z 7A 00 7A 7A 00 水 n/a 6C 34 34 6C Ѳ n/a 04 72 72 04   Table 1: Example of a few characters in ASCII and Unicode   When writing Unicode to a plain text file you commonly prepend a Byte Order Mark (BOM) as the first two characters of the file. The BOM indicates to the file reader that the file contians Unicode text and if the byte order is big-endian or little-endian. The BOM for big-endian is 0xFE FF. The BOM for little-endian including LabVIEW is 0xFF FE. Windows Notepad and Wordpad can detect a Unicode file using the BOM and display their contents correctly.   LabVIEW for Touchpanel on Windows CE   LabVIEW for Touchpanel on Windows CE supports multi-byte character sets (MBCS) — specifically double-byte character sets (DBCS). Under this  scheme, a character can be either one or two bytes wide. If it is two bytes wide, its first byte is a special "lead byte," chosen from a  particular range depending on which code page is in use. Taken together,  the lead and "trail bytes" specify a unique character encoding.”  (http://msdn.microsoft.com/en-us/library/ey142t48(VS.80).aspx" target="_blank">http://msdn.microsoft.com/en-us/library/ey142t48(VS.80).aspx<SPAN>) A code page only contains the characters from one particular language such as  Korean. Therefore MBCS can only support ASCII and one other set of  language characters at a time and you need to select the specific code  page for non-ASCII characters to be used in your application. To do that, look for the "language for non-Unicode programs" in the Windows Control Panel.   Using Unicode in LabVIEW   Common Use Cases   A list of common uses of Unicode in an application developed using LabVIEW includes:   Non Unicode   All strings in the application used for display, user input, file I/O network communication (e.g. TCP/IP) are ASCII strings. This is the most common use of LabVIEW and does not require the use or consideration of Unicode.   Non-Unicode = Extension of ASCII based on system code page   ASCII technically only defines a 7-bit value and can accordingly represent 128 different characters including control characters such as newline (0x0A) and carriage return (0x0D). However ASCII characters in most applications including LabVIEW are stored as 8-bit values which can represent 256 different characters. The additional 128 characters in this extended ASCII range are defined by the operating system code page aka "Language for non-Unicode Programs".  For example, on a Western system, Windows defaults to the character set defined by the Windows-1252 code page. Windows-1252 is an extension of another commonly used encoding called ISO-8859-1.   http://en.wikipedia.org/wiki/ASCII http://en.wikipedia.org/wiki/ISO-8859-1     Figure 1: LabVIEW ASCII string in Hex and normal display showing extended ASCII characters   Unicode   •    The application reads Unicode data from a file or other source and displays it using a non-Unicode encoding (ASCII based) on the user interface. In this use case it is assumed the Unicode characters are limited to the subset supported by extended ASCII.   •    The application reads Unicode data from a file or other source and displays it as Unicode characters on the user interface.   •    The application internally uses characters encoded in a non-Unicode way, including input from the UI by the user, but needs to write data to a file or other destination in Unicode.   •    The application uses Unicode strings internally including input from the UI and writes Unicode data to a file or other destination.   LabVIEW Configuration for Unicode   To use Unicode in LabVIEW you must enable Unicode support by adding the following setting in the LabVIEW.ini file. After making this change you must restart the development environment.   [LabVIEW] UseUnicode=True   LabVIEW Controls and Indicator Properties The LabVIEW string controls and indicators have two private properties related to entering and displaying Non-Unicode (extended ASCII) or Unicode characters. These properties are not exposed through the regular property node; access to these properties is provided through subVIs as part of the examples included with this document.   •    Force Unicode Text •    InterpretAsUnicode   Force Unicode Text is a property which can be enabled and disabled on the string control using the context menu of the control or indicators.   Figure 2: Setting the Force Unicode Text property on a string control   The Force Unicode Text property affects how text entered from the keyboard is converted to a string (byte stream) in the diagram. If text is passed from an ASCII keyboard and this property is turned on, then the text is automatically converted to the Unicode equivalent of the ASCII characters. Typically this means that every single byte character is converted to the two byte Unicode equivalent.   InterpretAsUnicode is a property which can be enabled on text elements of different UI controls and indicators, such as the text of a string control/indicator, the caption of a control/indicator, the Boolean text of a Boolean control/indicator, etc. This property controls whether a string value passed to the text element is interpreted as an ASCII or Unicode string. SubVIs provided with the example in this document allow you to pass strings to different UI elements and select whether you are passing an ASCII or Unicode string.   Note: The state of the InterpretAsUnicode property of a string element may be changed dynamically if text is pasted or entered into the text element by the user. The display mode (InterpretAsUnicode) of the text element will automatically adapt to Unicode or ASCII depending on the type of text entered into the control.   •    If you paste a Unicode string into a text element the InterpretAsUnicode property is turned on. •    If you paste a regular ASCII string into a text element the InterpretAsUnicode property is turned off.   For example, if the display mode of a string control is Unicode (InterpretAsUnicode property on) and text is entered from an ASCII keyboard, the display mode will be switched to ASCII and the current value of the string control will be interpreted and displayed as ASCII characters. This can cause issues if the Force Unicode Text property is enabled for a string control. Entering regular ASCII text will cause the string control to interpret all data as ASCII, however the Force Unicode Text property will automatically convert the new characters entered in the control input to Unicode data. These two conditions combined will cause ASCII text to have a ‘space’ between each letter entered. These spaces are actually the extra Null byte, which are the second byte of each of the ASCII characters converted to Unicode. To resolve this issue you must detect the keyboard input and set the Text.InterpretAsUnicode property of the string control to True to properly display all text as Unicode. This is shown in the examples.   Labels and Captions   When localizing the name of a control or indicator on the user interface you should always use the caption of the control instead of the label. The label is part of the code of the VI (similar to a variable name) and should not be changed. The caption should be displayed instead of the label and can be changed at run-time using the VIs provided.   Listbox, Multicolumn Listbox and Table   The Listbox, Multicolumn Listbox and Table controls have different behavior in terms of processing Unicode strings from the rest of the text elements described previously. These controls so not use the InterpretAsUnicode property. Instead they look for a BOM (Byte Order Mark) on any strings passed to them. If a string passed to these controls starts with a BOM (either 0xFFFE or 0xFEFF) then the string will be handled as Unicode. This allows you to mix both Unicode and ASCII strings in the same control. The examples include subVIs to pass strings to these controls and mark them as Unicode using the BOM.   Figure 3: Adding the BOM to Unicode strings to update a listbox Unicode Fonts In order to display Unicode strings on your user interface the fonts you are using must have the necessary support for all the characters you are using. If you are using an extensive set of characters from languages using non-latin characters you should verify that your selected fonts have the necessary character support.   Two specific fonts commonly available on Windows that include most Unicode characters are Arial Unicode MS and Lucida Sans Unicode.   Programming Unicode in LabVIEW Converting ASCII Strings to Unicode   Included in the examples are two very simple VIs to convert an ASCII (MBCS) strings to Unicode and vice versa. These VIs use functions provided by Windows to detect the current code page used for the MBCS and handle the conversion.   Figure 4: Converting between ASCII and Unicode strings in LabVIEW   The conversion VIs are polymorphic and can handle scalar strings as well as 1D and 2D string arrays.   Displaying Unicode Strings on Controls and Indicators The attached project includes a number of examples showing how to display Unicode strings on different UI controls and indicators. For each of these control types subVIs are included to pass strings to the control and their caption and specify whether the string should be treated as Unicode or not. The following UI controls and indicators are supported with specific VIs:   Caption of any control or indicator String 1D String Array 2D String Array Boolean Ring Listbox Multicolumn Listbox Table   Using control properties you can also access these controls inside of other data structures such as a cluster.     Figure 5: Converting an ASCII string to Unicode and display it on a string indicator, 1D string array and 2D string array   Figure 6: Converting an ASCII string array to Unicode and display it on a  Listbox, Multicolumn Listbox and Table   Reading Unicode from a String Control In order to read Unicode strings from a front panel string control there are a number of settings and that need to be made:   1.    Enable the Force Unicode Text property of the string control from its context (right-click) menu.   2.    Enable the Update Value while Typing property of the string control from its context menu. Figure 7: Enable the Force Unicode Text and Update Value while Typing properties   3.     Add an event case to the Event Structure for the Value Change event of the string control. In the event case wire the control reference and new value from the event to the Tool_Unicode Update String VI as shown in the following diagram. This will update the string control as the user is typing to keep the InterpretAsUnicode property set to Unicode, while entering ASCII characters. Figure 8: Event Handler for  the Value Changed event of the string control Reading and Writing Unicode Strings to Text File When reading and writing text files it is important to know if the contents of the file is ASCII or Unicode. The Read from Text File function in LabVIEW does not know whether the contents of the file is ASCII or Unicode. Therefore you need to check to see if the file contains a BOM (Byte Order Mark) at the beginning of the data read from the file and then process the data accordingly.   Figure 9: Read a Unicode text file and process   To write Unicode text to a file, convert all your strings to Unicode and then prepend the BOM before writing the final string to a file using the Write to Text File function. Figure 10: Write Unicode text to a file   Release Notes   June 2014 - Added VI package of the Unicode tools. v 2.0.0.4  Includes wrappers for built-in functions for converting between LV Text and UTF-8. Function palette moved to Addons palette.   February 2019 - Updated VI package to include minor bug fix that occurs in Windows 10 and LabVIEW 64-bit. Latest version is 2.0.1.5. The VIP will also be added to the LabVIEW Tools Network VIPM repository.

The System Management and Information (SMI) Library allows for programmatic retrieval of system configuration information for NI RIO hardware (CompactRIO, Single-Board RIO, myRIO, MXI-ExpressRIO, and EthernetRIO) and Real-Time CompactDAQ, as well as Real-Time PXI controller and chassis information. SMI is currently supported in LabVIEW 2014 and later versions.   Description   The System Management and Information (SMI) library provides functions for the detection of network devices and the management of NI hardware on a network. Device detection and system configuration management is implemented by wrapping System Configuration (SysConfig) API calls, supplemented with NI RIO target-specific module detection code. For example, SMI network detection encapsulates the SysConfig "Find Hardware" to retrieve information about detected devices. By comparison, C series module detection in RIO chassis is done by deploying a target specific FPGA bitfile and performing an EEPROM memory query for stored module information.     C  Series Module Detection   C Series module detection for RIO targets (example: cRIO) can be done either remotely over the network, or as part of a Real-Time application, if the target is in FPGA mode. In the case of remote module detection, NI-RIO, NI System Configuration, and NI-RIO IO Scan components must be installed on the RT target. Local module detection on an RT target requires that the components, as well as target specific FPGA bitfiles (for the RT target and expansion IO chassis) are installed on the target. The most convenient way to place necessary SMI dependencies (components and FPGA bitfiles) on an RT target is to install the "C Series Module Detection" user component (CDF file) on the target.   The C Series Module Detection component may be installed by using the "Custom software installation" option in NI MAX, or through programmatic use of the SysConfig API (Functions>>Measurement>>System Configuration>>Software Management>>Install.vi). Installing the C Series Module Detection component installs components (drivers) necessary to use SMI in either remote or local running RT applications.   In order for the C Series Module Detection component to appear in the LabVIEW Real-Time Software Wizard (NI MAX >> Target >> Software [right-click] >> Add/Remove Software) "Custom software installation" features list, the SMI installation will copy a folder containing the component to the User Components directory (C:\Program Files (x86)\National Instruments\RT Images\User Components). If a hardware target is not yet supported by SMI, developers can generate FPGA bitfiles by using an included module detection project, installed alongside SMI (<LabVIEW>\vi.lib\SMI\source\C Series module detection). No matter their source, any FPGA bitfiles or components required by SMI can be copied to the RT target filesystem as an alternative to installing the CDF. If copied manually, FPGA bitfiles should be copied into the following directories on the RT target (by OS):   Linux = /usr/local/natinst/labview/FPGABitfiles VxWorks = c:\FPGABitfiles PharLap = c:\ni-rt\system\FPGABitfiles   Possible Additional Installation Steps   The User Components directory is a read-only directory, and some versions of the Windows OS will prevent VI Package Manager from copying files to this location during installation. If a user dialog message is displayed during installation of the SMI package stating that the component could not be copied to the intended system directory, the following (manual) steps will need to be taken to complete installation of SMI:        1. Navigate to the temporary CDF component installation location (<LabVIEW>\vi.lib\NI\SMI\cdf\C Series Module Detection).      2. Copy the C Series Module Detection folder(Ctrl-C).      3. Navigate to the User Components directory (C:\Program Files (x86)\National Instruments\RT Images\User Components)      4. Paste the C Series Module Detection folder inside of the User Components directory.   The NI-RIO device driver version will determine which NI hardware is supported for certain SMI features.   Examples   SMI palette examples demonstrate possible uses of the SMI library. SMI runs on both host PC (remote detection) or NI Linux Real-Time targets (target address = "localhost").   Note: Remote detection of C Series modules on NI RIO hardware will deploy an NI FPGA bitfile to the target, which can potentially interrupt a running system. It is recommended to verify the safe, non-operating state of any remote target before triggering any remote module detection.   SMI system information is retrieved by initializing a System Session for the intended target with valid NI Auth login credentials. Subsequent calls to SMI palette member VIs use the authenticated "controller" reference in order to interact with the device. After initialization, SMI library VIs can be used to retrieve device information, or as in the advanced example, use System Session or Hardware References to modify system parameter settings. Once an SMI library VI is executed, information gathered by that VI updates the "controller" object, and it can be read using property nodes without the need to re-run the library VI. Some SMI classes which include such accessor methods are: Controller, Chassis, Modules, etc. The "controller" object (containing the System Session and Hardware Reference) is closed at such time as the connection is no longer necessary.     Figure 1: system detection.vi (example) - get controller information VI must come before the get chassis information VI.   Figure 2: advanced system information.vi (example) Requirements Software LabVIEW 2014 and later System Configuration 2017 and later NI-RIO 17 and later NI-RIO IO Scan 17 or later C Series Module Detection component deployed to RT RIO target*  *note - required only for detection of RT application implementation of C series module detection on NI RIO hardware.   Hardware NI Real-Time controller and chassis including PXI, CompactRIO, Single-Board RIO, myRIO, MXI-ExpressRIO, EthernetRIO and CompactDAQ C series modules in CompactRIO or CompactDAQ chassis   Support   SMI is an open source project, and the source code is available in the SMI GitHub project (https://github.com/NISystemsEngineering/SystemManagementAndInformation). We encourage contributions to the SMI library from the LabVIEW user community by branching the code and submitting pull request to the trunk in GitHub.   Bug reports and feature requests for the SMI library should be posted to the Issues list in the GitHub project (https://github.com/NISystemsEngineering/SystemManagementAndInformation/issues) Pre-release beta versions of SMI can be downloaded directly from Github (https://github.com/NISystemsEngineering/SystemManagementAndInformation/releases) General questions about using SMI can be posted in the comments section below.   History   Version Date Description/Changes 2013.0.0.1 9/2/16 Initial Release               Download and Installation   The SMI library is available for installation directly from VI Package Manager.

The Options Dialog Framework (ODF) is a reference design for adding an interface for managing options and settings within a LabVIEW-built application. It is based on the framework used by the options dialog in the LabVIEW development environment.   Please provide any comments, feedback, suggestions and questions in the comments below.   For the purpose of this discussion we differentiate between options/settings/preferences and (system) configuration.   Options/settings/preferences - parameters that configure the operation of an application such as where files are stored, how data is displayed, etc. The specific set of options is fixed by the application developer and you generally do not have a variable number of settings. The LabVIEW options dialog is a good example of this type of information.   System configuration - a description of the physical and logical setup and architecture of a system and the associated application. This typically includes information about HW targets, channels, modules, and configuration of these objects within the system. System configurations are often hierarchical in nature (tree object) and support adding many instances of different object types.   This document and the associated examples do not address system configuration. For a possible system configuration solution take a look at the xCE (Generic Configuration Editor Reference Example, http://zone.ni.com/devzone/cda/epd/p/id/6249). This reference design and framework uses LVOOP to define configuration objects and lets developers design their own configuration editor by inheriting from the provided bases classes.   Application Settings Architecture   Managing settings within an application typically consists of three components.   Settings Storage - a method to store and persist application settings values between instances of running the application. This is typically implemented using a database or a file (INI, XML, etc.) on the local computer. Active Settings - a method to load and hold current settings values (current value table) in the application and access these values from the application logic. In LabVIEW this is typically implemented using one of a number of common methods (global, FGV, cluster in a shift register, shared variables, etc.) Settings Dialog - a user interface to directly view and update specific application settings. Some settings may be updated interactively while working with the application, while other settings are updated explicitly using the settings/options dialog. Not all application settings are necessarily exposed in the settings dialog.   Operations dealing with Application Settings include the following: Start of Application - settings are loaded from storage (Settings Storage) into active memory (Active Settings) Application Logic - the application code reads and writes settings in active memory (Active Settings) as necessary Settings Dialog - when the settings dialog is opened, the dialog pulls settings values from active memory into the UI of the dialog. When the dialog is closed the new values in the dialog UI are written back to active memory (Active Settings). Close of Application - settings values from Active Settings are saved to Settings Storage when the application is closed. This Save routine may also be called at other times in the application such as when the setting dialog is closed.   To implement this architecture we need the three basic settings components with interfaces that provide the necessary control to the application and other components. The following sections will discuss each of these three components. It should be noted that each component can be implement using a number of different methods and LabVIEW features and these implementations can be mixed and matched depending on the needs and preferences of the application and developer.   Configuration of Settings   As part of developing an application the developer needs to decide and define the list of settings (name, data type, etc.) used by the application. To simplify the process of managing settings throughout an application the goal is to define the list of settings in one location and have all other components dealing with settings use this common list. The following discussion and examples will attempt to provide a solution that follows this high-priority design criteria.   Active Settings   The Active Settings component is the core piece of implementing settings management in an application as it interfaces to the other three related components of the application (settings storage, settings dialog, application logic). It also makes sense that this component would be used to define the list of settings in an application.   To simplify using settings the Active Settings should provide access to settings values in a number of different ways:   Access by Name - read and write current values in Active Settings by  name Access by Node - read and write settings using a static node (similar to a local variable node) - this feature allows for List of Settings - return a list of all available settings including name and data type Get All Settings - return the complete set of settings including values.  This method is typically used to persist the settings value to Settings  Storage.   Implementation   There are quite a few different implementations of an Active Settings component in use in the LabVIEW community today, each offering different advantages and drawbacks, partially based on the personal preference of individual developers. These implementations include:   Global variable Individual settings All settings in a cluster Functional Global Variable (FGV) LVOOP Class Shift Register Settings cluster Shared Variables   For the time being we will not make a specific recommendation or example to implement Active Settings.   Settings Storage   Storing settings values between instances of running an application is the other key component of managing settings in your application. Like for the Active Settings, there are a number of common LabVIEW implementations for settings storage. These include:   Configuration file (INI) XML File Binary file Database   The config or INI file is a common solution as LabVIEW includes a good native solution for accessing these files.   XML files are popular for implementations that store active settings in a cluster, because it allows you to store the cluster as a whole in XML. Several Cluster to XML solutions exist in LabVIEW and the community.   Binary files can be used to quickly store any LabVIEW data structure to file, but are not suitable if you need to access the settings file outside of the application (non human readable) and does not handle additions and changes to settings well.   An ideal solution for Active Settings and Settings Storage will allow you to quickly and easily save all settings values to storage and retrieve them in a single operation without needing to customize this routine for you specific list of settings.   For the time being we will not make a specific recommendation or example  to implement Settings Storage but will use INI files in our examples.   Settings Dialog   A settings or options dialog allows the user of the application to interactively modify specific settings exposed by the developers. As an example the LabVIEW options dialog provides access to a wide range of settings that affect the looks and behavior of the LabVIEW development environment.   Reference Example   To develop an options dialog for your own application can develop the dialog from scratch or you can use the same dialog framework used by the LabVIEW options dialog. The example included with this document provides an interface to use the same code as the LabVIEW options dialog.   The options dialog is customized by building a number of individual options pages. When the options dialog is opened you provide a list of options pages VI paths to the dialog VI which will load and display the pages dynamically.   Each options page is implemented in one VI and should be created from the VI template provided with the example. Each options page contains front panel controls to allow the user to set values for a list of related settings in your application. Customizing the options page template is documented in the diagram of the template VI. The options page VI integrates with the options dialog using a number of events and is displayed in a subpanel of the main dialog VI.     One of the important aspects of building and customizing your options pages is the load and save process of the settings values. In the template and example provide the settings values are loaded from and save to a config INI file directly, rather than loading them from active memory in a running application. This is different than the discussion and diagram above. You can adjust this code to load and save settings values from file or active memory.   The options page VIs are loaded and run the first time the particular page is shown in the options dialog. This means that VIs are loaded sequentially based on user interaction. When the dialog is closed, however, all of the running options page VIs are stopped at the same time based on a user event from the options dialog. This means that their respective Save routines are likely running simultaneously. This is important to remember so that you don't try to access a shared resources such as a file with multiple File Open calls, generating access errors. The example solves this conflict by using one File Save Load VI that reads and writes the config file for all options pages. This non-reentrant VI can only be called by one page at a time and the LabVIEW scheduler thus automatically manages sequential accesses to the file.   Note: Currently the options dialog framework VI is password protected while we refactor the code to make it user accessible. Stay tuned for an update of this reference example that includes the open source options dialog. In addition we are planning on adding tighter integration between the Settings Dialog, Active Settings, and Settings storage components, to have one fully integrated application settings management solution.   Building an EXE   When build an EXE using the ODF VIs, there are a couple of considerations you need to make.   Since the option pages are called dynamically by ODF, you need to include these VIs in your built EXE (Always Include) or, if you prefer to keep the option pages outside of the EXE, you need to add them to the distribution of the EXE and associated files. Based on the location of the option page VIs in or with your EXE, the VI calling the ODF dialog needs to determine the proper path for the option page VIs. In some cases the path will be different whether you run in the development environment or as an EXE and your code needs to handle this difference. The same is true for the path of the configuration INI file which is determined and used in each of the option page VIs. Most likely this needs to be handled differently in the development environment versus a built application. The attached example (ODF EXE Example.zip) shows how to hande this difference. For any of your option page VIs, you need to include the front panel in the build options for the EXE.   See ODF EXE Example.zip for an example of a project using ODF and building an EXE. The top level VI and option page VIs contain the code that determines the dynamic paths of the option page VIs and configuration file.   Note: This example is using the options page VI template from ODF version 0.5 and will not work with earlier versions of ODF.     Please provide any comments, feedback, suggestions and questions in the comments below. References   A different Options Dialog reference design based on the Actor Framework - https://decibel.ni.com/content/docs/DOC-32723   Version History   Version Date Notes v 1.0.0.0 August 25, 2010 Original release as ZIP file only v 0.2.0.2 August 27, 2010 Reverted version number from 1.0 to 0.2 Added VI package distribution Moved all dialog subVIs from LV resource folder into package Added support to show/hide Help button and specify dialog help file Moved API and framework into LV project library VIs install to ..\user.lib\ODF Added subpalette to User Libraries in Function Palette v 0.5.0.1 January 7, 2015 Added new ZIP file saved in LabVIEW 2009 Removed all passwords from the ODF VIs Fixed issue that caused a hidden control appear in the dialog after repeatedly running the dialog Removed unused controls in dialog framework VIs and page template (these were not really visible in the previous version) Existing dialog pages should run without changes using the updated framework VIs, but if you create new dialog pages using the templates in this new version, they will not run with the dialog framework VIs from the previous version. ODF EXE Example.zip April 7, 2015 Example project including a Build Spec to create an application executable using ODF. This example requires ODF version 0.5.0.1 or later.  

The LabVIEW Replication And Deployment (RAD) Utility is a turn-key utility for creating and deploying application images for LabVIEW Real-Time applications. It is based on the NI System Configuration API and designed to easily replicate the image (disk content) of a LabVIEW RT target (CompactRIO, PXI, FieldPoint) from one master target system to other target systems as part of an application installation process.   A detailed description of the RAD utility is available in http://www.ni.com/example/30986/en/.       Support   Please post comments, feedback and questions in the following Discussion Forum: http://forums.ni.com/ni/board/message?board.id=RTControl&thread.id=18   Downloads   Utility Version 5.5.2 – Built with LabVIEW 2012 Download the Replication and Deployment (RAD) Utility 14.0 Requirements:  NI System Configuration (14.0.1 or higher recommended) Optional: NI-RIO Driver Source Code RAD 14.0 Source