SLAC CPE Software Engineering Group
	EPICS IOC Development IOC Development in the new UDE*	SLAC Detailed SLAC Computing Software Home Software Detailed

This page is a "how-to" for common steps in the development and testing of iocs for CPE.

Useful Links :
How to add a vxWorks IOC to the SLAC network
IOCConsole
Soft IOC development at SLAC
SLAC EPICS IOC List
Terminal servers
Epics Site Packages
VMIVME Support at SLAC
List of ESD EPICS IOCs

Related utilities and software :

Alarm Heartbeat Monitor

Contents :
Modifying IOC Files - the short version (common daily operations)
IOC UDE Background - this starts the long version (start here if you need more background..)
IOC Source Dir Structure
IOC Distribution Dir Structure
IOC Boot Source/Distribution Dir Structure
IOC Boot Links Directory Structure (thanks Judy!)
Common Mount Points
Creating an IOC Test Setup
--Build your IOC application
--Testing from your personal sandbox area
Testing from the reference area on afs
Releasing ioc software to production

IOC Development in the new UDE*
* UDE = Unix Development Environment

Modifying IOC files: the short version

Basic instructions for modifying and releasing stuff in the new IOC UDE using packApp as an example, for the files most commonly modified in the course of operation.  This walks through the simplest case (i.e. what we mostly do at this point).  For more details on the CVS directory structure, and branching when files differ by EPICS version, please see the POD.

1. Check relevant directory out of CVS into your work area

databases or templates:
cvs checkout ioc/packApp/Db

source code:

cvs checkout ioc/packApp/src/<<src directory, e.g. seq, db, vmivme3122 >>

startup files:
cvs checkout epics/iocBoot/startup

creating a new application

in the work area create an application directory (xyzApp), and subdirectories, with appropriate Makefiles at each level.

2. Modify/add files

In your work area, modify the files of choice.

If you add a file, add a line to the corresponding Makefile.Host or Makefile.Vx.

If you're adding a database template, a new sequence or a new library, you'll need to add a line to the relevant IOC startup file to load the new thing.

3. gmake in your work area, for database or source changes

In your working directory, gmake.  If you have checked out ioc/commonApp:

cvs checkout ioc/commonApp

cd ~work/ioc
ln -s $CD_REF/epics/R3.13.x/ioc/config config

databases or templates:

~/work/ioc/db

binaries:

~/work/ioc/bin/ <<arch>> (e.g., ~work/ioc/bin/mv2700)

4. Test

databases or templates:

To test your template modification/new template + your db, you can run dbLoadTemplate in the Db directory in your area. Since in the templates the database files are in a db directory relative in current directory, you'll have to create a link so that dbLoadTemplate can find the files. So in the database directory, do
ln -s . db

Then you can do:
dbLoadTemplate template-name.template > records.lst

records.lst will contain the instantiated database records (have a look). If there are template errors, they will show up on the screen. So, if records.lst is created with no screen output, your template is syntactically fine. (no guarantees on function at this point)

For more complicated database changes, test by booting into a test IOC with links that point into the distribution directories in your area.  See later section for how to set this up.

binaries:

You'll need to boot a test IOC with links that point into the distribution directories in your area.  See later section for how to set this up.  This will only verify that the object file loads, and the sequence starts up.  Full functional verification will depend on the production hardware and network being present (i.e. on a production IOC)

startup files:

You'll need to boot a test IOC with links that point into the distribution directories in your area.  See later section for how to set this up.  This will only verify that the startup script runs.  Full functional verification will depend on the production hardware and network being present (i.e. on a production IOC)

5. cvs import and checkout, cvs add, cvs commit
For an existing application:

1.  cvs add new files.  (don't forget to update Makefiles too!!!)

2.  cvs commit all changes (db, template, Makefile.Host, Makefile.Vx, source code, startup file, whatever has changed)

If this is a new application (xyzApp):

1.  import it into CVS.

In your working directory (the one containing xyzApp) do:

   cvs import -m "comment" ioc CD_SOFT Repics version  

(epics version is 3_14_6, or 3_13, or whatever is appropriate)

2. now checkout the new app in the relevant reference area:

   cd $CD_REF/epics/R3.13.2 or R3.13.6 or R3.14.6

   cvs checkout ioc/xyzApp

   cvs release ioc/xyzApp

The new application will now be maintained by cvs in this directory(ies).

6. gmake in the reference directory
Once you've cvs commit-ed, go to the reference directory:

database files:

$CD_REF/epics/R3.13.x/ioc/packApp/Db

source code:

$CD_REF/epics/R3.13.x/ioc/packApp/src/<<src directory>>

and do a gmake where the changed file sits to move database files or compile source files into the reference area distribution directories.  (again, startup files are not gmake-d)

database files:

$CD_REF/epics/R3.13.x/ioc/db

binaries:

$CD_REF/epics/R3.13.x/bin/<<arch>>

These distribution directories contain databases and binaries for all IOCs.

7. scp changed files over to GTW00
From the distribution directories in the reference area:

database files:

$CD_REF/epics/R3.13.x/ioc/db

binaries:

$CD_REF/epics/R3.13.x/bin/<<arch>>

startup files:

$CD_REF/epics/iocBoot/startup

scp your files over to corresponding directories on GTW00:

database files:

$CD_IOC/R3.13.x/db

binaries:
$CD_IOC/R3.13.x/bin/<<arch>>

startup files:

$CD_IOC/boot/startup

example:

log into GTW00 as user cddev

cd $CD_IOC/R3.13.2/db
scp "<<username>>@slcsun1:/afs/slac.stanford.edu/g/cd/soft/ref/epics/R3.13.2/ioc/db/tr08_modu.template" .

8. Reboot the IOC

Production Directories on GTW00

Source code reference directories in AFS

IOC UDE Background - this starts the long version!
CVS
Source code in support of EPICS IOC applications can be found under $CD_REF/epics (specifically $CD_REF/epics/R3.13.X/ioc/ and $CD_REF/epics/iocBoot - on CVSWEB , look under ioc and epics, respectively). The IOC structure (under CVSWEB ioc and epics) is treated differently from other applications in cvs because EPICS provides its own "EPICS Build Facility" - refer to chapter of same name in EPICS IOC Application Developer's Guide. ESD maintains different EPICS versions of files through use of branch tags (ie BR3_13_2 for the R3.13.2 version), however, most of our files are version independent and don't require tags. Refer to the POD, "CVS for IOC Software" chapter. There is one cvs repository directory and separate (R3.13.1, R3.13.2, and R3.13.6) reference directories, one for each EPICS version supported at SLAC. It is assumed that R3.13.6 is the default, main trunk, and environment varibles that help the user reference this code are established for R3.13.6 in setEnv.csh (see below); the thinking being that most code doesn't vary between versions. The escalation /delivery support for EPICS is handled differently than the rest of the application code in ESD (there is no tst, dev, new, prod escalation nor delivery to production). Currently the updating of production areas is done manually via ftp,scp, etc. (More detail on that below)
(Note: cvs repository and reference directories are only maintained on afs. Whenever $CD_REF is written in this document, it pertains only to afs.)

IOC Source directory structure

Each <top> area is a separately managed set of application files and has its own release of software obtained from outside the application, e.g. a release of EPICS base. The ioc directory ($CD_REF/epics/R3.13.X/ioc, or <top>), is subdivided into xxxApp directories which contain source code for dbs, dbds, templates, sequences, subroutines, device/driver/record support etc., for their respective applications. It has the following generic structure:
<top>/ (one or many according to subsystems; site dep.)
config/ (source) contains files for make
xxxApp/ (many) (source)
     src/ (source) contains subroutines,
     Db/ (source) contains *.db, *.template
     seq/ (source) contains *.st, .h
     yyy/ - driver/device/record support (source) for module yyy
commonApp shared code common to all applications
...

IOC Distribution directory structure

When an application is built (via gmake, not gmaketst, dev, new), files are installed in the following distribution structure under <top>:
<top>/
bin/ (distribution)
    <host_arch>
    <target_arch(s)>
include/ (distribution)
db/ (distribution)
dbd/ (distribution)

Building an application is dependent on the EPICS version. The environment variable EPICS_VER must be set to the proper version. When sourcing ENVS.csh, setEnv.csh sets it to the default of R3.13.6 if previously undefined; this version can be overwritten in your .cshrc or .login if other than this default is desired. (ie setenv EPICS_VER R3.13.2 ). Also, the config dir must contain or symlink to the config correct EPICS version.

IOC Boot directory Source and Distribution structure

The (afs) epics/iocBoot directory ($CD_REF/epics/iocBoot) ($CD_IOC/boot/ on nfs) is EPICS version-independent and is subdivided into the startup and app/xxx directories, each of which contains .cmd files used during ioc boot.
iocBoot/ (one for all ioc applications)
    app/xxx (many; ea xxx ioc has an area here) (source and distribution)
    startup (source and distribution ) - contains an st.<ioc microname>.cmd for each ioc in xxxApp*

* The st.<ioc microname>.cmd file which is executed after vxWorks is started on an IOC (the vxWorks boot parameters have the full path to this file as the startup script). The st.<ioc>.cmd file loads various files which were built in the xxxApp source directories and installed in the bin/<arch> or other installation directories, then starts the IOC software.

The epics/iocBoot area is an ESD anomoly, in that it serves as a) cvs repository, b) reference area and c) ioc "delivery" area. Another directory in this "anomoly" category is the $CD_REF/epics/iocBoot/network directory, which contains common command files executed under vxWorks for customization of user setups, networks, mount points, etc.

Boot Links Directory Structure

There is a unix boot links area, under $CD_IOC which contain boot links for each ioc ($CD_IOC/<ioc nodename>) that are used by vxWorks when booting an ioc. The script makeIocBootLinks helps to establish boot links for an ioc. Example boot links in $CD_IOC/cdvw6 after invoking makeIocBootLinks for it:
base -> ../R3.13.2
bin -> ./base/bin/mv2700
cd -> ../..
cmd -> ../boot/app/pack
dat -> /nfs/slac/g/cd/ioc/CD06
db -> ./base/db
dbd -> ./base/dbd
startupE -> st.cdvw6.cmd
startupNE -> ../boot/network/netInit.lavc.cmd
userSetup.cmd -> ../boot/network/userSetup.dev.cmd
vxWorks -> ./bin/vxWorks
vxWorks.sym -> ./bin/vxWorks.sym

As you can see, these boot links point to the IOC boot distribution directories in <top> ($CD_REF/epics/R3.13.X/ioc/ area) as well as directly to the $CD_REF/epics/iocBoot/<app/xxx, startup, and network> reference directories. The st.<ioc microname>.cmd file , with the boot link "startupE" is executed after vxWorks is started on an IOC (the vxWorks boot parameters have the full path to startupE as the startup script) and initiates getting all code loaded and started. Below (thanks Judy!), is a "map" of most of the boot files involved:

Definitions:

BootLinks =   $CD_IOC/<<iocname>>

 

BootRoot =

Prod:    $CD_IOC/boot/

AFS:    $CD_REF/epics/iocBoot

 

AppRoot =

Prod:   $CD_IOC/R3.13.2

AFS distribution:   $CD_REF/epics/R3.13.2/ioc

Reference directory:  $CD_REF/epics/iocApp/ioc/<<appname>>App

 

Files:

**files in bold are symbolic links defined in the BootLinks directory

**not in order of execution

startupE = BootRoot/startup/st.tr07.cmd

 

BootRoot/network/netInit.cmd

userSetup.cmd = BootRoot/network/userSetup.leb.cmd

BootRoot/network/userNfs.cmd

      

startupNE = BootRoot/network/netInit.<<network>>.cmd

BootRoot/network/userLogin.cmd

BootRoot/network/netInit.<<network>>-lan.cmd

BootRoot/network/resource.<<network>>.def

 

BootRoot/network/userPrompt.cmd   

BootRoot/app/common/epicsInit.cmd

BootRoot/app/common/epicsCode.cmd

BootRoot/app/pack/userNfs.cmd

(BootRoot/app/pack/userInit.cmd – fold this into startupE – one less file!)

 

Load databases (from db = AppRoot/db, dbd = AppRoot/dbd)

Load libraries and dot-o's (from bin = AppRoot/bin)

Do module initializations

Start sequences (from bin = AppRoot/bin)

Common Mount Points

VxWorks establishes mount points for common directories that it references during boot (refer to $CD_REF/epics/iocBoot/network/userNfs.cmd). This "maps" an afs/nfs directory to a dir that can be used by vxWorks. Common mount points include:

vxWorks	afs	nfs
/boot	$CD_REF/epics/iocBoot	$CD_SOFT/ioc/boot
/cmd	$CD_REF/epics/iocBoot/app/pack	$CD_SOFT/ioc/boot/app/pack
/common	$CD_REF/epics/iocBoot/app/common	$CD_SOFT/ioc/boot/app/common
/bin	$CD_REF/ioc/<iocname>/bin	$CD_SOFT/ioc/<iocname>/bin
/db../dbd	$CD_REF/ioc/<iocname>/db../dbd	$CD_SOFT/ioc/<iocname>/db.../dbd

Developers may setup mount points to their personal directories for use with testing from their sandbox. This is done in the $CD_REF/epics/iocBoot/network/users.cmd file. (see Testing from your personal sandbox)

Creating an Ioc Test Setup

How do you test an ioc? The following will hopefully help you set up your environment, build your ioc, setup your sandbox, test from your sandbox, test from the common afs reference space, and finally install in production.

1) Setup the proper EPICS build environment
a) Source the proper EPICS build environment - refer to:
lhttp://www.slac.stanford.edu/grp/cd/soft/share/slaconly/how-to/epicsSetup.html
For testing from your afs sandbox, source /afs/slac/g/pepii/ctrl/prod/bin/solaris/epicsSetupDev (after sourcing ENVS.csh).
If you want a different EPICS version than the default of R3.13.6, then, in your .cshrc or .login file:
# set epics version to 3.13.2 so ENVS will set all epics env vars to 3.13.2
echo SETTING EPICS_VER TO R3.13.2
setenv EPICS_VER R3.13.2
source $CD_SOFT/dev/script/ENVS.csh
source /afs/slac/g/pepii/ctrl/prod/bin/solaris/epicsSetupDev
Building for EPICS on unix relies on the unix host environment variable HOST_ARCH in R3.13.X, and EPICS_HOST_ARCH in R3.14.X. All other variables are defined in the config files located in <top>/config. In the <top>/config/RELEASE file, EPICS_VER and EPICS_BASE are set, so it is important to symlink to the correct <top>/config; (either $CD_REF/epics/R3.13.6/ioc/config or $CD_REF/epics/R3.13.2/ioc/config) before you build, as explained below.
More useful EPICS variables:
$EPICS = /afs/slac/package/epics/R3.13.X
$EPICS_SITE = /afs/slac.stanford.edu/package/epics/vers3/R3.13.X/site

a) Useful reference directory environment vars:
Environment variables declared in $CD_REF/common/setup/setEnv.csh are established for users to easily view files in the reference directory. These variables point to the main cvs branch of the R3.13.6 version of the code, since most code is EPICS version independent.
$CD_BASE = $CD_IOC_EPICS=$CD_REF/epics/R3.13.6/ioc = points to the TOP of the local EPICS ioc app dir structure.
$CD_IOC_BOOT = $CD_IOC/boot = $CD_REF/epics/iocBoot because boot is a symlink to ../ref/epics/iocBoot (the boot -> ../ref/epics/iocBoot symlink is defined in $CD_IOC)
$CD_BOOT_APP = ${CD_IOC}/boot/app = $CD_REF/epics/iocBoot/app = contains app. specific dirs for loading and starting code in an ioc.
$CD_BOOT_ST = ${CD_IOC}/boot/startup = $CD_REF/epics/iocBoot/startup = contains ioc startup scripts loaded during boot
$CD_IOC = $CD_SOFT/ioc = boot links area for iocs (prod and dev)
"old area" environment vars:
$TARF = afs/slac.stanford.edu/g/nlcdev/tarf/ctrl/R3.13.2 = "old" area for nlcta source
$PACK = /afs/slac.stanford.edu/g/nlcdev/pack/ctrl/R3.13.2 = "old" area for 8-pack source
$PEPII = /afs/slac.stanford.edu/g/pepii/ctrl/R3.13.2 = "old" area for pepii

2) Setup Sandbox; cvs checkout
a) Create a sandbox. For the purpose of this document, the sandbox is under ~.
cd
mkdir sandbox
b) CVS checkout of xxxApp application dir
Checkout the current source code from cvs from the appropriate ioc/xxxApp area into sandbox; for example, for packApp:
cd ~/sandbox
cvs checkout ioc/packApp

If you cd to ioc/packApp and ls, you see that you will have the Db and src directories. Each of these contain makefiles, plus:
The Db dir contains your database (.db) files and template (.template) files. Any .db or .template filename that is unique to a particular ioc should be prefixed with the 4 digit alphanumeric ioc name (ie cd06_asens.template). Any .db file created with gdct can be converted to gdct by first invoking it with gdct and then "save as vdct". (The vdct file should have a .db extension in the end.) Your .template file establishes appropriate pattern replacements for each .db file that it loads.
The src directory may contain several sub-directories, which may contain the following:
src/db: "c" source code for subroutines, other; includes xxxLIBOBJS (all objects to be added to library for an app), xxxInclude.dbd (all .dbds, or database definitions for an app).
src/seq: sequence source code; includes .st sequence files; prefixed with 4 digit alphanum ioc name.
src/xxx: driver, device, and record support for an xxx module; includes .c, .h, and .dbd files (as well as an xxxInclude.dbd file which includes all of the other .dbd files in that dir as well as base.dbd).

c) Check out of boot dirs:
cd ~/sandbox
cvs checkout epics/iocBoot/app/pack
cvs checkout epics/iocBoot/startup
Above are the two directories that can change alot; you don't have to check out epics/iocBoot/network since those files can be referenced in the common afs space and do not change very often. Now, in ~/sandbox/epics/iocBoot/app/pack, you will have userInit.*.cmd files (loaded prior to iocInit), amongst others. In ~/sandbox/epics/iocBoot/startup, you will have your "st.<4-digit microname>.cmd" startup files. Refer to Boot Links Dir Structure for details.

d) Check out the common code that every app requires to run:
cvs checkout ioc/commonApp
Since all binaries are distributed under /bin, you must check this common code out and build it in order for its binaries to be found in the /bin of your sandbox.
e) Setup ioc/config dir for gmake rules
You can setup a symlink:
cd ioc
ln -s $CD_BASE/config config, which is the same as:
ln -s $CD_REF/epics/R3.13.6/ioc/config
or, for R3.13.2:
ln -s $CD_REF/epics/R3.13.2/ioc/config config
or, you can checkout the dir:
cvs checkout ioc/config
f) gmake the common code:
gmake ioc/commonApp
After this first gmake, you'll notice that, under the ioc dir, that you have the following installation, or distribution dirs:
ioc/bin, ioc/ include, ioc/db, ioc/dbd, ioc/javalib.
g) ! NOTE for cmlog: Do not build cmlog in your sandbox. Instead, copy the cmlog binaries from $CD_REF/epics/R3.13.2/ioc/bin/mv2700 :
cd ~/sandbox/ioc/bin/mv2700
cp $CD_REF/epics/R3.13.2/ioc/bin/mv2700/cmlogClientD .
cp $CD_REF/epics/R3.13.2/ioc/bin/mv2700/cmlogVxLogMsg .
or,
setup a symlink in your bin dir for cmlogClientD -> $CD_REF/epics/Re.13.2/ioc/bin/mv2700/cmlogClientD
cmlogVxLogMsg -> $CD_REF/epics/Re.13.2/ioc/bin/mv2700/cmlogVxLogMsg

3) Build your ioc application
Make any necessary changes/additions to xxxApp and
a) gmake in xxxApp dir
Remember to edit databases from the ~/sandbox/ioc/xxxApp/src/Db area, then gmake to install them to the ~/sandbox/ioc/db dir (it's easy to mistakenly edit a file from the ..ioc/db area, then gmake and overwrite). Modify source in the appropriate ~/sandbox/ioc/xxxApp/src/yyy dir, and gmake to install the objects and libraries into ~/sandbox/ioc/bin/<arch>; (and to install the .h files into ~/sandbox/ioc/include, and to install the .dbds into ~/sandbox/ioc/dbd.)

Viewing contents of an object library
The "nmppc" unix utility can help you determine the contents of your new object library. For example,
nmppc $CD_IOC/cdvw6/bin/packLib > temp
View the output file to see what the library contains.
Prior to this, for R3.13.6,
source /afs/slac/package/vxworks/devel/tor-2.0.2/cd/ENVS.csh
For R3.13.2,
source /afs/slac/package/vxworks/devel/tor-1.0.1/cd/ENVS.csh

Testing your template
In your ioc/db dir, you may invoke the Unix command "dbLoadTemplate(xyz.template) > temp" in order to expand your .db files with their appropriate pattern replacements to check their integrity prior to actually loading in an ioc. Make the following link such that the file paths in your template are setup:
ln -s . db

4) Testing from your personal sandbox (equivalent to the "tst" area of gmaketst)

ESD boots ioc's using the links in $CD_IOC/<ioc nodename>. In order to test the code from your personal sandbox, these links have to be changed to point to your sandbox rather than to the installation directories in $CD_BASE. This is the reason for the epics/iocBoot/network/users.cmd file, so that an application developer will have an NFS mount point to their personal area. Note: For new developers, modify file epics/iocBoot/network/users.cmd to add your user directory to be an NFS file system mount point for vxWorks.

a) Find an unused test closet ioc with the appropriate architecture by asking around. Save this ioc's current boot links structure in $CD_IOC/<ioc nodename> under another name so that you don't get yelled at. For example:
mv cdvw6 cdvw6_deb
b) makeIocBootLinks
Setup test closet ioc boot area directory structure. Each ioc is setup to boot from its corresponding directory in $CD_IOC/<ioc nodename>. For example, CD06 (which is cdvw6's 4-digit microname) boots from $CD_IOC/cdvw6. Use makeIocBootLinks utility to make the correct symbolic links; the utility will ask a series of questions and set up symbolic links in $CD_IOC/<ioc nodename> (=$CD_IOC/cdvw6, below).
drogind@flora01 $ makeIocBootLinks
Enter ioc nodename: cdvw6
Enter 4-char microname: CD06
Supported cpu's are mv167,mv177,niCpu030,mv2700,mv2400
Enter cpu [mv167]: mv2700
Available subnets are lavc,cad,pub2,nlcdev,leb,pepii,bbr
Enter subnet [lavc]: lavc
Do you want to load EPICS [y/n]: y
Supported EPICS applications are bic,gpib,lum,rf,tarf,pack,vib
Enter EPICS application name [common]: pack
Enter startup file [../boot/startup/st.bl37.cmd]: st.tr06.cmd
Enter EPICS release [R3.13.6]: (Note: as of current writing, pack executes under R3.13.2; bic under R3.13.6)

The above session set up the following boot links in /afs/slac.stanford.edu/g/cd/soft/ioc/cdvw6 ($CD_IOC/cdvw6):
drogind@flora01 $ pwd
/afs/slac.stanford.edu/g/cd/soft/ioc/cdvw6
drogind@flora01 $ ls
base -> ../R3.13.2
bin -> ./base/bin/mv2700
cd -> ../..
cmd -> ../boot/app/pack
dat -> /nfs/slac/g/cd/ioc/CD06
db -> ./base/db
dbd -> ./base/dbd
startupE -> st.cdvw6.cmd
startupNE -> ../boot/network/netInit.lavc.cmd
userSetup.cmd -> ../boot/network/userSetup.dev.cmd
vxWorks -> ./bin/vxWorks
vxWorks.sym -> ./bin/vxWorks.sym

c )Modify the symbolic links to point to your sandbox
Modify the bin, cmd, db, dbd, and startupE symbolic links in $CD_IOC/cdvw6. You can save the existing ones to *_old for later use if you like. (Also change the vxWorks symlinks, as noted below.)
mv bin bin_old
ln -s ~/sandbox/ioc/bin/mv2700 bin
mv cmd cmd_old
ln -s ~/sandbox/epics/iocBoot/app/pack cmd
mv db db_old
ln -s ~/sandbox/ioc/db db
mv dbd dbd_old
ln -s ~/sandbox/ioc/dbd dbd
mv startupE startupE_old
ln -s ~/sandbox/epics/iocBoot/startup/st.<4-digit microname>.cmd startupE

Note:
The vxWorks and vxWorks.sym files installed in bin as a result of the gmake do not work properly. So, point to vxWorks as built in the afs reference area:
mv vxWorks vxWorks_old
ln -s ./base/bin/mv2700/vxWorks vxWorks
mv vxWorks.sym vxWorks.sym_old
ln -s ./base/bin/mv2700/vxWorks.sym vxWorks.sym

d) Install a test ioc startup file
The startup file is located in ~/sandbox/epics/iocBoot/startup. For example,
drogind@flora01 $ cd ~/sandbox/epics/iocBoot/startup
drogind@flora01 $ cat st.cdvw6.cmd
#==============================================================
# Name: st.cdvw6.cmd (For Development System)
#==============================================================
#
# First, set up the network and some file systems
< cd/ioc/boot/network/netInit.cmd > /null
< /cmd/userNfs.cmd > /null
# Create environment variables
putenv("RESTORE_VXI = /sav/savedata")
putenv("RESTORE_INP = /sav/savedataInputs")
putenv("RESTORE_ALARM = /sav/savedataALARM")
putenv("VXSTATS_MACROS=STN=cd06,INPA=0,INPG=0")
putenv("SAVEDATA = /dat/save_restore/savedata")
# Load general EPICS and User routines
< /common/epicsCode.cmd
< /cmd/userCode.cmd
# Load databases
dbLoadDatabase("/dbd/packApp.dbd")
dbLoadTemplate("/db/cd06_asens.template")
dbLoadRecords("/db/VXStats.db", getenv("VXSTATS_MACROS"))
# Initialize User application and start EPICS
< /cmd/userInit.cd06.cmd
< /common/epicsInit.cmd
# Start asens_proc sequence; delay so that messages are not garbled
taskDelay(300)
# Sequence startup must be started after epics!
seq &cd06_asens_rms_proc

First each ioc has to load everything it needs from your sandbox installation dirs. For example, you will want to load your library (ie packLib), initHooks, and sequences from your bin dir. In the above example, this loading of application specific objects is done in /cmd/userCode.cmd (/cmd points to epics/iocBoot/app/pack/userCode.cmd). An example userCode.cmd file:
#==============================================================
# Name: userCode.cmd
# ==============================================================
# Load base EPICS Application software
ld < /bin/packLib
ld < /bin/initHooks

# load EPICS Application sequences
ld < /bin/cd06_asens_rms.o

Once code is loaded into an ioc, then the application has to be started. For example, in epics/iocBoot/app/pack/userInit.cd06.cmd:

drogind@flora01 $ cat userInit.cd06.cmd
#==============================================================
# Name: userInit.cd06.cmd
# Rem: This script is use to start EPICS application software that has already
# been loaded (ie: userCode.cmd). This script MUST be started prior to executing
# iocInit, which is in epicsCode.cmd
#==============================================================
# Initilize Asens Digitizer Module 0 (tr06 will have modules 1-14)
asens_init(0,0x00000000)

e) Connect to your ioc
Use iocConsole.pl <4-digit microname> to connect to your test ioc.
Refer to SLAC ESD iocConsole access for more details on using iocConsole and configuring for a new ioc.

f) Boot the ioc
Useful target (ioc) commands
cdvw6 -> Type Ctrl-x to reboot the ioc.
cdvw6 -> Type dbl to view a list of PVs
cdvw6 -> Type dbpr "PV name", # , where # = level, to get db printout
cdvw6 -> Type dbpf "PV name", # , where # = level, to get db printout
cdvw6 -> Type dbior for a device report
cdvw6 -> Type seqShow (paste task id) , seqChanShow <task id> to look at channels in sequence

g) Debug startup script, if necessary
Note any errors reported from the iocConsole. To pinpoint which file is causing errors, comment out most of the files in st.<ioc>.cmd, and then load each one in succession at the ioc prompt. Sometimes it is not obvious which file is causing errors due to the nature of the console output.

Testing from the reference area on afs
(equivalent to the "dev" area of gmakedev)

1)Check-in your added and modified files into cvs.
a) Check-in all changes from your sandbox area according to POD, "CVS for IOC Software" chapter.
From your sandbox, to add a new file, in general, do a:
cvs add filename
cvs commit -m "initial checkin" filename
Note: the post commit script currently does not checkout the newly added file in order to update the reference directory. Check by ls'ing the reference directory to see if it has been added. If not, do this manually, for example:
cd /afs/slac.stanford.edu/g/cd/soft/ref/epics/R3.13.6/ioc/packcd App/Db
ls -t filename.db
cvs update filename.db
You may have to repeat this for each version of EPICS.

b) gmake in reference directory
Once all of your tested changes are in cvs, cd to the appropriate afs reference directory and gmake:
cd $CD_REF/epics/R3.13.2/ioc/packApp
gmake

c) Change $CD_IOC/<ioc nodename> boot links to point to reference dirs.
makeIocBootLinks
or,
mv bin bin_sandbox
mv bin_old bin
mv cmd cmd_sandbox
mv cmd_old cmd
mv db db_sandbox
mv db_old db
mv dbd dbd_sandbox
mv dbd_old dbd
mv startupE startupE_sandbox
mv startupE_old startupE

d) Boot and test ioc.

Releasing software to production

See "How to Distribute EPICS IOC Software Using iocDist".

Programmers' Guides, Users' Guides, Requirements, Design, Papers, Administration, How-To, Hardware, IOC, Database

Author: Debbie Rogind, 17-June-2004 ; Judy Rock
Modified by Bob Hall, 13-August-2004 Minor corrections.
Modified by Mike Laznovsky, 15-December-2005 -- added link to "iocDist"
Modified by Judy Rock, 1-February-2006 -- added "useful links" section

Modified by Judy Rock, 7-March-2006 -- added "related utilities and software" section

Modified by Judy Rock, 23-March-2006 -- added section describing cvs-ing a new application