Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: timeStamp in pvget request not populated when using display field in v3 IOC
From: Jack Harper - UKRI STFC via Tech-talk <tech-talk@aps.anl.gov>
To: "Johnson, Andrew N." <anj@anl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 1 Mar 2019 09:06:47 +0000
Hi Andrew,


Many thanks for the help.


Jack

________________________________
From: Johnson, Andrew N. <anj@anl.gov>
Sent: 28 February 2019 17:19:58
To: Harper, Jack (STFC,RAL,ISIS); tech-talk@aps.anl.gov
Subject: Re: timeStamp in pvget request not populated when using display field in v3 IOC

Hi Jack,

On 2/28/19 8:43 AM, Jack Harper - UKRI STFC via Tech-talk wrote:
> I have been using pvget as well as the CPP API to attempt to set up a request for a v3 IOC that populates the timeStamp and display.units fields. For some reason, whenever i use anything from display, it stops timeStamp from being populated. I know the PVRequest is order-dependent, so I have tried moving the order of the fields around, but this doesn't help. I think this may be a bug, I am not sure if it affects V4 IOCs but i'd imagine someone would have flagged it up earlier if so.
The CA provider by definition uses the Channel Access network protocol
for data transport, thus it can only fetch channel data using the data
structures that CA supports. CA was designed in the days of limited
network bandwidth and the thinking was that display fields change very
rarely, whereas value, timestamp and alarm data need to be transported
frequently so should use a minimal data structure.

There is no single CA data type that provides the timestamp plus the
display metadata that you requesting, so the CA provider can't fulfil
your request in a single get operation. Instead of pretending that it
can and doing two separate CA gets from the channel with two different
data types (which would not be atomic), it just returns a subset of the
fields you asked for. I suggest you do one get to fetch the units
string, then another for the value, alarm and timestamp.

The pva provider is capable of getting any combination of fields that
you request, as long as your IOC is running a pvAccess server obviously.

Please note that your distinction between v3 and v4 IOCs doesn't really
exist; a v4 IOC is just a v3 IOC that is also running a pvAccess server,
either QSRV or the older pvaSrv. However you can add pvaSrv to a 3.14
IOC, or build EPICS 7 IOCs without the pvAccess server, so I using the
terms v3 or v4 for IOCs could be confusing.

HTH,

- Andrew

--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon


References:
timeStamp in pvget request not populated when using display field in v3 IOC Jack Harper - UKRI STFC via Tech-talk
Re: timeStamp in pvget request not populated when using display field in v3 IOC Johnson, Andrew N. via Tech-talk

Navigate by Date:
Prev: Fw: asynDriver - update record (timestamp), on no change Mark Rivers via Tech-talk
Next: Re: Basic PVAccess question Marty Kraimer via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
Navigate by Thread:
Prev: Re: timeStamp in pvget request not populated when using display field in v3 IOC Johnson, Andrew N. via Tech-talk
Next: asynDriver - update record (timestamp), on no change Joao Afonso via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
ANJ, 01 Mar 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·