EPICS FAQ

General

What is EPICS?

EPICS is a set of software tools and applications which provide a software infrastructure for use in building distributed control systems to operate devices such as Particle Accelerators, Large Experiments and major Telescopes. Such distributed control systems typically comprise tens or even hundreds of computers, networked together to allow communication between them and to provide control and feedback of the various parts of the device from a central control room, or even remotely over the internet.

The term (EPICS) also refers to the collaboration of organizations that are involved in the software's development and use. It was originally written jointly by Los Alamos National Laboratory and Argonne National Laboratory, and is now used by many large scientific facilities throughout the world. Development now occurs cooperatively between these various groups, with much sharing of I/O device support and client applications.

How Can I Learn More About EPICS?

Many of the sites listed above have tutorials, slides, or overviews of EPICS. It is helpful to peruse several different sites to get a broad exposure of how the facilities use EPICS.

The Getting Started With EPICS Lecture Series presented and recorded at the Advance Photon Source in the Fall of 2004 is probably the most recent and exhaustive series of training presentations. The lectures are available via synchronized streaming video and the Power Point slides are also available for downloading via the above link.

Is There a Demo I Can Play With?

The most recent published demo application is the Virtual Linac, which is available here. Also look at the LivEPICS CD images for a bootable system that you can use without having to install anything on a PC.

Hardware

What Hardware Platforms Can Be Used With EPICS?

The Platforms Supported sections of EPICS Base R3.13 and EPICS Base R3.14 provide a list of currently supported host and IOC target platforms for the corresponding EPICS Base release.

What I/O Devices Are Supported?

Lots. Most available I/O support is listed in the Supported Hardware Database but for various reasons that list is never complete, so it's always worth sending a message to tech-talk if there's something that you think other sites may be using but don't see listed.

Which target architecture should I use?

VxWorks

Hardware	Target Architecture
Motorola MVME-162	vxWorks-68040
Motorola MVME-167	vxWorks-68040
Motorola MVME-172	vxWorks-68040
Motorola MVME-2100	vxWorks-ppc603 if has 32 MB of RAM or less; vxWorks-ppc603_long if has more than 32 MB of RAM
Motorola MVME-2700	vxWorks-ppc604 if has 32 MB of RAM or less; vxWorks-ppc604_long if has more than 32 MB of RAM
Motorola MVME-5100	vxWorks-ppc604 if has 32 MB of RAM or less; vxWorks-ppc604_long if has more than 32 MB of RAM
Motorola MVME-5110	vxWorks-ppc604_long, or vxWorks-ppc604_altivec to use the AltiVec coprocessor
Motorola MVME-5500	vxWorks-ppc604_long, or vxWorks-ppc604_altivec to use the AltiVec coprocessor
Motorola MVME-6100	vxWorks-ppc604_long, or vxWorks-ppc604_altivec to use the AltiVec coprocessor

IOC Core Software

What are the relationships between Records, Fields, PVs and Channels?

The IOC database manages Records. A Record has Fields, for example an analog input record "fred" has fields such as

• VAL (value)
• EGU (Engineering Units)
• TIME (Timestamp)
• HOPR (High Operator Range)
• LOPR (Low Operator Range)
• STAT (Alarm Status)
• SEVR (Alarm Severity)
• ...

You can use a database (.db) file or the dbgf and dbpf commands to get and set with the fields of a record.

The Channel Access network protocol gives you access to Channels. A Channel has Properties. The Channel "fred" has properties such as

• value
• time stamp
• units
• upper control limit
• lower control limit
• status
• severity, ...

You use the DBR_... request types to read/write the properties of a channel. Although these are called "database request types" DBR_..., they really should be called "channel" or "property" request types.

How do Records map to Channels, and how do Fields of a Record map to the Properties of a Channel? To really understand this, you have to use the force and read the source. The result makes sense in the few but most common cases; it doesn't always make sense in many of the other possible cases.

Our first example makes perfect sense: You have a channel "fred" for an AI record "fred", and ask Channel Access for its value as a DBR_CTRL_DOUBLE. Your channel will provide its properties in a dbr_ctrl_double structure, mapped to the following fields of the record:

value = VAL

status = STAT

severity = SEVR

precision = PREC

units = EGU

upper_ctrl_limit = HOPR

lower_ctrl_limit = LOPR

...

You can also ask for a DBR_TIME_DOUBLE and get the

value = VAL

stamp = TIME

...

The time stamp is of course the time of the last value update, so it's the time stamp that belongs to the value. This case makes perfect sense.

The next good example is a channel "fred.SCAN", which is of type ENUM and you can get the DBR_CTRL_ENUM properties:

value = SCAN

strs = { "Passive", "Event", ..., ".1 second" }

Good, that's the current value as well as corresponding enumeration strings. But there's also

status = STAT

severity = SEVR

Those are status & severity of the "fred" record as a whole. A "NO_ALARM"/"NO_ALARM" or "READ"/"INVALID" pair in there doesn't say anything about the SCAN field, only about the "fred" record as a whole.

Now attach a channel to "fred.HOPR" and read the DBR_TIME_DOUBLE:

value = HOPR

stamp = TIME

You get a time stamp that has nothing to do with the value. It's not the time when HOPR was last updated.

Attach a channel to "fred.PREC" and read a DBR_CTRL_DOUBLE:

value = PREC

units = EGU

status = STAT

severity = SEVR

lower_ctrl_limit=-32768

upper_ctrl_limit=32767

The value and units are OK, but the status & severity are again really properties of the "fred" record as a whole, not of the PREC field which we were asking about. The two control limits also give the range of the 16 bit number that the PREC field holds, even though most values in that range won't make any sense for this field.

So if your channel name is simply a record name, the mapping of record fields to channel properties makes sense. In other cases, you have to look at the source code of the record to figure out what you'll get, and in many cases it's not what you might like.

You also have to understand that Channel Access cannot introspect a record (i.e. iterate over all its fields). There is no DBR_ALL_FIELDS type, only a fixed set of DBR_... requests which are hardcoded to get particular record fields or properties of a field by the record type's code.

The Collaboration

How Do I Join the Collaboration?

There is no formal membership criteria or process. If you begin attending the semi-annual collaboration meetings, submit questions or respond with answers on the tech-talk list-server, or share your EPICS device support or applications with others, you will be warmly welcomed as a contributing member of the collaboration.

What Are Some of the Collaboration Activities?

Questions, comments, solutions, and other dialogue are routinely exchanged on the EPICS mailing list tech-talk. If a question is worded thoughtfully and with sufficient detail, it is not uncommon to receive an answer (or sometimes several answers) in a few hours. The more precise the question, the more likely you will receive an expedient response.

There are semi-annual EPICS Collaboration Meetings where people give short talks on recent accomplishments, advances, changes, etc. This is a fertile ground for the exchange of ideas with respect to control systems. Agendas and presentations from most past meetings can be found on the website meetings page.

It is also not uncommon for individuals to visit other labs for short term assistance, training, or advice. This is a very beneficial aspect of the collaboration.