Display of PV valueAlarm fields intermittent

[GDH-ISIS]

When a bob file is created to display a PV via pvaccess (e.g. pva://root:ai1), Phoebus client connects to the PV and updates. However, when asked to display the PV alarm or warning limit fields, the widgets do not display the field in question reliably.

Points to note

• Example PV/field pva://root:ai1/valueAlarm/highAlarmLimit
• Phoebus client built to commit 49e516e
• Connection appears to work sometimes (Re-load Display works intermittently - feels possibly like an immediate timeout)
• Client on Windows operating system
• Java 21, Phoebus 5.0.1 SNAPSHOT
• Using standard example EPICS base IOC running in docker. Simple bob file attached.
• Using a pvaccess gateway, but I think this is fine due to below.
• Older Phoebus client works.
• Phoebus client built to commit 98f3e59 does appear to work.

test.zip

[kasemir]

If you simply display pva://root:ai1 in a text update widget or probe, does that indicate the alarm severity?

Using pva://root:ai1/valueAlarm/highAlarmLimit to fetch the alarm threshold has the same issue as pva://root:ai.HIHI or ca://root.ai.HIHI. They are specific to the PV Access normative type or assume that there's an analog record, when you might well have a custom p4p or pcas server provide the data.

Just pva://root:ai1 or ca://root:ai1 reads the value with meta info (units, limits, ...) into a VType. The text update widget or probe display the value with units, indicate the alarm state etc. If there's a need to extract the alarm info from the VType, we should add formula functions, for example

=alarmHighLimit(`pva://root:ai1`)

[GDH-ISIS]

I can confirm that simply displaying pva://root:ai1 in a test widget does indicate the value, but not the severity. The alarm severity, along with the description, HIHI, HIGH, LOW, LOLO appear via the tooltip. A probe on root:ai1 shows all the information as expected (Units, Format, Display Range, Control Range, Warnings, Alarms)
The info above is useful to know about, and adding a new formula function sounds good to me. May I just ask whether you think there has been a change that might relate to what we are seeing? If our approach is not correct, we probably need to alter the way we have done some of our screens - it has worked in the past without problem using pva://root:ai1/valueAlarm/highAlarmLimit

[kasemir]

There is no recent change which deliberately aimed to break this.
When I try to access both "some_pv" and "some_pv/valueAlarm/highWarningLimit", it works fine:

In the fullness of time we might figure out what's going on here.
Still, note that support for "some_pv/subelement/subsubelement" is neither well defined
nor universally implemented.
The EPICS base command line tools for example don't support it at all.

You can get the data, and if it's a normative type, you get some basic representation:

$ ./pvget ramp
ramp 2025-06-27 07:58:01.117  2

You can dump the complete structure:

  $ ./pvget -M raw ramp
  ramp epics:nt/NTScalar:1.0 
      double value 4
      ...
      structure timeStamp
          long secondsPastEpoch 1751025956
          int nanoseconds 123933000
          ...
      valueAlarm_t valueAlarm
           ...
          double highWarningLimit 5
          ...

But you can't fetch just one field:

$ ./pvget ramp/valueAlarm/highWarningLimit
Timeout

In phoebus, we convert the channel access structures or the normative types from pvaccess into VTypes and widgets use that metadata as they see fit. If direct access to elements of the metadata is required, we really need to add formula functions for that, and not access "SomePV.FIELD" which only works with "real IOCs", nor rely on "SomePV/subelement/subsubelement" which somewhat works for PVAccess but as mentioned isn't well defined nor universally implemented.

[kasemir]

I can confirm that simply displaying pva://root:ai1 in a test widget does indicate the value, but not the severity

Check your screenshot. The orange, single-line border indicates the severity.

[GDH-ISIS]

I can confirm that simply displaying pva://root:ai1 in a test widget does indicate the value, but not the severity

Check your screenshot. The orange, single-line border indicates the severity.

You are completely correct that the severity is represented correctly.

[GDH-ISIS]

Your points above are well made. I like your representation using a PVTable.
I believe the issue we are seeing was introduced in commit 859a158. Before this ommit, our screens behaved as expected.

pv-table.zip

For comparison, Phoebus built to commit 8860639 looks like the following

[kasemir]

Good that you narrowed it down to a commit!
I can reproduce it with this test database, and will look into what's happening

record(calc, "root:ai1")
{
    field(SCAN, "1 second")
    field(INPA, "root:ai1")
    field(CALC, "A<10?A+1:0")
    field(HIHI, "9")
    field(HIGH, "5")
    field(LOW,  "3")
    field(LOLO, "1")
    field(HHSV, "MAJOR")
    field(HSV,  "MINOR")
    field(LSV,  "MINOR")
    field(LLSV, "MAJOR")
}

[kasemir]

Figured it out, thanks for checking against different versions and narrowing it down to that commit.

In that commit we fix the handling of searches, properly removing searches once a channel is found.
Sounds good.

But then your example looks for root:ai1 as well as root:ai1/valueAlarm/highAlarmLimit.

If you enable more logging detail, you'll see that we analyze these as as

PVA 'root:ai1'
   -> Channel 'root:ai1', field 'value', request 'field()'

PVA 'root:ai1/valueAlarm/highAlarmLimit'
   -> Channel 'root:ai1', field 'valueAlarm.highAlarmLimit', request 'field(valueAlarm.highAlarmLimit)'

They're the same underlying Channel, but for the first we want to get all the data ('field()' selects nothing in particular),
whereas for the other we really only want to fetch field(valueAlarm.highAlarmLimit).

There idea here is: If the PV only wants GigaBytePV/some_substruct/some_double_field, we better just ask for field(some_substruct.some_double_field) instead of the whole GigaBytePV.
OK, in your example we do ask for the complete root:ai1 with all fields as well, but we're at this point not doing a global check of what are all the PVs that we might need, and how can we best optimize it.

So we have two PVs so far: We search for channel root:ai1 with the intention of subscribing to field() (all elements),
and another search for the same root:ai1 with the intention of subscribing to field(valueAlarm.highAlarmLimit).

As we receive the reply to one, we delete the other pending searches for that same name because we track the searches by name.
Before the commit you found, we would simply NOT properly clean searches once we get a reply, which was wrong (but helped here).

I'll update that to track the searches by client channel ID, so it only removes the one proper search and not others for the same name.

[kasemir]

Your specific problem should be fixed.

Stepping back, why do you use pva://root:ai1/valueAlarm/highAlarmLimit?
Every widget already shows the alarm limits in the tooltip.
The meter, scaled slider, ... can display the alarm limits on their scale.

Alarm limits are typically set by subsystem experts who know what the proper threshold would be, entered in the record definition, done. From then on, nobody needs to know what the exact number is, you just get the warning/alarm when a threshold is crossed.
There is the somewhat rarer case where operators need to see and adjust the alarm threshold. In that scenario, there's not a single alarm threshold setting that subsystem experts could provide. You're also unable to dynamically determine the correct threshold and use for example calcout records to adjust them. You do rely on operators to see and adjust the thresholds. In that case, you should use Text Input widgets for pva://root:ai1.HIGH, the corresponding field of the record, because that's what you can write to adjust the alarm limit.

[GDH-ISIS]

Thank you for the quick update/fix, that's fantastic. I am glad that the commit reference helped with the solution :)

Regarding your query - our circumstances are a little unusual. We are in the process of converting our control system to EPICS/Phoebus with pvaccess. Our screens were initially autoconverted and used pva://root:ai1/valueAlarm/highAlarmLimit as a way to display the PV alarm limit. The particular case in question was showing the vacuum status of our entire accelerator - which used numerous text monitor widgets. Historically, these limits were visible in the old control system as a separate indicator, and I believe we simply tried to reproduce those screens in Phoebus. The vacuum limits are nudged occasionally based on operational circumstances also - via a script, initiated by the user. I think the visibility of the limits was appreciated - to give the users confidence that limits had been applied as they wanted. The additional indicators showing the alarm limits just allowed quick checks to be made. Also, I am slightly embarrassed to admit that I am not aware of tooltips being available on our old control system and we have just followed the historical approach.

Having read your detailed description above (which was much appreciated), I was considering our current approach and whether we needed to update to the pva://root:ai1.HIHI etc. You have clarified the case well, and we will certainly move forward with this knowledge. Again, many thanks.

[georgweiss]

@GDH-ISIS, sorry for barging in, but have you looked at the Linear Meter widget? It supports display of alarm limits, and also indicate when the value has exceeded alarm limits (you need to disable alarm border on the widget):