V4 Standard Properties and Events

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