Configuring Mango for One-Minute In-Memory Point History

After logging is disabled and each point’s default cache size is set to 6, a source polled every 10 seconds keeps only the short in-memory history needed for display. This removes the need to purge minute-old SQL values: they are never written to persistent history.

What is the screen telling you?

Start with the operator-visible requirement. If the display needs current values plus roughly one minute of recent samples, the application needs a short display cache, not a historical database record.

This distinction controls the rest of the decision tree. A purge removes values after they have been stored. Disabling logging prevents those values from entering persistent history. For display-only data, prevention is the direct path.

Is the data point being logged?

Open the configuration for each Data Point and inspect its Logging option. If it is set to log samples, every qualifying poll can create stored history even though the screen only needs transient values. Select Do Not Log for points whose samples have no reporting, audit, analytics, or restart-persistence requirement.

The tag may already be reading the SQL source correctly; the binding between that live tag and historical storage is the problem. A changing value on the screen proves that acquisition is active, but it does not prove whether samples are cached, logged, or both. Read the point configuration rather than inferring storage behavior from the display.

If another consumer needs persistent history from the same value, do not disable logging without accounting for that dependency. Separate display-only acquisition from the historical requirement, or retain logging and accept the supported retention interval. The deciding observation is whether any function must retrieve the sample after it has left the in-memory cache.

Why does a one-minute purge setting not solve it?

Mango runs its purge task once per day, and the configured minimum purge duration in this setup is one day. A request to delete samples within the next minute therefore does not match the available purge schedule. The purge mechanism cannot provide minute-scale disposal merely because the SQL source polls every 10 seconds.

Frequent delete work would also impose avoidable database overhead on a larger system. Logging every sample and then attempting to delete it almost immediately adds writes, index maintenance, and deletion work for data that has no historical value. Do Not Log removes that write-and-delete cycle.

How many values should remain in memory?

At a nominal 10-second polling interval, six samples provide the requested short history:

Set the default cache size to 6 for all display points on the source that need this history depth. This controls the quantity of recent values held in memory; it does not create database retention or change the purge schedule.

Six regularly spaced timestamps contain five intervals between the oldest and newest samples. Polling delays, SQL response time, and missed reads can change the time span represented by the cache. If the operator requirement is stated as an exact elapsed-time window rather than a sample count, inspect the oldest and newest displayed timestamps after configuration and adjust the cache quantity based on measured cadence.

If the display consumes only the current value, a six-value cache is unnecessary for that point. If it draws a short trend, confirm that its binding reads the point’s cached values rather than querying persisted history. The tag can be correct while the display’s history binding is wrong.

How do you apply the resolving configuration?

1. List every Data Point supplied by the SQL data source and identify which points are strictly display-only.
2. For each display-only point, open the Logging option and select Do Not Log.
3. Set the default cache size to 6 for each point that must show approximately one minute of values at a 10-second poll interval.
4. Leave points with a genuine historical requirement out of this change. Their data must use persistent logging and the supported retention process.
5. Confirm that the display or short trend reads the point cache. A widget that queries logged history will appear empty after logging is disabled and must be bound to the live or cached point data instead.

Two configurations can keep data available: logging with scheduled purge, or no logging with an in-memory cache. Both serve valid but different requirements. Use logging when samples must survive beyond runtime memory. Use Do Not Log plus cache size 6 when the values exist only to support a live display; it meets the stated requirement without waiting for the daily purge.

What should be verified after the change?

1. Watch the live point through multiple 10-second polls and confirm that its value and timestamp continue to update.
2. Open the display trend and verify that it receives up to six recent samples from memory.
3. Compare the oldest and newest visible timestamps. Use the measured span to determine whether six samples satisfy the operator’s practical viewing requirement.
4. Check the historical-data view or storage path for the changed points and confirm that new samples are not being persisted.
5. Restart behavior matters: in-memory history is transient. Verify that the application may legitimately start with an empty short-history display and refill it as new polls arrive.

A blank historical trend after selecting Do Not Log does not indicate an acquisition failure when the live value still changes. It indicates that the screen was reading persistent history. Correct that display binding before changing the logging decision.

FAQ