Add log scaling property to Meter widget

[rjwills28]

I noticed that the old Meter widget in CS-Studio had the option of using a log scale but that this is missing in the Phoebus Meter widget.

This PR adds the code needed to support log scaling in the meter widget following what is implemented for the RTTank widget. The only real bit of logic needed is in MeterScale.java, otherwise it is pretty much boilerplate.

Checklist

• 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

[rjwills28]

Thanks @shroffk for the review. Would it be possible to merge this in or does it need a second review?

[georgweiss]

@rjwills28, I'm having issues with this. Attached screen recording shows a case where a random number 0 - 10000 is displayed on a meter with scale 0 - 10000. But maybe I'm missing something?

Also, it would be nice if we can reuse the same label for the property as (for instance) the Linear Meter widget, i.e. Logarithmic scale instead of Log. scale.

Screen.Recording.2026-04-10.at.09.32.39.mov

[rjwills28]

Hi @georgweiss - thank you for testing. How are you setting the limits? Is this from a PV or manually? Essentially I think what is happening is that the lower limit is set to 0. There is then a calculation that does value/low_range, i.e. divides by 0 and it blows up the axis ranges. This is a problem I have also seen on other widgets when using the log scaling, e.g. tank widget. If you set the low limit manually to be something very small, e.g. 0.001 does it then work?

I wasn't sure how to fix this issue of 0 as the lower limit. Essentially we shouldn't use it in the calculations and should just use some very small number close of 0 instead. But I wasn't sure whether we actually wanted to hardcode that in and what the very small number should be. Any thoughts on that? As I said, this could also be fixed for other widgets.

[georgweiss]

@rjwills28, thanks for your feed-back.
Yes, a lower limit of 0.1 resolved my issue.
However, setting zero as the lower limit for a logarithmic scale is actually handled such that the lower limit is set to 4.9E-324. See LogTicks.adjustRange().

[rjwills28]

Ah I see - @georgweiss thanks for pointing that out. So that is the expected behaviour?

And thanks for the suggesting of changing the log scale property label to match other similar widgets. I had been using the one from PlotWidgetProperties. I have updated this to match what is used by the LinearMeter which now displays 'Logarithmic Scale' as the label

p.s. sorry for all the commits to fix the quality check - these were things I had missed but should now be compliant.

[georgweiss]

So that is the expected behaviour?

I'm just saying that LogTicks should handle the case where lower limit <=0 and set that to something small. You might want to compare to the Linear Meter widget.

[kasemir]

So that is the expected behaviour?

See app/rtplot/src/main/java/org/csstudio/javafx/rtplot/internal/util/Log10.java

[rjwills28]

Thanks both for the advice here - very helpful. I have updated the log calculation used in the MeterWidget so that it makes use of the Log10 method and catches the case where the lower limit is 0.

I have compared the behaviour to that of the Tank widget and LinearMeter widget and can confirm that they all display the behaviour. See the example below:

I'm not sure the tick axis is quite correct for any of them but perhaps that warrants a separate issue/PR?

[kasemir]

Good progress! Yes, there can always be a follow-up to fine-tune the ticks

[rjwills28]

One final change here as I changed the widget log scale property to match the LinearMeter widget so instead of log_scale it is logScale. This means one small fix to the OPI->BOB converter so that the log_scale property value in the Meter widget from CSS is preserved when converted to the Phoebus Meter widget.

[kasemir]

All the widget properties use the_name, not theName. If you start changing that, you'll also need to change all scripts that might call widget.setPropertyValue("the_name", ...)

[rjwills28]

@kasemir - yes I see your point. I was following what was done for the LinearMeter widget but now I look at it I'm not sure why they set the property to be called logScale? Is this supposed to represent something different? See

phoebus/app/display/linearmeter/src/main/java/org/csstudio/display/extra/widgets/linearmeter/LinearMeterWidget.java

Line 165 in 0e4e200

newBooleanPropertyDescriptor(WidgetPropertyCategory.DISPLAY, "logScale", Messages.WidgetProperties_LogScale);

I'm going to undo my last commit and change the property back to log_scale.

[kasemir]

A newly added or "extra" widget is of course free to do whatever it wants when introducing new properties, but all the common widget properties, see https://github.com/ControlSystemStudio/phoebus/blob/master/app/display/model/src/main/java/org/csstudio/display/builder/model/properties/CommonWidgetProperties.java or the original https://github.com/kasemir/org.csstudio.display.builder/blob/master/org.csstudio.display.builder.model/src/org/csstudio/display/builder/model/properties/CommonWidgetProperties.java going back to 2015 used for example pv_name and not pvName.
This was also in the original documentation,
https://github.com/kasemir/org.csstudio.display.builder/blob/2a0ba03576cb76b1b6346ca35791354384fa75e9/org.csstudio.display.builder.editor.rcp/doc/display.builder.html#L749-L763 :

The name of a property is typically based on the simplified English description, all lower case:
<b>x</b>, <b>text</b>, <b>pv_name</b>.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[rjwills28]

Thanks for the clarification @kasemir and apologies for my misunderstanding and back-and-forth with commits. I think we should be there now!

[kasemir]

No worries, and thanks for adding the log support!