EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  <2023>  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  <2023>  2024 
<== Date ==> <== Thread ==>
Subject: Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor
From: Timo Korhonen via Core-talk <core-talk at aps.anl.gov>
To: Steven Hartman <hartmansm at ornl.gov>
Cc: EPICS Core Talk <core-talk at aps.anl.gov>, Michael Davidsaver <mdavidsaver at gmail.com>
Date: Mon, 8 May 2023 15:24:30 +0000

Hi,

 

OK, it looks like I was on a wrong track. The original issue was reported from the machine (in operation) and I do not have a full picture about what was going on there. Changes in the VAL field of a sequence record do not trigger updates in camonitor or pvmonitor so I could not tell if the sequence record was getting processed or not; it looked like nothing was happening.

 

@Andrew: I can't explain how your VAL field went from 0 to 1 above, I think you must have done a put to it (to trigger processing?). There should be no difference between what camonitor and pvmonitor actually show since they both use the same monitor mechanism; if you think you are seeing a difference, please run both camonitor and pvmonitor simultaneously and repeat what you were doing to demonstrate.

 

 

And in the simple example: indeed, there was a put into the sequence record (by me).

I was running camonitor and pvmonitor simultaneously but as there are no monitors on VAL change (even if the value actually changes), running them in parallel does not show a lot.

I think I just got confused by seeing the timestamp at put time on the other and timestamp at completion on the other side.

 

I think this explains what (I thought) I was seeing.

Sorry for the confusion!

 

Cheers,

 

Timo

 

From: "Hartman, Steven" <hartmansm at ornl.gov>
Date: Monday, 8 May 2023 at 16:18
To: Timo Korhonen <Timo.Korhonen at ess.eu>
Cc: Michael Davidsaver <mdavidsaver at gmail.com>, EPICS Core Talk <core-talk at aps.anl.gov>
Subject: Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor

 

Hi Timo—

 

I cannot reproduce your observation. I used your minimal db, only adding PINI=YES for testSequence . . .

 

% caget -a testSequence     

testSequence                   2023-05-08 10:06:29.851825 0  

% pvget testSequence

testSequence 2023-05-08 10:06:29.852  0 

% camonitor testSequence 

testSequence                   2023-05-08 10:06:29.851825 0  

^C

% pvmonitor testSequence

testSequence 2023-05-08 10:06:29.852  0 

^C%                                                                             

% pvmonitor testSequence.VAL

testSequence.VAL 2023-05-08 10:06:29.852  0 

^C%                                                                             

% pvmonitor -V

pvAccess 7.1.6-SNAPSHOT

pvData 8.0.5-SNAPSHOT

Base 7.0.6.2-DEV

 

And on the IOC . . . 

 

% softIocPVA -d foo.db

Starting iocInit

############################################################################

## EPICS R7.0.6.2-DEV

## Rev. R7.0.6.1-149-gd82ab819ef751f5c1f0c-dirty

############################################################################

iocRun: All initialization complete

epics> dbpr testSequence 4

ACKS: NO_ALARM      ACKT: YES           AMSG:               ASG :               

ASP : PTR 0x0       BKLNK: ELL 0 [0x0 .. 0x0]               BKPT: 00            

DESC:               DISA: 0             DISP: 0             DISS: NO_ALARM      

DISV: 1             DLY0: 1             DLY1: 0             DLY2: 0             

DLY3: 0             DLY4: 0             DLY5: 0             DLY6: 0             

DLY7: 0             DLY8: 0             DLY9: 0             DLYA: 0             

DLYB: 0             DLYC: 0             DLYD: 0             DLYE: 0             

DLYF: 0             DO0 : 0             DO1 : 0             DO2 : 0             

DO3 : 0             DO4 : 0             DO5 : 0             DO6 : 0             

DO7 : 0             DO8 : 0             DO9 : 0             DOA : 0             

DOB : 0             DOC : 0             DOD : 0             DOE : 0             

DOF : 0             DOL0: DB_LINK myInput NPP NMS           DOL1: CONSTANT      

DOL2: CONSTANT      DOL3: CONSTANT      DOL4: CONSTANT      DOL5: CONSTANT      

DOL6: CONSTANT      DOL7: CONSTANT      DOL8: CONSTANT      DOL9: CONSTANT      

DOLA: CONSTANT      DOLB: CONSTANT      DOLC: CONSTANT      DOLD: CONSTANT      

DOLE: CONSTANT      DOLF: CONSTANT      DPVT: PTR 0x600000a94000                

DSET: PTR 0x0       DTYP: <nil>         EVNT:               FLNK: CONSTANT      

LCNT: 0             LNK0: DB_LINK myOutput PP NMS           LNK1: CONSTANT      

LNK2: CONSTANT      LNK3: CONSTANT      LNK4: CONSTANT      LNK5: CONSTANT      

LNK6: CONSTANT      LNK7: CONSTANT      LNK8: CONSTANT      LNK9: CONSTANT      

LNKA: CONSTANT      LNKB: CONSTANT      LNKC: CONSTANT      LNKD: CONSTANT      

LNKE: CONSTANT      LNKF: CONSTANT      LSET: PTR 0x600002a94340                

MLIS: ELL 0 [0x0 .. 0x0]                MLOK: 50 c4 19 03 00 60 00 00           

NAME: testSequence  NAMSG:              NSEV: NO_ALARM      NSTA: NO_ALARM      

OFFS: 0             OLDN: 1             PACT: 0             PHAS: 0             

PINI: YES           PPN : PTR 0x0       PPNR: PTR 0x0       PREC: 0             

PRIO: LOW           PROC: 0             PUTF: 0             

RDES: PTR 0x600000a91500                RPRO: 0             

RSET: PTR 0x104efd138                   SCAN: Passive       SDIS: CONSTANT      

SELL: CONSTANT      SELM: All           SELN: 1             SEVR: NO_ALARM      

SHFT: -1            SPVT: PTR 0x0       STAT: NO_ALARM      

TIME: 2023-05-08 10:06:29.851825000     TPRO: 0             TSE : 0             

TSEL: CONSTANT      UDF : 0             UDFS: INVALID       UTAG: 0             

VAL : 0             

epics> 

 

 

-- 

Steven Hartman

hartmansm at ornl.gov

 

 



On May 8, 2023, at 6:17 AM, Timo Korhonen via Core-talk <core-talk at aps.anl.gov> wrote:

 

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 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
Re: Timestamp behaviour in pvmonitor vs camonitor Timo Korhonen via Core-talk
Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Hartman, Steven via Core-talk
Navigate by Date:
Prev: Re: Timestamp behaviour in pvmonitor vs camonitor Andrew Johnson via Core-talk
Next: Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Andrew Johnson 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: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Hartman, Steven via Core-talk
Next: Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Andrew Johnson 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 
ANJ, 08 May 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·