Module Configuration

As mentioned in the Module Concept document, one goal of this project is to be able to replace reusable modules like CIE with more generic data abstraction classes. To meet this need, we have to be able to provide the same configuration data that the CIE required. This basic configuration is shown here:

For the CIE to function, a system must not only open references to the appropriate scan engine variables--it must also allocate memory in the CVT in which to place the scan engine data. If we were to simplify this configuration information into a single table, it would look something like this:

In the CIE style of API development, each process has a configuration which defines the source of the data ("IOV Name" for the CIE), a direction, a CVT tag (since all data was mapped to CVT) and a type. In a situation where the data copy process is a single function, this makes perfect sense. Execution just flows down the configuration table, reading or writing each element from a source and to a sink.

One problem here is that all data is separate. That is, there are two arrays -- one which contains the CVT tags, one which contains IOVs. To make things worse, the data direction isn't known until runtime, when the CIE polls the scan engine to determine whether or not these variables exist and whether they are inputs or outputs.

We've solved some of these problems with the concept of Channels.

Other modules might need to have some metadata for configuration. In our current example, scan engine period is a good example. Thus we'd have a list of channels and then a single value for scan engine period. Or, we might have a scaling function which needs an input channel, output channel, and then scaling coefficients on a per-function basis. These needs can't be met by simply extending the channel concept, but they can be met by wrapping these channels in a higher level configuration class, the TBM Module Configuration. In our scan engine example, this configuration class' data looks like this:

Regardless of the situation, the actual interface between our modules and the rest of the system is this list of channels -- what data is going in, what data is coming out? To meet this need, the parent class (TBM Module Configuration) has a single must-override VI called "get channels.vi". This method is responsible for returning a list of all channels in the system.

Besides this core functionality, our configuration class also allows users to define whether or not they can dynamically discover and link to other channels in the system, as well as listing out what channels are supported by the system.

In addition, users can add other features to their configuration class. For example, the developer of the scan engine module might want to make a simple API for adding a channel with all of the required information. This is easy, and encouraged. A critical concept of this design is the idea that every configuration object acts as an API for the module it is configuring.