Difference between revisions of "V4 Standard Properties and Events"
| Line 3: | Line 3: | ||
== Properties == | == Properties == | ||
I'll start by going through the 'leaf' property names and their meanings. The hierarchies will be documented | I'll start by going through the 'leaf' property names and their meanings. The hierarchies will be documented below under Catalogs, and their usage under Events. | ||
My initial property set doesn't necessarily match what Marty and/or Jeff have in mind... | |||
=== value === | === value === | ||
| Line 11: | Line 11: | ||
This is a scalar or n-dimensional array of any of the basic types. | This is a scalar or n-dimensional array of any of the basic types. | ||
Q: Should array values use a different property name? | Q: Should array values use a different property name? If implicit conversion from an array type to a scalar type is supported then the answer can be no, but without such implicit conversion then we might want to make these different. | ||
| Line 18: | Line 18: | ||
An epicsTimeStamp. | An epicsTimeStamp. | ||
Note: This may have a subproperty at some sites that further describes the event that caused the value: beam type etc. | Note: This may have a subproperty at some sites that further describes the event that caused the value: beam type or destination, etc. I won't discuss this any further. | ||
| Line 25: | Line 25: | ||
Alarm severity, an enum {None, Minor, Major, Invalid}. | Alarm severity, an enum {None, Minor, Major, Invalid}. | ||
Q: Did we add Offline to this? | Q: Did we add Offline to this? I forget... | ||
| Line 31: | Line 31: | ||
Alarm status, a string. | Alarm status, a string. | ||
It would seem and interesting and logical change for the alarm status to become a subordinate property of the alarm severity (which we could then just call 'alarm'), but this is probably a bad idea for efficiency reasons as it would mean having to create another property catalog just to hold the status string. Therefor I'm keeping it at the same level unless someone else says something. | |||
Q: Do we hide status string compression stuff from the user, or instead make it a special kind of enum that keeps getting longer? | Q: Do we hide status string compression stuff from the user, or instead make it a special kind of enum that keeps getting longer? | ||
=== limits: upper, lower === | === limits: upper, lower === | ||
A pair of scalars of the same basic type as the associated value they are | A pair of scalars of the same basic type as the associated value they are subordinate properties of. Marty likes to use the names "low" and "high", but I think I prefer "upper" and "lower", which is what I'm proposing here. | ||
Limit value pairs are used for various properties: | |||
==== controlLimits ==== | ==== controlLimits ==== | ||
Range of values over which the user can easily change | Range of values over which the user can (easily) change a value, for graphical controls. | ||
==== convertLimits ==== | ==== convertLimits ==== | ||
Raw to Engineering units conversion process (this might not really be a standard property). | Used in the Raw to Engineering units conversion process (this might not really be a standard property). | ||
==== displayLimits ==== | ==== displayLimits ==== | ||
| Line 56: | Line 57: | ||
=== alarmLimits === | === alarmLimits === | ||
Marty has these replicating the current "high, low, severity" pattern repeated for an inner and outer range, but I | Marty has these replicating the current "high, low, severity" pattern repeated for an inner and outer range, but I would like to simplify this whole area into just minorAlarmLimits and majorAlarmLimits and drop the adjustable severity thing completely. This could reduce the complexity of the code in lots of places. | ||
| Line 66: | Line 67: | ||
=== choices === | === choices === | ||
An array of strings containing the choice text for each of the enumerated choices of the associated value. | An array of strings containing the choice text for each of the enumerated choices of the associated value. I'm assuming we need this, although I may be misunderstanding how Data Access handles enumerated types. | ||
== Catalogs == | == Catalogs == | ||
This section documents the standard property hierarchies, giving each one a property catalog name. | This section documents the standard property hierarchies, giving each one a property catalog name. It seems that we should only need to define the catalogs and the hierarchy that will get posted as a result of an event subscription. | ||
=== | === valueTimeAlarmCatalog === | ||
* value | * value | ||
| Line 85: | Line 81: | ||
* alarmSeverity | * alarmSeverity | ||
* alarmStatus | * alarmStatus | ||
This is the basic value monitor event catalog. | |||
=== guiCatalog === | === guiCatalog === | ||
This deliberately does not contain the value. It does seem a bit big though, can we split it up a bit? | This deliberately does not contain the value. It does seem a bit big though, can/should we split it up a bit? | ||
* choices | * choices | ||
| Line 97: | Line 95: | ||
* minorAlarmLimits | * minorAlarmLimits | ||
* controlLimits | * controlLimits | ||
=== valueCatalog === | |||
* value | |||
This is used for modifying fields, or if you really only want to get a record's value field with no associated metadata. | |||
=== alarmCatalog === | |||
* alarmSeverity | |||
* alarmStatus | |||
This is intended for alarm handlers, that really only want the alarm severity and status without the value. Is there a need for the timeStamp too? | |||
| Line 103: | Line 116: | ||
=== value === | === value === | ||
Posts a | Posts a valueTimeAlarmCatalog | ||
=== archive === | === archive === | ||
Assuming we still want this, it posts a | Assuming we still want this, it posts a valueTimeAlarmCatalog | ||
=== alarm === | === alarm === | ||
alarmCatalog | |||
=== gui change === | === gui change === | ||
Revision as of 16:20, 10 May 2005
This page is being used to develop the standard subscription events and related property hierarchies that we expect EPICS V4 servers and clients to use.
Properties
I'll start by going through the 'leaf' property names and their meanings. The hierarchies will be documented below under Catalogs, and their usage under Events.
My initial property set doesn't necessarily match what Marty and/or Jeff have in mind...
value
This is a scalar or n-dimensional array of any of the basic types.
Q: Should array values use a different property name? If implicit conversion from an array type to a scalar type is supported then the answer can be no, but without such implicit conversion then we might want to make these different.
timeStamp
An epicsTimeStamp.
Note: This may have a subproperty at some sites that further describes the event that caused the value: beam type or destination, etc. I won't discuss this any further.
alarmSeverity
Alarm severity, an enum {None, Minor, Major, Invalid}.
Q: Did we add Offline to this? I forget...
alarmStatus
Alarm status, a string.
It would seem and interesting and logical change for the alarm status to become a subordinate property of the alarm severity (which we could then just call 'alarm'), but this is probably a bad idea for efficiency reasons as it would mean having to create another property catalog just to hold the status string. Therefor I'm keeping it at the same level unless someone else says something.
Q: Do we hide status string compression stuff from the user, or instead make it a special kind of enum that keeps getting longer?
limits: upper, lower
A pair of scalars of the same basic type as the associated value they are subordinate properties of. Marty likes to use the names "low" and "high", but I think I prefer "upper" and "lower", which is what I'm proposing here.
Limit value pairs are used for various properties:
controlLimits
Range of values over which the user can (easily) change a value, for graphical controls.
convertLimits
Used in the Raw to Engineering units conversion process (this might not really be a standard property).
displayLimits
Expected range the value will lie within, for graphical displays of value.
alarmLimits
Marty has these replicating the current "high, low, severity" pattern repeated for an inner and outer range, but I would like to simplify this whole area into just minorAlarmLimits and majorAlarmLimits and drop the adjustable severity thing completely. This could reduce the complexity of the code in lots of places.
units
A string containing the units description text of the associated value and limits properties.
choices
An array of strings containing the choice text for each of the enumerated choices of the associated value. I'm assuming we need this, although I may be misunderstanding how Data Access handles enumerated types.
Catalogs
This section documents the standard property hierarchies, giving each one a property catalog name. It seems that we should only need to define the catalogs and the hierarchy that will get posted as a result of an event subscription.
valueTimeAlarmCatalog
- value
- timeStamp
- alarmSeverity
- alarmStatus
This is the basic value monitor event catalog.
guiCatalog
This deliberately does not contain the value. It does seem a bit big though, can/should we split it up a bit?
- choices
- units
- displayLimits
- majorAlarmLimits
- minorAlarmLimits
- controlLimits
valueCatalog
- value
This is used for modifying fields, or if you really only want to get a record's value field with no associated metadata.
alarmCatalog
- alarmSeverity
- alarmStatus
This is intended for alarm handlers, that really only want the alarm severity and status without the value. Is there a need for the timeStamp too?
Events
value
Posts a valueTimeAlarmCatalog
archive
Assuming we still want this, it posts a valueTimeAlarmCatalog
alarm
alarmCatalog
