save-and-restore service and EPICS vtype

[connorfi]

Hello,

I am developing a SAR REST client in LabVIEW. I am able to save snapshots of type VDouble,
but do not require all of the fields that SAR/EPICs vtype is expecting - namely Alarm and Display.
I am looking for simpler vtypes that provide a scalar numeric value field, a timestamp and perhaps
a string field that I can use for my own purposes. A numeric array version would also be desirable.

Is there a suggested vtype or some means to pass a reduced dataset into SAR? My JSON strings throw exceptions unless I have all of the fields and no nulls.

Also how are the AlarmStatus and AlarmSeverity enums of vtype-1.0.6.jar mapped to newer versions of EPICS? How does Phoebus handle this?

Thank you,
Connor

[georgweiss]

The save&restore service relies on the type system defined in the vtype dependency. There is no plan to change this for a different (simpler) type system.

As for mapping of enums and differences in EPICS versions I do not know how this has evolved over time. Save&restore in Phoebus relies on what is decoded from the EPICS data using the Java enums:

https://github.com/epics-base/epicsCoreJava/blob/master/epics-vtype/vtype/src/main/java/org/epics/vtype/AlarmStatus.java
and
https://github.com/epics-base/epicsCoreJava/blob/master/epics-vtype/vtype/src/main/java/org/epics/vtype/AlarmSeverity.java

[connorfi]

Thank you Georg,
I will proceed with sending all fields.

Those were the files I was referring to. I am just not sure how things will behave when mapping from EPICS R7 since the enums differ so greatly:
https://epics.anl.gov/base/R7-0/7-docs/menuAlarmSevr.html
https://epics.anl.gov/base/R7-0/7-docs/menuAlarmStat.html

Right now I am simply using the UNDEFINED values of Severity and Status for EPICS values that don't correlate. Am I missing something about how newer EPICS Alarm data can be translated to these older vtype enums?

Connor

[kasemir]

Also how are the AlarmStatus and AlarmSeverity enums .. mapped to newer versions of EPICS?

Channel Access supported alarm severities OK, MINOR, MAJOR, INVALID.
For alarm status, it had that list of values that you link, with the inherent problem that channel access itself cannot transfer those values because the number of labels in a DBR_ENUM_... is less than the number of options in that https://epics.anl.gov/base/R7-0/7-docs/menuAlarmStat.html

With the newer versions of EPICS, you get PV Access as a new protocol.
PV Access supports alarm severities OK, MINOR, MAJOR, INVALID plus a new UNDEFINED option.
For alarm status, it uses the "String message" which can have arbitrary values, including those read from the channel access alarm status, and uses a new "status" to indicate the origin of the alarm (driver, database, ...).
Details are in https://docs.epics-controls.org/en/latest/specs/Normative-Types-Specification.html#alarm-t

The VType's alarm basically uses the newer way of describing alarm from the PV Access protocol.
So VType == PV Access alarm info == "newer", channel access == "older".

[connorfi]

Thank you for this description, Kay. It definitely helps fill some gaps in my understanding. I still have more to look into and would like to keep this discussion open for now.