Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <[email protected]> · Sun, 16 Dec 2018 10:50:47 -0800

On 12/16/18 10:02 AM, Ralph Lange wrote:
> 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....

My funding on PVA so far has been for line item features.
Adding features which are not funded feels increasing like
stealing from myself.  No one will pay for work which is
already complete, nor should they.

Still, fool that I am, I did spend a few hours on this.
On a Tuesday evening I would point out.  Your comment does
not encourage me in this.

This is another example of the sort of work which imo would
be better handled under a maintenance/support contract.
Too short to motivate a contract, and too long for a train ride.

> Cheers,
> ~Ralph
> 
> 
> On Sun, 16 Dec 2018 at 12:50, Timo Korhonen via Core-talk <[email protected] <mailto:[email protected]>> 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" <[email protected] <mailto:[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
>     >>
>     >>
>     >>
>     >
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System