A trend client only has a few hundred to a couple of thousand pixels of width, but the data behind a chart can be millions of raw samples. Returning every one of those samples across the wire just to draw a line that is the same width either way would be slow and wasteful. A plot-values query is the retrieval mode trend tools use to avoid that: it asks the historian to send only enough representative points to reproduce what the chart would look like at that width, so a year of data plots in an instant and the visible shape, including sharp spikes, is preserved. This page explains what the historian returns for a plot-values query, why it is not the same as an average, and how it keeps trends both fast and honest.
Plot-values query in one line: A plot-values query is a display-optimized retrieval mode in which the historian divides the requested time range into as many intervals as the chart has pixels and returns a small set of representative points per interval, typically the minimum, maximum, first, and last value, rather than every raw sample. This lets a trend draw a very long time span quickly while still showing brief spikes and drops that a plain average would smooth away. It is about reproducing the visible curve efficiently, not about computing true statistics.
When a user asks for a year of a fast tag on a trend, the raw archive might hold millions of samples for that tag. Transferring and rendering all of them would strain the network, the historian, and the client, and yet the chart is only a few hundred pixels wide, so the vast majority of those points would land on the same pixel column and be invisible. The plot-values query exists to close that gap between how much data exists and how much a screen can actually show. The client tells the historian the time range and roughly how many intervals it wants, usually one per horizontal pixel, and the historian returns just those.
The subtlety is that naive downsampling can lie. If the historian simply returned every hundredth sample, or a single average per pixel column, a one-second pressure spike buried in an hour of calm would vanish, and an operator scrolling a year of history might never see a brief excursion that actually tripped an alarm. That is the exact opposite of what a trend is for. A plot-values query is designed so that the extremes inside each interval survive, because the whole point of looking at a long trend is to spot the moments that stand out.
So plot-values is best understood as a rendering aid rather than an analytic result. It answers the question the chart is asking, which is what does this curve look like at this width, and it answers it with the smallest number of points that still draw the right picture. If a user then zooms in on a suspicious spike, the client issues a new plot-values query over the narrower range, and because the intervals are now much shorter, more detail is returned, converging toward raw data as the window tightens.
For each interval that corresponds to a pixel column, a typical plot-values query returns a handful of characteristic points rather than one. The most common set is the minimum and the maximum within the interval, plus the first and last actual samples of that interval. Returning both the min and the max guarantees the vertical extent of the data in that column is drawn, so a spike that reaches far above the surrounding values still produces a tall mark. Returning the first and last preserves the continuity of the line as it enters and leaves the column, so the curve joins cleanly to its neighbors.
Crucially these are real stored samples with their real timestamps and quality, selected from the interval, not synthetic values computed from it. That is the sharp difference from an aggregate query. An average, a time-weighted average, or an interpolated value is a calculation that produces a number that may never have existed in the archive. A plot-values result is a selection of points that did exist, chosen because they define the shape of the curve. This is why plot-values is safe for drawing but should not be used when someone needs a true statistic such as the mean discharge pressure for the shift.
Because the number of returned points is bounded by the number of intervals, the payload is roughly constant regardless of whether the range is a day or a decade. A wider window simply means each interval covers more time and the min, max, first, and last are drawn from a larger pool of raw samples. That bounded-size behavior is what makes plot-values feel instant even as history grows, and it is why trend clients use it by default and only fall back to raw retrieval when a user zooms in far enough that raw points are few.
In a SCADA or cloud monitoring context, the plot-values pattern is what lets a browser-based trend feel responsive over a network with real latency. The heavy work of scanning millions of samples and reducing them to a few per pixel happens on the historian, close to the data, and only the reduced set crosses the wire. A remote engineer pulling up a month of a flare tag from a laptop gets a chart that renders as fast as one covering an hour, because the client asked for the same modest number of points in both cases.
This division of labor also keeps trends honest on constrained links. Because the extremes survive the reduction, a supervisor watching a fleet of sites from a central dashboard can still see the brief upsets that matter, even though almost none of the raw samples were sent. If the tool instead requested plain averages to save bandwidth, the very events worth investigating would be the ones smoothed out of existence, which would quietly erode trust in the trend.
The practical guidance for anyone building or configuring dashboards is to use plot-values retrieval for interactive trending and reserve raw or aggregate retrieval for the cases that truly need them, such as exact calculations, exports, or a zoomed-in view of a specific short window. Understanding that a plot-values chart is a faithful sketch rather than a full transcript also prevents a common mistake, which is reading exact values off a long-range trend when the point being hovered is a representative min or max, not necessarily the value at that precise instant.
An aggregate query computes a statistic such as an average, sum, or standard deviation over each interval and returns a calculated number. A plot-values query instead selects real stored samples, typically the min, max, first, and last of each interval, so the chart shows the actual extremes rather than a smoothed value. Use aggregates when you need true numbers and plot-values when you need a fast, faithful drawing of the curve.
No, that is exactly what it is designed to avoid. By returning both the minimum and the maximum within each pixel-interval, it guarantees that a brief spike or drop inside that interval still produces a mark at the correct height. This is the main reason plot-values is preferred over plain decimation or averaging for trends, since those methods can erase short excursions.
When you zoom in, the client issues a new plot-values query over the narrower time range, and because there are still the same number of pixel-intervals covering a much shorter span, each interval now spans very little time and returns points that are close to the raw data. Keep zooming and the intervals eventually hold only a sample or two each, so the trend converges on the raw archive values.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.