Fixed-timer plunger control does the same thing every cycle regardless of how the well responds, which means it is always slightly wrong as conditions change. Adjust-on-arrival control replaces that rigidity with a feedback loop: the controller watches how fast each plunger arrives and tunes the next cycle to keep that speed where it wants it. This guide explains how adjust-on-arrival works, why arrival velocity is the signal it acts on, and how it differs from - and improves on - the fixed-timer cycling it is designed to replace.
Adjust-on-Arrival Control in one line: Adjust-on-arrival control is a closed-loop plunger lift strategy in which the controller lengthens or shortens the next cycle's shut-in time based on how fast the last plunger arrived at surface. If the plunger arrived too fast it shortens shut-in, and if it arrived too slow it lengthens shut-in, automatically steering arrival velocity into a target window. It is the adaptive alternative to running the well on fixed, unchanging timers.
Adjust-on-arrival control treats arrival velocity as a measurement to be regulated, in the same spirit as any feedback control loop. The controller has a target for how fast the plunger should arrive - a window bounded by a minimum velocity, below which the plunger risks not making it up at all, and a maximum, above which it arrives with damaging force. After each cycle, the controller compares the actual arrival velocity to that window and reacts. The single most influential knob it has is shut-in time, because how long the well builds pressure before the valve opens determines how much energy is available to drive the plunger, and therefore how fast it arrives.
The control logic is intuitive. If the last plunger arrived faster than the target, the well had more energy than needed, so the controller shortens the next shut-in - less build time, less energy, a slower and gentler arrival, and less production lost to sitting shut in. If the plunger arrived slower than the target, the well was short of energy, so the controller lengthens the next shut-in to build more pressure before opening. If arrival fell within the window, the controller leaves the timing roughly where it is. Cycle by cycle, these small adjustments push the well toward arriving consistently inside the target velocity band.
Because it adjusts incrementally rather than jumping, adjust-on-arrival control settles the well into a stable rhythm and then keeps it there as conditions drift. A well does not hold still - reservoir pressure declines over months, liquid loading varies, line pressure changes - and a fixed timer set for last month is wrong this month. By continually correcting from the most recent arrival, the strategy tracks those slow changes automatically, keeping the well in its productive velocity window without a person re-tuning it each time conditions move.
Fixed-timer cycling is the traditional way to run a plunger well: an operator sets a shut-in time and a flow or afterflow time, and the controller repeats those intervals indefinitely regardless of what the well does. It is simple and predictable, and for a stable well it can work acceptably. Its weakness is that it is open-loop - it never looks at the outcome. If the well starts arriving too slowly because reservoir pressure has fallen, a fixed timer keeps opening on the same schedule and the plunger may begin failing to arrive; if the well becomes stronger, the fixed timer leaves it shut in longer than necessary and gives up production. Keeping fixed timers well-tuned requires an operator to notice the drift and manually change the settings, which across a large field rarely happens promptly.
Adjust-on-arrival control removes that manual burden by making the well self-correcting. Instead of a person periodically inspecting arrival trends and re-entering timer values, the controller does the tuning continuously from the arrival data it already collects. This tends to produce more consistent lifting, fewer non-arrivals as conditions decline, and less wasted shut-in time, because the well is never running on a stale schedule. It also spreads an operator's attention further: wells that would each have needed periodic hand-tuning instead keep themselves in their velocity window, so the operator can focus on the exceptions that the automatic control cannot resolve.
The strategy is not magic - it still needs sensible bounds and a realistic velocity target, and a well whose conditions have degraded past what plunger lift can handle will fall out of its window no matter how the shut-in is adjusted. Adjust-on-arrival control optimizes within the well's capability; it does not manufacture energy the well does not have. But within that capability, letting the last arrival steer the next cycle is a clear step up from a timer that never learns, which is why it is regarded as the modern approach to plunger control.
The control loop itself runs in the field controller, close to the well, so it keeps adjusting each cycle even when communications are down. What a cloud SCADA adds is the ability to configure, monitor, and supervise that loop across an entire field. An operator can set each well's velocity window and adjustment bounds remotely, watch how the automatic tuning is behaving, and confirm that a well is settling into its target rather than fighting its limits - all without driving out to read a controller at the pad. The autonomy of the loop and the visibility of the platform complement each other.
Monitoring an adjust-on-arrival well through SCADA reveals things a single controller cannot show on its own. Seeing arrival velocity trend over weeks, alongside shut-in time and production, tells an operator whether a well is comfortably inside its window or slowly being pushed to the edge as it declines - which is early warning that the well may soon need a different intervention. A cloud SCADA such as Merobix reads plunger controllers over Modbus and DNP3, so these arrival velocities, shut-in times, and the controller's own adjustments become monitored, historized values that an operator can review across many wells at once.
That fieldwide perspective is where adjust-on-arrival and cloud monitoring reinforce each other most. The controllers handle the moment-to-moment tuning locally, keeping each well in its velocity window; the platform aggregates the results, flags the wells that are drifting despite the automatic correction, and lets an operator adjust targets or plan interventions from one screen. For a producer running many plunger wells, the combination turns a large fleet of self-tuning controllers into a supervised, optimizable system rather than a set of black boxes that must each be visited to understand.
It compares the last plunger's arrival velocity to a target window. If the plunger arrived faster than the target, the controller shortens the next shut-in so the well builds less energy and arrives more gently; if it arrived slower, the controller lengthens shut-in to build more pressure. If arrival fell within the window, the timing is left roughly unchanged. Small adjustments each cycle steer the well toward consistent, in-window arrivals.
A fixed timer is open-loop - it repeats the same intervals regardless of how the well responds, so it drifts out of tune as conditions change and needs an operator to notice and re-enter settings. Adjust-on-arrival is closed-loop, continuously correcting from the most recent arrival, so it tracks a declining or strengthening well automatically. That means more consistent lifting, fewer non-arrivals, and less wasted shut-in without manual re-tuning.
It helps, but within limits. As a well declines, the strategy automatically lengthens shut-in to keep building enough energy to hold arrival velocity in the window, which extends the productive life of plunger lift. However, it optimizes within the well's capability and cannot create energy the well no longer has, so a well degraded past what plunger lift can handle will eventually fall out of its window regardless of tuning.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.