Re: query ioc/cas for list of channels

["Dohan, Donald" <dohan@bnl.gov>]

Hi Jamie:

The crawler that populates the IRMIS database examines the user's *.db files, and does not interact with the real-time IOC, as Andrew indicated.  This was particularly important for the APS feedback IOCs where client access to the IOC was restricted while the IOCs were operational.

When populating the IRMIS tables, only those fields of a particular record that are actually modified by the user are stored in the database.  This cuts down significantly on the database storage requirements.  If the user modifies 1 field in a record with 50 fields, then only that field is stored in the RDB.

A query to the database will return *all* of the fields in the record.  These are marked in the GUI as either 

1) modified by the user (contains an entry in the .db file)

2) modified by the user but whose value is not different from the default value.  (The user has put the field (unmodified) in the .db file).

3) the default value of the field.  This is extracted from the record definition tables.  This can change with time, in which case the new record definitions are stored in the RDB.

A huge convenience provided by the IRMIS PV database is that all of the process variables are fully instantiated (calls to msi), making it easier to visually examine EPICS logic.  The IRMIS application allows the user to follow link fields to/from the successive PVs.

The purpose of the ChannelFInder is to map a hardware device to a channel.  Lacking a full list of Pvs, some implementations of the ChannelFinder simply use the list of records (the .dbl list) from the IOC. Issues come up with the Channel Finder in which one field of the record accesses one device, and a different field in the record accesses a different device.  At the record level, it is a many-to-many mapping.  At the PV level, it is a one-to-many mapping.

The ChannelFInder is not a replacement for IRMIS. It needs a reliable list of Pvs, such as those provided by IRMIS.  

SLAC is working on an alternative approach to the crawler, which examines the dbDumpRecord output to populate the RDB.  The advantage here is that the crawler maintenance should be dramatically reduced.  It will, however produce a verbose list of all the (~50) Pvs per record (Andrews comment).

Don

From: Andrew Johnson <anj@aps.anl.gov>
Date: Wednesday, August 21, 2013 3:18 PM
To: Jameson Graef Rollins <jrollins@ligo.caltech.edu>
Cc: EPICS tech-talk <tech-talk@aps.anl.gov>
Subject: Re: query ioc/cas for list of channels

Hi Jamie,

On 08/21/2013 12:42 PM, Jameson Graef Rollins wrote:

But it is indeed the same thing I was looking for.  And unfortunately it

sounds like there's no good way to query a channel server for a list of its

records.

I must say I'm quite surprised to find out there's no method for doing

this.  It seems like a pretty obviously useful feature.

An obvious feature, but unfortunately one which could take up a lot of

bandwidth. The two popular solutions that have been developed to solve

this problem (IRMIS and the Channel Finder) both have the advantage that

they don't run on the real-time systems, so they don't run any risk of

loading the control system when someone does a wild-card name search by

mistake that returns a ridiculous number of PV names.

Many IOC records are not meant to be user-facing, they're doing internal

processing inside the IOC, and even for those records which do have

public fields, most of their fields are not supposed to be touched by

anyone other than the controls engineers responsible for the IOC.

Making every field of every record appear in a pull-down box in the

user's GUI is not something that most engineers on large control systems

want, even if those fields have been properly protected from

modification using Channel Access security (which is not universally used).

Also note the difference between records and PVs.  Your subject field

refers to channels (i.e. PVs), but your message body is asking for a

list of records.  The two are different.  For each record, there are

many possible PV names corresponding to the fields of the record.

Yes, sorry, that was maybe a little sloppy.  But I would settle for

either, actually, since there's obviously a lot of overlap.  The set of

records is just a subset of the set of PVs, and the additional fields in

the full set of PVs is predictable from the set of records.

It is a subset, but there are on average about 50 fields per record, so

the volume of data for the full list of PV names is rather larger.   We

have half a million records in our accelerator control system here at

the APS, so let's say about 25 million PV names which would take about

600MB just to hold the complete list of names.

There are thus significant down-sides to adding this "pretty obviously

useful feature" when it comes to a real-world EPICS control system,

which is probably why we haven't pursued adding it.

- Andrew

--

Advertising may be described as the science of arresting the human

intelligence long enough to get money from it. -- Stephen Leacock