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. I'm also introducing the concept of 'views' of a record, which provides ways of looking at different aspects of a record and its fields.

Properties

We start by defining the 'leaf' property names and their meanings. The hierarchies and their intended usage will be documented below.

My initial property set doesn't necessarily match what Marty and/or Jeff had in mind, I'm making some changes.

The property identifier used in C/C++ code to refer to each property should be created by (we currently have two methods, both a bit long IMHO):

• Marty appends 'PropId' to the name given, e.g. timeStampPropId, alarmSeverityPropId.
• Jeff and Ralph prepend 'propertyId' to the name, e.g. propertyItTimeStamp, propertyIdAlarmSeverity.
• I'd suggest prepending 'pid' to the name, e.g. pidTimeStamp, pidAlarmSeverity.

Which we eventually use doesn't really matter as long as we agree, although IMHO our source code will look slightly more uniform and be easier to read if we prepend rather than append to the name.

value

This is the fundamental data value we expect to be returned by all CA data transport operations. It could reference a scalar or array of any of the basic types, or just return the property catalog for a structure, so it isn't necessarily a leaf property.

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 idea any further here, just note the possibility for future reference.

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 gets longer whenever a new string comes in?

limits: upper, lower

A pair of scalars of the same basic type as the associated value the relate to. Marty is using the names "low" and "high", I prefer "upper" and "lower" which more closely match the old db_access.h structures; we need to pick one.

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 is using the V3 "limit, severity" pattern repeated four times inside the record, but I would like to simplify this, at least once we get to the property catalog. I suggest completely dropping the idea of having an adjustable severity associated with each limit, and instead provide the properties:

• minorAlarmLimits
• majorAlarmLimits
• invalidAlarmLimits

This should reduce the complexity of the code in the clients, since the main reason for providing these limits is to be able to put them up on a meter display or similar, and for that you want to know where the individual limits are.

units

A string containing the units description text of the associated value and limits properties.

Data Rate-Limiting

If we're allowing clients to specify the size of their deadbands or to limit data transfer by some other means, we should provide some way for the database designer to give some hint to a CA client that doesn't know anything about a particular record what data rates and/or noise it should expect to see.

The obvious property to support might be

• deadband

However we could instead use something like

• noiseLevel

Any ideas/comments?

Views

When a client gives a PV name to CA, everything between the first dot and the first colon following that dot is the name of a 'view' associated with that record type, which controls what data will be returned. The colon may be followed by additional information such as a field name or other data needed to describe the specific view required, but there should be no spaces, since as a whole the PV name should not contain any:

<recordName>.<viewName>:<viewArgs>,...

Q: Does anybody want to change that colon into something different?

A record type defines the views it wants to provide in the DBD file - a view consists of a series of (property name, field name) pairs that declare the complete property catalog for this view.

If there is no dot in the PV name, the client is asking for the default view of the record, which in V3 meant its VAL field. In V4, the record's DBD file will specify what the default view of the record should be; it will usually return a catalog containing the value field (or some other default field) and all of its associated metadata.

A standard view called "field" is created automatically for each record type, which provides access to all of the accessible record fields in the record.

Standard Views

These views contain the metadata that we expect most general-purpose CA clients to request when fetching or monitoring a channel.

In all cases the view's property catalog should include a value property, which contains the value of the thing actually being requested. Channel Access will not send any property values that the client doesn't include in its request catalog, so there should be no problem in making the standard views wide, and having the clients limit what gets sent by what they actually request.

Q: What do we do/expect to happen for puts? Can I change a record's displayLimits by putting a catalog with a displayLimits property to its value view?

value

Most record types will provide something like this list of properties from their value view, which will usually also be marked as being the default view of the record type.

• value
• timeStamp
• alarmSeverity
• alarmStatus
• units
• displayLimits
• majorAlarmLimits
• minorAlarmLimits
• controlLimits

The intent here is that an MEDM widget will subscribe for those properties that it wants from the channel, and the record will return those which it has.

field

There needs to be a view that provides direct access to a record's visible fields, without any of the metadata that the valueView adds to the value field etc. This view will accept a view argument (after the colon in the channel name) that specifies a field name or even name.name etc to descend into the field hierarchy.

As described above, the property catalog returned will contain a value property, but what this contains depends on the view argument. If the view argument is the name of a basic type field, the value returned will be the value of that field; if the field is a structure, the value property will map to a property catalog that contains the complete contents of that structure (the property names used in this catalog will exactly match the field names of the structure).

If no view argument is provided in the channel name, the value property will map to a property catalog containing all the readable fields of the record.

We could drop the outer catalog and just return every field in the outer catalog, but I think it will be easier for clients to always expect to get a value property and for everything to be found inside that.

The field view may be directly usable for the redundant IOC replication requirement, and should also permit a version of capr to be written that just goes to the field view and prints out the complete structure it gets back.