Re: Normative types (again...)

["Kasemir, Kay" <kasemirk@ornl.gov>]

Hi:

I'm personally not 100% happy with the choice of display.format == printf format.

As you say, there are detailed differences between the printf format used by C, Java, Python, perl, ..

Plus we have the legacy of IOC record PREC == number of digits,

which has made its way into the widget 'precision' setting used by all the display tools.

The idea, I guess, was to allow configuring exponential format etc. all in just one display.format string.

Going by that argument, why are there still display.units? Couldn't they be included in the display.format?

I think not, and in fact would prefer to replace display.format with

 display.precision = number of digits

 display.type = decimal, exponential, engineering, hexadecimal, ..

Still, it should basically work as far as trailing digits for existing IOCs.

When I create a record with PREC=2 I see that reflected in both Channel Access and PV access:

caget -d CTRL_DOUBLE test
test
    Native data type: DBF_DOUBLE
    Request type:     DBR_CTRL_DOUBLE
    Element count:    1
    Value:            1.234
    Status:           NO_ALARM
    Severity:         NO_ALARM
    Units:            
    Precision:        2  <================
...

pvget -r 'field()' test
test
epics:nt/NTScalar:1.0
    double value 1.234
    alarm_t alarm NO_ALARM NO_STATUS <no message>
    time_t timeStamp 2018-04-13T11:02:49.083 0
    display_t display
        double limitLow 0
        double limitHigh 0
        string description
        string format %.2f     <================
        string units

==> pvaSrv does wrap the PREC into display.format.

The vtype.pv and display builder work with that, I get 2 trailing digits in a text update widget the same way for ca:// and pva://

For BOY, the code is different:

It tries to get the precision back out of the format, because it wants to honor the widget settings for decimal, exponential etc. format, using that when you select "precision from PV".

The relevant change is this one from DLS:

https://github.com/ControlSystemStudio/cs-studio/commit/39ee11ec4314be0d3769e8bc86b4685d72bf3d10

It worked for the CA case where the DBR_CRTL precision it turned into a Java NumberFormat of that precision, and then we can get the precision back out.

But it gets a 0 for the PVA case, and I'm not sure it's generally possible to get the precision back when using Java String.format(that_printf_format, value).

So at ESS you should be fine when you move to the display builder.

For BOY, you'd have to change it to be like the Display Builder:
For format = default, use the display.format as such with  Java String.format(..).

Otherwise, use the precision set in the widget, since we can't really extract that from the printf string.

That might, however, have unintended side effect for those sites that now use BOY with Channel Access.

-Kay

---

From: core-talk-bounces@aps.anl.gov <core-talk-bounces@aps.anl.gov> on behalf of Timo Korhonen <Timo.Korhonen@esss.se>
Sent: Friday, April 13, 2018 10:52 AM
To: EPICS Core Talk
Subject: Normative types (again...)

 

Hi,

Everybody's favourite topic again.

I was checking some BOY screens and comparing the behaviour when switching from CA to PVA provider.

I noticed that with PVA provider the precision field is not obeyed whereas CA provider behaves like in the good old days.

Now, starting to track what is going on, I went to the Normative Types document and found the following sentence in the description of "display":

format

A format for converting the value field to a string Needs work: What is display.format? What's it for and what are examples? If it's a sprintf pattern, which syntax must it conform to - C or Java?

Looks like undone homework...

In addition, the scalar/scalarArray types have the metadata fields (alarm/time/display/control) as optional. 

I do remember the discussions around this, even if only vaguely. I believe the intention here was to mimic CA behaviour where on defines the dbr type when calling ca operations (get/put/subscribe).

Two questions:

-does the PVA API still work like this? Does e.g., qsrv deliver the display field if a PVA clients asks for it?

-has the format field (as above) been defined in the mean time and I have missed the discussion? This looks rather unlikely but maybe.

I am sorry if this has already been discussed and clarified; in that case it just has not made its way to BOY/DiiRT or where it may be handled.

Or is this still an open issue? In that case I am afraid the Types and their behaviour/semantics has to be revisited. I know how much everybody loves these discussions...

Timo