Re: Update behavior of camonitor

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

The waveform record also now has the fields MPST and APST, but their default value is "Always". The implementation of the "On Change" choice calculates a 32-bit hash of the array data buffer and only sends updates if the hash value has changed since the last monitor was sent. Since there is a 1 in 2**32 chance that two different subsequent array values might hash to the same value, using "On change" isn't recommended for all systems.

 

- Andrew

 

-- 

Complexity comes for free, Simplicity you have to work for.

 

 

On 2/11/25, 12:06 PM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:

 

On 2/11/25 05:31, Neidherr, Dennis Dr. via Tech-talk wrote:
> Hi Ziga,
>
> thanks a lot. For ai records I knew about the MDEL field, but I did not know that there is something similar for strings.

Referring to the RRM for the stringout record type [1], you can set MPST
and potentially APST.

> field(MPST, "Always")

which is implemented in code at [2]

> ... Is there a purpose behind that difference? ...

It is inefficient to transmit the same value repeatedly, so the default
is not to do so.


[1] https ://epics.anl.gov/base/R7-0/8-docs/stringoutRecord.html

[2] https ://github.com/epics-base/epics-base/blob/1d19ba4cc2e8c9ab17288b684022a0682e398bde/modules/database/src/std/rec/stringoutRecord.c#L220-L227

> Greetings Dennis
>
> -----Original Message-----
> From: Žiga Oven <ziga.oven at cosylab.com>
> Sent: Dienstag, 11. Februar 2025 14:22
> To: Neidherr, Dennis Dr. <D.Neidherr at gsi.de>; tech-talk at aps.anl.gov
> Subject: RE: Update behavior of camonitor
>
> Hi Dennis,
>
> Most records will only send out a monitor event when the value changes.
> Certain records have dedicated monitor parameter fields such as MDEL (ai record) or MPST (stringin or waveform record).
>
> Here is example from Component Reference Manual for AI record.
>
> ------------------------------------------
> Monitor Parameters
> These parameters are used to determine when to send monitors placed on the VAL field. The monitors are sent when the current value exceeds the last transmitted value by the appropriate deadband. If these fields are set to zero, a monitor will be triggered every time the value changes; if set to -1, a monitor will be sent every time the record is processed.
>
> The ADEL field sets the deadband for archive monitors (DBE_LOG events), while the MDEL field controls value monitors (DBE_VALUE events).
>
> The remaining fields are used by the record at run-time to implement the record monitoring functionality.
>
> Field Summary Type    DCT     Default Read    Write   CA PP
> ADEL  Archive Deadband        DOUBLE  Yes       Yes     Yes     No
> MDEL  Monitor Deadband        DOUBLE  Yes       Yes     Yes     No
> ALST  Last Value Archived     DOUBLE  No        Yes     No      No
> MLST  Last Val Monitored      DOUBLE  No        Yes     No      No
> ORAW  Previous Raw Value      LONG    No        Yes     No      No
>
> ------------------------------------------
>
> As described above if you set AI record's MDEL to -1 it will update via camonitor each time the record is processed.
> Be aware that STRINGIN has a different implementation, so check the Component Reference Manual [1] for the records that you plan to use.
>
>
> Hope this helps,
>
> Žiga
>
>
> [1] for EPICS base 7.0.8 https://epics.anl.gov/base/R7-0/8-docs/ComponentReference.html
>
>> -----Original Message-----
>> From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Neidherr,
>> Dennis Dr. via Tech-talk
>> Sent: Tuesday, February 11, 2025 13:51
>> To: tech-talk at aps.anl.gov
>> Subject: Update behavior of camonitor
>>
>> Dear all,
>>
>> I have a small and very basic question about the behavior of camonitor:
>> It seems to be that it depends on the type of the record if I get an
>> update in camonitor or not when I overwrite the record value with
>> exactly the same value. Simple types like "stringout" do not trigger
>> an update whereas a waveform for example does. Is there a purpose
>> behind that difference? And can I somehow reproduce the
>> "waveform-behavior" also for simple record types? An alternative would
>> be to use the waveform record for everything, but maybe there is an easier solution.
>>
>> Thanks a lot
>> Greetings Dennis
>