synApps is a collection of EPICS software intended to support most of the common requirements of an x-ray laboratory or synchrotron-radiation beamline. Because it is EPICS software, synApps is extensible by developers and end users, to support new devices and experimental techniques. This extensibility frees synApps to focus mostly on general-purpose capabilities and infrastructure, from which application-specific software can be built or assembled.
Thus, for example, synApps provides support for motors, scalers, and scans, but it does not tie those items together into an immediately executable scan (of specific motors, to acquire specific scaler channels, for a specific dwell time, etc.). The user does this at run time (or a knowledgeable user can provide a fully specified scan, and give the novice user a button to start it).
Similarly, synApps provides support for ADC's and PID loops, but somebody has to tell the PID software what feedback value to read, what conditioning function to run it through, what PID parameters to use, and what actuator to drive. By default, all of these choices can be made at top level, by the end user. Or, a knowledgeable user can provide a fully specified PID loop, and make it available to a novice user through a simplified or otherwise customized interface. The techniques and tools used to accomplish this are essentially the same as those a user would have applied at run time, so the packaged solution can be prototyped and tested at run time.
synApps is organized into modules, whose structure is based on the example
directory tree produced by the EPICS application, makeBaseApp.pl
,
typically with two additional directories: a documentation directory, and a
display-file directory. synApps modules typically contain source code, EPICS
databases and database-definition files, autosave-request files, client scripts,
display files, libraries and executables, and documentation.
Most synApps modules are intended primarily to export support to other modules. Some synApps modules produce bootable software, in addition to support software, but in most cases, this bootable software is primarily for testing, and for demonstrating how the support software can be used. The support exported by a module is of the following types, with example names and locations from the calc module:
One synApps module, the xxx module, is different: it doesn't export anything. It imports support from other modules, and produces bootable software to support an EPICS IOC. The xxx module is documentation in runnable form, and also a template from which a synApps application can be constructed. xxx is not comprehensive: it doesn't apply all of synApps; it's usually a little behind the rest of synApps; it focusses more on VME crates than on other kinds of IOCs; and it's a compromise between what is most widely used and what is most likely to build and run out of the box.
- database-definition file, in calc/dbd
calcSupport.dbd
...- link library, in calc/lib/<arch>
libcalc
- header files, in calc/include
transformRecord.h
...- database files, and associated autosave-request files, in calc/calcApp/Db
userTransforms10.db
userTransforms10_settings.req
...- display files, in calc/calcApp/op/adl, and calc/calcApp/op/opi
userTransforms10.adl
userTransforms10.opi
...
If you haven't run into the term 'IOC' yet, two things:EPICS Application Developer's Guide is an essential reference for anyone planning to develop or deploy EPICS software. While you won't need to read the guide to build or run synApps, you will need it to understand what you've done, to diagnose problems, and to extend synApps in any significant way.
- IOC stands for Input/Output Controller. Initially, this was a VME crate with a processor running EPICS under the VxWorks operating system, but beginning with EPICS 3.14, an EPICS IOC can also be a set of tasks on a workstation running Linux, Windows, Cygwin, Solaris, RTEMS, Mac OS, and, no doubt, other operating systems.
- The
Here's a list of the modules and directories in synApps:
Module/directory | description |
---|---|
areaDetector | Support for area (i.e., 2-D, or image) detectors, including CCDs, pixel array detectors, and online imaging plates. This module replaces the ccd and pilatus modules. |
autosave | Support for saving software parameters at run time, and restoring them during the next reboot. Autosave is also a way to initialize array PV's at boot time. |
busy | The busy record, which allows developers more ways to indicate when an operation is complete. Previously, this record was provided by the sscan module, because the sscan record is one of its beneficiaries. |
calc | Run-time expression evaluation, derived from the calcout record in EPICS base, and extended to operate on strings, arrays, and to implement coupled expressions. |
camac | Support for CAMAC hardware. |
configure | Build files |
dac128V | Support for an IndustryPack DAC module. |
delaygen | Support for delay generators, including the SRS DG645, Colby Instruments PDL100A, and Gigabaudics PADL3. |
documentation | Um... documentation |
dxp | Support for X-Ray Instrumentation Associates's DXP digital signal processor |
ebrick | Support and sample application for low-cost PC-104 and uCDIMM based IOC. |
ip | Support for various serial, and other message-based, devices. |
ip330 | Support for an IndustryPack ADC module |
ipUnidig | Support for an IndustryPack digital I/O module |
love | Support for Love controllers |
mca | Support for multichannel analyzers and multichannel scalers. |
measComp | Support for USB I/O modules from Measurement Computing |
modbus | Support for ModBus-protocol devices over TCP, serial RTU, and serial ASCII links |
motor | Support for motors |
optics | Support for optical tables, monochromators, slits, etc. |
quadEM | Support for an APS-developed 4-channel electrometer |
softGlue | Support for user-programmed "wiring" of custom FPGA content loaded into an Acromag IP-EP201 module. |
sscan | Support for scans (programmed control and data acquisition). |
std | Miscellaneous EPICS support, including the epid (extended PID), scaler, sseq (string sequence), and timestamp records; and pvHistory support. |
stream | Dirk Zimoch's streamDevice, in a module-flavored wrapper. |
utils | Miscellaneous tools, including support for converting an application from one version of synApps to another; support for the MDA file format, written by the sscan module; and support for EPICS-application prototyping. |
vac | Support for vacuum controllers |
vme | Support for VME hardware |
xxx | Sample user-application directory |
See support/configure/RELEASE for a complete set of compatible module versions. This release of synApps is compatible with EPICS release 3.14.12, Tornado 2.2, and the following EPICS modules, which are produced and maintained by other members of the EPICS collaboration. These modules are not part of synApps, but their maintainers have permitted us to distribute copies along with synApps:
Module | description |
---|---|
allenBradley | for communicating with Allen Bradley PLC's (ANL) |
ipac | required for IndustryPack support (ANL) |
asyn | required by many modules (ANL) |
seq | for SNL programs in synApps (BESSY) source: http://www-csr.bessy.de/control/SoftDist/sequencer |
stream | configurable device support for message-based devices (PSI) source: http://epics.web.psi.ch/software/streamdevice. |
vxStats | vxWorks statistics, modified by us (SNS) This module has been replaced by devIocStats, and will be removed from the next version of synApps. |
devIocStats | IOC statistics, replaces vxStats (SLAC) source: http://www.slac.stanford.edu/grp/cd/soft/epics/site/devIocStats/ |
Previous versions of synApps included and relied on the genSub, ccd, and pilatus modules. Beginning with EPICS 3.14.10, a replacement for the genSub record, called the aSub record, is included in base, and synApps has been modified to use it instead of the genSub record. The ccd and pilatus modules have been replaced by the areaDetector module.
For convenience, this distribution includes the modules listed above, in place and ready to build, with minor modifications to build files. A few of the modules have suffered more substantial modifications to fix problems, add display files, etc.
synApps includes software developed by the Beamline Controls & Data Acquisition, Software Services, and Accelerator Controls groups of the Advanced Photon Source (APS); by developers in APS Collaborative Access Teams – notably, Mark Rivers (CARS-CAT); and by developers in the EPICS collaboration outside of the APS – notably, those at the Diamond Light Source, the Berliner Elektronenspeicherring-Gesellschaft für Synchrotronstrahlung (BESSY), the Stanford Linear Accelerator Center (SLAC), the Swiss Light Source (SLS)/Paul Scherrer Institut (PSI), the National Synchrotron Light Source (NSLS), the Deutsches Elektronen Synchrotron (DESY), the Spallation Neutron Source (SNS), the Australian Light Source, and the Canadian Light Source.
Aside from EPICS databases, SNL (State Notation Language) programs, and the like, synApps contains the following code:
Record | Description |
---|---|
ab* | AllenBradley-module custom records |
acalcout | calcout record extended to handle array expressions |
asyn | provide access to nearly all of the features of the asyn facility |
busy | utility record: calls recGblFwdLink only when its VAL field is zero, allowing CA clients, and asyn drivers to participate in EPICS putNotify (ca_put_callback()) operations |
camac | camac-module custom record |
digitel | vac-module custom record |
epid | Extended version of the PID record, previously in EPICS base. Intended for implementing feedback loops |
mca | support for multichannel analyzers, and some other array-valued detectors |
motor | stepper and servo motors, "soft" motor |
scalcout | calcout record extended to handle string expressions, links, and values |
scaler | scaler bank |
sscan | Replaces the scan record (Ned Arnold/APS) previously in EPICS base. This version uses a modified version of recDynLlib that supports dbNotify command completion. It uses ca_put_callback to do puts, instead of ca_put. |
scanparm | scan parameters for use with the scan record |
sseq | string-sequence record. This is a modified version of the seq record in base. This version can link to/from either string or numeric PVs, and it can use dbCaPutLinkCallback to wait for completion of the execution started by one link before going on to the next. |
swait | replaces the wait record previously in EPICS base. This version uses a modified version of recDynLlib that supports dbNotify command completion. It uses ca_put_callback to do puts, instead of ca_put. |
table | 6-degree-of-freedom optical table |
transform | like an array of calc records, with output links |
vme | generic vme record (Mark Rivers/APS/CARS-CAT) |
timestamp | (written by Stephanie Allison/SLAC) Needed by the vxStats module, but apparently not available in a published module. |
vs | vac-module custom record |
List appended to this document.
In addition to this top-level documentation, synApps modules have their own documentation directories, and the xxx module contains examples of how much of the software is imported, built, loaded, and run. Some modules have their own example iocBoot directories.
The synApps support/utils directory contains a variety of scripts, programs, etc., that some have found useful.
Although synApps is distributed as a single 'support' directory, it's normally deployed as a two-part system: a 'support' directory, and one or more 'user' directories. The support directory can be installed on a read-only file system, along with EPICS base and other modules, and used from there by user directories, each of which typically begins as a copy (or a collection of copies) of the xxx module, and is customized/extended to suit a particular application and set of hardware.
I'm not being very precise about what is meant by a user directory, because there are a number of reasonable variations. At the simplest, a single copy of the xxx module, which supports a single IOC, is a user directory. If several IOC's cooperate to serve a single application (such as a synchrotron beamline), one might make several independent copies of xxx, or one might extend a single xxx copy to contain multiple xxxApp directories, and multiple iocBoot/iocxxx directories. At APS, the BCDA group maintains around 100 top-level user directories (for each version of synApps) each of which contains a number of copies of xxx, and most of which, in turn, contain multiple xxxApp and iocBoot/iocxxx directories.
Here's what a complete installation might look like (much detail omitted) with all the files you will have to edit before you can build or boot an IOC:
synApps_X_X/support/ Makefile allenBradley/ areaDetector/ asyn/ busy/ calc/ camac/ configure/ CONFIG CONFIG_SITE <— EDIT to build RELEASE <— EDIT to build EPICS_BASE.<arch> <— EDIT to build for <arch> Makefile RELEASE SUPPORT.<arch> <— EDIT to build for <arch> ... dac128V/ delaygen/ devIocStats/ documentation/ dxp/ ip/ ip330/ ipUnidig/ ipac/ drvIpac/drvIpac.dbd <— EDIT to build love/ mca/ measComp/ modbus/ motor/ motorApp/ Makefile <— EDIT to build optics/ quadEM/ seq/ softGlue/ sscan/ std/ stream/ utils/ vac/ vme/ xxx/
synApps_X_X/ioc/ 1bm/ Makefile bin/ configure/ CONFIG_SITE <— EDIT to build RELEASE <— EDIT to build dbd/ iocBoot/ Makefile nfsCommands <— EDIT to run ioc1bma/ Makefile <— EDIT to build *.cmd *.req *.substitutions autosave/ cdCommands or envPaths ioc1bmb/ ioc1bmc/ ioc1bmd/ <much like ioc1bma> release.pl setup_epics_common <— EDIT to run user interface start_epics_1bma <— EDIT to run user interface start_epics_1bmb <— EDIT to run user interface start_epics_1bmc <— EDIT to run user interface start_epics_1bmd <— EDIT to run user interface 1bmaApp/ 1bmbApp/ 1bmcApp/ 1bmdApp/ 1id/ 2bm/ 2id/ ... <much like 1bm>
As shown above, the following files can or must be edited to modify the way
the synApps support directory is built. After modifying files in the support,
or support/configure directories, you should run make release
,
and make rebuild
, in the support directory.
support/configure/RELEASE
- Edit the definitions of
EPICS_BASE
andSUPPORT
with the correct paths to these directories on your system.
Comment out any modules you don't want to build.support/configure/EPICS_BASE.<arch>
- If you plan to build on more than one host architecture from a single synApps directory, and the hosts use different paths to refer to the same file (for example, Windows and Linux using a shared file system) then you can override the definition of
EPICS_BASE
in theRELEASE
file by specifying host-specific paths to base in separateEPICS_BASE.<arch>
files. If you don't have such plans, then you can delete these files, but if they exist, they must be correct.support/configure/SUPPORT.<arch>
- Similar to
EPICS_BASE.<arch>
, but for the synAppssupport
directorysupport/configure/CONFIG_SITE
- Edit to set the following variables, which control what will be built: The supported values for these variables are
YES
andNO
.
LINUX_USB_INSTALLED
- This controls the build of the dxp module. If usb is not installed for developers, then parts of dxp/dxpApp/handelSrc will not be built, and the example application executable, dxpApp, will not be built, so dxp/iocBoot cannot be used.
LINUX_NET_INSTALLED
- This controls the build of the mca module, specifically, support for the Canberra AIM hardware.
IOCS_APPL_TOP
- Path to application top as seen by IOC. Set this when your IOC and host use different paths to access the application directory. This will be needed to boot from a Microsoft FTP server or with some NFS mounts. You must rebuild in the iocBoot directory for this to take effect.
support/ipac/<version>/drvIpac/drvIpac.dbd
- uncomment
registrar()
commands for IndustryPack carriers you plan to use.support/motor/<version>/motorApp/Makefile
- comment or uncomment to select the motor support you want to build.
The following files must be edited before building a user directory:
ioc/<appname>/configure/RELEASE
- edit the definition of
SUPPORT
with the correct path to the support directoryioc/<appname>/iocBoot/<iocname>/Makefile
- edit to specify the architecture that is to be built
The following files must be edited before running the user interface:
ioc/setup_epics_common
- set the value of Channel Access variables, such as EPICS_CA_MAX_ARRAY_BYTES.
ioc/start_epics_xxx
- edit to specify the path to the application and display-file directories, and the name of the top-level display file.
The association between a user directory, and the support directory on which it depends, is made entirely by the file, configure/RELEASE, in the user directory. Typically, this file simply includes the configure/RELEASE file from the support directory, but it may differ: it may specify EPICS modules not included in synApps, for example. Or, if the support directory contains more than one built version of a module (the original and a bug fix, for example) the user directory can choose which version it will use.
Note, however, that the modules in synApps are interdependent. Many of the modules depend on the asyn module, for example, and there are many other dependencies, both direct and implied. (If module a depends on module b, and module b depends on module c, then a also depends on c, and it must specify the same version of c that b specifies.) The complete set of modules selected by a user directory must be self consistent, and the EPICS build will ensure this, unless you tell it not to, by definingCHECK_RELEASE=NOorCHECK_RELEASE=WARNinioc/configure/CONFIG_SITE
.
For completeness, the format of a RELEASE-file path definition is
"<name>=<path>
", where <name> is an arbitrary
string, and <path> is an absolute directory name (starts with '/' on a
unix host, or with a drive name such as 'C:' on Windows). Although <name>
is arbitrary, you should be consistent. Generally, the EPICS build doesn't care
what paths are named, because it's just going to collect them all into a list,
and use the list to search for libraries, .dbd files, etc. But, in the module
consistency check mentioned above, the name does matter, because EPICS can't
check that all modules in a build are using the same version of, say, the asyn
module, unless they all use the same <name> for it. Also, in the xxx
module, <name> is used extensively to find display files (that is, to set
the EPICS_DISPLAY_PATH environment variable), and to specify databases, autosave
request files, etc., when an ioc is booting.
The synApps build imposes an additional constraing on module names. Because
synApps uses EPICS build rules to descend from support
into the
modules, module names may not include the character '.'. (The EPICS build rules
expect '.' to be followed by a host or target architecture.)
Before building synApps, you should ensure that your system has the tools, libraries, header files, etc. required to build the modules you want to build. Here's a list of dependencies we've documented so far.
Please help: new users are particularly well placed to help us complete this list. Long-time developers typically have lots of things correctly configured that they don't even remember configuring.
Cygwin is configured from a menu of choices organized by function. You will need the following components from the following menu headings:
If you have a built copy of EPICS base 3.14.12.1 or later, then building the synApps support directory should be very simple:
If you are using Perl 5.6 or earlier, see comments in support/configure/makeReleaseConsistent.pl for needed script modifications.
EPICS_HOST_ARCH
to the
architecture (and compiler, if there is a choice) on which you are building.
synApps is tested with the architectures linux-x86_64
,
cygwin-x86
, and win32-x86
.
make release
'. (See note below.)
make
'. (You should be able to use
'make -j
' to build synApps more quickly.)
You should use the same GNU Make executable that was used to build EPICS
base. You may need $(EPICS_BASE)/bin/<arch>
in your path,
and you may need $(EPICS_BASE)/lib/<arch>
in
LD_LIBRARY_PATH
.
When executed in the support directory, 'make release
' will go
to all of the modules support/Makefile
is configured to build, and
edit the configure/RELEASE
files in those modules so that they all build from
the same versions of EPICS base and other known modules.
Typically, the build will not succeed the first time, because you will not
have all of the required system support. If you find that you cannot build some
synApps module, you can disable its build by commentng it out of
support/configure/RELEASE
.
Once synApps' support directory has built without errors, the xxx
module will have been configured (xxx/configure/RELEASE
will have
correct, absolute paths to base and support) and built, so you can use it as an
example – or, better, a template – for constructing user directories
to support your IOCs. To make a template of xxx, clean and uninstall it, and
tar a copy of the directory. To use the template, untar it, cd to its top-level
directory and run support/utils/changePrefix
to change the PV-name
prefix from xxx to whatever you want. (Note you must have
support/utils
in your command path, or you could copy
support/utils/changePrefix
and support/utils/doSed
to
a directory that is in your command path. Note that changePrefix
is
synApps-version specific.)
Here's what I do:
# Do once when synApps is built: cd $(SYNAPPS)/support/xxx setenv EPICS_HOST_ARCH <host architecture> gnumake clean uninstall (repeat as needed for any other architectures) tar cvf ../xxx.tar * # Do whenever a new user directory ('1bm', in this example) is needed: cd $(SYNAPPS)/ioc mkdir 1bm cd 1bm tar xf $(SYNAPPS)/support/xxx.tar changePrefix xxx 1bma mv iocBoot/iocvxWorks iocBoot/ioc1bma edit iocBoot/ioc1bma/Makefile to specify the IOC processor type gnumake
To put a second application, 1bmb, into 1bm, I run the following commands:
cd $(SYNAPPS)/ioc mkdir temp cd temp tar xf $(SYNAPPS)/support/xxx.tar changePrefix xxx 1bmb mv iocBoot/iocvxWorks iocBoot/ioc1bmb edit iocBoot/ioc1bmb/Makefile to specify the ioc processor type cd $(SYNAPPS)/ioc mv temp/1bmbApp/start_epics_1bmb 1bm mv temp/1bmbApp 1bm mv temp/iocBoot/ioc1bmb 1bm/iocBoot rm -rf temp cd 1bm gnumake
Edit the files above to agree with your hardware, to load the databases you want, etc., set up the IOC processor's parameters to load from the software just configured, and boot the crate. If you don't know how to do this, read on.
Ensure that $(EPICS_BASE)/bin/<arch>/caRepeater
gets run
when your
workstation boots. If you have no way of doing this, you can run it manually
or put the command in your .login file.
Setup your host system to work with the EPICS processor. See the VxWorks Programmer's Guide if you have a copy. Here's what we do (on a Sun workstation):
<vx_username>
with the password
<vx_password>
. The user has nothing in its home
directory, and very few priviledges.
cu -lttya
(On some workstations we must type "cu -lcua/a
".)
This gets the xterm communicating with the crate processor.
boot device : dc processor number : 0 host name : <server> file name : /usr/local/vxWorks/T222/mv2700-asd1 inet on ethernet (e) : xxx.xxx.xxx.xxx:fffffe00 inet on backplane (b): host inet (h) : xxx.xxx.xxx.xxx gateway inet (g) : user (u) : <vx_username> ftp password (pw) (blank = use rsh): <vx_password> flags (f) : 0x0 target name (tn) : iocxxx startup script (s) : /home/server/USER/epics/xxx/iocBoot/iocxxx/st.cmd other (o) :
See support/xxx/iocBoot/ioc*/bootParms
for other processor
types. If your VME processor has mount access to an 'APSshare' NFS file
server, you can specify the 'file name', above, as
"/APSshare/vw/T222/mv2700-asd1".
synApps includes hundreds of display files intended for use with the EPICS display manager, MEDM, and translations of those files that work with CSS-BOY and caQtDM. Other EPICS display managers exist, and I once did a mass automated translation of MEDM display files to the EDM display manager's file format, using software developed by others. This translation was only partially satisfactory, but we don't have the resources to do the job better or more generically. In this documentation, I'll limit attention to MEDM display files.
This happens in the user directory. Generally, you must tell "EPICS" what hardware is in your crate, and what addresses, interrupt vectors, etc. you have set your hardware to use. (See support/xxx/documentation/vme_address.html for a list of suggested values.) You also must specify which motors any slit, table, monochromator, etc., control software is to use. If you use serial or GPIB, you must match port names to hardware devices, set serial-port parameters, and specify GPIB addresses. For any IndustryPack modules, you must specify the IP carrier and slot into which you've loaded those modules.
In a complete job of fitting synApps to an IOC's hardware, all of the following files will be touched:
xxx/iocBoot/ioc*/st.cmd
- This is the ioc's startup script, and it loads the other .cmd files
xxx/iocBoot/ioc*/*.cmd
xxx/iocBoot/ioc*/*.substitutions
- Other command files that may or may not be invoked by st.cmd
xxx/iocBoot/ioc*/auto_positions.req
xxx/iocBoot/ioc*/auto_settings.req
- specifies PV's to be saved periodically during operation, and restored automatically when the ioc is rebooted.
xxx/iocBoot/ioc*/saveData.req
- identifies PV's used by the saveData software, sscan records to be monitored for data, and PV's whose values are to be included in all scan-data files.
xxx/iocBoot/ioc*/bootParms
- a copy of the boot parameters (in case the IOC processor crashes in a way that erases nonvolatile memory)
xxx/iocBoot/ioc*/st.cmd
This is the file run by the IOC at boot time. It loads an executable built in
the IOC directory (e.g., xxx
, or xxx.munch
), sets parameters to configure that
software, makes calls to that software to configure it for a particular set of
hardware, and loads databases from synApps modules. Mostly, it sources other
.cmd files that do these same things.
This file, and the files it sources, are probably worth studying. They are
reasonably well commented, and contain dbLoadRecords()
commands for most of
the EPICS databases in synApps.
To load more motors, add lines to the file
xxx/iocBoot/ioc*/motor.substitutions
. For motors controlled by a
VME board, edit vme.cmd
to specify the hardware address, etc. For
motors controlled through a serial connection, edit serial.cmd
.
If you want the new motors to work with the 'AllStop' button
(xxx:allstop.VAL
– see the top-level MEDM display xxx.adl
), load the database
$(MOTOR)/db/motorUtil.db
, and run the command
motorUtilInit("xxx:")
.
If you want the IOC automatically to save positions and settings of the new
motors, and restore them when the crate reboots, add lines to the files
xxx/iocBoot/ioc*/auto_settings.req
and
xxx/iocBoot/ioc*/auto_positions.req
.
To use a pair of motors to control a slit, search for 2slit.db
in xxx/iocBoot/ioc*/st.cmd
, and edit the
dbLoadRecords()
command you'll find there. The example in
st.cmd
loads two copies of 2slit.db
intended for use
as the horizontal and vertical members of a four-jaw slit. The MEDM displays
2slit*.adl
and 4slit*.adl
are involved in these
applications.
The slit database can make either of two sets of assumptions about the two motors attached to the individual slit leaves, depending on the value of the macro "RELTOCENTER" that may be supplied when loading the 2slit.db database.
If "RELTOCENTER=0" is supplied, or if RELTOCENTER is omitted altogether:
If "RELTOCENTER=1" is supplied:
The 2slit.db
database allows users to move either the slit
virtual motors or the actual motors, and it keeps all the readback values
current regardless of how the actual motors got moved or recalibrated. But it
does not automatically reset the slit drive values when the actual motors are
used. This must be done manually, using the "SYNC" button on the
2slit.adl
display. Pressing this button causes the database to
read the actual motor drive values and set the slit-drive values accordingly.
To recalibrate slit positions, press the "Set" button, type in the current slit position as you want it to be called, and press the "Use" button. This procedure uses the "Set" buttons of both motors the slit software talks to, and the user/dial offsets of those motors actually implement the recalibration.
There is a new, experimental slit database in synApps which uses soft motor records as the user/client interface. This allows clients that know how to control a motor also to control a slit, with some limitations. We hope to use soft motor records in front of other positioners (e.g. monochromators, optical tables, insertion devices, and DAC channels) in the future.
Optical tables are controlled by a custom EPICS record (the "table" record),
used in the database table.db
and controlled via MEDM displays
table*.adl
.
Table virtual motors behave in much the same way as do slit virtual motors. However, the table software does not use user/dial offsets in the underlying motor to implement recalibration (it can't, since it works through a nonlinear transform). Instead, the table maintains its own offsets for all of the six coordinated motions it implements. Pressing the "Set" button causes new table positions to modify the offsets instead of moving the table (which is exactly the way motor and slit calibration works). In addition to a "Sync" button, which reads motor positions and calculates the table positions from them, the table display has an "Init" button, which zeros all offsets before doing a "sync" operation. It also has a "Zero" button, which manipulates all the table offsets to make the current table positions zero without moving or recalibrating any motors.
Several varieties of crystal monochromators are supported in synApps: two
constant-offset "channel-cut" monochromators, a high-resolution double-crystal
monochromator, and a spherical-grating monochromator. Most are supported by
databases paired with State Notation Language (SNL) programs, and several MEDM
displays. The EPICS databases kohzuSeq.db
, SNL program
kohzuCtl.st
, and MEDM displays kohzu*.adl
(also
kohzu*.gif
) are involved in control of two varieties of
high-heat-load monochromators. The EPICS database hrSeq.db
, SNL
program hrCtl.st
, and MEDM displays hSeq*.adl
are
involved in control of the high-resolution double-crystal monochromator. The
spherical grating monochromator is supported by the database SGM.db
and the displays SGM*.adl
.
The APS standard user filters combine several motors and solenoids to control
the placement of filter material in the beam path. The databases
filterMotor.db
and filterLock.db
, and the MEDM displays
*filter*.adl
are involved in this application.
Impromptu coordinated motions and other bits of run-time programming are handled by what we call a "userCalc" (actually just a swait record with a nice MEDM interface) or a "userTransform" (actually just a transform record with a nice MEDM interface). We normally load sets of these and other records into each EPICS processor, specifically for end-user programming. Users type in expressions to be evaluated, and link inputs and outputs, as needed, to glue existing objects together to do what they want done at the moment. Here are some examples of the tasks that have been accomplished with userCalcs and userTransforms:
Run-time programming involving strings and/or numbers can be done with userStringCalcs, which resemble userCalcs closely, but differ in significant details. A package containing two stringCalcs and an 'asyn' record (called a "deviceCmdReply") is also available for run-time programming of simple support for serial and other message-based devices.
Run-time programming involving arrays and/or numbers can be done with userArrayCalcs, which resemble userCalcs closely, but differ in significant details.
Scans of up to five dimensions are supported by the
standardScans.db
database. Scan data is written to disk by the
saveData program, whose user interface is contained in
saveData.db
. The number of data points per scan dimension is
specified when standardScans.db
is loaded, and is limited to 2000,
unless the environment variable EPICS_CA_MAX_ARRAY_BYTES
is
specified.
Note that loading saveData.db
does not automatically cause scan data to be
written to disk. You must also call the function saveData_Init()
, specifying a
scan-configuration file (saveData.req
) which tells saveData which sscan records
to monitor.
Also note that initializing saveData is an all-or-nothing choice. If you
initialize saveData, then all scans performed by sscan records named in
the configuration file will be written to disk. If saveData cannot write a
file, it will prevent the next scan from completing. (Scans performed by sscan
records that are not named in saveData.req
are completely outside of this
restriction. The data they accumulate is not written to disk by saveData, so
saveData is not involved in their operation.)
Run-time programming of sequences is possible using the sseq record and related
MEDM displays yySseq.adl
Up to four measurement steps involving positioners, detectors, and end
calculations (e.g., to support dichroism experiments) can be done with the
4step.db
database and the related MEDM display, 4step.adl
. The entire
measurement sequence can be involved in a scan by treating the 4step database
as you would treat the scaler or mca software.
See xxx/iocBoot/ioc*/bootParms
for sample boot parameters.
See the MEDM Operator's Manual for detailed information on the special needs of this X11/Motif program. I'll assume those needs have been met.
MEDM uses a search path list to find .adl files, and we'd like for that path
list to refer to the synApps module versions actually in use. To generate the
search path list from an application's configure/RELEASE file, edit the file
xxx/start_epics_xxx
so it sets the environment variables
EPICS_APP
and EPICS_APP_ADL_DIR
. Here's an example:
setenv EPICS_APP /home/oxygen/MOONEY/epics/synApps/support/xxx setenvEPICS_APP_ADL_DIR ${EPICS_APP}/xxxApp/op/adlIf you plan to run MEDM on a workstation that isn't on the same subnet as the IOC's, you'll need to uncomment and edit the definition of the environment variable
EPICS_CA_ADDR_LIST
. In principle, you should be able to
name only the broadcast address for the subnet that contains the IOC's, but if
this doesn't work, you can put in the IP addresses of all the IOC's you want to
connect with, separated by spaces, as follows:
setenv EPICS_CA_ADDR_LIST "164.54.53.126 164.54.53.127"
If you want to use arrays larger than 16000 bytes (e.g., MCA spectra of more
than 4000 channels, or scans of more than 2000 data points), you must set the
environment variable EPICS_CA_MAX_ARRAY_BYTES
, in both the IOC and
workstation, to the size of the largest array you plan to send over the
network, plus the size of the extra data channel access might be asked to
include with the array. On a Unix system, for example, you might say
setenv EPICS_CA_MAX_ARRAY_BYTES 64008in the IOC's st.cmd file, you'd say
putenv "EPICS_CA_MAX_ARRAY_BYTES=64008"This will permit scans of up to 8000 points (8000 doubles * 8 bytes per double + 8 bytes for channel-access overhead), and mca spectra of up to 16000 channels.
To bring up the top-level MEDM display for synApps software, cd to xxx and type "start_epics_xxx" (e.g., start_epics_1bma). This script locates the directories that might have MEDM-display files and includes them in the environment variable EPICS_DISPLAY_PATH, cd's to xxxApp/op/adl, and runs MEDM with the default top-level display file.
caQtDM display files (*.ui) in synApps were translated from MEDM-display files (*.adl) with the adl2ui translator in caQtDM-2-8 (available from http://epics.web.psi.ch/software/caqtdm/).
caQtDM implements a search path list very much as in MEDM, so we can use the
same technique to autogenerate that path from an application's configure/RELEASE
file. Edit the file xxx/start_caQtDM
so it sets the environment
variables EPICS_APP
and EPICS_APP_UI_DIR
. Here's an
example:
setenv EPICS_APP /home/oxygen/MOONEY/epics/synApps/support/xxx setenv EPICS_APP_UI_DIR ${EPICS_APP}/xxxApp/op/ui
Other environment variables used by caQtDM are the same as for MEDM.
CSS-BOY display files (*.opi) in synApps were translated from MEDM-display files (*.adl) using the ADL-to-BOY translator included with CSS-BOY.
CSS-BOY can use a search path list for display files, as MEDM does, but the path is defined differently. One way to set it is to select the menu "Edit/Preferences", then select "CSS Applications/Display/BOY" and type the path into the "OPI Search Path" box. See CSS-BOY documentation for other options.
You must give the crate write permission to xxx/iocBoot/ioc*/autosave so it can
write the files auto_positions.sav and auto_settings.sav there. It's also
helpful to set the autosave directory's 'group' bit so that files the crate
writes will be owned by the owner of the directory instead of by
To modify the list of PV's that are saved and restored, edit the files
xxx/iocBoot/ioc*/auto_settings.req and
xxx/iocBoot/ioc*/auto_positions.req
The autosave software is started by the lines
" saveData is a CA client that monitors sscan records and saves scan data to
disk. On vxWorks, this is an NFS-mounted disk; on other operating systems, it's
whatever file system the system provides for the standard C library. The
saveData software is configured with the file xxx/iocBoot/ioc*/saveData.req,
which needs no special attention unless you want to modify the list of EPICS
PV's whose values are to be saved with every data file. To do this, look for
the string "[extraPV]" in the file, and edit the list of PV's immediately
following that string. If an entry in this list contains only the PV name,
saveData will describe the PV, in the data file, using the .DESC field of the
record that contains that PV. If a string follows the PV name, saveData will
use the string instead.
chmod a+w,g+s autosave
create_monitor_set(...
" in xxx/iocBoot/ioc*/st.cmd. The restore
happens during iocInit as a result of function calls inserted into initHooks.o,
which is included in the library provided by the autosave module, and
linked into the executable loaded by xxx/iocBoot/ioc*/st.cmd.
Like all EPICS software, synApps can be extended in many ways, and at many levels, by EPICS developers and users. (That's how the package came to exist in the first place. It started as a single App directory, and folks just added stuff.) But synApps pushes the idea a little bit further toward end users who are not developers. One of the driving notions behind the development of synApps was to put as much of EPICS' flexibility and power as seems both wise and practical into the hands of end users – typically, scientists running experiments – whose backgrounds in software development and implementation vary over a wide range.
Here is a list of techniques by which synApps has already been extended by users and developers, arranged very roughly according to the amounts of effort, skill, and EPICS knowledge required.
This is certainly too simple to be considered an extension – all you do
is type something like "(A-B)/I
" into a text box – but it's still pretty
useful, and it demonstrates a technique that will be used for much more
sophisticated purposes.
The first extension that many users attempt is the programming of a scan. This might also seem more like mere use than extension, but it can become a very highly evolved skill, and it is software development in a reasonably literal sense. If you buy into the notion that an EPICS database is essentially a program (in a very high-level programming language), then scan configuration can be viewed as the simpler end of a continuum.
synApps facilitates run-time programming of a number of EPICS record types, by providing the following kinds of support:
The word "userCalc" has become generic for the records and database fragments with which run-time programming is done, and most of the records so used are, in fact, calculation records whose expressions can be modified by users. But synApps also contains records and databases intended for run-time programming of other kinds:
userStringSeqs10.db, userStringSeqs10_settings.req, userStringSeq*.adl
*pid_control.db, *pid_control_settings.req, pid*.adl
ramp_tweak.db, ramp_tweak_settings.req, ramp_tweak*.adl
deviceCmdReply.db, deviceCmdReply_settings.req, deviceCmdReply*.adl
4step.db, 4step_settings.req, 4step.adl
interpNew.db, interpNew_settings.req, interpNew.adl
In addition to "userCalcs", many synApps records and databases contain sections intended primarily for run-time programming by end users. Examples include end-of-acquisition calculations for scalers and digital multimeters; region-of-interest summing, and background-subtraction for mca records.
End users know better than anybody what they want in a graphical user interface. One thing they've demonstrated that they want is the ability to have some control over the user interface without having to specify every little detail to a programmer. MEDM provides end users with the ability easily to create custom displays, and synApps provides over 800 user-interface files that can be copied from, called up from, or included as part of a user crafted display.
An EPICS IOC is populated and configured by ASCII command files, which knowledgeable end users can edit to add motors, change default baud rates, load additional copies of databases, etc.
Many synApps end users have written scripts, in languages such as the unix shell, Python, SPEC macro, IDL, tcl, perl, and Labview, to simplify and/or standardize beamline operations. Any language can be used for this purpose, if it can be fitted with a Channel-Access interface.
One very easy step from run-time programming to EPICS-database development can be taken by using the wxPython program, snapDb.py, (in the utils directory) to "freeze" a collection of programmed userCalcs into an independently loadable database. snapDb can also generate a first cut at a user interface for the database.
But most EPICS database development is done with a database-configuration tool, such as VDCT, or a text editor. In any case, EPICS-database development typically involves the selection of device support, the specification of links and link attributes, and the setting of parameters. More sophisticated development also involves the programming of an initialization strategy into the database, and maybe the writing of an autosave-request file, for it.
This is probably the simplest way to add custom C code to an EPICS application. SynApps contains several examples of this type of code, among them are arrayTest.c, interp.c, and subAve.c, all in the directory support/calc/calcApp/src.
This is probably the next easiest, and the next most capable, way of adding compiled code to an application. SNL also introduces to this list the notion of client-side program development, for an SNL program is a Channel Access client, even though it runs on an IOC. Again, synApps has a bunch of examples, which you can find by searching for ".st" and ".stt" files.
Documentation for SNL can be found in the seq module, a copy of which is bundled with synApps.
If synApps doesn't contain device support for the device you want to use, you can probably find (in synApps or elsewhere) a device-support example that has, at least, the structure of the sort of support you will need.
Nobody writes device support from scratch; it's just not an effective way to develop. Everybody tries to find the closest approximation to what they need, and modifies it until it serves their purpose. One important use of the EPICS tech-talk email list is to gather suggestions, from folks further up the learning curve, on what might be a good piece of code to use or modify for a particular purpose.
This requires a lot of skill, effort, and information. Developers at this level need the EPICS Application Developer's Guide, the Channel Access Reference Manual, and very capable cross-platform GUI infrastructure.
This also requires a lot of skill, effort, and information. Developers at this level need the EPICS Application Developer's Guide, and the EPICS Record Reference Manual. One of the very best features of EPICS is the fact that experts in module development can collaborate with experts in client-side development, even if the developers are unaware of each other.
All of the extension strategies described above produce (or, at least can produce) results which are fully integrated into the control system. This means that they can be used in further extensions by the same techniques. Thus, for example, motors ganged together by a transform record can be scanned, driven by a PID loop, or controlled by another userCalc.
The synApps support/utils directory contains a variety of executables that may be useful in administering and/or using synApps. Some of these tools are probably peculiar to the way synApps is used at APS.
- changePrefix, doSed
- These are for the application developer's convenience in changing EPICS prefixes in a user directory. You must be in the top level of the user directory to run changePrefix, and you should do a "gnumake clean uninstall" before running it.
Example of use:
cd $(SYNAPPS)/ioc/1bm changePrefix xxx 1bma- copyAdl
- Look through synApps for .adl files, and copy them all to a specified directory
Example of use:
copyAdl $SYNAPPS/support adl_files- convertIocFiles.py
- This file, and its associates, are intended to help convert an IOC directory from one version of EPICS to another, by collecting data from an existing IOC directory, and attempting to correctly edit files in a new IOC directory. See support/utils/HowToUse_convertIocFiles.txt for more information on this program.
- mdautils-src.tar.gz
- This tar file contains utility programs for using data files written by the sscan module's "saveData" program. These programs were written by Dohn Arms, and contributed to synApps.
- mdaExplorer
- This wxPython program displays the content of MDA files, and directories of MDA files. (An MDA file is the scan-data file produced by the synApps sscan module's saveData software during a scan.)
- mdaPythonUtils
- A collection of python programs that read, write, modify, and translate MDA files.
- snapDb
- A wxPython rapid development tool for EPICS databases and MEDM display files. This program supports the use of EPICS' run-time programmability to prototype EPICS databases, using records loaded into an IOC. It's particularly useful with synApps "userCalcs", a collection of various record types intended for end users to program at run time.
record | bus-type | codename | DTYP name |
---|---|---|---|
aai | CONSTANT | devAaiSoft | Soft Channel |
aai | INST_IO | devaaiStream | stream |
aao | CONSTANT | devAaoSoft | Soft Channel |
aao | INST_IO | devaaoStream | stream |
acalcout | CONSTANT | devaCalcoutSoft | Soft Channel |
ai | AB_IO | devAiAb1771Ife0to5V | AB-1771IFE-0to5Volt |
ai | AB_IO | devAiAb1771Ife | AB-1771IFE |
ai | AB_IO | devAiAb1771IfeMa | AB-1771IFE-4to20MA |
ai | AB_IO | devAiAb1771IfeSe | AB-1771IFE-SE |
ai | AB_IO | devAiAb1771Il | AB-1771IL-Analog In |
ai | AB_IO | devAiAb1771IrCopper | AB-1771RTD-Copper |
ai | AB_IO | devAiAb1771IrPlatinum | AB-1771RTD-Platinum |
ai | AB_IO | devAiAb1771Ixe | AB-1771IXE-Millivolt In |
ai | AB_IO | devAiAbSlcDcm | AB-SLC500DCM |
ai | AB_IO | devAiAbSlcDcmSigned | AB-SLC500DCM-Signed |
ai | BBGPIB_IO | devAiAX301 | PZT Bug |
ai | CONSTANT | devAiSoftRaw | Raw Soft Channel |
ai | CONSTANT | devAiSoft | Soft Channel |
ai | CONSTANT | devAiTodSeconds | Sec Past Epoch |
ai | CONSTANT | devAiTodSeconds | Sec Past Epoch |
ai | GPIB_IO | devAidg535 | dg535 |
ai | GPIB_IO | devAiGP307Gpib | Vg307 GPIB Instrument |
ai | GPIB_IO | devAiHeidAWE1024 | Heidenhein Encoder |
ai | GPIB_IO | devAiKeithleyDMM199 | KeithleyDMM199 |
ai | GPIB_IO | devAiTestGpib | GPIB Test |
ai | GPIB_IO | devGpib | GPIB init/report |
ai | INST_IO | asynAiFloat64 | asynFloat64 |
ai | INST_IO | asynAiFloat64Average | asynFloat64Average |
ai | INST_IO | asynAiInt32 | asynInt32 |
ai | INST_IO | asynAiInt32Average | asynInt32Average |
ai | INST_IO | devAiAb1791 | Allen Bradley 1791 |
ai | INST_IO | devAiAbDcm | Ab Dcm |
ai | INST_IO | devAiCan | CANbus |
ai | INST_IO | devAiClusts | IOC stats clusts |
ai | INST_IO | devAiClusts | VX stats clusts |
ai | INST_IO | devAiGeneralTime | General Time |
ai | INST_IO | devAiHeidND261 | asyn ai HeidND261 |
ai | INST_IO | devAiHuberDMC | Huber DMC 9200 |
ai | INST_IO | devAiMKS | HPS SensaVac 937 |
ai | INST_IO | devAiMPC | asyn MPC |
ai | INST_IO | devAiStats | IOC stats |
ai | INST_IO | devAiStats | VX stats |
ai | INST_IO | devaiStream | stream |
ai | INST_IO | devAiStrParm | asyn ai stringParm |
ai | INST_IO | devAiTelevac | asyn Televac |
ai | INST_IO | devAiTelevac | asyn Televac |
ai | INST_IO | devAiTPG261 | asyn TPG261 |
ai | INST_IO | devAiTPG261 | asyn TPG261 |
ai | INST_IO | devInterfaceAI1 | InterfaceAI1 |
ai | INST_IO | devTimestampAI | Soft Timestamp |
ai | VME_IO | devAiA32Vme | Generic A32 VME |
ai | VME_IO | devAiAvmeMRD | devAvmeMRD |
ai | VME_IO | devAiBunchClkGen | APS Bunch Clock |
ai | VME_IO | devAiVaroc | ESRF Varoc SSI Encoder Iface |
ai | VME_IO | devIK320Ai | Heidenhain IK320 |
ai | VME_IO | devIK320GroupAi | Heidenhain IK320 Group |
ao | AB_IO | devAoAb1771Ofe | AB-1771OFE |
ao | AB_IO | devAoAbSlcDcm | AB-SLC500DCM |
ao | BBGPIB_IO | devAoAX301 | PZT Bug |
ao | CONSTANT | devAoSoftCallback | Async Soft Channel |
ao | CONSTANT | devAoSoftRaw | Raw Soft Channel |
ao | CONSTANT | devAoSoft | Soft Channel |
ao | GPIB_IO | devAodg535 | dg535 |
ao | GPIB_IO | devAoHeidAWE1024 | Heidenhein Encoder |
ao | GPIB_IO | devAoKeithleyDMM199 | KeithleyDMM199 |
ao | GPIB_IO | devAoTestGpib | GPIB Test |
ao | INST_IO | asynAoFloat64 | asynFloat64 |
ao | INST_IO | asynAoInt32 | asynInt32 |
ao | INST_IO | devAoAb1791 | Allen Bradley 1791 |
ao | INST_IO | devAoAbDcm | Ab Dcm |
ao | INST_IO | devAoCan | CANbus |
ao | INST_IO | devAoEurotherm | asyn ao Eurotherm |
ao | INST_IO | devAoMPC | asyn MPC |
ao | INST_IO | devAoStats | IOC stats |
ao | INST_IO | devAoStats | VX stats |
ao | INST_IO | devaoStream | stream |
ao | INST_IO | devAoStrParm | asyn ao stringParm |
ao | INST_IO | devAoTPG261 | asyn TPG261 |
ao | INST_IO | devAoTPG261 | asyn TPG261 |
ao | INST_IO | devInterfaceAO1 | InterfaceAO1 |
ao | VME_IO | devAoA32Vme | Generic A32 VME |
ao | VME_IO | devAoAvme9210 | AVME-9210 |
ao | VME_IO | devAoBunchClkGen | APS Bunch Clock |
ao | VME_IO | devAoVMI4116 | VMIVME-4116 |
asyn | INST_IO | asynRecordDevice | asynRecordDevice |
bi | AB_IO | devBiAb16 | AB-16 bit BI |
bi | AB_IO | devBiAb32 | AB-32 bit BI |
bi | AB_IO | devBiAb | AB-Binary Input |
bi | CONSTANT | devBiSoftRaw | Raw Soft Channel |
bi | CONSTANT | devBiSoft | Soft Channel |
bi | GPIB_IO | devBidg535 | dg535 |
bi | GPIB_IO | devBiGP307Gpib | Vg307 GPIB Instrument |
bi | GPIB_IO | devBiHeidAWE1024 | Heidenhein Encoder |
bi | GPIB_IO | devBiKeithleyDMM199 | KeithleyDMM199 |
bi | GPIB_IO | devBiTestGpib | GPIB Test |
bi | INST_IO | asynBiInt32 | asynInt32 |
bi | INST_IO | asynBiUInt32Digital | asynUInt32Digital |
bi | INST_IO | devBiAbDcm | Ab Dcm |
bi | INST_IO | devBiCan | CANbus |
bi | INST_IO | devBiMPC | asyn MPC |
bi | INST_IO | devbiStream | stream |
bi | INST_IO | devBiStrParm | asyn bi stringParm |
bi | INST_IO | devBiTelevac | asyn Televac |
bi | INST_IO | devBiTelevac | asyn Televac |
bi | INST_IO | devBiTip810 | Tip810 |
bi | INST_IO | devBiTPG261 | asyn TPG261 |
bi | INST_IO | devBiTPG261 | asyn TPG261 |
bi | VME_IO | devBiA32Vme | Generic A32 VME |
bi | VME_IO | devBiAvme9440 | AVME9440 I |
bi | VME_IO | devBiAvmeMRD | devAvmeMRD |
bi | VME_IO | devBiBunchClkGen | APS Bunch Clock |
bi | VME_IO | devBiHP10895LaserAxis | HP interferometer |
bo | AB_IO | devBoAb16 | AB-16 bit BO |
bo | AB_IO | devBoAb32 | AB-32 bit BO |
bo | AB_IO | devBoAb | AB-Binary Output |
bo | BBGPIB_IO | devBoAX301 | PZT Bug |
bo | CONSTANT | devBoSoftCallback | Async Soft Channel |
bo | CONSTANT | devBoSoftRaw | Raw Soft Channel |
bo | CONSTANT | devBoSoft | Soft Channel |
bo | GPIB_IO | devBodg535 | dg535 |
bo | GPIB_IO | devBoGP307Gpib | Vg307 GPIB Instrument |
bo | GPIB_IO | devBoHeidAWE1024 | Heidenhein Encoder |
bo | GPIB_IO | devBoKeithleyDMM199 | KeithleyDMM199 |
bo | GPIB_IO | devBoTestGpib | GPIB Test |
bo | INST_IO | asynBoInt32 | asynInt32 |
bo | INST_IO | asynBoUInt32Digital | asynUInt32Digital |
bo | INST_IO | devBoAbDcm | Ab Dcm |
bo | INST_IO | devBoCan | CANbus |
bo | INST_IO | devBoGeneralTime | General Time |
bo | INST_IO | devBoMPC | asyn MPC |
bo | INST_IO | devboStream | stream |
bo | INST_IO | devBoStrParm | asyn bo stringParm |
bo | INST_IO | devBoTPG261 | asyn TPG261 |
bo | INST_IO | devBoTPG261 | asyn TPG261 |
bo | INST_IO | softGlueShow | softGlueShow |
bo | VME_IO | devBoA32Vme | Generic A32 VME |
bo | VME_IO | devBoAvme9440 | AVME9440 O |
bo | VME_IO | devBoAvmeMRD | devAvmeMRD |
bo | VME_IO | devBoBunchClkGen | APS Bunch Clock |
bo | VME_IO | devBoHP10895LaserAxis | HP interferometer |
busy | CONSTANT | devBusySoftRaw | Raw Soft Channel |
busy | CONSTANT | devBusySoft | Soft Channel |
busy | INST_IO | asynBusyInt32 | asynInt32 |
calcout | CONSTANT | devCalcoutSoftCallback | Async Soft Channel |
calcout | CONSTANT | devCalcoutSoft | Soft Channel |
calcout | INST_IO | devcalcoutStream | stream |
digitel | INST_IO | devDigitelPump | asyn DigitelPump |
digitel | INST_IO | devDigitelPump | asyn DigitelPump |
epid | CONSTANT | devEpidSoftCB | Async Soft Channel |
epid | CONSTANT | devEpidSoft | Soft Channel |
epid | INST_IO | devEpidFast | Fast Epid |
event | CONSTANT | devEventSoft | Soft Channel |
longin | AB_IO | devLiAbSlcDcm | AB-SLC500DCM |
longin | CONSTANT | devLiSoft | Soft Channel |
longin | GPIB_IO | devLidg535 | dg535 |
longin | GPIB_IO | devLiHeidAWE1024 | Heidenhein Encoder |
longin | GPIB_IO | devLiKeithleyDMM199 | KeithleyDMM199 |
longin | GPIB_IO | devLiTestGpib | GPIB Test |
longin | INST_IO | asynLiInt32 | asynInt32 |
longin | INST_IO | asynLiUInt32Digital | asynUInt32Digital |
longin | INST_IO | devLiAbDcm | Ab Dcm |
longin | INST_IO | devLiGeneralTime | General Time |
longin | INST_IO | devLiHuberDMC | Huber DMC 9200 |
longin | INST_IO | devLiStrParm | asyn li stringParm |
longin | INST_IO | devlonginStream | stream |
longin | VME_IO | devLiA32Vme | Generic A32 VME |
longin | VME_IO | devLiAvmeMRD | devAvmeMRD |
longin | VME_IO | devLiHP10895LaserAxis | HP interferometer |
longout | AB_IO | devLoAbSlcDcm | AB-SLC500DCM |
longout | BBGPIB_IO | devLoAX301 | PZT Bug |
longout | CONSTANT | devLoSoftCallback | Async Soft Channel |
longout | CONSTANT | devLoSoft | Soft Channel |
longout | GPIB_IO | devLodg535 | dg535 |
longout | GPIB_IO | devLoHeidAWE1024 | Heidenhein Encoder |
longout | GPIB_IO | devLoKeithleyDMM199 | KeithleyDMM199 |
longout | GPIB_IO | devLoTestGpib | GPIB Test |
longout | INST_IO | asynLoInt32 | asynInt32 |
longout | INST_IO | asynLoUInt32Digital | asynUInt32Digital |
longout | INST_IO | devLoAbDcm | Ab Dcm |
longout | INST_IO | devlongoutStream | stream |
longout | INST_IO | devLoStrParm | asyn lo stringParm |
longout | INST_IO | softGlueSigNum | softGlueSigNum |
longout | VME_IO | devLoA32Vme | Generic A32 VME |
longout | VME_IO | devLoHP10895LaserAxis | HP interferometer |
mbbi | AB_IO | devMbbiAb16 | AB-16 bit BI |
mbbi | AB_IO | devMbbiAb32 | AB-32 bit BI |
mbbi | AB_IO | devMbbiAb | AB-Binary Input |
mbbi | AB_IO | devMbbiAbAdapterStat | AB-Adapter Status |
mbbi | AB_IO | devMbbiAbCardStat | AB-Card Status |
mbbi | CONSTANT | devMbbiSoftRaw | Raw Soft Channel |
mbbi | CONSTANT | devMbbiSoft | Soft Channel |
mbbiDirect | AB_IO | devMbbiDirectAb16 | AB-16 bit BI |
mbbiDirect | AB_IO | devMbbiDirectAb32 | AB-32 bit BI |
mbbiDirect | AB_IO | devMbbiDirectAb | AB-Binary Input |
mbbiDirect | CONSTANT | devMbbiDirectSoftRaw | Raw Soft Channel |
mbbiDirect | CONSTANT | devMbbiDirectSoft | Soft Channel |
mbbiDirect | INST_IO | asynMbbiDirectUInt32Digital | asynUInt32Digital |
mbbiDirect | INST_IO | devMbbiDirectCan | CANbus |
mbbiDirect | INST_IO | devmbbiDirectStream | stream |
mbbi | GPIB_IO | devMbbidg535 | dg535 |
mbbi | GPIB_IO | devMbbiHeidAWE1024 | Heidenhein Encoder |
mbbi | GPIB_IO | devMbbiKeithleyDMM199 | KeithleyDMM199 |
mbbi | GPIB_IO | devMbbiTestGpib | GPIB Test |
mbbi | INST_IO | asynMbbiInt32 | asynInt32 |
mbbi | INST_IO | asynMbbiUInt32Digital | asynUInt32Digital |
mbbi | INST_IO | devMbbiAbDcm | Ab Dcm |
mbbi | INST_IO | devMbbiCan | CANbus |
mbbi | INST_IO | devmbbiStream | stream |
mbbi | INST_IO | devMbbiTPG261 | asyn TPG261 |
mbbi | INST_IO | devMbbiTPG261 | asyn TPG261 |
mbbi | VME_IO | devMbbiA32Vme | Generic A32 VME |
mbbi | VME_IO | devMbbiAvme9440 | AVME9440 I |
mbbi | VME_IO | devMbbiAvmeMRD | devAvmeMRD |
mbbi | VME_IO | devMbbiHP10895LaserAxis | HP interferometer |
mbbo | AB_IO | devMbboAb16 | AB-16 bit BO |
mbbo | AB_IO | devMbboAb32 | AB-32 bit BO |
mbbo | AB_IO | devMbboAb | AB-Binary Output |
mbbo | CONSTANT | devMbboSoftCallback | Async Soft Channel |
mbbo | CONSTANT | devMbboSoftRaw | Raw Soft Channel |
mbbo | CONSTANT | devMbboSoft | Soft Channel |
mbboDirect | AB_IO | devMbboDirectAb16 | AB-16 bit BO |
mbboDirect | AB_IO | devMbboDirectAb32 | AB-32 bit BO |
mbboDirect | AB_IO | devMbboDirectAb | AB-Binary Output |
mbboDirect | CONSTANT | devMbboDirectSoftCallback | Async Soft Channel |
mbboDirect | CONSTANT | devMbboDirectSoftRaw | Raw Soft Channel |
mbboDirect | CONSTANT | devMbboDirectSoft | Soft Channel |
mbboDirect | INST_IO | asynMbboDirectUInt32Digital | asynUInt32Digital |
mbboDirect | INST_IO | devMbboDirectCan | CANbus |
mbboDirect | INST_IO | devmbboDirectStream | stream |
mbbo | GPIB_IO | devMbbodg535 | dg535 |
mbbo | GPIB_IO | devMbboHeidAWE1024 | Heidenhein Encoder |
mbbo | GPIB_IO | devMbboKeithleyDMM199 | KeithleyDMM199 |
mbbo | GPIB_IO | devMbboTestGpib | GPIB Test |
mbbo | INST_IO | asynMbboInt32 | asynInt32 |
mbbo | INST_IO | asynMbboUInt32Digital | asynUInt32Digital |
mbbo | INST_IO | devMbboAbDcm | Ab Dcm |
mbbo | INST_IO | devMbboCan | CANbus |
mbbo | INST_IO | devMbboMPC | asyn MPC |
mbbo | INST_IO | devmbboStream | stream |
mbbo | INST_IO | devMbboTPG261 | asyn TPG261 |
mbbo | INST_IO | devMbboTPG261 | asyn TPG261 |
mbbo | VME_IO | devIK320Dir | Heidenhain IK320 Sign |
mbbo | VME_IO | devIK320Funct | Heidenhain IK320 Command |
mbbo | VME_IO | devIK320ModeX3 | Heidenhain IK320 X3 Mode |
mbbo | VME_IO | devMbboA32Vme | Generic A32 VME |
mbbo | VME_IO | devMbboAvme9440 | AVME9440 O |
mbbo | VME_IO | devMbboHP10895LaserAxis | HP interferometer |
mca | CONSTANT | devMCA_soft | Soft Channel |
mca | INST_IO | devMcaAsyn | asynMCA |
motor | CONSTANT | devMotorSoft | Soft Channel |
motor | INST_IO | devMotorAsyn | asynMotor |
motor | VME_IO | devE500 | E500 |
motor | VME_IO | devEMC18011 | EMC18011 |
motor | VME_IO | devESP300 | ESP300 |
motor | VME_IO | devIM483PL | IM483PL |
motor | VME_IO | devIM483SM | IM483SM |
motor | VME_IO | devMAXv | OMS MAXv |
motor | VME_IO | devMCB4B | ACS MCB-4B |
motor | VME_IO | devMCDC2805 | MCDC2805 |
motor | VME_IO | devMDrive | MDrive |
motor | VME_IO | devMDT695 | MDT695 |
motor | VME_IO | devMicos | Micos MoCo |
motor | VME_IO | devMM3000 | MM3000 |
motor | VME_IO | devMM4000 | MM4000 |
motor | VME_IO | devMotorSim | Motor Simulation |
motor | VME_IO | devMVP2001 | MVP2001 |
motor | VME_IO | devOms58 | OMS VME58 |
motor | VME_IO | devOMS | OMS VME8/44 |
motor | VME_IO | devOmsPC68 | OMS PC68/78 |
motor | VME_IO | devPC6K | PC6K |
motor | VME_IO | devPIasyn | PI Motor GCS2 |
motor | VME_IO | devPIC630 | PI C630 |
motor | VME_IO | devPIC662 | PIC662 |
motor | VME_IO | devPIC663 | PIC663 |
motor | VME_IO | devPIC844 | PIC844 |
motor | VME_IO | devPIC848 | PIC848 |
motor | VME_IO | devPIC862 | PIC862 |
motor | VME_IO | devPIE516 | PIE516 |
motor | VME_IO | devPIE710 | PIE710 |
motor | VME_IO | devPIE816 | PIE816 |
motor | VME_IO | devPIJEDS | PIJEDS |
motor | VME_IO | devPM304 | Mclennan PM304 |
motor | VME_IO | devPM500 | PM500 |
motor | VME_IO | devPmac | PMAC |
motor | VME_IO | devPMNC87xx | PMNC87xx |
motor | VME_IO | devSC800 | SC-800 |
motor | VME_IO | devSmartMotor | SmartMotor |
motor | VME_IO | devSoloist | Soloist |
motor | VME_IO | devSPiiPlus | SPiiPlus |
scalcout | CONSTANT | devsCalcoutSoft | Soft Channel |
scalcout | INST_IO | devscalcoutStream | stream |
scaler | INST_IO | devScalerAsyn | Asyn Scaler |
scaler | VME_IO | devScalerCamac | CAMAC scaler |
scaler | VME_IO | devScaler | Joerger VSC8/16 |
scaler | VME_IO | devScaler_VS | Joerger VS |
steppermotor | AB_IO | devSmAB1746Hstp1 | Allen Bradley 1746-HTSP1 |
stringin | CONSTANT | devSiSoft | Soft Channel |
stringin | CONSTANT | devSiTodString | Time of Day |
stringin | CONSTANT | devSiTodString | Time of Day |
stringin | GPIB_IO | devSidg535 | dg535 |
stringin | GPIB_IO | devSiGP307Gpib | Vg307 GPIB Instrument |
stringin | GPIB_IO | devSiHeidAWE1024 | Heidenhein Encoder |
stringin | GPIB_IO | devSiKeithleyDMM199 | KeithleyDMM199 |
stringin | GPIB_IO | devSiTestGpib | GPIB Test |
stringin | INST_IO | asynSiOctetCmdResponse | asynOctetCmdResponse |
stringin | INST_IO | asynSiOctetRead | asynOctetRead |
stringin | INST_IO | asynSiOctetWriteRead | asynOctetWriteRead |
stringin | INST_IO | devSiGeneralTime | General Time |
stringin | INST_IO | devSiHuberDMC | Huber DMC 9200 |
stringin | INST_IO | devSiMPC | asyn MPC |
stringin | INST_IO | devSiStrParm | asyn si stringParm |
stringin | INST_IO | devSiTPG261 | asyn TPG261 |
stringin | INST_IO | devSiTPG261 | asyn TPG261 |
stringin | INST_IO | devSiWiener | CANbus |
stringin | INST_IO | devStringinEnvVar | IOC env var |
stringin | INST_IO | devStringinEpics | IOC epics var |
stringin | INST_IO | devStringinStats | IOC stats |
stringin | INST_IO | devStringinStats | VX stats |
stringin | INST_IO | devstringinStream | stream |
stringin | INST_IO | devTestBlockInp | testBlock |
stringin | INST_IO | devTimestampSI | Soft Timestamp |
stringout | CONSTANT | devSoSoftCallback | Async Soft Channel |
stringout | CONSTANT | devSoSoft | Soft Channel |
stringout | GPIB_IO | devSodg535 | dg535 |
stringout | GPIB_IO | devSoHeidAWE1024 | Heidenhein Encoder |
stringout | GPIB_IO | devSoKeithleyDMM199 | KeithleyDMM199 |
stringout | GPIB_IO | devSoTestGpib | GPIB Test |
stringout | INST_IO | asynSoftGlue | softGlue |
stringout | INST_IO | asynSoOctetWrite | asynOctetWrite |
stringout | INST_IO | devSoEurotherm | asyn so Eurotherm |
stringout | INST_IO | devSoMPC | asyn MPC |
stringout | INST_IO | devSoStdio | stdio |
stringout | INST_IO | devSoStrParm | asyn so stringParm |
stringout | INST_IO | devstringoutStream | stream |
stringout | VME_IO | devIK320Parm | Heidenhain IK320 Parameter |
subArray | CONSTANT | devSASoft | Soft Channel |
swait | CONSTANT | devSWaitIoEvent | Soft Channel |
vs | INST_IO | devVacSen | asyn VacSen |
vs | INST_IO | devVacSen | asyn VacSen |
waveform | CONSTANT | devWfSoft | Soft Channel |
waveform | INST_IO | asynFloat32ArrayWfIn | asynFloat32ArrayIn |
waveform | INST_IO | asynFloat32ArrayWfOut | asynFloat32ArrayOut |
waveform | INST_IO | asynFloat64ArrayWfIn | asynFloat64ArrayIn |
waveform | INST_IO | asynFloat64ArrayWfOut | asynFloat64ArrayOut |
waveform | INST_IO | asynFloat64TimeSeries | asynFloat64TimeSeries |
waveform | INST_IO | asynInt16ArrayWfIn | asynInt16ArrayIn |
waveform | INST_IO | asynInt16ArrayWfOut | asynInt16ArrayOut |
waveform | INST_IO | asynInt32ArrayWfIn | asynInt32ArrayIn |
waveform | INST_IO | asynInt32ArrayWfOut | asynInt32ArrayOut |
waveform | INST_IO | asynInt32TimeSeries | asynInt32TimeSeries |
waveform | INST_IO | asynInt8ArrayWfIn | asynInt8ArrayIn |
waveform | INST_IO | asynInt8ArrayWfOut | asynInt8ArrayOut |
waveform | INST_IO | asynWfOctetCmdResponse | asynOctetCmdResponse |
waveform | INST_IO | asynWfOctetRead | asynOctetRead |
waveform | INST_IO | asynWfOctetWrite | asynOctetWrite |
waveform | INST_IO | asynWfOctetWriteRead | asynOctetWriteRead |
waveform | INST_IO | devwaveformStream | stream |
waveform | VME_IO | devWfBunchClkGen | APS Bunch Clock |