Experimental Physics and
Industrial Control System

"Zelazny, Michael Stanley" <[email protected]> · Wed, 21 Aug 2013 16:36:05 -0700

Don,

dbDumpRecord only shows fields that are not defaulted.  Example:

dbDumpRecord shows:

record(stringout,"PNBN:MP00:1:NAME") {
        field(DESC,"PNET bit field Id")
        field(PINI,"YES")
        field(DTYP,"Soft Channel")
        field(UDF,"0")
        field(VAL,"YY")
        info("autosaveFields","VAL")
}

...for

sioc-sys0-pn00>dbpr("PNBN:MP00:1:NAME",5)
ACKS: NO_ALARM      ACKT: YES           APST: On Change     ASG:                
ASP: (nil)          BKPT: 00            DESC: PNET bit field Id                 
DISA: 0             DISP: 0             DISS: NO_ALARM      DISV: 1             
DOL:CONSTANT        DPVT: (nil)         DSET: 0xe0fd70      DTYP: Soft Channel  
EVNT: 0             FLNK:CONSTANT 0     IVOA: Continue normally                 
IVOV:               LCNT: 0             LSET: 0xb71fc2d8    
MLIS: 68 9f d8 08 68 9f d8 08 01 00 00 00                   MLOK: 50 e2 af 08   
MPST: On Change     NAME: PNBN:MP00:1:NAME                  NSEV: NO_ALARM      
NSTA: NO_ALARM      OMSL: supervisory   OUT:CONSTANT        OVAL: YY            
PACT: 0             PHAS: 0             PINI: YES           PPN: (nil)          
PPNR: (nil)         PRIO: LOW           PROC: 0             PUTF: 0             
RDES: 0x83b1e50     RPRO: 0             RSET: 0x341620      SCAN: Passive       
SDIS:CONSTANT       SEVR: NO_ALARM      SIML:CONSTANT       SIMM: NO            
SIMS: NO_ALARM      SIOL:CONSTANT       SPVT: (nil)         STAT: NO_ALARM      
TIME: 2013-08-19 10:57:26.820436412     TPRO: 0             TSE: 0              
TSEL:CONSTANT       UDF: 0              VAL: YY             
sioc-sys0-pn00>

Mike

________________________________________
From: Dohan, Donald [[email protected]]
Sent: Wednesday, August 21, 2013 1:59 PM
To: Andrew Johnson; Jameson Graef Rollins; Zelazny, Michael Stanley
Cc: EPICS tech-talk
Subject: Re: query ioc/cas for list of channels

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 <[email protected]<mailto:[email protected]>>
Date: Wednesday, August 21, 2013 3:18 PM
To: Jameson Graef Rollins <[email protected]<mailto:[email protected]>>
Cc: EPICS tech-talk <[email protected]<mailto:[email protected]>>
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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System