Experimental Physics and
Industrial Control System

"Schoeneburg, Bernd" <[email protected]> · Tue, 17 Feb 2009 20:43:33 +0100

Hello Andrew and all,

<SOMETHING NEW IN THE END!>

Andrew Johnson schrieb:

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).

Very good!

*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.

This looks for me like a solution for a different problem. If a record

has its alarm disabled, other record should still be able to read data

from it and the severity (if MS of the inlink is set) should not become

invalid. Nothing is really offline.

In an alarm tree display, the root of the tree shows the highest

severity of the leaves. An alarm-disabled record therefor must have

NO_ALARM severity for not to interfere the status of the root. Why is

acknowledgment necessary if the severity is NO_ALARM?

*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.

Ok, I asume that the reason for not to put it in dbCommon.dbd is, that

this would apply to all records even if their record support does not

support the new function, which may be confusing, right?

I will try to make a description - its not so easy.

*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.

May be that less than 40 characters are sufficient. Device specific

short error codes which can be documented in a manual could be enough. A

long description in the record field is not necessary.

*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.

It may be my fault, but I don't understand the first problem. I don't

care of the severities except checking for beeing NO_ALARM. The "arrows"

in the display widget is useless if the corresponding severity is

NO_ALARM because the code of the record (ai, longin,..) does not compare

the value with the limits if the severity is 0 (NO_ALARM). HIHI and LOLO

ist alway compared prior to HIGH and LOW and the function returns if one

of it applies.

For the second problem (dbAccess converts back to INT)... - well, no

idea. Anyone uses bargraphs of integer values?

*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.

OK.

*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.

Agree fully. For a bi record ADEL=0 would be correct. But I don't know

how to achive this in a clean way.

*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.

Good idea.

*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.

I did once write an improved NTP support including PLL with multiple

server support for the old tsDrv. Perhaps we could use parts of this

code. Matthias held a talk about it on the EPICS meeting in june 2006. I

just found my presentation.

- Andrew

Thank you very much for reviewing and for the feedback, Andrew.

I have one additional proposal:

10. Make "Smoothing" in aiRecord independent of Conversion

The SMOO field in the aiRecord is evaluated in the convert function,

which is not executed if the device support read function returns 2

(don't convert). If the device delivers a float value directly, I do not

see a reason not to smooth it. Can we take the smoothing code out of

convert()?

- Bernd

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System