Visualize alarm limits in data browser by georgweiss · Pull Request #3949 · ControlSystemStudio/phoebus

georgweiss · 2026-10-12T17:47:53Z

This PR adds support for visualizing alarm limits in data browser plots for PVs stored by the Archiver Appliance. Screen shots attached below.

How this works

In the traces tab, the added Show Alarm Limits column will render a check box for each trace if the following conditions are met:

Item is not a formula item.
Request type is RAW.
PV (EPICS record) defines alarm limits.
Archiver policy file does omit alarm limits.

When the Show Alarm Limits checkbox is ticked by the user, additional traces are added to the plot to show the alarm limits defined by that PV. To be noted:

If the limit traces fall outside the current value range, they would be visible only if the value axis is set to auto-scale.
All alarm limits (LOLO, LOW, HIGH, HIHI) are by default rendered using the same line style and color as the PV plot proper. The line width is hard coded, though.
User may tweak the MINOR (LOW/HIGH) and MAJOR (LOLO/HIHI) alarm limit trace colors to improve visibility.
Adding alarm limit traces will not make the plot dirty. Saving alarm limit traces visibility an color was considered for a while, but dropped as it came with some side effects.

Limitations

In case a PV does not define all four alarm limits, the undefined ones will be rendered as traces at zero. This is essentially due to native EPICS behavior. Since an undefined alarm limit cannot be distinguished from an alarm limit at zero, users will need to be familiar with the PV in question to resolve this ambiguity.
If an alarm limit has changed within the time span of the plot, that alarm limit will be (incorrectly) plotted at its current value. A fix for this corner case is pending a change in the Archiver Appliance.
For a very noisy PV plot, alarm limit traces may not be discernible as they are by default are rendered using the same color.

Aspects on trace rendering

Ideally users should not be bothered with changing the color of alarm limit traces to improve the visual presentation. I leave that as a challenge for future improvements. Ideas are welcome.

Testing:
- The feature has automated tests
- Tests were run
- If not, explain how you tested your changes
Documentation:
- The feature is documented
- The documentation is up to date
- Release notes:
  - Added an entry if the change is breaking or significant
  - Added an entry when adding a new feature

…nge (e.g. in alarm limits)

…e value

jacomago

I would prefer would big changes like this to have a clear commit structure. 3000 lines changed can be hard to track what's going on over all the code.

jacomago · 2026-10-13T12:43:35Z

                         AddPV_PeriodTT,
                         AppendSearchResults,
                         AppendSearchResultsTT,
-                         AreaOpacity,


Why are we removing all these messages?

Because the definition (in messages.properties) is referenced only in FXML, not in Java code.

jacomago · 2026-10-13T12:45:14Z

+    private final Range controlRange = Range.of(-1000, 1000);
+
+    @Test
+    public void testHasAlarmLimits1(){


Can we have more descriptive test names, if these are all the same it would be better to use ParametizedTests for test case variation.

I'll look into this.

jacomago · 2026-10-13T12:52:13Z

+                            AlarmLimitItem alarmLimitItem = AlarmLimitItem.createAlarmLimitItem(pvItem, limitType);
+                            alarmLimitItem.setAxis(pvItem.getAxis());
+                            alarmLimitItem.setDisplayName("");
+                            alarmLimitItem.setColor(pvItem.getPaintColor());


I really don't like this default. Maybe we can ask Balazs for UI opinion. But I think being the same colour and opacity as the main line is really not a great option. Some options:

desaturate the colour

Reduce the opacity (similar to the area colour)

Saturate

As pointed out in the PR comment, visualization is not ideal as it stands. Tweaking saturation may be an option, but then again user may choose to give the PV plot a less saturated color. Reduced opacity won't help if the alarm limit trace is painted on top of a very noisy PV plot.

At this point I would like the PR to demonstrate a feature we can improve incrementally.

jacomago · 2026-10-13T12:55:00Z

+public class AlarmLimitItemTest {
+
+    @Test
+    public void testConstructor1(){


Again here the test cases are almost identical, better to use parametized tests to make clear the difference between them.

Will look into this.

jacomago · 2026-10-13T12:59:01Z

+    /**
+     * Helper enum...
+     */
+    public enum LimitType {


I think most of this class and AlarmLimits class would be better in the VType module where it can be reused across the other modules.

Disagree. AlarmLimits is particular to the data browser app. It manages colors, which should be of no concern of the VType module.

jacomago · 2026-10-13T13:00:55Z

+public class AlarmLimitItemTest {
+
+    @Test
+    public void testConstructor1(){


These tests are pretty much the same and I think could be improved by using ParametizedTest

I'll look into that.

jacomago · 2026-10-13T13:02:54Z

+        final Range warningRange = Range.of((low != null) ? Double.parseDouble(low) : currentDisplay.getWarningRange().getMinimum(),
+                (high != null) ? Double.parseDouble(high) : currentDisplay.getWarningRange().getMaximum());
+
+        return Display.of(displayRange,


I think @abrahamwolk work to create the description provider would help here. Having the alarm information split out from Display I think would improve the code api.

Can be updated when that change is available.

jacomago · 2026-10-13T13:03:28Z

+     * @param value {@link VType} under test.
+     * @return <code>true</code> if alarm or warning limits have been set.
+     */
+    public final static boolean hasAlarmLimits(final VType value) {


I think it would be better this method as part of VType

Yes, why not.

But then again... that brings up the question on moving all org.phoebus.archive.vtype.VTypeHelper methods to org.phoebus.core.vtypes.VTypeHelper, which in my view is a different PR.

jacomago · 2026-10-13T13:03:57Z

    }
+
+    @Test
+    void testUpdateDisplay1() {


Prefer either more descriptive test cases or using ParametizedTest

I'll look into that.

…d name

sonarqubecloud · 2026-10-14T11:20:11Z

Quality Gate passed

Issues
32 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.6% Duplication on New Code

See analysis details on SonarQube Cloud

georgweiss added 28 commits August 24, 2026 16:07

Convert Data Browser traces tab to FXML

b801f81

Remove commented out line

c15fafa

Added Show Alarm Limits column to properties tab view

49a2564

Added behavior for showing alarm limits in data browser, step 1

dbc2070

Initial changes to support alarm limits in data browser

3466e1c

Read Display information from each sample for raw requests

db3df71

Fixing linter complaints

c87483b

Merge branch 'databrowser_display_fix' into CSSTUDIO-2788

2840f1b

Backup commit

5932b31

Support update of Display if field values of an event indicates a cha…

c64529f

…nge (e.g. in alarm limits)

When constructing AlarmLimitItem, avoid creating samples with same value

f3700c4

Do not add alarm limit trace to statistics tab

7ef26d3

Fixed Java warnings

0666a72

Merge branch 'master' into CSSTUDIO-2788

37da4f1

Optimize check for alarm limits

1ed3465

Implement hide alarm limits

928dc9f

Ignore live values for alarm limit item if Display contains non-finit…

d6bd3b8

…e value

AlarmLimitItem constructor made private

279ab59

Rename and document PVItem methods

857e4d6

Implement hide alarm limit traces

57fb185

Move alarm limit management to PVItem

269affa

Hide alarm traces when switching to OPTIMIZED request

b601f08

Add alarm limit type enum

b1113f8

Write/read show_alarm_limits to/from plt

1a50faa

Remove plt support for alarm limits. General code cleanup

03edbb1

Merge branch 'master' into CSSTUDIO-2788

6df81e3

Fix linter lamentations

d7ceffe

Linter fixes, removed unused message string

ceebfb5

georgweiss requested review from jacomago and shroffk October 13, 2026 07:41

jacomago reviewed Oct 13, 2026

View reviewed changes

Changes due to peer feed-back: clarify unit tests in Javadoc or metho…

f51dfda

…d name

Conversation

georgweiss commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacomago left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sonarqubecloud Bot commented Oct 14, 2026

Quality Gate passed

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

georgweiss commented Oct 12, 2026 •

edited

Loading