Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor

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

Hi,

 

Getting back to this old thread from May.

I mentioned a “corner case” in our meeting yesterday. We have stumbled on that again, I think.

We saw a case where pvmonitor and camonitor show different values for the same record – unless we explicitly point pvmonitor to the VAL field.

 

This matches with Andrew’s explanation below. I assume that waveform is one more of the “unusual” types?

 

Timo

 

From: Andrew Johnson <anj at anl.gov>
Date: Monday, 8 May 2023 at 18:17
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>
Subject: Re: [EXTERNAL] Timestamp behaviour in pvmonitor vs camonitor

 

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.