The Use of ACOP Tools in Writing Control System Software
Ivan Deloose
CERN, CH-1211 Geneva 23, Switzerland

Philip Duval and Honggong Wu
DESY MKI, 22607 Hamburg, Germany

Several institutes are making increasing use of PCs inaccelerator controls. In particular, Windows NT and/or
Windows 95 is already, or is becoming, a supported
platform at the client-end in a variety of control systems.
Notably,
controlsystemsat
CERN/ISOLDE,
DESY/HERA,
KEK/PF-LINAC,
Daresbury,
ISA(Denmark), MSI (Sweden), and ESRF currently make useof Windows NT as a control system client. As all of thesecontrol systems are either object-oriented or object-based,
their is a considerable overlap in their functionality andrequired features. This point was realized at the PCaPAC'96 workshop, and gave rise to the ACOP work group,
which stands for Accelerator Component OrientedProgramming. The first fruit born of this group is theACOP.OCX (OLE Control eXtension) ActiveX control.
MicrosoftTM ActiveX controls are the updated version ofthe former OLE (Object Linking and Embedding) control
specification. The ACOP control has been designed inorder to support the common functionality requirements ofobject-oriented and object-based control systems. The
binary form is shareable on all Win32 platforms.
This report gives an overview of the functionality ofACOP.OCX and its implementation at CERN and DESY,
together with the progress on a compatible Java bean.

Visual C++, Visual FoxPro, Visual J++ and the Internet
Explorer Java Basic. Some other Win32 applications, such
as LabView, can also act as ActiveX containers, but withmore limited support.
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 to
the 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 data from the control
component to a required, ACOP-compliant Dynamic Link
Library (DLL), called ACOP.DLL. This DLL interfaces
the ACOP control to the institute specific device accesscalls, which are mostly provided in a home-made DLL.
This strategy enables developers porting to Win32, toconcentrate specifically on data exchange and not to worry
about the peculiarities of OLE.
With these features, ACOP targets other institutes,
which make use of object-oriented or object-based Win32
control systems.

1 Introduction

2 The Device Access Interface

Abstract

At the recent PCaPAC ’96 workshop in Hamburg andCAT ’96 workshop in Tsukuba, it was evident that a large
number of institutes are using PCs running either
Windows NT or Windows 95 at the control systemconsole level.
ACOP is a client-side component, developed as a joint
project between CERN and DESY. At both laboratories itwill be integrated in all current and future Win32(Windows NT, Windows 95, 98) based control systems,
beginning with the 1998 run period.
The ACOP ActiveX control is based on the MicrosoftTM
COM (Component Oriented Model) foundation, which
implies both binary reusability and dynamic linking with
its container. In turn, this implies that integrating
upgrades of ACOP.OCX do not require re-compilation orre-linking. As a COM object it offers a languageindependent interface to its container. The most popular
ActiveX control containers are typically Visual Basic,

2.1 Properties
Most object-based control systems offer an object-viewof the front-end hardware, where the device has a uniquename and exposes its hardware-specific actions throughproperties and methods. The latter typically involveschanging hardware settings or data acquisition. It wasdecided to keep the device access interface as simple aspossible, respecting the individual needs. This resulted
into the exposure of only two device identification
properties:
DeviceName and DeviceProperty
Both of these properties are variable-length strings sothat a wide-variety of naming hierarchies and properties
can be supported. Naming hierarchies might begin at theaccelerator domain level and continue through device

family to the specific device. Likewise the device property
is frequently a simple string such as “POSITION” but
could also conceivably be more complex for othersystems. ACOP assumes that these two properties aresufficient to identify any device parameter. The issue ofname resolution is not addressed at the interface level,
and assumed to exist at lower level.
Similarly, ACOP exposes three device data accessproperties (variable length strings) :AccessMode, AccessRate, and AccessProtocol
Typically, control systems employ a variety of data
AccessModes including synchronous or asynchronous
READ and WRITE, POLLING, SMART-POLLING, etc.
The control system specific identifiers are passed throughthis property. As a string, AccessRate might contain for
instance a polling rate in milliseconds or simply “FAST”,”SLOW” or even in the case of CERN/PS a cycle tag. The
AccessProtocol, however, can be considered as a control
system identifier. For instance, at DESY, it might bedesirable to interface both DOOCS[1] and TINE[2]protocols from the same application. In this case, theAccessProtocol will indicate the compliant ACOP.DLL
which specific homemade layer (DLL) to branch.
In order to allow a user-friendly way of property setting
at design time, the ACOP control provides several
property pages. The following picture (Fig. 1) illustrates
the ‘Device’ specific page.

2.2 Methods
We have so far only described the device accessproperties. To acquire data or send commands to the front
end, the user must call one of the ACOP device accessmethods. These are listed below:
ExecuteIssues a synchronous request based on the current data
access and device properties, and returns a completion
code. By default, the method takes the data buffer as only
parameter. Optional (also called Extended) parameters areforeseen when the user wants to perform a bi-directionalcall. e.g. Sending some settings down to a device while
doing a data acquisition.
OpenLink
Issues an asynchronous request based on the current
data access and device properties, and returns a handle
which identifies the open link. The user only needs tospecify the array size and the data format for asynchronous
data acquisition. The same optional parameters areavailable as in the Execute method in order to allow bidirectional device access.
When new data arrives, an event notification callback istriggered (see 2.3). The acquired data can now be
retrieved by calling the GetData method.
There are no limits on the number of simultaneous open
links issued by the same instance of an ACOP control.
AttachLink
Similar to the OpenLink method, but the data buffer isdirectly attached to the established link. This means thatbuffer is automatically updated when the notification
callback gets fired. The GetData method is not requiredin this case. AttachLink can only be used if the memory
allocated by the data buffer remains stationary during
program execution.
GetDataFig. 1 : The ‘Device’ property page.
It is clear that all properties can be modified at any time
during program execution.
Other properties (mostly read-only), returning
information about the current device access will not be
discussed here, but are documented in the software
package.

This method should be called in response to the event
notification callback routine. It retrieves the incoming data
into the local buffer for links created by the OpenLink
method.
CloseClink
This method terminates the specified link, or all active
links if the argument is omitted.
In addition to all the standard OLE data types, themethods accept any kind of user defined data type orstructure. In the last case, some optional parameters arerequired to indicate the array size and format of the data.
It is clear these user-defined types are control system
specific and has to be recognized by the underlying
software layer (homemade DLL).
2.3 Events
Callback in OLE controls takes the form of events.
Regarding device access, ACOP exposes only one event :Receive
This is triggered upon receipt of incoming data orinterim status messages (such as link time outs).
2.4. Device access sample

interface has been included in the first release of theACOP control. The programmer can choose from a variety
of display modes, ranging from simple vector drawing toadjusted histograms. The histogram display mode itselfoffers several features such as displaying a marker ortagging individual lines. ACOP also features a very
intuitive zooming capability.
The drawing methodparameters make use of the standard OLE data types, sothat a method such asacop.draw PSField,
called inside the acop.Receive event procedure of thedevice access sample from paragraph 2.4, produces thefollowing output (Fig. 2) :The following Visual Basic code illustrates thesimplicity of device access (which is especially simple if
the data sets involved use OLE types). As an example,
consider obtaining an array of 1200 points, representing
the shape of the magnetic field of one of the CERN/PS
accelerator cycles. Provided that the device accessproperties are filled in correctly, one writes simply:
Dim PSField(1200) As Single‘as global
acop.Execute PSField‘synchronous execution.
acop.AttachLink PSField ‘asynchronous execution.
2.5. ACOP.DLL
As already mentioned in the introduction, a compliant
DLL called ACOP.DLL connects the ACOP.OCX to theindividual communications layer of the control system inquestion. Most of the data exchange between the OCX
and the DLL occurs via a unique function, called
DevRequest. When one downloads the ACOP package
from a web-site, a sample ACOP.DLL is included, which
simulates data access. Furthermore, the source code
contains key wizard-like “TODO” comments to indicate
where the user should fill in his private device accesscalls. This task is particularly simple when the concerned
control system is already accessible through a Win32
DLL.
3 The Graphical Interface
One could be perfectly content to leave the ACOP
control invisible and simply make use of the bevy ofgraphical widgets already available as ActiveX controls.
Nevertheless, there are several graphical rendition styles
that are used repeatedly in console applications, such as
displaying traces and histograms, but sometimes, none of
the graphical widgets in the arsenal available to theprogrammer does precisely what is required.
In order to offer the programmer more of the specifictools he needs, a control system oriented graphicalFig. 2 : The PS magnetic field for a particular cycle
4 Conclusions
As a client-side control component, ACOP’s usefulness
is primarily at the device interface level. It hides the bulkof details of client-server data exchange, and separates theOLE-specific and COM-specific interface the applications
programmer sees from the control-system specific datatransport mechanism. It can be used as a unification layeron the client-side for a wide variety of PC based control
systems. In addition a powerful graphics package is part ofthe control.
ACOP has been tested at both DESY and CERN andhas been seen to offer a very simple and intuitive interface
to control systems application programmers. At CERN, it
will replace the current ISOLDE and PS device access
control (RpcOle32.OCX) [3] and be deployed as standard
device interface for all future Win32 based applications(e.g. The ISOLDE/REX [4] project). At DESY, it will
replace Eqp.OCX, currently used in HERA and PETRA
Win32 console applications.
As an object, it offers a type of inheritance calledaggregation and can be sub-classed in other OLE controls.
As a COM object, its interface is language (container)independent. It can be fully integrated into a number ofcommercial products, including Visual Basic, Visual C++,Visual J++, Visual FoxPro and Internet Explorer. Using
ACOP in the Visual Basic development environment
provides the user the ability to create on-line prototypes
and operational programs in a minimum of time. At thesame time, it can be used in more complex environments
such as C++ or Java.
Work is currently underway on an ACOP Java Beanthat would offer similar capabilities. As a Java Bean,
however, it will be inherently slower than a native
compiled ActiveX control. As more and more institutes
are embracing Windows NT as a console, the mostpractical control component is more likely such anActiveX control.
References[1] G.Grygiel, O.Hensler, K.Rehlich, “DOOCS: A
Distributed Object-Oriented Control System on PCsand Workstations,” PCaPAC conference 1996.

[2]P. Duval, “DESY Activities ’96: A Report on
PCaPAC and Status of the HERA Control System,”
IWCSMSA workshop 1996. Note: “TINE” wasdescribed as “MCS-1” in this report.

[3] I. Deloose, “Integrating the New Generation ofISOLDE Controls into a Multi Platform
Environment”,
ProceedingsofPCaPAC’96,
Hamburg, Germany, Oct. 7-9, 1996
[4] I. Deloose, “Windows NT as Device Server for theISOLDE-REX project”, CERN internal note PS/CONote 97-27
The ACOP package can be obtained from :n http://wwwps2.cern.ch/acopn http://www.desy.de/hera/controls/acop
Email: Ivan Deloose: Ivan.Deloose@cern.ch
Phil Duval : Duval@desy.de
Honggong Wu : Wu@desy.deFilename:
P100.DOC
Directory:
D:\NPAPER97\ZRY
Template:
C:\WINWORD\TEMPLATE\NORMAL.DOT
Title:The Use of ACOP Tools in Writing Control System Software
Subject:
Author:JIANG MINGBAO
Keywords:
Comments:
Creation Date:
11/14/97 6:51 PM
Revision Number:
3
Last Saved On:
11/14/97 6:51 PM
Last Saved By:
JIANG MINGBAO
Total Editing Time:2 Minutes
Last Printed On:
01/19/98 4:56 PM
As of Last Complete Printing
Number of Pages:
4
Number of Words:
1,976 (approx.)
Number of Characters: 11,266 (approx.)