Re: Questions on EPICS 7 NT types and CA → PVAccess migration

[Simon Rose via Tech-talk <tech-talk at aps.anl.gov>]

Hi Ernest -

 

Regarding CA links, there are also PVAccess links as well, though the syntax is different, see

 

https://epics-base.github.io/pvxs/ioc.html#pvaccess-links

 

record(longin, "tgt") {}

record(longin, "src") {

    field(INP, {pva:{pv:"tgt"}})

}

 

Cheers,

 

Simon Rose

ESS

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Reply to: Ralph Lange <ralph.lange at gmx.de>
Date: Saturday, 7 February 2026 at 16:05
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Questions on EPICS 7 NT types and CA → PVAccess migration

 

On Fri, 6 Feb 2026 at 15:06, Williams Jr., Ernest L. via Tech-talk <tech-talk at aps.anl.gov> wrote:

1. Optional fields in EPICS 7 NT types

In EPICS3, records share a common set of fields (e.g., alarm status/severity, timestamp, description), which are always present regardless of whether a specific application strictly requires them.

In contrast, EPICS 7 NT types define many of these fields as optional, and producers are not required to implement them.

• What design considerations led to this change?

• What are the intended advantages and trade-offs of making these fields optional?

• Are there recommended best practices for when producers should include fields such as alarm and timeStamp, especially for higher-level consumers such as ML pipelines, archivers, or monitoring tools?

 

Both CA and PVA are network protocols aimed at transporting data efficiently. They are independent of the applications on both ends. Many different client and server applications contain a CA or PVA server or client (or both, or all).

 

The EPICS Process Database is just one of those applications. Its internal structures (records, fields) are largely unchanged between EPICS v3 and EPICS 7. What you describe for EPICS v3 stays true for EPICS 7.

 

The functional equivalence is between CA's DBR_* types and PVA's Normative Types.

 

CA has a set of fixed DBR_* types, including metadata, e.g., for a double value:
DBR_DOUBLE - only the value

DBR_STS_DOUBLE - value, status, severity

DBR_TIME_DOUBLE - value, status, severity, timestamp

DBR_GR_DOUBLE - value, status, severity, precision, units, display limits, alarm limits

DBR_CTRL_DOUBLE - value, status, severity, precision, units, display limits, alarm limits, control limits

 

In the NT world of PVA, this is expressed as a structure with optional elements:

NTScalar :=
structure
    scalar_t    value
    string      descriptor  :opt
    alarm_t     alarm       :opt
    time_t      timeStamp   :opt
    display_t   display     :opt
    control_t   control     :opt

 

Obviously, the optional parts map to the metadata that CA makes available through the extended DBR_* types - plus the descriptor that was left out in CA (clearly a design flaw).

 

Again, the two approaches are functionally equivalent - that was an important design idea, as it allows users to migrate without major disruptions.

 

Where a CA client would use a DBR_DOUBLE type to write a value and a DBR_CTRL_DOUBLE type structure to read its metadata, a client using PVA/NT uses NTScalar for both, either without or with optional elements.

 

Applications (e.g., IOCs, middle-layer services, etc.) are free to provide the optional parts. They should provide them if they have meaningful data. E.g., a service on top of a database that might not have use for the control or alarm parts is not forced to implement them.

 

QSRV, the NT-based PVA server on the IOC, maps record fields to NT elements in the same fashion that rsrv, the CA server on the IOC, maps them to DBR_* types. That's why some general-purpose clients, e.g., Phoebus, are able to switch the underlying protocol through configuration.

 

Hope this clarifies things...

 

Cheers,
~Ralph