Integration of a PC based experiment in a Network based Control
System: the TTF Optical Diagnostics Control System
L. Catani, INFN-Roma2, Roma, Italy-Abstract
Optical Diagnostics for Tesla Test Facility at DesyLaboratory[1] have been provided by INFN groups ofFrascati and Roma2. More than fifteen diagnostic station
have been installed on the TTF beam line and Test beamline and operated with the Optical Diagnostics Control
System (ODCS). ODCS is a stand alone system based on
Macintosh computer and provides full control over thespecific hardware while a network based Control
System[2] takes care of the whole TTF.
This paper describes the ODCS system, its features andthe solutions utilised to integrate ODCS with the TTF
control system.

1 THE ODCSWhen we started to design the Optical Diagnostic
Controls we followed these main guidelines:- the system has to be used for hardware control as well
as for data acquisition and analysis: a common
software environment should be preferred;- the large number of heavy images continuouslytransferred between the computer hosting the Image
Grabber and the Operator’s Console shouldn’t effectthe network and moreover shouldn’t be limited by thenetwork’s bandwidth and traffic on it;- furthermore the transfer speed must be high enoughto allow real time measurements;- the system must be easily expandable in order tofollow the further development of the TTF linac;- remote control of the whole system must be allowed
in order to permit operation and maintenance from“home”;
CONTROL ROOMCONTROLSYSTEM

Network
Fiber Optic link

Operator Console
Beam Trigger

Instrumentation
Area

L L
L L
3 30 00 00 0NetworkRAM
8M
BIP

IP

IP IP IP IP IP IPTiming

DigitalD S S S S Si t t t t tg e e e e ei p p p p pt p p p p pa e e e e el r r r r rFiber Optic link

Host

2 DATA SHARING AND
COMMUNICATION
2.1 Shared memory

Frame Grabber

Main

TT
F

previous experiences [3] and well known hw/sw has
to be preferred to reduce the efforts for development.
Our previous experience with Apple Macintosh for
hardware and instrumentation controls and for dataacquisition and analysis, defined the preference for thecomputers. The characteristics of MacOS and the need ofVME modules for I/O defined requirements for thearchitecture. In Figure.1 is sketched the layout of theODCS’s hardware configuration.
The three partners of the system are shown: in theInstrumentation Area the main ODCS computer and theTTF host (VME-Sparc Computer), the Operator’sConsole in the Control Room. The two Macintosh arelinked to the VME crate via a fibre optic link (LextelLL3000 series); this ensure an high bandwidth for datatransfer and moreover allows the Operator’s Console to belocated at quite long distance from the VME crate (approx.
80m.). The VME memory space is seen from theMacintosh as it was within its 32–bit address space anddirectly accessed. Main computer and Operator’s Console
have also a connection to the network to access the local
services and to allow their remote control by means ofTimbuktu (Farallon). On the Operator’s Console runs anFTP server to allow downloading of images andmeasurements from any machine.
All the software tools have been developed using
LabVIEW™ from National Instruments. For the low levelcommunication routines C libraries have been written andimported into LabVIEW Vis using CIN (Code InterfaceNode).
The Image Grabber (a number of them have beensuccessfully used) is hosted by the Main computer andcontrolled with LabVIEW. The beam trigger is used tosynchronise the image grabbing with the beam pulses.
For special measurements (low intensity radiation, time
resolved measurements) an intensified camera from
Princeton Instruments is used. Its interface to controller
unit is installed directly into the Operator’s Console andoperated locally.
Input/Output with hardware is performed using IP(Industry Pack) I/O modules: digital IO, DAC, Step
Motor Controller, etc.

video MPX

to diagnosticstations

Although the two Macs and their functionality can bemerged into one, we decide to use the two computersconfiguration in order to avoid the Operator’s Console tobe slowed down from the operations related to the images
acquisition and digitisation. With this splitting offunctionality, the Main computer takes care of the Image
Grabber and I/O controls while the Operator’s Console isused to display data, to run automatic procedures for themeasurements and for data analysis. Information about thesystem and the images are written from the Maincomputer into a RAM memory in the VME crate; theMain can be considered as the system’s “server”. The
Operator’s Console and the TTF Control System arehosts and they access information in the same way since
they share the same VME RAM memory. Furthermore,since the two hosts don’t control the hardware directly, a
set of mailboxes have been defined in order to sendcommands to/from the server.
Because LabVIEW doesn’t support C-like pointervariables, a C structure has been defined to map the shared
VME memory and C routines have been written toread/write from/to this structure. They have been imported
into LabVIEW Vis as CINs. At the same time the TTF
host interface application includes the same C–structure(the same header file) for its read/write routines.

image, or the projections, or just the RMS value, or evenall of them. Projections and statistics of images arecalculated while writing to VME to improve the speed.

2.2 Commands and Readout
Figure2 shows a flow chart outlining the execution of acommand. The operator clicks a button on its graphic
display to, for instance, insert an OTR screen at station“n” named “1exp3”. A command is written into themailbox to be executed by the Main and when it iscompleted, the variable ele[n].screen is updated to value“otr”. The display software of the Operator’s Console
detect this change and update the graphic display
accordingly.
Commands from the TTF host are executed in the sameway. The interface program use the same C routines toread/write the mailboxes while data are directly read fromthe ODCS_mem shared memory and sent through thenetwork to a console running a display application.

2OTROUTODCS_mem

1struct ODCS_mem {uInt32
SysInited;
mailbox
mbx[NumOfMbx];
modulesmod[NumOfMod];
elements
ele[NumOfEle];extelexele[NumOfextele];
imagesima[NumOfIma];

ttf.diag/1exp3/viewscreen/otr=in
mbx[0]/* Memory map inited *//* mailboxes *//* VME modules tables *//* elements tables *//* external elements *//* 512x512 8-bit image */ };Table1: The C structure that defines the “real-time”
database of ODCSIn Table1 is presented the C-structure defined to map
the shared memory. The mailbox type is a container forcommands strings to/from the Main computer and theother two partners: four unidirectional Mailboxes areimplemented. Commands are coded following the format
defined for TTF, i.e. “facility/device/location/property”
and looks like: “ttf.diag/viewscreen/1bc1/screen=otr”.
mod[] array (modules type) contains information about
the hardware and is used by the Main to executecommands. Every ele[] array element contains information
about the status of a diagnostic station and the I/Ochannels that uses; it is updated by the Main andcontinuously red by the Operator’s Console to refresh dataon graphic display. ima[] array is the container for the last
image taken at every diagnostic station, its projections
and RMS values (i.e. center of mass, sigmas) and totalintensity. ima[] and ele[] are indexed in the same way (e.g.
image for ele[n] is given by ima[n]).
When the Image Grabber is set in order to digitise theimage seen from the camera at station “n”, ima[n] iscontinuously updated from the Main computer. The
operator can configure its display to update either the fullMain

Operator Console4.screen=otr.camera=on.light=off…

3ele[3]Figure2: Execution of a command from the Operator’sConsole and readout from Shared Memory

2.3 Data from TTF Control System
ODCS has been also designed to send commands andreceive information from the TTF Control System. Thisis very important when some procedures have to be
executed automatically as, for instance, the emittancemeasurement. In this case the current of one or more
quadrupoles must be set to change the beam optics andread during the measurement. For this purpose the xele[]array of type extele is used. Type extele mainly consistsof a string and a float variable: in the string the ODCS
writes the name of the item whose values is needed (e.g. aquadrupolecurrent:
TTF.MAGNETS/DOUBLET/F2EXP1/PS.RBV)
whilethe TTF host continuously check this list and update thevalues of listed item in the correspondent float variable.
When the quadrupole’s current has to be changed, theprocedure running in the Console write a command into
the TTF host’s mailbox and waits for the reply message
that confirms the completion of the command.

3 PERFORMANCESThe present configuration of the ODCS still consists ofa Macintosh 7100/66 and a Macintosh 8100/110computers. The first one is the Main computer and hosts
the Image Grabber; the second is the Operator’s Console.
The Main can digitise and transfer to the VME half-size
images (384x256 pixels) at more than 1Hz; full-size
images are refreshed at 0.5÷1Hz. Execution of a commandtakes approximately, but usually less, than 1sec. This ismainly due to the time needed to execute the routine that
reads the images from the Image Grabber boards and theone that writes it to the VME. These routines, being
LabVIEW CINs, prevent LabVIEW and the MacOS to run
other tasks in parallel. At 1Hz beam repetition rate theMaintosh CPU is then “occupied” running these routines
for some hundred of milliseconds. Actually, the increaseof speed of commands execution is not a critical issue
since the typical command, i.e. the insertion/extraction ofa view screen in the beamline by means of a stepper
motor, needs some seconds to be completed from theactuator.

4 COMMENTS AND FUTURE
DEVELOPMENTS
Since 1997 ODCS is used daily from TTF operators tohelp the transport of the beam and for measurements. Newtools are continuously developed and controls for new
diagnostic devices are implemented as they are added. For
normal operation the diagnostic stations are usuallyoperated from a TTF Control System console via theinterface to ODCS while measurements are performed
using automated procedures on the ODCS console.
Because new and much faster computers are now
available, we planned to upgrade the two Macintosh. The
Main computer will be the one to be replaced first and wehave three open options:
1- a new MacG3 will be installed beside the actual
Main. The latter will continue to host and run the Image
Grabber while the new one will take care of thecommunications and commands execution;
2- the new MacG3 will completely replace the existingMain;
3- the new MacG3 will be used to host and run theImage Grabber and a new embedded VME Sparc computerrunning LabVIEW will be the new Main.
It is likely that the three options will be implemented
in the order as successive upgrade stages.
If option 3 will not be realised we planned to install“network mailboxes” to allow execution of commands
from a remote computer. These have been successfully
tested already with a TCP/IP server VI (based onLabVIEW TCP/IP tools) running in the Main computerthat receive commands from authorised hosts on thenetwork. Another TCP/IP server VI will interface theVME shared memory and will send data for remotedisplay.

We have also tested a LabVIEW http server that weplanned to install to distribute measurements and real-timedata to members of collaboration.

5 ACKONWLEGMENTS
I’m grateful to all the colleagues of INF-LNF inFrascati for their work developing part of the software forODCS. Many thanks also to the DESY colleagues andtheir continuos collaboration and support especially toK.Relich and O.Hensler that implemented the interface toTTF Controls.

REFERENCES[1] TESLA-Colaboration, “TESLA TEST FACILITY
LINAC - Design Report”, DESY-TESLA 95-01(1995)[2] K. Relich et.al., “DOOCS: an Object Oriented
Control System as the Integrating Part of the TTF
Linac”, Proceedings of ICALEPS97, Beijing China[3] L. Catani et.al., “Commissioning and Operation ofthe Control System of the LISA Superconducting
Linac”, ICALEPCS'93, Nucl. Instr. Meth. in Phys.
Res. A 352 (1994) 71-74