Generic Configuration Editor (xCE) Reference Example

System configuration is a large task for application architecture. In an attempt to make system configuration easier for designers as well as end-users, configuration editors are often implemented. This article accesses the common features of configuration editors, and presents an implementation of a Generic Configuration Editor (xCE) for LabVIEW.

Installation

The source code for the Generic Configuration Editor (xCE) example is included above as xce_source_101.zip.  It includes the xCE source and example editors.  

Requirements

• LabVIEW 2009 Development Environment
• Asynchronous Message Communication (AMC) Reference Library

Introduction

System Configuration is used to store and access semi-static data in an application which describes the hardware and behavior of the application. Configuration decouples the need to edit source code when a user needs to

• make changes to parameters,
• change hardware specific information,
• configure application specific behavior, and
• customize applications for a specific use.

The data for a configuration is stored in a file or database. At run-time, applications open the data from a file or database, rather than having the developer hardcode the information into the source. Time and money is saved by removing the need to validate new source code.

The interface to a configuration is called a configuration editor. Configuration editors are typically graphical user interfaces (GUIs) that enable a user to create/edit configurations so that the resulting file conforms to a format that an application can interpret. By enabling and limiting the interactions of data in a configuration the user can create a scalable and maintainable way to store information. Configuration editors have similarities between the structure of a configuration, and the interactions between data in the structure.

Common Features of Configuration Editors

National Instruments provides some examples of typical configuration editors. Measurement and Automation Explorer (MAX) is a configuration editor commonly used to configure NI Hardware. Figure 1 shows the GUI for MAX.

[+] Enlarge Image
Figure 1:  NI MAX Graphical User Interface

Another configuration editor is the LabVIEW Project Explorer. The Project Explorer saves the information as an XML file with the extension “.lvproj”. Even LabVIEW has a configuration file called “labview.ini” which is stored as human readable initialization file.

After reviewing the above configuration editors, three common elements can be extrapolated.

• There is a graphical way to navigate through the configuration. Typically this is using a tree control.
• After we navigate to a node in our tree data structure, we can edit the data stored at that node. Typically this is though another window (floating or attached).
• Nodes in the tree data structure can be added , duplicated, removed/deleted, and moved to another location in the tree data structure.

[+] Enlarge Image
Figure 2:  Common Layout for a Configuration Editor

The goal for a generic configuration editor framework is to implement the most common features of a configuration editor, and not impede the ability of a developer to customize the editor to their specific application.

Implementation of a Generic Configuration Editor Framework (xCE) in LabVIEW

LabVIEW object-oriented programming uses concepts from other object-oriented programming languages such as C++ and Java, including class structure, encapsulation, and inheritance. These concepts become very useful when designing the xCE. Inheritance becomes particularly important because it allows us to use existing class as the starting point for a new class. If the base (or parent classes) of xCE are implemented then a developer can expand on the xCE classes to make a custom configuration editor.

In addition, LabVIEW 2009 allows for data value references of LVOOP objects. Data value references allow a developer to pass an object to multiple locations without fearing a data copy. They are similar to a single-element queue.

Navigation

Navigation is the method that we move from data object to data object in our configuration. Since we are navigating through a tree data structure, figure 3 best represents the way we accomplish navigation.

[+] Enlarge Image
Figure 3:  A representation of a tree data structure for xCE

We start with a number of data objects. In the MAX example, they would be something like DAQ cards, and I/O channels. The nodes need to be given a way to interact with each other. That way we can associate DAQ channels with their respective DAQ cards. In figure 3, there are six nodes. Each of them has a unique identifier, or tree tag. No two nodes may have the same tree tag. Excluding Node0 (which is a special case) every node has a single supernode. Node0 is the supernode to Node1, Node3, and Node2. A node may have an infinite number of subnodes. Node0 has three immediate subnodes, Node1, Node3, and Node2. The arrows between the nodes are data value references. So Node1 has a data value reference to its supernode (Node0), its subnode (Node4), and a data value reference to itself (Node1) for later use.

Figure 4:  A LabVIEW tree control that represents a tree data structure.

When we implement out tree data structure with a tree control in LabVIEW it looks like figure 4. In this example, ClassType1 has two subnodes (subClassA and subClassB) and a supernode (Example Root).

Figure 5:  LVOOP Inheritance for the xCE framework

Figure 5 presents the LVOOP inheritance for the xCE framework with an expansion of the private data of the xceNode class. At the top we have the generic LVClass that all LV Classes inherit from. Beneath the LVClass we have xceTreeObj. xceTreeObj is a placeholder object. A caveat of data value references is that a LV Class may not contain a data value reference to its own class. Thus the workaround is to make a placeholder class that we inherit from, and make data value references to the placeholder class. Inheriting from xceTreeObj is xceNode. xceNode contains a data value reference to itself, to its supernode, to its subnodes, and its tree tag. The methods of xceNode deal with the navigation through our tree data structure. An example method of xceNode is GoToNode.vi. GoToNode.vi returns the data value reference to a node whose path is inputted. Relating to figure 3, the input string of “Node0/Node1/Node4” returns the data value reference to Node4 by navigating through Node0 to Node1 to Node4.

Data

xceNode deals with the navigation, but another class is needed to store additional common data that all nodes will need. Common data all nodes need includes the node name, allowed subnodes classes, if the node is movable, if the node is duplicatable, if the node is removable, the nodes description, and the node's UI VI which we will go into detail later. In LabVIEW this new class that inherits from xceNode is named xceDataNode.

[+] Enlarge Image
Figure 6: LVOOP Inheritance with xceDataNode

xceDataNode methods deal more with UI interaction, file saving/loading, and the private data of each node. For example a method of xceDataNode is saveDataNode.vi. saveDataNode.vi is a dynamic dispatch VI that writes the relevant information of the node to a file. By default the minimum information it saves is the node’s name and description.

Root Node

In our tree data structure, one special node acts as a gateway between the tree data structure and the GUI of our configuration editor—Root Node. The root node contains a reference to the tree control which is uses to add, remove, and move tree tags from the tree control. It also contains the file path of the current configuration, whether changes have been applied to the current configuration, etc.

The root node also contains the public members of the xCE framework. This protects developers from incorrectly accessing the wrong functions to manipulate a configuration. The result is the top-level VI for the configuration editor should only interact with the xceRootNode or one of its descendants.

[+] Enlarge Image
Figure 7:  The Root Node interacts with the tree control

Configuration

Each xceDataNode contains the private data needed to make a comprehensive configuration. To manipulate the private data, a subpanel is loaded with an xceDataNode user-interface VI. Figure 8 shows the location of the subpanel. To aid with common operations associated with subpanels (i.e. loading/unloading UI VIs) an xceSubPanel class is included in the xCE.

[+] Enlarge Image
Figure 8:  xCEDataNode loading a UI VI into a subpanel for configuration

To configure a specific node, the node hands the xceSubPanel class its user-interface VI, which is in turn loaded into the subpanel on the top-level VI. When the user operates on the user-interface VI, the information they enter is then stored into the node’s private data. So the xceSubPanel class facilitate the operations that change a node’s private data.

[+] Enlarge Image
Figure 9:  Interaction between a Node and a SubPanel class for configuration

To fully understand how xCE operates, we will examine what happens when a user clicks on a node inside the tree control, and then configures a node from inside a user-interface VI encapsulated in a subpanel. Fig. 10 shows the full framework.

[+] Enlarge Image
Figure 10:  Overview of how the entire xCE framework interacts

The user clicks on the tree control so that they can configure a node (for example Node3)

1. The tree control reports to the root node (Node0) the path Node0/Node3.
2. The root node navigates to Node3 using the path.
3. Node3 returns a reference to its UI VI.
4. The SubPanel class takes the UI VI reference from Node3, and loads the UI VI into a subpanel control.
5. The user interacts with the UI VI, which is inside the subpanel control. Since the UI VI has a data value reference to Node3, it can safely manipulate the private data of Node3.

Distributing Data

After our tree data structure is populated with the correct data using our configuration editor, we need a way to preserve that data. This is accomplished by saving the data into a file for later use in our application. The xCE saves data in an XML format because the structure of XML is a document tree. The result is a easily-parsed human-readable configuration file.

Figure 11:  An example configuration file

To distribute the configuration file, we can include it as a dependencies of our installer, or simply FTP it to targets (for cRIO or other real-time OS machines).

More Examples

A walkthrough document is located in the xce_source.zip download.  The walkthrough covers how to quickly get started, and the bare information on how to add onto xCE.

In addition to the Example Editor that comes with the above download, two other Editors have been made with using the xCE framework.  The Tag Configuration Editor was designed to aid with configuring a machine control architecture.  The Localization Configuration Editor facilitates the need to add multi-language support to Human-Machine Interfaces (HMIs).  Both examples provide source code built upon the xCE and demonstrate what functionality is included.

Feedback

This reference application was created by the NI Systems Engineering group. 

We do not regularly monitor Reader Comments posted on this page.

Please submit your feedback in the Configuration Editor discussion forum so that we can improve this component for future applications. 

Please direct support questions to NI Technical Support.

Requirements

Filename: xce_source_101.zip

Software Requirements

Application Software: LabVIEW Professional Development System 2009

Reader Comments | Submit a comment »