Visitar URL original
Bug in macro replacement in display · Issue #3950 · ControlSystemStudio/phoebus · GitHub
Skip to content

Bug in macro replacement in display #3950

Open

Description

@MarkRivers

I think I have found a bug in macro replacement in display files. In my case these are files that are converted from medm .adl files, but I think the problem is more general.

I originally saw the problem using the adl converter from Phoebus 4.6.10 and Phoebus display 4.7.3. But I have reproduced it using both the converter and display in Phoebus 6.0.0.

This is an example of the problem.

quadEM.bob loads the related display file NDStats, and passes the macro parameters P=QE1:FX4:, R=Current1:

NDStats.bob loads the related display file NDStatsTimeSeriesPlot, and passes the parameters P=$(P), R=$(R)TS:, RN=$(R)TSTotal

The title of this plot is $(P)$(RN)

Image

After substitution the plot title should thus be QE1:FX4:Current1:TSTotal.

However, it is not. As seen below it is QE1:FX4:Current1:TS:TSTotal.

Image

The reason is clear. This is the screen for the Actions of the menu that calls NDStatsTimeSeriesPlot:

Image

What is happening is that it is not using the original value of R when it builds RN, it is using the modified version from the first line.

I can work around the problem by swapping these 2 lines in the .adl file, so that RN is built before R. But it seems that this should be fixed in the translation or runtime engine.

Activity

  1. shroffk commented on Oct 14, 2026

    @shroffk
    Member

    Thanks for the example and the diagnosis.

    I believe that the ordered and immediate resolution of the macros was a deliberate choice and this "feature" is being used at some facilities. ( The same is true when it comes of rules, where the conditions are all checked sequentially and the order matters )

    We should discussion if this is still the best approach, and clearly document the decision.

    @MarkRivers I will assume that your suggestion is that all the macros should be resolved "simultaneously" when the action is executed and so that their value is not dependent on the order of their declaration.

  2. MarkRivers commented on Oct 14, 2026

    @MarkRivers
    Author

    @shroffk , yes i am suggesting that it should not matter what order macro arguments are listed. That is how medm and perhaps other OPIs work. Lots of areaDetector screens don’t work correctly in Phoebus now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions