|
Yes, you can cause records to send updates even when the value doesn't change.
For ai, calc, ao, .. records, set the ADEL field to -1, so now the record will send a new value whenever processed.
But then you'll fill your disk with the same value over and over.
As Ralph mentioned, archive retrieval for a time range from start to end should actually include the last sample at-or-before the start time, so you see what the value was right then.
Also consider operator setpoints. Operators may not have changed some setpoint for months. In the archived data, it can be useful to have that sample with the value and time stamp of when it was last set by an operator, instead of repeating the same value every
second, wasting disk space, and then having to add additional logic to figure out when the value last changed.
Instead, the general idea for archiving should be: Configure the ADEL a little wider than the MDEL to throttle the number of updates from the IOC such that you get "significant changes" but not every little bit of noise. The archive then only stores those received
changes, and the data retrieval always includes the last sample at-or-before the requested start time so that for example a plot can show what a user setpoint was at the start of the plot, even though operators last adjusted that setpoint many moons ago and
had no need to change it because it was and still is a very good setpoint.
-Kay
The EAA uses camonitors for both SCAN and MONITOR requests. So, samples should be recorded as long as the IOC is sending camonitor events - the flip side of this is that no samples are recorded if the IOC does not send any camonitor events. I think this is
what you are referring to. There should be standard EPICS ways of making this happen from the IOC side; so this may be accomplished using those techniques.
Regards,
Murali
|