EPICS (Experimental Physics and

Industrial Control System) - ”Driver”

for Kenwood power supplys
Sebastian Matkovich
September 22, 2013

1
EPICS - ”Driver”

2 of 23
EPICS - ”Driver”

Abstract
Until now the Kenwood Power Supply for semiconductor detectors was con-
trolled through an application in C, through the terminal. EPICS was the choice,
to make more than one controllable at a time. That didn’t work out of the box so
I had to write a ”driver”, or in EPICS terminology, device support.

3 of 23
EPICS - ”Driver”

4 of 23
EPICS - ”Driver” Contents

Contents

introduction 6
0.1 physical background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
0.2 GPIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

EPICS 12

environment setup 15

device support 21

5 of 23
EPICS - ”Driver” introduction

introduction
0.1 physical background
link to table of contents
What can be measured with semiconductor particle detectors is the energy the particle
loses during interaction with the detector, resulting a voltage proportional to its mass
and velocity. There are multiple forms of interactions a particle can have and also
some other effects on their way through the detector that make them lose energy. Main
interactions and effects are:
• collision

• bremsstrahlung
An electromagnetic radiation which gets emitted every time the particle is accel-
erated, for instance when getting distracted in an electric field or when its path
describes a curve like it does in a circular accelerator.

• cerenkov radiation
An electromagnetic radiation in visible spectrum (blue), which gets emitted when
the velocity of the particle is higher than the phase velocity of light for the fraction
index in the medium where the particle is. It is something like the vapor cone,
just for electromagnetic waves instead of sound waves.

• transition radiation
An electromagnetic radiation emitted when a particle gets from a medium to an-
other medium with a different dielectric constant.

• photoelectric effect
The arriving photon gives his energy to an electron, which has now enough energy
to escape the atom.

γ + atom → e− + ion

• compton scattering
This photon has more energy than the photon from the photoelectric effect and
has enough energy so the electron in the atom cannot absorb it.

γ + atom → γ + e− + ion

• pair production
The photon has even more energy than the photon from compton scattering and
produces an electron and an anti-electron. This could also happen with an electron,
not just an atom.

6 of 23
EPICS - ”Driver” 0.1 physical background

γ + atom → γ + e− + e+ + atom; γ + e− → γ + e− + e+ + e−

These effects are used to measure particles and those effects which come along
with measuring, like bremsstrahlung, also have to be considered in order to get
right results.

The detectors could be described as diodes with voltage in reverse direction, so that the
depletion zone reaches from end to end from the diode. When a particle arrives it gives
energy to an electron, which has now enough energy to get from the valence band into
the conduction band. This way an electron - hole pair emerges which travels to the edge
of the diode where the voltage is applied. This results a change in voltage which could
be measured.

Figure 1: principle of a semiconductor particle detector [5]

What we want to know is how much voltage we need for such a detector. First we
need the charge density ρ(x). We assume that the number of acceptors and donors is
homogeneous through the detector.

−eNA f or − dp < x < 0

ρ(x) = +eND f or 0 > x > dn (1)

0 elsewhere


e ... elementary charge

NA ... number of acceptors per cubic meter
ND ... number of donors per cubic meter
dp , dn ... depletion depths
With Gauss’s law we get

7 of 23
EPICS - ”Driver” 0.1 physical background


 − eN A
0
(x + dp ) f or − dp < x < 0
dΦ 
eND
E= = 
(x − dn ) f or 0 > x > −dn (2)
dx   0
0 elsewhere
E ... electric field
0 ... electric constant
Φ ... electric flux
r ... relative dielectric constant
and


0 f or x < −dp
 eNA (x + d )2

f or − dp < x < 0
p
Φ(x) = 20 eN
(3)


 ∆Φ0 − 20 (x − dn )2
D
f or 0 > x > −dn

∆Φ0 f or x > dn [6]
dΦ
V =
dt
V ... voltage
The voltage needed, so that the depletion zone can reach the end of the detector can
then be approximately determined through:
e
VF D ≈ |Nef f |d2 [5] (4)
20 r
VF D ... full depletion voltage
Nef f ... effective doping density
d ... thickness of the depleted region

8 of 23
EPICS - ”Driver” 0.1 physical background

Figure 2: needed voltage depending on thickness of the depletion zone and specific re-
sistance [5]

9 of 23
EPICS - ”Driver” 0.2 GPIB

0.2 GPIB
link to table of contents

Figure 3: GPIB cable [3]

GPIB stands for General Purpose Instrumentation Bus or General Purpose Interface
Bus. It is an 8-bit bus, originally developed by Hewlett Packard, which connects one or
more devices to a network and with a computer. Both ends of a cable have female and
male ends so that someone can simply attach two or more cables, with the advantage
that you don’t need any parts in between in order to form a network. That way you can
connect up to 15 devices, due to physical specifications, although 30 addresses could be
assigned. Since HP created this bus it got standardized under IEEE-488.1 and IEEE-
488.2. The bandwidth is about 1MB/s and the 16 signal lines in the cable are grouped
into three clusters, according to their functions.
That are the pinouts for GPIB:

Pin Name Description Source

1 DIO1 Data Bit 1 Talker
2 DIO2 Data Bit 2 Talker
3 DIO3 Data Bit 3 Talker
4 DIO4 Data Bit 4 Talker
5 EOI End Or Identity Talker/Controller
6 DAV Data Valid Controller
7 NRFD Not Ready For Data Listener
8 NDAC No Data Accepted Listener
9 IFC Interface Clear Controller
10 SRQ Service Request Talker

10 of 23
EPICS - ”Driver” 0.2 GPIB

11 ATN Attention Controller

12 Shield -
13 DIO5 Data Bit 5 Talker
14 DIO6 Data Bit 6 Talker
15 DIO7 Data Bit 7 Talker
16 DIO8 Data Bit 8 Talker
17 REN Remote Enabled Controller
18 Ground DAV -
19 Ground NRFD -
20 Ground NDAC -
21 Ground IFC -
22 Ground SRQ -
23 Ground ATN -
24 Logical Ground -

[2]
Pins from 1 to 12 are on the wider side of the connector, pins from 13 to 24 are on
the narrower side of the connector.
There are two mainly used drivers, one from National Instruments and the other one is
an open source linux driver called linux-gpib. Both deliver abilities to control or diagnose
a device through a terminal or a gui. Following commands need to be understood from
every device:

Figure 4: GPIB IEEE-488.2 commands [1]

11 of 23
EPICS - ”Driver” EPICS

EPICS
link to table of contents
What is EPICS? Epics stands for Experimental Physics and Industrial Control Sys-
tem. It is something like a framework or a collection of applications written in different
languages. There are many parts, of which it consists. There is a database with func-
tions, which also stores the last result of these functions. These functions could be
queries for values or commands with parameters. In EPICS these functions are called
records and depending on the type of their value or parameter they have different names.
There are analog output, string output and binary output (and input respectively) for
instance. In these record databases first the type of the record is declared and then
the name we want to give the record to recognize it later. The type is declared with
a shortcut, for analog input we write ai, for binary output we write bo and for string
input (or output) we write stringin (or stringout). Here an example of ”getID.db” for
getting the device identification string.

record(stringin, s_i_kenwood_10_getID)
{
field(DTYP, "stream")
field(INP, "@getID.proto s_i_kenwood_10_getID violet 10")
field(PINI, "YES")
}

As we can see at stringin, this is a string input record and we called it

s i kenwood 10 getID. Records are also called Process Variables (PV’s). These records
have multiple so called fields, these are their content. There are various types of fields,
which define settings on the record or actually do, or do a part of the job, the records
have. The most important fields are DTYP, which stands for devicetype and is further
explained in section device support. Then there are input fields (INP) and output fields
(OUT) for actually recieving a value or sending a command. PINI is a field, if it is set to
yes, it lets the record be processed, when it is initialized. That means when the record
database is loaded this record will then be processed. With the SCAN field you define
when to process (or scan) a record (in EPICS scanning means processing). It already
has a default value and is set to PASSIVE, which means only when we write to it (we
can even do that to input records and also use it at the GUI to invoke scanning of the
values), it will be scanned. With FLNK fields you can link to another record, which
also should be scanned, if the record with the FLNK field is scanned. For instance in
enable.db the s o kenwood 10 (...) enable records have a link to their corresponding
records in ”status.db”. Here it is done as such:

(...)
field(FLNK, "s_i_kenwood_10_status_ch01")
(...)

12 of 23
EPICS - ”Driver” EPICS

In EPICS there are so called Channel Access Servers, these are applications which
read out the databases and handles the requests for records to be scanned (from Channel
Access Clients, which I will describe later) and forwards the responses to Channel Access
Clients. These clients could be the GUI or a terminal. This is the Channel Access Server
startup script ”st.cmd” created by a tool (MakeBaseApp.pl), which comes with epics,
modified for the kenwood power supply environment.

#!../../bin/linux-x86_64/PSupply
epicsEnvSet("STREAM_PROTOCOL_PATH",
"/home/testbeam/top_powerSupply/protocols")
## You may have to change PSupply to something else
## everywhere it appears in this file

< envPaths

cd ${TOP}

## Register all support components

dbLoadDatabase "dbd/PSupply.dbd"
PSupply_registerRecordDeviceDriver pdbbase

GpibBoardDriverConfig("violet",1,0,3,0)
asynSetTraceIOMask(GPIB0,10,0x0005)
asynSetTraceMask (GPIB0,10,0x001f)
var streamDebug 1

dbLoadRecords("db/vmeas.db","user=rootHost")
(...)
cd ${TOP}/iocBoot/${IOC}
iocInit

## Start any sequence programs

#seq sncxxx,"user=rootHost"

In the following I will describe which things I changed, compared to the default file.
GpibBoardDriverConfig(”violet”,1,0,3,0) is needed for setting up the communication.
The first argument is the port used in gpib.conf, in this case ”violet”. The second
argument sets autoconnect to 1. The third argument associates the port violet with its
bus, in this case 0 (/dev/gpib0). The fourth argument is one of the linux-gpib timeout
codes, in this case 3 seconds.

13 of 23
EPICS - ”Driver” EPICS

The according section in gpib.conf (/etc/gpib.conf):

interface {
minor = 0 /* board index, minor = 0 uses /dev/gpib0,
minor = 1 uses /dev/gpib1, etc. */
board_type = "ni_pci" /* type of interface board
being used */
name = "violet" /* optional name, allows you
to get a board descriptor using ibfind() */
pad = 0 /* primary address of interface */
sad = 0 /* secondary address of interface */
timeout = T3s /* timeout for commands */

eos = 0x0a /* EOS Byte, 0xa is newline and 0xd is

carriage return */
(...)
/* pci_bus and pci_slot can be used to distinguish two pci boards
supported by the same driver */
/* pci_bus = 0 */
/* pci_slot = 7 */

master = yes /* interface board is system controller */

}

asynSetTraceIOMask(GPIB0,10,0x0005)
asynSetTraceMask (GPIB0,10,0x001f)
var streamDebug 1 - this group of commands is used for debugging and to see what
commands are send, respectively received, at a time. dbLoadRecords(”db/>record
name<.db”,”user=rootHost”) loads all the record databases mentioned. Now the Chan-
nel Access Clients come into play. As mentioned these could be a terminal, or our GUI.
Since there is no multicast support right now it is recommended to fire up the caRe-
peater in between by typing caRepeater in the terminal in order to assure that Process
Variables get forwarded to the terminal or our GUI. Now we can control the Process
Variables. caget <PV name> gives the current value of the Process Variable, caput
<PV name> <value> changes the value and cainfo <PV name> displays information
about the Process Variable.

14 of 23
EPICS - ”Driver” environment setup

environment setup
link to table of contents
EPICS base version 3.14.12.3 installation In the following, commands marked with #
are those given as the root, $ stays for a user of the group (EPICS) ”developers”.
1. Create a sub-directory in /opt for EPICS (#)

mkdir opt
cd /opt
mkdir epics

2. Change the group ownership of /opt/epics to ”developers” (#)

chgrp developers /opt/epics

3. Download the file baseR3.14.12.tar.gz from the website http://www.aps.anl.gov/epics/download/

base/baseR3.14.12.tar.gz to /opt/epics
4. Uncompress the archive file baseR3.14.12.3.tar.gz (#)

cd /opt/epics
wget http://www.aps.anl.gov/epics/download/
base/baseR3.14.12.3.tar.gz
tar -zxvf baseR3.14.12.3.tar.gz

5. Change the group ownership of everything in /opt/epics to ”developers” (#)

chgrp -R developers /opt/epics

6. Run the script called EpicsHostArch.pl to make sure of your architecture ($)

/opt/epics/base-3.14.12/startup/EpicsHostArch.pl
linux-x86_64

this is the architecture we used.

7. Write the following two lines into the profile file /etc/profile to setup the needed
environmental variables for EPICS (#)

vi /etc/profile
EPICS_HOST_ARCH="linux-x86_64"
export EPICS_HOST_ARCH

15 of 23
EPICS - ”Driver” environment setup

8. Apply changes in the profile and check ($)

source /etc/profile
env

9. Build EPICS Base ($)

cd /opt/epics/base-3.14.12.3
make clean uninstall
make

10. The Channel Access (CA) protocol needs the ports 5064 and 5065 to be open for
both TCP and UDP, so we configure the firewall as follows (#)

iptables -I INPUT -p tcp --dport 5064 -j ACCEPT

iptables -I INPUT -p udp --dport 5064 -j ACCEPT
iptables -I INPUT -p tcp --dport 5065 -j ACCEPT
iptables -I INPUT -p udp --dport 5065 -j ACCEPT
5064 tcp (CA server)
5064 udp (CA server)
5065 tcp (repeater CA beacons)
5065 udp (repeater CA beacons)

11. You need to setup some additional environmental variables for an IOC to be
running (#):

vi /etc/profile
EPICS_BASE=/opt/epics/base-3.14.12.3
#(location of EPICS Base)
export EPICS_BASE
PATH=$PATH:/opt/epics/base-3.14.12.3/bin/linux-x86_64
#(location of EPICS Base binaries)
EPICS_CA_AUTO_ADDR_LIST=NO
#(do not look for IP addresses of all connected
#CA servers automatically)
export EPICS_CA_AUTO_ADDR_LIST
EPICS_CA_ADDR_LIST="localhost"
#(list of all IP’s in the CA;
#the list is - of course - according to your system environment)
export EPICS_CA_ADDR_LIST

12. Again, apply changes in the profile and check ($)

16 of 23
EPICS - ”Driver” environment setup

source /etc/profile
env

13. Now we need ASYN (asynchronous) device support, which forwards the com-
mands, understood by the device, to the GPIB driver. Make a subdirectory called
deviceSupport in /opt/epics ($)

cd /opt/epics
mkdir deviceSupport

14. Download the file asyn4-21.tar.gz into /opt/epics/deviceSupport from website

http://www.aps.anl.gov/epics/modules/soft/asyn/ and extract it ($)

wget http://www.aps.anl.gov/epics/download/modules/asyn4-21.tar.gz
tar -zxvf asyn4-21.tar.gz

15. Apply changes in the file /opt/epics/deviceSupport/asyn4-21/config/RELEASE

($)

vi /opt/epics/deviceSupport/asyn4-21/config/RELEASE
eliminate (comment) the following lines:
(old:) IPAC = /corvette/...
(new:) --> #IPAC = /corvette/...
(old:) SNCSEQ = /corvette/...
(new:) --> #SNCSEQ = /corvette/...
change the location of EPICS Base:
(old:) EPICS_BASE = /opt/epics/base
(new:) --> EPICS_BASE = /opt/epics/base-3.14.12.3
enable GPIB support:
(old:) LINUX_GPIB=NO
(new:) --> LINUX_GPIB=YES
optionally you add gpib_DIR=/usr/local/lib under #RELEASE
Location of external products, if it isn’t already there

16. make ASYN ($)

cd /opt/epics/deviceSupport/asyn4-21
make

17 of 23
EPICS - ”Driver” environment setup

17. Now we need StreamDevice. StreamDevice is a device support for EPICS I/O
records. It makes the data transfer simple between an I/O EPICS record and a connected
device, which listens to string commands. It is the StreamDevice’s responsibility to
envelope the value (VAL) of an output EPICS record into a string, which is a command
for the connected device and to send the command to the device using the ASYN device
support described in the previous section. On the other hand, it is also the responsibility
of StreamDevice to put queries to the device, to unfold the strings as answers of the
device and to write the contained value (VAL) into an input EPICS record. The format
of queries and answers in the device communication are device specific and have to be
implemented in protocol files. Lets see how to install the StreamDevice for an EPICS
database to communicate with our Kenwood power supply. First of all you need an
EPICS IOC as an EPICS application in your home directory ($):

#go to the user’s home directory:

cd /home/user/
#make a directory for your IOC
mkdir top_powerSupply
#go into this directory
cd top_powerSupply
#create the application directories for PSupply
makeBaseApp.pl -t ioc PSupply
#create the boot directories for your IOC
makeBaseApp.pl -i -t ioc PSupplyIOC
Application name? PSupply (That is the application that
the IOC boots at startup.)

18. You may start with the settings specific and needed for the power supply commu-
nication. First make ASYN available for our application ($):

#edit into the file /home/user/top_powerSupply/configure/RELEASE

vi /home/user/top_powerSupply/configure/RELEASE
#add the following line to the file:
ASYN=/opt/epics/deviceSupport/asyn4-21/

19. Install StreamDevice ($):

#download the file StreamDevice-2-6.tgz from the homepage

#http://epics.web.psi.ch/software/streamdevice/
#into the application’s home directory:
cd /home/user/top_powerSupply
wget http://epics.web.psi.ch/software/streamdevice/
StreamDevice-2-6.tgz
#uncompress the archive file

18 of 23
EPICS - ”Driver” environment setup

tar -zxvf StreamDevice-2-6.tgz

#make StreamDevice
cd StreamDevice-2-6
make

What happened? A database definition file called stream.dbd has appeared in the di-
rectory /home/user/top powerSupply/dbd/. This file contains definitions for the stream
device, so that ”stream” is now a possible option for the field DTYP in any conventional
I/O record types, if the stream.dbd has been included into your application dbd file.)
Before starting to realize your application database you are supposed to have a database
definition file (.dbd) in the /home/user/top powerSupply/dbd/ directory which contains
definitions for all records, devices and functions the database is built of. This dbd file is
normally created at make time, i.e. when you give the make command in the application
home directory (/home/user/top powerSupply/), but its content is subject to some set-
tings in the directory /home/user/top powerSupply/PSupplyApp/src/. At least one dbd
file must be present at make time in /home/user/top powerSupply/PSupplyApp/src/,
for instance psupp.dbd, and, accordingly, the following line has to be inserted into the
Makefile in the same directory ($):

vi /home/user/top_powerSupply/PSupplyApp/src/Makefile
...
PSupply_DBD += psupp.dbd
...

And insert the following lines into the same Makefile ($):

vi /home/user/top_powerSupply/PSupplyApp/src/Makefile
PROD_LIBS += stream
PROD_LIBS += asyn

20. To use StreamDevice in your database, the psupp.dbd has to contain at least the
following lines ($):

vi /home/user/top_powerSupply/PSupplyApp/src/psupp.dbd
...
include "base.dbd" #This line includes definitions on
all conventional EPICS Base records like ai, ao, calc, ...
include "stream.dbd" #This line includes the device
definitions for StreamDevice and adds the "stream" option to
the DTYP fields in any I/O records
include "asyn.dbd" #This line and the two followings
loads the definitions for ASYN which is used by StreamDevice
registrar(drvAsynIPPortRegisterCommands)

19 of 23
EPICS - ”Driver” environment setup

registrar(drvAsynSerialPortRegisterCommands)
...

21. Lets go now to the application home directory and make the application ($):

cd /home/user/top_powerSupply/
make

That’s it. The PSupp.dbd file has been created in /home/user/top powerSupply/dbd/
and you now have an installed framework for creating an EPICS database using StreamDe-
vice.
22. This power supply listens to string commands sent through GPIB. First of all
you need the protocol files, which initialize the serial communication and envelope the
analog (float) value of the ao record into a string command the device understands. Here
you put the protocol files ($):

mkdir protocols
cd protocols

23. Next you need the databases, you put them here ($):

cd ..
mkdir db #if it isn’t already there
cd db

24. Now we need to load these files in st.cmd. Put the st.cmde here ($):

cd ../iocBoot/iocPSupply/

20 of 23
EPICS - ”Driver” device support

device support
link to table of contents
For device support there is something like a library for EPICS called StreamDevice. It
reads out ”protocol files” with corresponding commands to records and make it possible
to communicate with devices, like the power supply, which are controlled by string
commands. In the example of ”getID.db” I referred do stream as a devicetype. Through
setting the devicetype to stream we can let Streamdevice do the work for EPICS and
refer to the protocol files in INP and OUT fields. The corresponding protocol file to
”getID.db” looks like this (”getID.proto”):

ExtraInput = Ignore;
MaxInput = 71;
LockTimeout = 15000;
WriteTimeout = 300;
ReplyTimeout = 3000;

s_i_kenwood_10_getID
{
out "*IDN?";
in "%71c";

@mismatch
{
wait 1000;
out "*IDN?";
in "%71c";
}

@writetimeout
{
wait 1000;
out "*IDN?";
in "%71c";
}

@replytimeout
{
wait 1000;
out "*IDN?";
in "%71c";
}

@readtimeout

21 of 23
EPICS - ”Driver” device support

{
wait 1000;
out "*IDN?";
in "%71c";
}
}

At the top we have a few options. With MaxInput = 71; we tell StreamDevice that
the string is 71 bytes long and since the power supply doesn’t send any terminator to tell
us when to close the connection, this way we can determine when to close it. The next
three lines define the timeouts. (also described here http://epics.web.psi.ch/software/
streamdevice/doc/protocol.html) LockTimeout tells StreamDevice how long to wait to
get access to the power supply while other records are communicating with the pow-
ersupply until it gives a timeout. WriteTimout defines the time we give StreamDevice
to speak to the device, when there is a connection. ReplyTimeout tells StreamDevice
how long to wait for an answer when there is a connection. These three values are in
milliseconds and are three times the default values. out and in are used like printf and
scanf, for sending and receiving commands the power supply understands.
There are commands for setting values on the device like :CURR <current in ampere>,
:VOLT <volatge in volt>, for setting limits there are corresponding commands, like for
instance :CURR:PROT <current in ampere>and for reading these values out with an
added question mark like this: :CURR:PROT?. For measuring you add :MEAS before
the phrase, like :MEAS:CURR?. The power supply has multiple channels. Before you
send one of these commands you send the command :CHAN<channel number>and then
you can ”talk” to this channel. To actually switch a channel on or off you send :OUTP
<OFF/ON>.
Here at the identification string EPICS wants to know how long it is and we tell it to
expect a 71 characters long message. @mismatch, @writetimeout, @replytimeout and
@readtimeout are exception handlers and tell Streamdevice what to do when something
else is sent than expected, or one of the timeouts occurred. readtimeout occurs when
the power supply started sending, but we only received a part of the message size we
expect. Here it should wait one second and try doing the same thing again. Exception
handlers are processed once and call no other exception handler.

22 of 23
EPICS - ”Driver” References

References
[1] http://www.ni.com/white-paper/3388/de

[2] http://old.pinouts.ru/ParallelPorts/ieee488 pinout.shtml

[3] http://www.l-com.com/content/Article.aspx?Type=L&ID=203

[4] http://www.lnl.infn.it/˜epics/WikiDumps/localhost/
howto setup an epics development linux box based on centos 5.html

[5] http://www.hephy.at/project/halbleiter/VOSkriptum/VO-4-
Halbleiterdetektoren.pdf, Detektoren in der Hochenergiephysik Univ.Doz.DI.Dr.
Manfred Krammer Institut für Hochenergiephysik der ÖAW, Wien

[6] http://www.hep.man.ac.uk/theses/MikeJonesMSc.pdf

23 of 23