On 1/10/19 9:22 AM, Kasemir, Kay via Core-talk wrote:
Hi:
Is it possible that qsrv doesn't fully use the request information?
When I introspect and read a PV provided by the SNS neutron data server or the area detector NVPluginPVA, I can request specific fields:
$ pvinfo neutrons
neutrons structure
time_t timeStamp
long secondsPastEpoch
int nanoseconds
int userTag
epics:nt/NTScalar:1.0 proton_charge
double value
epics:nt/NTScalarArray:1.0 time_of_flight
uint[] value
epics:nt/NTScalarArray:1.0 pixel
uint[] value
$ pvget -r 'field(proton_charge)' neutrons
neutrons structure
epics:nt/NTScalar:1.0 proton_charge
double value 1e+08
$ pvget -r timeStamp.secondsPastEpoch neutrons
neutrons structure
structure timeStamp
long secondsPastEpoch 1547129085
$ pvinfo 13SIM1:Pva1:Image
13SIM1:Pva1:Image epics:nt/NTNDArray:1.0
union value
boolean[] booleanValue
..
dimension_t[] dimension
dimension_t
int size
..
display_t display
double limitLow
..
$ pvget -r dimension 13SIM1:Pva1:Image
13SIM1:Pva1:Image structure
dimension_t[] dimension
dimension_t
int size 1024
int offset 0
int fullSize 1024
int binning 1
boolean reverse false
dimension_t
int size 1024
int offset 0
int fullSize 1024
int binning 1
boolean reverse false
For the SNS neutron data that was one argument for using PVAccess:
An XY histogram client may only need the pixel[],
a time-of-flight client may only need the time_of_flight[],
a proton charge accumulator may only need the proton_charge,
others may need a combination of elements up to the complete structure.
This access to sub-elements of the structure is also useful for CSS:
We cannot handle arbitrary structures like pva://neutrons, but we allow fetching sub-fields with a notation pva://neutrons/proton_charge.
The image widget can handle pva://13SIM1:Pva1:Image, but general tools like probe cannot. Still, probe can display pva://neutrons/proton_charge or pva://13SIM1:Pva1:Image/value which is just a scalar vs. number array.
When I use qsrv, however, I always seem to get the whole structure.
This is with EPICS 7.0.2:
$ pvinfo training:random
training:random epics:nt/NTScalar:1.0
double value
alarm_t alarm
int severity
int status
string message
time_t timeStamp
long secondsPastEpoch
int nanoseconds
int userTag
display_t display
double limitLow
double limitHigh
string description
string format
string units
control_t control
double limitLow
double limitHigh
double minStep
valueAlarm_t valueAlarm
boolean active
double lowAlarmLimit
double lowWarningLimit
double highWarningLimit
double highAlarmLimit
int lowAlarmSeverity
int lowWarningSeverity
int highWarningSeverity
int highAlarmSeverity
double hysteresis
$ pvget -r timeStamp.secondsPastEpoch training:random
training:random 2019-01-10 09:05:35.193 6.65934
$ pvget -vv -r timeStamp.secondsPastEpoch training:random
training:random epics:nt/NTScalar:1.0
double value 4.50019
alarm_t alarm
int severity 0
int status 0
string message NO_ALARM
time_t timeStamp 2019-01-10 09:05:41.193
long secondsPastEpoch 1547129141
int nanoseconds 193341059
int userTag 0
display_t display
double limitLow 0
double limitHigh 0
string description
string format
string units
control_t control
double limitLow 0
double limitHigh 0
double minStep 0
valueAlarm_t valueAlarm
boolean active false
double lowAlarmLimit nan
double lowWarningLimit nan
double highWarningLimit nan
double highAlarmLimit nan
int lowAlarmSeverity 0
int lowWarningSeverity 0
int highWarningSeverity 0
int highAlarmSeverity 0
double hysteresis 0
The following almost does what you want.
pvget -r timeStamp.secondsPastEpoch -p ca training:random
In exampleCPP/database there is a DBRecord named DBRdouble and a
PVRecord named PVRdouble
I see
rk> pvget -r timeStamp.secondsPastEpoch -p ca DBRdouble
DBRdouble structure
time_t timeStamp <undefined>
long secondsPastEpoch 0
int nanoseconds 0
int userTag 0
mrk> pvput DBRdouble 1
Old : <undefined> 0 INVALID DRIVER UDF
New : 2019-01-11 16:40:29.939 1
mrk> pvget -r timeStamp.secondsPastEpoch -p ca DBRdouble
DBRdouble structure
time_t timeStamp 2019-01-11 16:40:29.939
long secondsPastEpoch 1547242829
int nanoseconds 939371084
int userTag 0
mrk> pvget -r timeStamp.secondsPastEpoch PVRdouble
PVRdouble structure
structure timeStamp
long secondsPastEpoch 0
mrk> pvput PVRdouble 1
Old : <undefined> 0
New : 2019-01-11 16:47:48.055 1
mrk> pvget -r timeStamp.secondsPastEpoch PVRdouble
PVRdouble structure
structure timeStamp
long secondsPastEpoch 1547243268
Maybe Michael can explain why qsrv does not have similar semantics.
Marty
It may not be an operational issue, because you typically want to get the complete NT* type for records served via qsrv.
But it's inconsistent, and it's unfortunate for training sessions where pvaSrv allowed me to say:
Look, you can read records via PVA and easily get just the units as pva://record/display/units, because PVA generally allows you to fetch just what you want.
I think pvDatabaseCPP automatically supports requests for subsections of a structure.
Is qsrv not using pvDatabaseCPP for performance reasons?
Thanks,
Kay
- References:
- 'Request' support in qsrv Kasemir, Kay via Core-talk
- Navigate by Date:
- Prev:
Re: Warning when building areaDetector with base 7.0.2 Mark Rivers via Core-talk
- Next:
EPICS Base 7.x - Known Problems & Patch files Hugo Slepicka 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:
'Request' support in qsrv Kasemir, Kay via Core-talk
- Next:
Re: 'Request' support in qsrv 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
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·