Using a Fiber Optic CAN Bus for the Proton Source Controlof the CERN PS-Linac
G. Gräwer, W. Heinze
CERN, PS Division
CH-1211 Geneva 23, Switzerland
Abstract
Following the recommendations for the use of fieldbuses at CERN, the CAN (Controller Area Network) bus
has been chosen to control and acquire the necessary
parameters of the proton source of the LINAC II. This
project represents two novel aspects, one on the hardwareand one on the software side: since the source is on ahigh electrical potential (92 kV), a fiber-optic interface
has been developed which permits communicationbetween the VME CAN bus controller and the CAN
equipment in the proton source over optic fibers.
Concerning the software, the CAN protocol had to beintegrated into the equipment access method used at thePS.

Five analog parameters have to be controlled:xxxxx

filament (cathode) heating current
hydrogen gas flow
main magnet current
expansion cup magnet current
voltage of pulse forming network (to create thedischarge of the Duoplasmatron).
Faraday cage

19' rack forelectronicsand control(on 92kV)

Solenoids

LinacIsolation

1 Introduction
Protons for the CERN accelerators are produced by aDuoplasmatron source [1]. The protons are injected into
the LINAC2 where they are accelerated to 50 MeV. Fig.
1 shows the mechanical set-up of the proton source.
The task was to connect the proton source to the VME
based control system of the PS [2]. In the previoussystem, the control electronics was housed in a CAMAC
crate and the communication was done over an optical
CAMAC Serial Highway. This worked fine, however, theCAMAC modules had become obsolete and one wantedto reduce the amount of space taken by the crate. So, inthe frame of the renewal of the PS control system, Serial
CAMAC had to be replaced by one of the 3 field buses
recommended at CERN, Profibus, Worldfip or CAN bus.
The CAN bus [3] was chosen because of its simplicity,robustness, cost-effectiveness, and because it seemed
well adapted for this local and relatively simple controlproblem.

ProtonsourceIsolationtransformer

Isolation

Fig. 1: Proton source for the PS
These five parameters are measured and have to beacquired by the control system. In addition, 2 moreanalog values (the polarisation cup voltage and a second
measurement of the arc current), as well as 15 status bits
have to be acquired.
Furthermore, 2 timing pulses are needed: one controls
the pulsing of the source (the timing of the measurements
is also derived from this pulse), the other one the lengthof the proton burst (“tail clipper”).

2 Stating the problem
3 Hardware solution
Two 19 inch racks on isolating columns are provided tohouse the electronics. The racks are on a potential of
92 kV, the same voltage as the proton source. Theelectronics is powered by 220 V delivered by an isolatingtransformer (Fig. 1).

Three pieces of equipment had to be selected:xxx

the CAN controller in the VME crate
the CAN node with the necessary I/ O facilities forthe proton source
the fiber-optic interface to the CAN bus

3.1 CAN Controller

mechanical condition. This system uses a simple parallelbus on the backplane of the chassis to connect the I/O
modules to a CAN CPU (Fig. 2). A drawback of the IND
I/O S system is that it does not provide the possibility tosynchronize acquisition to an externally given timing.
This is essential for a pulsed device like the protonsource. None of the two possibilities to relate ameasurement to an external timing is provided, neither
triggering a CAN message from the node nor accepting a
Remote Transmission Request. Instead, an acquisition
message is sent to the controller if, and only if, an inputchanges.
A solution is to change the data artificially for all input
modules at the moment of the measurement, without
affecting the real data. For the digital input this is simple:
one spare bit is toggled at every acquisition timing pulse.
For the analog input modules, the digital output (after theADC) is held at a fixed value except for a window of afew ms which allows the ADC output to settle for thecorrect value which in turn causes the sending of the data(of course, the real data must always be different fromthat fixed value!). A small timing module (Fig.2)
generates the window and delivers the necessary signals
to the input modules.

We did not find fiber-optic CAN buses commerciallyavailable, so the necessary interface had to be developedat CERN. This lead to the selection of VMOD-ICAN2 [4]as CAN controller because a MODULbus carrier boardcould be used to accommodate both the CAN controller
and the conversion electronics.
3.2 CAN Node
A condition for the CAN node in the proton source wasto be physically pluggable into a crate to be housed in the19 inch rack provided for the control electronics. For easeof maintenance, the modules had to be exchangeable
separately.
The input-output characteristics (control andacquisition of voltages, acquisition of status bits) areuniversal that virtually all CAN providers have thesemodules in their product range. However, most of thecommercially available industrial I/O modules areclipped onto a TS35 mounting rail and thus less suited forour application. Finally, we selected the IND I/O S series
from Weidmueller [5], which permits installation of themodules into an Euro-chassis, thus fulfilling theoptical C A Nlink C P UEurochassis

timingpulse
timingmodulepower
supplies

I/O modules

CAN node
opticfibers

electrical
CAN busCPU

VMOD-ICAN2
opticallink

VME crate
VMOD CarrierboardFig. 2: CAN Net for PS proton source3.3 Fiber-optic CAN Interface
The CAN node being on 92 kV, a transmission of theCAN messages via optic fibers is mandatory. Two fiberoptic interfaces are necessary: electrically they are thesame, but mechanically they are in the form of aMODULbus mezzanine board for the VME CANcontroller, and in the form of an Euro-module for theCAN node. The circuit schematics is shown in Fig. 3.

worst case is shown in Fig. 4: both nodes transmit thesame data bits. The signal from node 2 arrives at node 1
slightly before node 1 starts to transmit, but just too late
for node 1 to detect that the bus is already busy. In themeasurement shown in Fig. 4, DATA1 and DATA2
correspond to the signals the nodes want to transmit, andCAN1 and CAN2 are the signals measured after theelectrical transceivers of the nodes (Fig. 3). Positivesignals correspond to dominant bus levels. The
measurement was done at a bit rate of 1Mbit/s with an
optic fiber length of 20m.

2 fibre optic cables 20m

DELAY

CAN
node
1

CAN1

DATA1

DELAY

CANnode2

CAN2

DATA2

Fig. 4: CAN signals using fiber-optic transmission
The pulses and glitches which appear at the nodes donot cause any harm ifxx

Fig. 3: Fiber-optic CAN interface
Whereas one copper cable can transmit signals in both
directions, one needs two optic fibers, one for eachdirection. These paths have to be mutually exclusive
which is achieved by interlocking them: if one path isactivated (dominant level), the other one is automatically
blocked. Without this, the bus would latch-up at the first
dominant level because it would be transmitted backwithin two propagation times and hold the bus
indefinitely at dominant level.
If one node starts to transmit, the signal is transmitted
into one direction and arrives at the receiver after thepropagation delay. The other path is interlocked by theNOR gate (Fig. 3) which assures that the data is correctly
received.
If two nodes start to transmit at the same time or withina time interval of less than the propagation delay, thedirection of the signal flow (corresponding to which nodehas higher priority) may change within one bit time. This
causes variations in the pulse length and glitches. The

the data is correct around the internal bit sampling
point,
edges do not cause a faulty resynchronization of thebit sampling.

Both conditions are fulfilled: the sampling point isaround the last third of the bit time where the signals areclean, and the edges of the pulses of CAN2 do not cause aresynchronization because the value after the edge is notdifferent from the value at the previous sampling point.
4 Software
For the proton source control, there are only 2 different
kind of messages:xx

the control messages, generated cyclically by theVME CAN controller, which in turn is controlled by
the VME CPU,
the acquisition messages, triggered by an acquisition
timing pulse and generated in the CAN node (therecan be more than one message per cycle for the samedata).

These messages have to be treated by our generalcontrol system which works as follows: at every machine
cycle, a real-time program in the VME CPU reads all
acquisition messages from the CAN link and puts theminto predefined data columns. For acquisition, a real-time
program has to select the correct messages (it has to sortout the messages with fixed values generated at the endof an acquisition window). Then it writes the control
values via the CAN link into the CAN node. The control
values have before been put into corresponding control
data columns by an Equipment Module (EM) call [6].
The EM asynchronously writes control data into datacolumns and reads acquisition data from data columns. It
thus represents the link to standard application programs
which do the man-machine interface.
The application programs correspond to level 7 of theISO communication model. The consequence is that there
is no advantage in using higher level CAN protocols, e.g.
DeviceNet (Allen Bradley), SDS (Honeywell) or CAL(CIA), because they do not adhere to the standards in ourapplication programs. The CAL (CAN ApplicationLayer) was considered but would have introduced anothersoftware layer without giving much benefit, also because
all functions serving to reconfigure CAN nets arecompletely unnecessary in our case.
5 Conclusions
CAN permits data control and acquisition at moderatecost: it is the least expensive of the three field buses
recommended at CERN. The proton source control costs
about a quarter of the equivalent solution with CAMAC.
However, the commercially available CAN nodes (CANprocessors and I/O modules) are not well suited forprocesses needing synchronization with external events.
It is expected that this situation will improve with thearrival of new products, because CAN naturally offers thepossibility to synchronize processes. The fiber-optic CAN
interface developed at CERN permits us to extend therange of applications into areas which are electricallyheavily disturbed or whose nodes are on different
electrical potentials like in our case.
6 References[1] M. Hone, “The Duoplasmatron ion source for the newCERN Linac preinjector”, CERN int. note
PS/LR/Note 79-37 (1979).
[2] F. Perriollat, C. Serre, “The new CERN PS control
system overview and status”, Proceedings of
ICALEPCS, Berlin, Germany, Oct. 18-23, 1993,
p.86-90.
[3] CAN specification V2.0 part A & B, Robert BoschGmbH 1991.
[4] VMOD-ICAN2, JANZ Computer AG, Paderborn,
Germany.
[5] IND I/O S Modules, Weidmüller, Paderborn,
Germany.
[6] C.-H. Sicard, J. Cuperus, “Control module handbook”, CERN int. note PS/CO/Note 95-01, 1995.