Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <[email protected]> · Fri, 14 Dec 2018 09:49:54 -0800

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
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System