Unsuitable station for SRAM support

To summarize SRAM operation, the DataRecoveryService writes values to SRAM as they occur. SRAM is divided into 3 separate blocks. When a block is filled, it is copied from SRAM to the controller’s flash memory. During this “flush process”, data is written to a different block in SRAM.

By default, the DataRecoveryService sets a threshold of 10% of the free flash disk space on the JACE controller for SRAM block data. Once the number of blocks exceeds this threshold, a station save is forced. When the station save successfully completes, those blocks are no longer needed and are deleted from the flash memory.

With this in mind, note that in some cases it is possible a JACE’s station may be an unsuitable candidate for SRAM support. For example, a station with many “change of value” (COV) histories, associated with rapidly changing values, may result in SRAM data buffers filling too often. This results in the “automatic database save”, as performed by the DataRecoveryService when SRAM buffers become full, to occur too frequently—possibly every couple of minutes.

Ideally, such database saves (to flash memory) should occur no more than once an hour.

High frequency database saves are undesirable for two reasons:

Inefficient use of the JACE’s CPU time, as each automatic save consumes processing power otherwise used by other processes (threads) in the station.
Possible flash memory problems in the future, resulting from too many writes every few minutes—or minute. Even though the file system on the JACE performs flash-wear leveling, excessive writes to flash could lead to problems over time.

See the following station examples: