Re: query ioc/cas for list of channels

[Andrew Johnson <anj@aps.anl.gov>]

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