Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 19 Feb 2009 08:33:39 -0700

> > *6. CA Support for "Our ArchiveRecord" and Others*
> > The DESY archive record samples "value, time and severity" into an array
> > of structures. Unfortunately we can not pass this array over channel
> > access directly (as far as I know). So we have additional arrays with
> > value (double), seconds_epoch (ulong), nanoseconds (ulong) and severity
> > (short). It would be better and more safe (locking is not provided well
> > now) if we could use something like an array of
> > "DBR_TIME_DOUBLE_STAT_SEVR (or so).
> 
> I will leave Jeff Hill to comment on the feasibility of adding new request
> types like this and the idea below to CA.

The quick answer is that there are two ways to do this. 

1) We certainly can code new data types into the db_access data model. The primary obstacle to overcome, when satisfying your request, will be that CA and db_access both currently expect that arrays occur only with the value field, and that the value field is always the last field in the structure. Thus, making arrays of DBR_TIME_DOUBLE_STAT_SEVR tends to break data model consistency in a number of important places. In the CA client API, CA client library, in the CA protocol, in the CA server, and in the database library. I think that an inconsistent approach to arrays in the legacy CA client API is what we might be most fearful of. Furthermore, I think it's safe to say that the scale of the changes in the base codes is not making this appropriate for an R3.14 patch.

2) So it appears that we need a better API and when we make that jump it's important to adopt a flexible approach which will accommodate future needs. What we really need is more flexible APIs so we can have generalized client and service specified formats for aggregating data. I have written a design document (it's on the wiki) describing a new protocol that can have this level of flexibility, but for R3.15 we are concentrating only on new flexibility allowing service specified formats for aggregating data on the server's (IOC's) event queue, and on an ability for clients to specify in their subscriptions generic filtering expressions that test service specific parameters determining which subscription updates will be sent. We admit to being strongly requirements driven for our upgrade here at LANSCE, but nevertheless we are committed to a very general approach which should have excellent utility for the community. 

To summarize, the db_access data model has many severe constraints, but changing the model to make its approach to arrays inconsistent may not be a great strategy, and making large changes in R3.14 probably isn’t a robustness enhancing strategy either. From my perspective, the Data Access library is the proper flexible, runtime bound, API for accessing client/service specified data aggregation formats that we will need in the future. Furthermore, wire protocol flexibility for client / service specified data formats is not on the short list, but event queue flexibility and API flexibility is. Once the near term event queue goals and API upgrades are done, then wire protocol flexibility looks like a logical next step. I admit to working specifically on LANSCE's immediately needs for its upgrade, and while protocol flexibility is certainly going to be very useful here it hasn’t been given as high a priority near term as the event queue changes.

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Monday, February 16, 2009 4:45 PM
> To: [email protected]
> Subject: Re: Ideas for Codeathon
> 
> Hi Bernd,
> 
> Thanks for this very interesting list.
> 
> On Sunday 15 February 2009 14:03:23 Bernd Schoeneburg wrote:
> >
> > *1. Alarm Distribution over Links (MS or NMS) could be extended by an
> > additional "MSI"*
> > Often records like calc read data from other records using in-links
> > (INPA etc.). The record calculates something that has physically a
> > different meaning than the input data. If the input data is not valid,
> > the calculation can not deliver a valid result. So MS must be used to
> > make this visible. On the other hand, a "high"-alarm in the source
> > record should not alter the alarm state of the calc record. Therefore we
> > propose to introduce a third choice: MSI = maximize severity invalid. If
> > the source record has "invalid" severity, the severity of the local
> > record is maximized, otherwise nothing happens.
> 
> Great idea, there are spare bits in the pv_link.pvlMask to store this and
> the
> implementation should be relatively easy.  If this does get implemented it
> will need a corresponding change to VDCT to match (but that's a separate
> task).
> 
> 
> > *2. Alarm Disable Field in all Records
> > *If a record rises an alarm because of a "known bug" or in case of
> > maintenance or special operating conditions, it would be a very smart
> > solution to disable this alarm at the source. Otherwise all connected
> > clients must mask this alarm individually. Setting all severities to
> > "NO_ALARM" does not help if the alarm is set by the device support.
> > Setting a new disable-field to "DISABLE" would set SEVR to "NO_ALARM"
> > and STAT to something like "ALMDIS" or so. Changing the disable field
> > would need some special function which sends out the change. If
> > disabled, the alarm bit in the monitor mask is ignored and the
> > logAlarms-hook-function returns without doing anything. This change is
> > useful if using the conventional alarm handler as well as the new AMS
> > used by CSS.
> 
> This idea needs some discussion.  There is a related suggestion in my list
> called "OFFLINE Alarm Status" which takes a different approach, requiring
> device support to set an Invalid/Offline alarm instead.  I don't know
> whether
> using a NO_ALARM severity with a different status would work properly with
> alarm acknowledgments.
> 
> 
> > *3. Alarm Delay Field in all Records*
> > Beside the alarm limits we have a "HYST" in the analog records. Why not
> > also a "DLY" (delay). Some values are very unstable and have some noise
> > or over-swing. So a short time over/under the limit should be allowed
> > sometimes. Implementing this in the ioc has two advantages: 1.:It is
> > analog to "HYST" which is a value-related hysteresis. "DLY" is a
> > time-related hysteresis. 2.:Sending a lot of good/no-good messages to
> > the clients could be avoided. This change is not so easy, many things
> > must be considered.
> 
> Any new fields needed can be added to each record type as they are added to
> the support code; they should not be added to dbCommon.dbd though.  I would
> like to see a clear description of how the final alarm code will work, but
> I
> have no particular objections to these ideas being implemented in the Base
> record types.
> 
> 
> > *4. Device Status Field in all Records*
> > If the device support encounters a problem, it has only limited
> > possibilities to say that to the operators. Alarms could be rised like
> > "READ" or "COMM". Detailed information can only be sent to a log-file. A
> > string-type field like "DSTA" would be a destination for such messages,
> > that could be displayed by each graphic display.
> 
> We support writing to a central logServer for this kind of information.  I
> agree that it's not as convenient as putting it in a field, but 40
> characters
> for an error message really isn't very many, and adding 40 bytes to the
> size
> of every record would be impossible for some smaller embedded IOCs.
> 
> 
> > *5. get_alarm_double should not return unused limits
> > *This has to be explained: When a display widget is coming up, it may
> > need some values from the record, like display limits, control limits
> > and alarm limits. Alarm limits are needed on a bargraph widget to mark
> > some positions with arows or lines. If the corresponding alarm is not
> > used, it's severity is set to "NO_ALARM". This means, crossing this
> > limit does nothing! Specially when the EGU-range includes zero (EGUL <
> > 0, EGUF > 0) then the arrows are missleading.
> > The solution: If the alarm is not used, the records function
> > "get_alarm_double" should return "NaN" for this limit. In this way the
> > client knows, not to display the limit.
> > The direct access to the limit fields is not affected.
> 
> I agree the current requests for compound types that return alarm
> information
> are of little practical use to a display widget because they don't account
> for the severity that applies to each alarm level.  However I'd like to
> know
> what should be returned if I set HSV to INVALID_ALARM, or if I set both HSV
> and HHSV to MINOR_ALARM?  Also the use of NaN values doesn't solve what
> should happen with the DBR_GR_LONG and analogous CA types that have integer
> warning levels — get_alarm_double() requests the values from the record as
> doubles, but dbAccess subsequently converts them to integers if necessary.
> 
> 
> > *6. CA Support for "Our ArchiveRecord" and Others*
> > The DESY archive record samples "value, time and severity" into an array
> > of structures. Unfortunately we can not pass this array over channel
> > access directly (as far as I know). So we have additional arrays with
> > value (double), seconds_epoch (ulong), nanoseconds (ulong) and severity
> > (short). It would be better and more safe (locking is not provided well
> > now) if we could use something like an array of
> > "DBR_TIME_DOUBLE_STAT_SEVR (or so).
> 
> I will leave Jeff Hill to comment on the feasibility of adding new request
> types like this and the idea below to CA.
> 
> 
> > *7. CA Request Type for Archiver which includes Deadband (ADEL)*
> > The channel archiver can not archive the current ADEL of a PV. So the
> > "quality" of an archived value is not known. Between two
> > time-value-pairs it is not defined in which corridor the value could
> > have been in between. For display and for data compression this deadband
> > value is helpful. A new CA request type including the deadband would
> > solve the probem.
> 
> You could always archive the ADEL field separately, although admittedly
> that
> would make it harder for the automated tools to use the information.
> However
> it doesn't make sense to ask for the deadband for a bi record, which shows
> that this requirement doesn't really make sense for all record types.
> 
> 
> > *8. Meta-Info for the Waveform Record
> > *The waveform record is often used to hold a buffer contents of a fast
> > ADC. The index of the record corresponds to an amount of time, the
> > sample time. The value is either an integer, which must be converted or
> > a float, which means some engineering unit. We would like to propose
> > fields for the sampling rate and/or time scale and the trigger position
> > (pre/post) in seconds or in samples. A kind of LINR would also be
> > usefull if the array-type is not floating-point.
> > These changes would enable the archive viewer to show the events in a
> > correct time scale.
> 
> Bob already has "CA support for Array with Timebase" on the To-Do list,
> this
> is similar, probably a superset of what he's asking for.
> 
> 
> > *9. Epics General Time: Allow more than one NTP Server*
> > It can be, that this is not related to Epics-base. epicsGeneralTime
> > facility is using os-depending services. I think osdNTPGet is the place
> > were an extension would be necessary, if alternative NTP servers are
> > needed. But nevertheless I mention it here. If the desired server (or
> > the network path to it) fails, a second server would be better. In my
> > changes I once did for the tsDrv in 3.13.x a list of servers in the
> > environment variable was foreseen. Perhaps this is possible too now.
> 
> General time allows you to register your own time providers, so it should
> be
> quite easy to add providers for additional NTP servers.  The osiNTPTime.c
> provider in libCom can't talk to multiple servers at the moment because the
> NTP client code in RTEMS wasn't written with that in mind, but we'd be
> happy
> to see a better NTP time provider if someone wants to write one (preferably
> one with a built-in PLL for doing slow adjustments).  This doesn't have to
> be
> part of Base, although eventually it could be incorporated into Base.
> 
> - Andrew
> --
> The best FOSS code is written to be read by other humans -- Harold Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System