Re: Timestamp behaviour in pvmonitor vs camonitor

[Timo Korhonen via Core-talk <core-talk at aps.anl.gov>]

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?