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  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
<== Date ==> <== Thread ==>

Subject: Re: Precision and formatting - again
From: Ralph Lange via Core-talk <core-talk@aps.anl.gov>
To: Timo Korhonen <Timo.Korhonen@esss.se>
Cc: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Sun, 16 Dec 2018 19:02:15 +0100
If I remember correctly, we had discussed the issue at one of the last meetings, and we had assigned actions.
Since such action items are not being followed-up....

Cheers,
~Ralph


On Sun, 16 Dec 2018 at 12:50, Timo Korhonen via Core-talk <core-talk@aps.anl.gov> wrote:
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" <mdavidsaver@gmail.com> 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 Michael Davidsaver via Core-talk
References:
Precision and formatting - again Timo Korhonen via Core-talk
Re: Precision and formatting - again Michael Davidsaver via Core-talk
Re: Precision and formatting - again Timo Korhonen via Core-talk

Navigate by Date:
Prev: Re: Precision and formatting - again Timo Korhonen via Core-talk
Next: Re: Precision and formatting - again Michael Davidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
Navigate by Thread:
Prev: Re: Precision and formatting - again Timo Korhonen via Core-talk
Next: Re: Precision and formatting - again Michael Davidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
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 ·