The original record was running on an IOC with Base version 7.0.5 (pvData 8.0.4, pvAccess 7.1.3, pva2pva 1.3.0, as released.)
My pvmonitor -V says:
pvAccess 7.1.5
pvData 8.0.4
Base 7.0.6.1
However, I can replicate the behavior with a minimal db like this:
record(seq,"testSequence") {
field(DOL0,"myInput")
field(LNK0,"myOutput PP")
field(DLY0,"1.0")
}
record(ai,"myInput"){
}
record(ao,"myOutput"){
}
on Base 7.0.7.1.
timokorhonen@CIN-906975 Work % pvmonitor testSequence
testSequence 2023-05-08 11:48:16.571 0
^C
timokorhonen@CIN-906975 Work % pvmonitor testSequence.VAL
testSequence.VAL 2023-05-08 11:50:35.554 1
^C
timokorhonen@CIN-906975 Work % camonitor testSequence.VAL
testSequence.VAL 2023-05-08 11:50:35.553895 1
No processing has happened in between.
Apart from this oddity, I do not see any issues in how the sequence record works. This is just curious.
I know that the VAL field in a sequence record does not do anything, just that a put to it causes the record to process.
Timo
On 2023-05-08, 07:03, "Michael Davidsaver" <mdavidsaver at gmail.com <mailto:mdavidsaver at gmail.com>> wrote:
On 5/7/23 13:39, Timo Korhonen via Core-talk wrote:
> Hello,
>
> Can somebody remind me about timestamp handling with monitors?
>
> Namely, we see the following behaviour:
>
> caget -a <record>
>
> and
>
> pvget <record>
>
> and
>
> camonitor <record>
>
> give the same timestamp, but
>
> pvmonitor <record>
>
> gives a different one, rather far in the past.
>
> The record in question is a sequence record. VAL has no other meaning there except causing the record to process, right? VAL of the record in question is always null.
>
> Thus, there are no monitor updates (as far as I have seen).
>
> Interestingly enough, when I do pvmonitor <record>.VAL, I get the same timestamp as with the three other methods.
>
> I was asked why this happens but I could not figure out the reason. I vaguely remember some discussion on this but could not find any hints.
I also can't think of a reason. Nor do I recall any discussion where "record" and "record.VAL" behave differently.
Can you share details about the situation, including module versions?
- Replies:
- Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Hartman, Steven via Core-talk
- Re: Timestamp behaviour in pvmonitor vs camonitor Andrew Johnson via Core-talk
- References:
- Timestamp behaviour in pvmonitor vs camonitor Timo Korhonen via Core-talk
- Re: Timestamp behaviour in pvmonitor vs camonitor Michael Davidsaver via Core-talk
- Navigate by Date:
- Prev:
Re: Timestamp behaviour in pvmonitor vs camonitor Michael Davidsaver via Core-talk
- Next:
Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Hartman, Steven 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: Timestamp behaviour in pvmonitor vs camonitor Michael Davidsaver via Core-talk
- Next:
Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Hartman, Steven 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
|