Using ACOP in HERA Control Applications
Philip Duval and Honggong Wu, DESY, Hamburg, Germany

Abstract
The ACOP (Accelerator Component OrientedProgramming) ActiveX control is now used in a wide
variety of console applications in the control of HERA
and its pre-accelerators. It has proven itself to be a
versatile graphics control in its own right, with an intuitive
interface for the developer. Its primary function, however,has been to provide a common Application Programmer’s
Interface (API) for three rather different data exchangemechanisms found in accelerator control at DESY. Theseinclude the TINE data exchange protocol, MKI3 dataexchange, and Channel Access. At DESY, ACOP is
primarily used in console applications programmed in
Visual Basic 5.0 running on Windows NT. Nevertheless,there are a number of applications which use ACOP in
MS Visual C++, Excel and HP VEE for example. In allcases, the ease in programming in a high-level language
such as Visual Basic with components has proven to be amarked advantage. We report here on our first year’s
experience using ACOP at DESY.

1 INTRODUCTION
The ACOP[1] ActiveX control is based on theMicrosoft™ COM (Component Oriented Model)
foundation, which implies both binary reusability anddynamic linking with its container. Just as important, it
offers a language-independent interface.
The mostpopular ActiveX control containers are typically Visual
Basic and other Visual Basic-based applications such asExcel, although integration in Visual C++ and Visual J++
for instance is also straightforward. Some other Win32
applications, such as LabView and HP VEE, can also act
as ActiveX containers.
Primarily, ACOP.OCX is a client-side control andoffers an interface for accessing front-end devices.
Secondly, the object offers a control system orientedgraphics package for on-line data analyses. This package
has been streamlined for efficient data-rendition at highfrequency in a number of styles of paramount interest tothe client-side applications running in the control room.
In order to be applicable to a wide variety of objectbased control systems, ACOP does not require adherence
to any particular naming convention or data transportmechanism.
ACOP only passes parameters and datafrom the control component to a required, ACOPcompliant Dynamic Link Library (DLL), calledACOP.DLL. This DLL interfaces the ACOP control tothe control-system specific device access calls, which aremostly provided in a secondary DLL. This strategy

enables developers porting to Win32, to concentratespecifically on data exchange and not to worry about thepeculiarities of OLE.
The ability to include a component with a well-known
interface inside the development application of choice has
great advantages over integrating say a class librarywritten in C++. The latter can of course be accomplished.
However, there are typically different integration
strategies among target applications (e.g. the interface tomethods and properties in LabView will be accomplisheddifferently than in Visual Basic), and the interface mightturn out to be language specific (i.e. only works in C++
unless a C-wrapper exists) or require a knowledge of C++.
A COM component on the other land is language neutral
and can be immediately plugged into any application that
supports ActiveX.
A working definition of a component can be taken from arecent Microsoft Developer Network News[2]: “selfcontained, programmable, reusable, language-neutral
pieces of code easily pluggable into applications.”
Furthermore, components expose properties and methods,
fire events, and are unequivocally identified through name
and/or ID.
The ACOP strategy violates the “self-contained” ansatz
to a certain extent, in that the interface to ACOP.DLL isrequired. ACOP.DLL itself is likely to require secondary
DLLs in order to communicate with a control system(s).
However, if installed properly, this “violation” is wellhidden from the user.

2 ACOP.OCX
ACOP.OCX is the binary ActiveX control, which canbe downloaded and installed as is. It provides a clientside component interface divided into two categories: dataacquisition and data rendition.
The interface toACOP.DLL is entirely concerned with data acquisitionand highlights the facility-dependent development whichmust take place in order to benefit from ACOP. The data
rendition aspect of ACOP is entirely self-contained within
ACOP.OCX. It was decided early on to incorporate bothaspects within the same control, largely on grounds that acontrol object should know how to draw itself. To be sure,the data rendition provided by ACOP is designed to cover
the most common display needs of developers, but is by
no means complete. When, for instance, complicatedsynoptic display is required, it is suggested to make theACOP control invisible and to use the graphical toolbox

available
withinthecontainer-application.
The developer interfaces to ACOP by setting propertiesof, calling methods of, and responding to events of
ACOP.OCX. We discuss the data acquisition and datarendition aspects separately below.

2.1 Data Acquisition
The settable data acquisition properties DeviceName,
DeviceProperty, AccessRate, AccessMode, andAccessProtocol are all passed through ACOP.OCX toACOP.DLL as non-fixed length strings. So any string
parsing or interpretation that takes place, occurs inACOP.DLL and reflects the control-system dependent
implementations there. The AccessProtocol property isdesigned to specify the control system protocol. AtDESY, ACOP provides a common layer for the TINE
protocol [3], the MKI3 protocol [4], and Channel Access[5]. Therefore, this parameter can be “TINE” (default),“MKI3”, or “CA”. The AccessRate, although passed as astring, is converted to an unsigned long value representing
milliseconds in the DESY implementation. This value
also serves as a timeout parameter for simple READ orWRITE requests. AccessMode is used to specify thenature of the data acquisition (at DESY: “READ”,“WRITE”, “POLL”, “REFRESH”, “RECEIVE”). The
DeviceName property follows the naming convention:[//<facility>/]<device server>/<device>
For instance “//HERA/BPM/WL197” or simply“BPM/WL197” (using the default facility) targets device
WL197 from the BPM sub-system. DeviceProperty
follows TINE conventions and reflects the property to berequested from the device in question. Channel accessnames can be specified either as one long string in
DeviceName or split between DeviceName andDeviceProperty as per TINE convention.
The remaining settable data acquisition property Grouped
is a boolean value which governs the behavior of event
notification when more than one data link is bound to aparticular control.
This provides a comfortable set of data acquisition
properties which can completely specify the data request.
One could take the standpoint that one non-fixed length
string could uniquely determine the data request.
However, this would place an unnecessary burden on theACOP.DLL developer to come up with a set of string
delimiters which could be used to parse out the necessary
information for his control system protocol. Most objectbased or object-oriented control systems make use of theabove elemental descriptions in making a data request.
Read-only data acquisition properties include Status (astring value containing the data acquisition status) andTimestamp (the unsigned longassociated with the data acquisition).

UNIXtimestamp

The principal data acquisition methods are Execute()(synchronous) and OpenLink() and AttachLink()(asynchronous). All three of these methods utilize two(optional) data sets, a primary set and an extended set, sothat the argument list takes the form of:[data,] [len,] [type,] [dataEx,] [lenEx,] [typeEx].

All arguments are optional, which means that they are
passed to ACOP.OCX as OLE Variants. This makes life
very easy for Visual Basic Applications, where anoptional argument is simply omitted. The difference
between the two asynchronous calls OpenLink() andAttachLink() is that the latter binds (attaches) the remote
data to the addresses passed in [data] and [dataEx]. Thus
these parameters must be globally available. OpenLink()
on the other hand does no such binding. Therefore, whenan event notification arrives, it is necessary to use thesecondary call GetData(data, [dataEx], [hLink]) to
actually obtain the acquired data into the application. AtDESY, the extended data set [DataEx] quite generally
refers to input data sent to the front-end server, where as
the primary data set [Data] refers to the output data,
returned from the front-end server. We note here anotherfeature of ACOP, namely that if the data elements [Data]or [DataEx] represent fundamental OLE data types (suchas arrays of shorts, longs, floats, or doubles) then theparameters [len] and [type] may be safely omitted. Insuch cases, the content of the elements will be scanned todetermine the array length and the data type. If special
user-defined data types are used, then these secondary
parameters must be supplied, in which case ACOP.DLL isqueried as to the nature of the data type.
As intimated above, the asynchronous calls fire an event
when incoming data arrive at the client-side. The ACOP
event that is fired in this case is the Receive(hLink,StatusCode) event. When this event is fired, the client
program can check the StatusCode for success and thelink handle in case more than one data links are bound tothe same control.
ACOP.OCX passes the data acquisition parameters
blindly to ACOP.DLL, whose duty it is to redirect therequest to the appropriate control system. The situation atDESY is depicted below in Figure 1, where the request issent to the TINE, MKI3 or Channel Access sub-systems
according to the AccessProtocol parameter.
In the above figure, if the AccessProtocol parameter
is “TINE”, the request is sent to Eqp32.DLL. If it is“MKI3”, the request is sent to MKI3.DLL. If it is “CA”,
the request is sent to the channel access DLL.

be written in a matter of minutes. This is also true ofapplications which use VBA (Visual Basic forApplications) as a macro language, such as Excel. Highlevel development environments such as HP-VEE™ andLabView™ can also easily incorporate ACOP, which has
been a considerable help to control engineers. Note thatin the case of LabView, OLE events are as of this writing
not yet supported (synchronous use only!).

Figure 1. Data Flow from an ACOP instance at DESY.

2.2 Data Rendition
The data rendition aspects of ACOP are indeed selfcontained. The idea is to offer a simple set of display
tools for the most common categories of data display.
This includes for instance displaying data arrays as atraces or histograms and offering various zooming andscrolling possibilities. We shall not go into any great
detail here as the details are many, but instead refer thereader to the ACOP documentation from the ACOP webpage. We note only that, once again, a good many of theparameters in the display methods are optional and indecreasing order of frequency of use.

3 ACOP.DLL
In order for ACOP.OCX to work properly, ACOP.DLL
must exist on the path, and export the following interface
routines:
long WINAPI DevRequest()
long WINAPI QueryDefaultAccessProtocol()long WINAPI QueryDataBlockSize()long WINAPI QueryStockAccessModes()We shall not go into the details of the calling arguments
here. Suffice it to say, that such details are covered in theACOP readme file, and that a sample ACOP.DLL withsource code is provided in the ACOP download package.
It is then a matter of adapting the sample DLL to thecontrol system protocol(s) in question.

4 CONTAINERS
The principal development language for console control
applications at HERA is Visual Basic. ACOP has been
seen throughout the past year to be wonderfully suited tothis environment. Useful control applications can literally

Microsoft Visual C++ (MSVC) can likewise act as acontainer for ACOP, although here, its use is not as
straightforward as in the previously mentioned cases. Thereason for this is the use of OLE variants in most of theACOP method calls.
Whereas in the higher-levelcontainers, type-casting into variants is automatic, and“optional” parameters can be omitted, in C++, OLE
variants must be specifically allocated and assigned, and“optional” parameters must be passed as empty variants.
This makes MSVC a somewhat cumbersome container for
ACOP, but it can nonetheless be used, as is used inseveral applications in HERA control.

5 UPGRADES
1998 can be considered a “beta” year for ACOP atDESY. Throughout the year, there were numerous bugfixes and feature additions, mostly in the area of data
rendition. As an ActiveX control is also a dynamic link
library, updating ACOP.OCX is as simple as copying thelatest version into the Windows system32 directory. No
re-compilation or linking is necessary. The one caveat
here concerns an upgrade involving an interface change.
If so much as a single new method or property is added tothe existing methods and properties of the control, allbinary executables using it must be recompiled. This is
not true of design-mode VBA applications or Visual Basic
Pseudo-code executables, but nevertheless must be taken
into consideration when upgrading to a newer ACOP
which features an interface change. So as to facilitate
HERA operation in 1998, upgrades involving interfacechanges were banned toward the beginning of the HERArun.

6 CONCLUSIONSACOP has an enthusiastic following at DESY as
concerns both its data acquisition and its data rendition
capabilities. Furthermore, it has been seen to integrate
seamlessly into a number of popular container
applications such as Visual Basic, Excel, HP VEE, andLabView, all in common use at DESY. As the standard
desktop workstation as well as the standard HERA
console are PCs running Windows NT, ACOP’s current
limitation to Win32 does not pose any significant
development problem. As ActiveX becomes available on
non-Windows systems, it is hoped that ACOP will
respond with cross-platform implementations as well. Inthe mean time, most control physicists and engineers are
now able to trivially access the control system of choice(independent of protocol), and do so from their favorite
development environment.

REFERENCES[1] I.Deloose, P.Duval, H.Wu, “The Use of ACOP Tools
in Writing Control System Software”, Proceeding
ICALEPCS’97, 1997.
[2] Esposito, D., “Writing COM Objects with ScriptingLanguages”, Microsoft Developer Network News,Vol. 7, No. 6, 1998.
[3] P.Duval, “TINE: An Integrated Control System forHERA”, These Proceedings.
[4] Ruediger Schmitz, “A Control System for the DESYAccelerator Chains”, These Proceedings.
[5] see: J.Hill, “Experience with PC Based EPICS IO
Controllers”, These Proceedings for references.
[6] http://wwwps2.cern.ch/acop,
http://www.desy.de/hera/controls/acop