Re: Question: CA monitor event and timestamp handling on compress record reset

["Kim, Kukhee via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Mark,

Thank you for the quick response.

You’re right — we are running older versions (mainly 7.0.3 and 7.0.6). I’ll review the changes in 7.0.9 and confirm whether upgrading resolves our use case.

Thanks again for pointing this out.

Best regards,

Kukhee

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Tuesday, February 10, 2026 4:52 PM
To: Kim, Kukhee <khkim at slac.stanford.edu>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Question: CA monitor event and timestamp handling on compress record reset

 

BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.

Hi Kukhee,

The release notes say this was fixed in base 7.0.9. What version are you using?

Mark

Sent from my iPhone

On Feb 10, 2026, at 7:34 PM, Kim, Kukhee via Tech-talk <tech-talk at aps.anl.gov> wrote:



Hello EPICS community,

I’d like to ask for guidance regarding a possible issue (or design choice) in the compress record reset behavior.

In a use case involving long-term data collection, a compress record is triggered infrequently (e.g., ~10-minute intervals) to capture very slow source-side events (~Hz) over weeks to months. After a long accumulation period, the compress record is reset using:

.RES = 1

This correctly clears the internal ring buffer and sets NUSE = 0. However, we observed that Channel Access monitors (e.g., camonitor) do not receive an update at the time of reset. The reset becomes visible to CA clients only after the next compress trigger occurs.

From initial inspection, it appears that the reset path (handled in special() in the compress record support) clears internal state but does not generate a CA monitor event.

One possible approach would be to explicitly call monitor() after handling the reset in special(). However, this raises a question about timestamp semantics:

• If a reset is treated as a form of record processing, should we update the timestamp (e.g., via recGblTimeStamp(prec)) before calling monitor()?
• Alternatively, if reset is considered a configuration/state change rather than data acquisition, is it preferable not to update the timestamp and simply notify clients of the state change?

I’d appreciate any guidance on the intended behavior here, or whether there is an established pattern in EPICS Base for handling CA monitor events and timestamps in reset-style operations.

Thank you very much for your time and insight.

Best regards,
Kukhee

SLAC National Accelerator Laboratory