Experimental Physics and Industrial Control System
|
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
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 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
<2018>
2019
2020
2021
2022
2023
2024
- 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
<2018>
2019
2020
2021
2022
2023
2024
|
ANJ, 16 Dec 2018 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|