The Use of PCs in Controlling DESY Accelerators
Philip Duval
DESY MKI Hamburg

Abstract
PCs now play a dominant role in the control of theHERA, PETRA and DORIS machines at DESY. Initially(1992), the control system employed made use of MSDOS Front ends and MS-WINDOWS Consoles. Today,
the HERA control system supports a number of platforms,
the preferred configuration using LINUX Front ends andWindows NT Consoles. A handful of front ends are not
PCs at all, however, necessitating an interface between
the PC and the non-INTEL world. This has been by andlarge unproblematic, and over the years the PC itself has
proven to be a surprisingly robust and versatile element in
the control system. Nevertheless, one must contend withfrequently changing tools and components, both hardware
and software, in an area where the ″State-of-the-Art″
looks different every six months. We report here on theexperiences at DESY concerning the PC as a systemchoice.
1 Introduction
The Intel-based PC has been integrated into a numberof modern control systems. Recent workshops at PCaPAC[1] (DESY) and ESONE [2] (CERN) have in fact focusedentirely on PCs. At DESY HERA, PCs have beenemployed in machine control since the 1992 run. Now,
five years later, virtually all HERA consoles are PCs as
are more than three quarters of the HERA front ends.
Recently, the smaller PETRA and DORIS machines havebeen converted to all PC control. At the TESLA Test
Facility (TTF), PCs are also being employed, albeit on amuch smaller scale (but also using much different control
systems). Throughout this span of time and range ofmachines, a wide spectrum of Operating systems and PChardware has been/is being used.
2 The operating system
The operating systems employed on PCs used inaccelerator control at
DESY encompass MS-DOS,
Windows 3.X, Windows 95, Windows NT, Linux,,
VxWorks, and NetWare. For the sake of simplicity weshall not be concerned here with version information.
That is, Windows NT will be referred to as Win NT (andnot 3.51 or 4.0) and Linux is Linux regardless of whether
it is the Slackware distribution with kernel 2.0.7 or theSuSE distribution with kernel 1.2.12). OS 2 was briefly
tested in 1993, and although found to be (at the time) oneof the best operating systems for the PC, it was later
dismissed as a dead-end.

Tables I - IV will help to illustrate the distribution ofOSes on PCs at DESY. The primary control system for
the HERA machine is TINE (Three-fold Integrated
Networking Environment) which has been described
elsewhere as MCS1 [3]. TINE is PC-biased, but as can beseen from the Table I below includes many non-PC
components. Subsystems controlled by other control
systems include Cryogenics (soon to be EPICS), Powerand Cooling (EPICS), and Proton Vacuum (a DOOCS[4]predecessor). Of these, PCs are used in the Power andCooling subsystem and are included in Table I.
Also shown in Table I are the IP and IPX stacks usedfor each platform (note that TINE supports IPX whereavailable). Of particular interest are the last two columns.
By ″software reboot events″, we refer to workstation
conditions arising from commercial software (be it theoperating system, device drivers, or other third-partypackages) which require a reboot for recovery.
The
distinction here is between problems of my own making(which I can find and correct) versus those of the software
components I′m dependent upon.
The two events
concerning the Win NT consoles were due to PCI busmastering problems for the 3COM ethernet card then inuse. This problem was acknowledged by 3COM, thework-around being to turn the bus-mastering off. From1992 to 1996, Win16 consoles were in common use in thecontrol room, and suffered such reboot events at the rateof approximately one per console per month. This waslargely due to the nature of the Win16 operating system,
where starting and stopping applications over a long
period of time can sometimes leave resources (such asGDI handles) in a fragmented state (or not cleaned up atall!). The only other OS to have entries in this column isNetware, which is an unprotected operating system. Bothevents reported in this column occurred in 1996 and wereunexplained. However, since applying the most recent
patch level, no further events have been seen.
As to hardware faults, all of the entries shown refer todisk problems, with the exception of the Win NT
consoles. In this latter case the cooling fans had ceased tofunction. Following this discovery, the cooling fans on all
the consoles were replaced with higher quality fansequipped with an audible alarm in case of malfunction.
Note that under MS-DOS, the disks are not used at all,unless the front end program explicitly uses file IO. This
explains the astonishing stability of the DOS platformshown above.
The primary control system used in PETRA andDORIS is MCS2 (Machine Control System-2)[5] and isbased exclusively on PCs using the IPX protocol. As canbe seen in Tables II and III, the software and hardware

Table I: PCs in HERA
Control System: TINEOSTYPEIP Stack

IPX Stack

No.
Units

Win NT
Win16DOS
Win16Linux
Win NT
Win 95
Non-PC
NetwareConsoleConsoleFront End
Front End
Front End
Front End
Front End
Front End
File Server

WINSOCKWINSOCK (LWP)
LWP
WINSOCK (LWP)
BSD
WINSOCKWINSOCK
BSD
NovellWINSOCKNOVELLNOVELLNOVELLBSD
WINSOCKWINSOCK
Novell2064020321172SW
events’97)
2
Many0000002

Reboot(‘92-HW faults(‘92-97)200
100011

Control System: EPICS
VxWorks

Front End

BSD (WindRiver)-300

Table II: PCs in PETRA
Control System: MCS2OSTYPEIP Stack

IPX Stack

No. Units

Win16
Win16DOS
NetwareConsoleFront End
Front End
File Server-NOVELLNOVELLNOVELLNOVELL

72841SW Reboot events (‘96’97)
Many002

HW faults (‘96-97)
1001

Table III: PCs in DORIS
Control System: MCS2OS

TYPE

IP Stack

IPX Stack

No. Units

Win16
Win16
DOS
NetwareConsoleFront End
Front End
File Server-NOVELLNOVELLNOVELLNOVELL

72031SW
Reboot(1997)
Several000events

HW faults (‘9697)
0000

Table IV: PCs in TTF
Control System: DOOCSOSTYPEIP Stack

IPX Stack

No. UnitsLinuxLinuxConsole
Front End

BSDBSD-1
3events parallel what has been observed in HERA.
In the TESLA Test Facility (TTF), the principal control
systems are DOOCS and EPICS. Presently EPICS PCs
are not being used at TTF. DOOCS was originallydesigned to run on SUN workstations, but has been ported
to Linux, and in the case of TTF, four such machines havebeen in use over the past two years, all without incident,
as noted in Table IV.
3 Development environment
Beginning with Turbo C from Borland in the late

SW Reboot events (‘96‘97)
00

HW‘97)
00faults(‘96-1980s, the user-friendly, intuitive integrated development
environment (IDE) has been the forte of the PC. In the16-bit world of DOS and Win16, the C and C++
compilers of both Borland and Microsoft are in common
use, almost always in the context of their IDEs as opposedto the command line. In the 32-bit world of Win NT andWin 95, the Visual C++ compiler of Microsoft is used
exclusively. Under Linux, the Gnu compilers arefrequently used at the command line. However the ″X
Windows Programming Environment,″ xwpe [6], IDE isalso used by those developers who want the feel ofBorland 3.1 on Linux. Indeed, it is hoped that thetransition from DOS front ends to Linux for front end
developers can be made palatable through this tool.
Much of the high level (GUI) development on theconsoles (and sometimes on the front end) is done using
Visual Basic. As is known to most users of Visual Basic,programming at this level can be very simple, i.e. merely
putting together components in a meaningful manner.With
Visual Basic 5, the programmer can create a nativecompiled executable, rather than the interpreted″executable″ of versions past. This means that theprogrammer could in principle write long algorithms in
Visual Basic without concern that they might be too CPUintensive. Nonetheless this practice is still discouraged,
i.e. writing code to do say matrix inversion is better left toC or C++ and called from a Dynamic Link Library (DLL).
Visual Basic has proven to be an invaluable tool for ″parttime programmers″ such as machine physicists andengineers.
At HERA, Linux is used only in the capacity of TINE
Front ends and as such does not require GUI development
tools. At TTF, Linux is used both at the front end and theconsole end, and in the latter case the DOOCS Display
Data (DDD)[7] graphics display package is used.
The possibilities of JAVA are also being investigated atDESY. Almost all development work in JAVA has so far
occurred on Win32 platforms, using either Visual J++ or
Symantec Café, both of which appear to be viable
development tools.
4 PCs and Real-TimeFor most aspects of accelerator control in HERA,PETRA, DORIS and the TTF, real-time is not an issue.
Where it is an issue, ″traditional″ solutions involving(Motorola) VME CPUs running a real-time OS such as
VxWorks are typically used. Recently, VxWorks has
been deployed directly on industrial PCs in the context ofPower and Cooling controls for HERA. This has so far(since July 1997) proven to be a stable platform.
Other real-time operating systems which apparently
work well on standard PCs (OS9, LinxOS) have not beentested at DESY, but were reported on at the recent
PCaPAC workshop[8], all with positive results.
The real-time add-ons to DOS, RTK [9] and RTX [10],have been tested at DESY. Both of these products were
found to be stable but could not guarantee hard real-time
when file IO was underway. In the case of the electron
RF, RTX was in fact used for several years, not because of
the need for real-time, but in order to provide a preemptive multi-tasking environment.
The real-time capabilities of Windows NT have notbeen investigated at DESY. At the recent ESONEworkshop, Win NT was reported to have no hard real-time
capabilities, but there were several third-party add-ons
which did.
Linux also offers a real-time kernel [11], but this has
not been tested at DESY.

5 Hardware/Software considerations
Putting together the finished PC Workstation from
hardware components has the distinct advantage that there
are generally many vendors vying for market share,
driving prices down and offering greater choice. The
disadvantage is that finding an acceptable combination of
say graphics cards, ethernet cards, mother boards thatworks well for the targeted operating system(s) can be a
research project in itself. Furthermore, PC distributors
sometimes skimp on ″non-specified″ components such as
cooling fans or power supplies, which can contribute tomaintenance problems if faulty. Nonetheless, after amodicum of experience, so-called ″noname″ PCs can beobtained with the same stability and longevity as theirmore expensive counterparts.
Linux on the Intel platform reaps the benefits ofhardware market for PCs as well. Consider that Xgraphics on a Linux station with an accelerated SVGA
card will generally have much greater performance thanon commercial UNIX workstations. In one benchmark
test Xfree86 on a 486DX2-66 PC with 20MB RAM plus
VLB s3-864 graphics card with 2MB DRAM was found tobe seven times faster than a Sparc IPX workstation[12].
IO cards in general tend to be much cheaper on the PC
than their equivalent VME counterparts, sometimes asmuch as a factor of 10. The bus architecture on the VME
crate is much more sophisticated than the ISA bus
common on PCs (and perhaps more so than the PCI bus aswell). However, this extra degree of sophistication has
turned out to be completely unnecessary in a large numberof cases concerning IO in the HERA, PETRA, and DORISsubsystems.
The PC market is such that PC components undergo
dramatic improvements every 12 to 18 months, often
giving the impression that one is constantly trying to stayup to date. There is in fact (justifiably) some concern
regarding ″platform stability″ over the longevity of anaccelerator. In other words, if I need replacement parts infive years, can I get them? For instance, the transition
from the ISA to the PCI bus has been underway for thepast three years or more and already it is difficult to find
ISA bus ethernet cards. In perhaps as little as two to threeyears, standard PCs may no longer offer ISA slots!
Generally we have to accept the fact that these transition
periods exists and take advantage of them to 1) stockpile
replacement parts (such as ISA ethernet cards) or 2)
upgrade the PC as a unit. What has also been true at
DESY is that as staff members ″rush to obtain the latest
Pentium-pro″, the pool of ″unwanted″ i486-vintage
equipment has continued to grow and to be absorbed intoeither the control system proper or the spare-parts
department. In general, the 5-year transition period whichappears to be accompanying the change in bus standard on
the PC (a major change) has not brought with it any undue
expenditure in either time, manpower, or equipment
regarding HERA controls operation.
Likewise, the software which one runs on the PCseems to undergo dramatic improvements at an evenhigher rate. Of course, ″Service Packs″ and ″Patches″ arenecessary for virtually every operating system.
InWindows systems, however, the concept of network
administration becomes very important, where say asystem of 20 consoles consists of 20 individual
workstations, as opposed to 20 X-terminals attached to ahigh-end central work station. The administrative effort
to guarantee that all stations are configured identicallyshould not be underestimated. To this end there arevarious tools on the market, including Microsoft’s own
Zero Administration for Windows (ZAW). At DESY theproduct NetInstall [13] is currently being tested in order tomeet these requirements.
6 Conclusion
The overall experience in using PCs in accelerator
control at DESY has been quite positive. In particular
Windows NT appears to be well suited as a control system
console. At the front end, PCs provide ample power andstability in many circumstances. Here, Linux would seemto be the favored operating system, since the hardware
requirements are not so extensive as in Windows NT, and
it is relatively easy to write device drivers for Linux.
Nonetheless, the availability of software development
tools under Windows NT (in particular Visual Basic)
makes front-end development for Windows NT attractive
as well. There are also several real-time operating
systems which run directly on a standard PC, but with theexception of VxWorks, these are not used on PCs atDESY.
PCs are by no means regarded as a panacea for all
front-end problems at DESY, and in several (missioncritical) cases are not used at all. Nevertheless, the casefor using PCs in some capacity in accelerator control is astrong one. There are now several examples of small andmedium scale accelerators being controlled exclusively byPCs.
References[1] ″PCs and Particle Acclerator Control (PCaPAC)″
workshop proceedings, DESY, 1996.
[2] ″European Studies on Norms for Electronics(ESONE)″ workshop, CERN, March 3, 1997.
[3] Duval ″Status of the HERA Control System,″IWCSMSA (CAT’96) proceedings, KEK, 1996.
[4] G.Grygiel,O.Hensler,K.Rehlich,″DOOCS:
ADistributed Object-Oriented Control System on PCs
and Workstations,″ PCaPAC proceedings 1996.
[5] Duval and R. Schmitz, ″Controlling DESY
Accelerators with PCs,″ PCaPAC proceedings, 1996.
[6] Kruse, ″X Window Programming Environment(xwpe),″ Version 1.4.2 Gnu General Public License.
[7] Rehlich, ″An Object-Oriented Data Display for theTesla Test Facility,″ these proceedings.
[8] Goetz et al. ″TACO: An object oriented controlsystem for PCs running Linux, Windows NT, OS9000 or LynxOS,″ PCaPAC proceedings, 1996.
[9] ″Real Time Kernel″, version 3.0, Copyright ©
1991,1992 On Time Informatik Gmbh.
[10] ″RTXDos″, Version 1.0, Technosoftware AG.
[11] Victor Yodaiken, ″The RT-Linux approach to hard
real-time,″ Department of Computer Science New
Mexico Institute of Technology Socorro, NM (Error!
Bookmark not defined.)[12] M.Walsh and L.Kaufman, ″Running Linux”,
O’Reilly & Associates, Inc. ISBN: 1-56592-151-8 .
[13] ″NetInstall,″
NetSupport,Gmbh(www.netinstall.de)