Archive Engine: Operation and Timing

ChannelAccess

The ArchiveEngine is a ChannelAccess client. It receives values served by a ChannelAccess server. This server might be on an EPICS IOC running the EPICS "database". A record in this database can be configured to scan at a fixed rate or be triggered by external hardware signals. The point is that your data source (record in this example) which is served via ChannelAccess has either a fixed periodic behaviour (scanned at a fixed rate, triggered at a fixed frequency) or it might change at an unpredictable rate. You have to know at least something about the nature of your data source.

Fixed Rate Data Sources

If we assume that a record changes every second (1Hz), we might not want to archive every sample because that would be too much data. Instead, we configure the ArchiveEngine to sample this channel every 10 seconds or 30 seconds. While you could configure the ArchiveEngine to sample every .5seconds, this is obviously useless because the data source does not provide new data at this rate.
If on the other hand we are interested in every sample, configurung the ArchiveEngine to scan every second is not advisable: Though both the record and the ArchiveEngine would scan every second, the two scans are not synchronized and rather unpredictable things can happen. Instead, the "Monitor" option for the ArchiveEngine with an estimated period between values of 1 second should be used for this case.

Time Stamps

Each ChannelAccess Server provides time-stamped data. An IOC for example stamps each sample when the corresponding record is processed. These time-stamps offer nano-second granularity. Most applications will not require this accuracy, but some hardware-triggered aquisition, utilizing interrupts on a fast CPU, might in fact put the full time stamp resolution to good use.
The ChannelArchiver as a generic tool does not know about the origin of the time stamps, but it tries to conserve them.

Archived Data

The above example shows the same value, archived with different methods:

• The "Monitor" channel archived every change (up until there are more changes than anticipated, which leads to buffer overwrites, see configuration)
• The channel archived with a "1.0 sec" period is stored every second.
  But: The timestamp written to the archive is not a generated timestamp, for example rounded to "10.0", "11.0", "12.0", ... seconds.
  Instead, every second the last sample provided by the ChannelAccess Server is written, conserving the original time stamps. In this case it happened to be at

  	  9.9679712 seconds
  	 10.9894400 seconds
  	 11.7605488 seconds...
  	

Repeat Counts

To save disk space, the ChannelArchiver writes only changes to the disk. For "Monitor" channels, this is redundant because ChannelAccess does only report changes. For periodically sampled channels, special "Repeat Counts" are written when a value has not changed.
Example:

03/01/2000 16:42:24.983827200 6.50
03/01/2000 16:42:28.000000000 6.50 Repeat 3
03/01/2000 16:42:28.308608000 6.62
03/01/2000 16:42:28.859400000 8.86

This channel was configured with a period of 1 second.
After 16:42:24.98, the value 6.50 was repeated three times when checked at 16:42:26, 16:42:27 and 16:42:28, before the value changed to "6.62".
A retrieval tool can choose to neglect repeat counts because the time stamp is not an original IOC time stamp but an artificial one (usually easy to spot because the nanoseconds are all 0). For plotting, on the other hand, you might prefer to expand the repeat count into inividual samples.

---

ChannelArchiver Manual