Macintosh/LabVIEW combination as the instrumentation platform. The advantages of selecting a desktop computer as the platform for running instrumentation applications is both the availability of software and hardware and that only one computer is needed to perform the regular personal desktop duties as well as bench-top instrumentation applications. The main disadvantage is that embedded computers typically have real-time operating systems designed for fast and reliable data-acquisition and control applications. Choosing a desktop like the Macintosh will mean that certain applications cannot be implemented.
To add the capability of communicating with the control system, an interface to the ACcelerator NETwork (ACNET) was written. The integration of LabVIEW with ACNET is described in the following section, followed by an overview of applications and experiences.

INTEGRATION OF LABVIEW WITH ACNET

Communication

The ACNET protocol associates data with physical devices, for example, the value of the voltage of a power supply. In LabVIEW, an ACNET device is associated with an analysis result, a variable, rather than a device. To retrieve data, the ACNET protocol requires that remote nodes have a task called RETDAT to handle requests for data readings, and a task called SETDAT to handle data settings. On the LabVIEW nodes, the tasks are implemented in C and run as completion routines. The implemented RETDAT task supports single-reply, multi-reply interval-based, and multi-reply event-based on a single message containing requests for data from one or more devices. The SETDAT task supports a single-set of data on a single message containing requests for data settings of one or more devices. The RETDAT and SETDAT tasks talk to a server task that was already written for the Macintosh as part of the Lineac control system (see [1]). The server connects the tasks to a tokenring or ethernet network and provides ACNAUX (ACNET AUXiliary) node statistics services, such as which tasks are connected, the number of messages handled, and uptime. The data accessible by RETDAT and SETDAT is stored in shared memory that the LabVIEW program accesses through a library of read/write routines for the different variable types (see [2]).
From the operator's point of view, the LabVIEW/ACNET interface makes a LabVIEW node look like just another node in the accelerator network, so that the standard console environment can be used to read out or control a LabVIEW application.
As more complex applications were built, the ability to be read or be set was extended with a new interface that enables a LabVIEW program to read and set devices on other nodes, for example, the reading out of beam energy or current store number, or the setting of a timing gate. This interface, TCPORT, connects LabVIEW as a client to the VAX TCPORT server which will, on behalf of the client, issue the proper ACNET requests. The data requested from nodes must be scaled according to the database entries. To avoid having to reimplement these data scaling services and database lookup facilities already available on the VAX, the TCPORT server performs these functions, including permission checks and activity logging, before requesting the settings or sending scaled data to the TCPORT client on the Mac. Because the client is completely implemented in LabVIEW itself, it can also run on the other computers on which LabVIEW runs.
Because the instrumentation platform uses a desktop computer, additional commercial communication software is readily available. Utilities like Timbuktu (PC/MAC) and PlanetX (X-Windows) can remotely control a node before an

Table 1. The device table used to initialize the LabVIEW/ACNET interface.

The table is used to initialize the ACNET interface each time the LabVIEW program is started. By doing this from a table instead of hardcoding this into the program, modifications to the device table do not require a recompilation of the code or involvement of an ACNET programming expert. A LabVIEW utility, Ac_MakeDabbel, is used to convert the device table to a database file with device entries. This way, a developer does not have to be familiar with the syntax of the database entries. The format of the device table is also suitable as documentation for what devices are defined for the node.

Development tools

To help a developer use the ACNET interface, a template of a LabVIEW/ACNET application is available. The template includes the initialization and termination of the ACNET interface and has a location on the diagram where the developer can insert the LabVIEW application (see figure 2). The developer only has to fill out the name of the device table, over which network the interface should communicate (or even both), and the name of the project. The template includes an error logging display and a statistics page. The statistics page shows the registered devices, the ACNET access activity as well as computing load on the node and the program versions of the ACNET interface. To help install the required software for the ACNET interface, an installer disk is available.

To assist the development and documentation of LabVIEW system, the utility VI Hierarchy has been created (see figure 2). It displays the hierarchy of calling routines and the information about the operation of the routine. The utility allows the developer to browse through the hierarchy and print out documentation. Even though the graphical nature of LabVIEW automatically provides a graphof the data flow of each routine, a high level description of the functionality, much like the description of a c routine,is still needed to help others understand the program (see figure 3).

Figure 2. The Hierarchy Browser.

To make it possible to test or diagnose the LabVIEW application without requiring the use of the console environment, a LabVIEW utility, ParameterPage, was created to read out indexed devices, plot array devices, and time plot a device. The ParameterPage utility uses the TCPORT interface to request the data from any ACNET node (see figure 3). The TCPORT utility also makes it possible to prototype a console application in the LabVIEW environment before writing it in the console environment.

Figure 3. The LabVIEW parameter page.

In case a Macintosh system crashes and remote control is no longer possible over ACNET or with other means, the

EXPERIENCE

Reliability

We have had excellent results with the reliability of the hardware platform and the software. Several nodes had uptimes of about half a year only to be shut down by a site-wide power outage. None of the desktop hardware has failed in the several years that nodes have been on-line. During the development phase, the programs could hang or crash, but once these bugs have been removed (often incompatibilities of extensions) the systems ran reliably. On a downside note, on every upgrade of the software (e.g., new versions LabVIEW or Mac OS) we found that problems arise that affect the reliability. Therefore we are very careful in upgrading our software, especially new versions of the development environment.

Code sharing and documentation

The ability of code sharing is often the pride of a new programming paradigm. How did we do with LabVIEW so far? Code for instruments that was made available by the companies was used quite a lot, not always right out of the box but often with small modifications to be suitable for our applications. The Acnet interface code was used in all on-line applications and did not require any modifications. Many of our applications share the same analysis routine, a non-linear gaussian fit. Initially, a fitting routine coming directly out of LabVIEW's analysis library was used but this was adapted to our use and improved in speed (see [3]). Other code used to store data on disk (circular buffers), or pop-up menus has been reused some but not yet as much as we would like. In these cases it was very hard to find common ground for the different applications.

Development

We did find that programming in LabVIEW enabled more people with different backgrounds to set up a system. The graphical nature of LabVIEW saves one from making the typical syntax errors in text-based language and thus saves time. One of the most powerful debugging features is that one can run each routine by itself interactively (without having to create a main program) or, when run as a part of a program, view the parameters and results, possibly in graphical format. One wonders why such a powerful debugging feature has not been built into text-based development environments where you always have to put a wrapper (main program) around the subroutine to test its operation.
Even though a LabVIEW program is a graphical diagram of data flow, it is still possible to do bad programming and make the code incomprehensible. Proper documentation and proper programming styles are still very important to complete the development with a maintainable system. We have put documentation on a WWW server to provide easy access and have been using it quite a lot ourselves during development. We are also standardizing the development cycle for LabVIEW systems. This is described in [8].

Software/hardware availability

though, that this did not limit us too much, since much of the real-time operations can be done by the ever smarter instruments.

CONCLUSIONS

The LabVIEW/Macintosh combination with the addition of the ACNET interface has given us a general purpose instrumentation platform that is easy to use and able to implement a wide variety of applications, including those used for the continuous accelerator operation. We limited ourselves to applications that didn't require fast and deterministic feedback loops. Most of our applications provide results to operators, requiring only that the results are returned within the range of the operator's patience. We found that the integration of commercial software and hardware with ACNET enabled us to buy off-the-shelf products, thus reducing time and cost and making life a lot easier.

REFERENCES

[1] [2] [3] [4] [5] [6] [7] [8]

B. Peters, "Macintosh Parameter Page", (to be published).
W. Blokland, "An Interface From LabVIEW To The Accelerator Controls Network", Proc. of Accelerator Inst. Workshop, Berkeley, USA, 1992, pp. 320-329.
A. A. Hahn and P. Hurh, "Results From An Imaging Beam Monitor In The Tevatron Using Synchrotron Light", HEACC'92, Hamburg, Germany, July 1992, pp. 248-250.
W. Blokland, "A VXI/LabVIEW-based Beamline Tuner", PAC'93, Washington, USA, 1993. E. Barsotti, "A longitudinal Bunch Monitoring System using LabVIEWand high-speed oscilloscopes", 1994 Accelerator Instrumentation Workshop, Vancouver, Canada, 1994, pp. 466-472.
J. Zagel, "Booster Ion Profile Monitor using LabVIEW", 1994 Accelerator Instrumentation Workshop, Vancouver, Canada, 1994, pp. 384-390.
J. Steimel, "Fast Digital Damper for the Fermilab Booster", PAC95, 1995.
W. Blokland, "A LabVIEW-based Accelerator Instrumentation Platform", EPAC94, London, GB, 1994.