A flow computer does more than add up volume; it also keeps track of how long a meter run was genuinely flowing during each period, because that flow time is what its flow-weighted averages are built on. To do that honestly it needs to decide the moment a run has actually gone quiet rather than just dipped for an instant, and the no-flow cutoff timer is the mechanism that makes that call. It watches whether the differential pressure has stayed below the cutoff long enough to count the run as idle, and while it counts, the computer stops adding to the accrued flow time. This guide explains how that timer works, why it is separate from the rate cutoff that zeroes the reading, and how the idle decision ripples into hourly flow time and averaging.
No-Flow Cutoff Timer in one line: A no-flow cutoff timer is the logic a flow computer uses to declare a meter run idle after its differential pressure has stayed below the cutoff for a set length of time, at which point the computer stops accruing flow time for that run. It exists so that brief dips below cutoff do not immediately break the flow-time count, and so that a genuinely shut-in run is recognised as not flowing. The declared idle state is what controls whether the period's flow-time keeps advancing and therefore how the flow-weighted averages are formed.
It helps to separate two things a flow computer does when differential pressure falls to nothing. The first is what happens to the instantaneous rate: once differential drops below the low-flow cutoff, the computer forces the calculated rate to zero so that transmitter noise near zero does not integrate into phantom volume. The second, and the subject here, is what happens to flow time: the running tally of how many seconds or minutes within the current period the run was actually delivering. The no-flow cutoff timer is about that second question, deciding when to stop the flow-time clock rather than what to report as the rate.
The distinction matters because flow time is the denominator behind the flow-weighted averages a flow computer records. When the computer forms an average differential, average temperature, or average density for the hour, it weights each sample by the flow time it represents, so that conditions during actual flow dominate and idle stretches do not drag the average toward shut-in values. If flow time kept advancing while the run sat dead, the averages would be diluted by conditions that no gas ever experienced. The timer's job is to make sure the accrued flow time reflects only the intervals the run was really moving product.
So the low-flow cutoff and the no-flow cutoff timer work on the same underlying signal but answer different needs. The cutoff sets the threshold below which flow is treated as zero; the timer decides how long the signal must remain below that threshold before the run is formally declared idle and the flow-time count is held. Reading them as one thing is a common source of confusion, and keeping them apart is the key to understanding why a run can be reporting zero rate for a few seconds yet still be counted as flowing for flow-time purposes.
The timer works on a simple principle of persistence. When differential pressure crosses below the cutoff, the flow computer does not instantly conclude the run has stopped, because a momentary dip can come from a passing disturbance, a control valve stroking, or ordinary signal wander at the low end. Instead it begins timing how long the signal stays below the cutoff. Only after that condition has persisted for the configured no-flow period does the computer declare the run idle and stop accruing flow time. If the differential climbs back above the cutoff before the timer expires, the count resets and the run is still treated as flowing.
This debounce-like behaviour keeps the flow-time record from fragmenting into a rapid stutter of tiny idle and flowing intervals every time a low-flowing run brushes the cutoff. On a run that is barely moving, differential can cross the threshold repeatedly, and without a timer the flow computer would toggle the run status constantly, littering the event log and chopping up the averaging. The no-flow period gives the decision hysteresis in time: a run has to be quiet for a meaningful stretch before it is called idle, and it comes back to flowing as soon as real differential returns.
Once the run is declared idle, the consequences follow through the whole period record. Flow time stops advancing, so the hour's flow-time total reflects only the minutes the run was live. The flow-weighted averages freeze on the last flowing conditions rather than being pulled toward the idle signal, and the run's status is typically logged so an auditor can see when it went idle and when it resumed. When flow returns and stays above cutoff, the computer clears the idle state, resumes accruing flow time, and picks the averaging back up. The net effect is a period record where volume, flow time, and averages all agree about when the run was actually flowing.
The no-flow timer's idle declaration is a genuinely useful operational signal, not just an internal accounting detail. A run that the flow computer has marked idle is telling you the point is shut in or has fallen effectively dead, which on a producing well, a delivery meter, or a plant inlet can be exactly the event an operator wants to know about promptly. Because the timer has already filtered out momentary dips, an idle declaration that persists is a fairly reliable indicator that something has actually stopped rather than merely fluctuated.
This is where a cloud SCADA such as Merobix adds value across a fleet of metering points. By reading run status, accrued flow time, and differential from the flow computers into one place, it lets an operator see which runs have gone idle and how long they have been idle, without visiting each site or polling each computer by hand. A run that goes idle unexpectedly, or one that keeps flickering between idle and flowing near its cutoff, both stand out on a trend, and the second pattern in particular hints that the run may be operating right at the edge of its measurable range.
Watching flow time alongside volume also protects the quality of the numbers. If a run reports volume for an hour but its accrued flow time is far short of the full hour, that gap is worth a look, because it says the run spent much of the period idle and its averages rest on a thin slice of real flow. Surfacing accrued flow time and idle status through cloud monitoring turns the timer's internal decision into visible context, so the people relying on the measurement can tell a healthy full-hour record from one stitched together from a few flowing minutes.
The low-flow cutoff is a differential pressure threshold below which the flow computer forces the calculated rate to zero, which stops noise near zero from integrating into false volume. The no-flow cutoff timer is separate: it decides how long the differential must stay below that threshold before the run is declared idle and flow-time accrual stops. One controls the reported rate, the other controls when flow time is held and how the run's status is reported.
A brief dip below the cutoff can come from a control valve stroking, a passing disturbance, or ordinary signal wander at the low end, none of which mean the run has actually stopped. The timer requires the low condition to persist for a configured period before it calls the run idle, which prevents the run status from stuttering on and off and keeps the flow-time record and event log from fragmenting. If flow returns before the timer expires, the count resets and the run is still treated as flowing.
Flow time is the weighting behind the flow-weighted averages a flow computer records, so conditions during actual flow dominate the hour's averages. When the timer declares a run idle it stops accruing flow time, so idle stretches no longer pull the average differential, temperature, or density toward shut-in values. The result is that the hour's averages reflect only the intervals the run was genuinely delivering, and the accrued flow time shows how much of the hour that was.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.