RPC Communications

The use of global sections imposed considerable restrictions on the format of the configuration database, and was inconvenient for a configuration that changes dynamically. In particular, the total size of each section was constant, fixing such things as the maximum number of instruments, the size of the structure for each instrument variable and the size of each character string. Using an RPC (remote procedure call) methodology was seen to be able to solve these restrictions and inefficiencies, as well as adding many other desirable benefits.

The second version of CAMP again consisted of a server maintaining a database in memory and multiple client applications (see Fig. ). In this system, however, RPCs were used for all requests and data retrieval. Global memory sections were no longer necessary. At this time, ONC (Sun) RPCs were considered more portable than DCE (OSF) RPCs.[4,5] The MultiNet software in use at TRIUMF provided an unsupported ONC RPC library, and was chosen for the implementation. Since then, the release of UCX 3.0 provided another ONC RPC library alternative. CAMP has been successfully built, but not used, with the UCX library.

  
Figure: CAMP Distributed Design using RPCs

Using an RPC methodology made the system distributed. The drawback to this was that the client applications would now make RPC requests for updates of the database from the server rather than mapping to the global sections. The RPC XDR routines were optimized so that updates of the database would supply only the items in the database that can change, so as to incur minimal overhead. Updates of a single variable, the variables at one level in the path, or all the variables below any point in the path could be requested. For simplicity of design, and because it was not deemed necessary, the server keeps no record of client information, i.e., clients do not register with the server. All client requests are ``pushed" to the server, and all updates of the database are ``pulled".

A proprietary slow control system, LabVIEW, was studied at this time. [6] LabVIEW contained most of the necessary functionality, but was not available for the required platform (Mac, Sun and IBM/PC only). LabVIEW's use of multiple variable types appeared very useful and prompted a similar implementation in CAMP.

The structures defining the configuration could now be expanded. Since many instruments have variables that are best described by an editable character string, or a selection of character strings, the variable types ``string" and ``selection" were added. Furthermore, as the instruments in use have many variables, it was found advantageous for the lesser used variables to be ``hidden" at levels below the top level. The ``structure" variable was added and the variables organized like a (Unix) directory tree, with an ``instrument" variable at the top level (see Fig. ). The ``instrument" variable (at the root of the tree) has a unique identifier, specified at instrument addition. All variable identifiers below the ``instrument" variable are generic for that instrument type. Thus, multiple instances of the same instrument type are possible. The ``instrument" variable structure would contain the interface-specific information.

  
Figure: Sample CAMP Variable List - tree-like organization

This flexible linked-list version of the database of instrument variables, with multiple variable types, also allowed for the implementation of pseudo-instruments. The ``link" variable was added to provide links from a pseudo-variable in the pseudo-instrument driver to variables in a physical instrument driver. That is, the pseudo-instrument driver provides a level of abstraction above existing instrument drivers. This capability has not as yet been used, but it will soon prove necessary for two different instrumentation facilities at TRIUMF. These facilities use more than one instrument for implementing a control loop, but to the user it is more natural to operate them as one pseudo-instrument.

This version of CAMP (v1.0) went into use in Spring 1994.

Another advantage was the ability to remove interface-specific information from the instrument driver. Access to the interface of an instrument is generalized so that an instrument definition may be modified for access by more than one interface type.

This version of CAMP (v1.1) went into use in Summer 1994.