2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Normative types (again...) |
From: | "Kasemir, Kay" <[email protected]> |
To: | Timo Korhonen <[email protected]>, EPICS Core Talk <[email protected]> |
Date: | Fri, 13 Apr 2018 15:38:05 +0000 |
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
pvget -r 'field()' test
==> 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: 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
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
|