EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Precision and formatting - again
From: Timo Korhonen via Core-talk <[email protected]>
To: Michael Davidsaver <[email protected]>
Cc: EPICS Core Talk <[email protected]>
Date: Sun, 16 Dec 2018 11:50:24 +0000
Hi Michael,

I have tried that (setting qsrvDisableFormat), however at least my version
of CS-Studio (ESS CS-Studio 4.6.1.11) does not seem to support that
feature.


I do get the format string with pvget but it has no effect on the widget
behaviour. Changing PREC does not have an effect either.

I have to talk to Claudio, maybe I am missing something.

Nevertheless, we should try to finalise this at the specification level. I
think we all agree that sending a (C) format string is not the optimal
solution.

Best regards,

Timo


On 14/12/18 18:49, "Michael Davidsaver" <[email protected]> wrote:

>On 12/14/18 8:49 AM, Timo Korhonen via Core-talk wrote:
>> Colleagues,
>> 
>> I hate to bring this issue up again but this is getting more and more
>>annoying as time goes by.
>>
>> I would like to get a solution on this. Or some way of moving forward.
>
>Firstly, you could try enabling the existing format strings.
>Last I checked (some time ago) this worked with BOY.
>
>> var(qsrvDisableFormat, 0)
>
>Looking back I see that I did start on something back in
>October.  This takes care of the more complicated handling
>of the format enumeration, but not the simpler mapping
>of PREC.
>
>https://github.com/mdavidsaver/pva2pva/tree/format
>
>Obligatory reference https://github.com/epics-base/pva2pva/issues/19
>
>> I hope the pictures below come through, screenshots from CS-Studio (BOY
>>in this case). Please take a look below.
>> One of them is using CA, the other using PVA. Exactly same IOC
>>application, running rsrv and qsrv in parallel.
>> 
>> Guess which is which. Which one would you like to show your operators,
>>A or B?
>> 
>> A)  
>> B)
>> 
>> 
>> 
>> Some food for thought, just to provoke some (critical) reactions.
>> 
>> 
>> In CA, dbr_ctrl types for floating point values (float, double – *only
>>these*) have the following:
>> 
>> 
>> struct dbr_ctrl_float{
>> 
>> dbr_short_tstatus;/* status of value */
>> 
>> dbr_short_tseverity;/* severity of alarm */
>> 
>> *dbr_short_tprecision;/* number of decimal places */*
>> 
>> dbr_short_tRISC_pad;/* RISC alignment */
>> 
>> charunits[MAX_UNITS_SIZE];/* units of value */
>> 
>> dbr_float_tupper_disp_limit; /* upper limit of graph */
>> 
>> dbr_float_tlower_disp_limit; /* lower limit of graph */
>> 
>> dbr_float_tupper_alarm_limit;
>> 
>> dbr_float_tupper_warning_limit;
>> 
>> dbr_float_tlower_warning_limit;
>> 
>> dbr_float_tlower_alarm_limit;
>> 
>>  dbr_float_tupper_ctrl_limit; /* upper control limit */
>> 
>> dbr_float_tlower_ctrl_limit; /* lower control limit */
>> 
>> dbr_float_tvalue;/* current value */
>> 
>> };
>> 
>>  
>> 
>> Whereas our beloved NTypes define:
>> 
>> 
>> display_t :=
>> 
>> structure
>>     double limitLow
>>     double limitHigh
>>     string description
>>     string format
>>     string units
>> 
>> 
>> Where I do find units, upper and lower display limits, a description (?
>>What was that supposed to mean, I have lost it. Was it supposed to be
>>the DESC field from a record?), and the format.
>> 
>> Have we not been a bit too ambitious here? Or rather too simplistic?
>>Format as a just a(ny) string?
>> 
>> Could we perhaps have something like:
>> 
>> display_t := structure double limitLow double limitHigh string
>>description structure format
>> 
>> string precision
>> 
>> string specifier :opt
>> 
>> string units
>> 
>> Where precision and specifier are like in Java (or C/C++). To reproduce
>>CA functionality, precision could be just a number defining how many
>>places after decimal point should be printed.
>> 
>> (https://docs.oracle.com/javase/tutorial/java/data/numberformat.html)
>> 
>> Specifier – if we stick to CA behaviour, this could default to "f".
>>Could extend it to others as wanted.
>> 
>> Extend this with width, flags and whatever is in the format
>>specification, if required.
>> 
>> Iam by no means insisting on this or any other definition, I would just
>>like to have this issue fixed so that we can start using our PVA clients
>>in the control room. Any better or equivalent idea is ok with me.
>> 
>> 
>> Timo
>> 
>> 
>> 
>


Replies:
Re: Precision and formatting - again Ralph Lange via Core-talk
References:
Precision and formatting - again Timo Korhonen via Core-talk
Re: Precision and formatting - again Michael Davidsaver via Core-talk

Navigate by Date:
Prev: Removing epicsTempName() Johnson, Andrew N. via Core-talk
Next: Re: Precision and formatting - again Ralph Lange via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Precision and formatting - again Michael Davidsaver via Core-talk
Next: Re: Precision and formatting - again Ralph Lange via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·