Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Fri, 13 Apr 2018 08:45:02 -0700

Timo/Kay,

The reason you're not seeing the precision through QSRV is that I just couldn't quite bring
myself to publish printf-like specifiers over the network.  The idea of tempting client
code to directly pass this to printf() scares me.

So QSRV has the ability to do this, but right now it's disabled by default.  There is a global
variable 'qsrvDisableFormat'.  Use

> var("qsrvDisableFormat", "0")

To enable display.format

Michael

https://github.com/epics-base/pva2pva/issues/3

On 04/13/2018 08:38 AM, Kasemir, Kay wrote:
> 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:* [email protected] <[email protected]> on behalf of Timo Korhonen <[email protected]>
> *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
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System