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: Andrew Johnson via Core-talk <core-talk at aps.anl.gov>
To: Timo Korhonen <Timo.Korhonen at ess.eu>, 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 11:17:07 -0500
Hi Timo,

On 5/8/23 10:24 AM, Timo Korhonen via Core-talk wrote:
 

@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.

Ahh, yes puts to a record's VAL field will not (normally) result in a monitor being posted. The original assumption there was that when the record's process() routine is called it will update and post a monitor on the VAL field anyway, and we wouldn't want there to be 2 monitor events resulting from that put. Thus the code in dbAccess that normally posts a monitor after updating a field value will skip that for the VAL field (as long as it is marked pp(TRUE) and thus will trigger record processing).

The sequence record is one of the unusual types where that original assumption was wrong, and that's another reason why I think my suggested behavior change is worth doing.

- Andrew

-- 
Complexity is free, it's Simplicity that takes work.
Replies:
Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Timo Korhonen 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
Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Timo Korhonen via Core-talk
Navigate by Date:
Prev: Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Timo Korhonen via Core-talk
Next: Build failed: EPICS Base 7 base-7.0-926 AppVeyor 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 Timo Korhonen via Core-talk
Next: Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor Timo Korhonen 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, 29 Jun 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·