Experimental Physics and
Industrial Control System
I would like to announce and discuss some ideas for base modifications.
These are in detail:
1. Alarm Distribution over Links (MS or NMS) could be extended by an
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.
db: dbAccess, dbLock
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-funktion returns without doing anything. This change is
useful if using the conventional alarm handler as well as the new AMS
used by CSS.
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.
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.
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.
Related files: many records
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).
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.
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.
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.
Thats all for now - please forgive me my curious English.
- Re: Ideas for Codeathon Steve Lewis
- Re: Ideas for Codeathon Andrew Johnson
- Navigate by Date:
Re: Base 3.14.11 Release Timetable Andrew Johnson
Re: Ideas for Codeathon Steve Lewis
- Navigate by Thread:
Re: libCom tests results 32 bit compatibility mode on windows vista 64 Andrew Johnson
Re: Ideas for Codeathon Steve Lewis
ANJ, 02 Feb 2012