How to Set a Plunger Arrival Failure Alarm

Back to Blog

Choose the Arrival Timeout From the Well's History

The arrival timeout is the window, measured from when the controller opens the well, within which the plunger is expected to reach the surface arrival sensor. Set it from the well's own normal open-to-arrival times, not a generic number. Collect a range of recent successful arrivals and set the timeout comfortably longer than the slowest normal arrival, so ordinary cycle-to-cycle variation does not read as a failure. A timeout set too tight will flag healthy slow arrivals; one set too loose will let a real failure sit too long.

Account for the well's normal spread of arrival times. Plunger arrival is not perfectly consistent, so the timeout has to bracket the natural variation seen across changing conditions. If arrival times vary widely, the timeout has to be generous enough to cover the slow end, which means accepting a slightly longer detection delay for a genuine miss. Reading the well's arrival distribution from its history is how you set a timeout that is tight enough to be useful but loose enough not to nuisance-trip.

Base the timeout on the same arrival signal the controller already uses, so the alarm and the normal cycle logic agree on what arrival means. The controller detects the plunger reaching surface through its arrival sensor, and the non-arrival timeout is simply the absence of that detection within the window. Keeping the definition of plunger arrival detection consistent between the normal cycle and the alarm avoids a mismatch where the two disagree about what counts as an arrival.

Decide the Missed-Arrival Count and Response

Decide whether a single non-arrival triggers the protective response or whether the controller tolerates a count of consecutive misses first. A single occasional miss can happen on a healthy well, so some operators allow one or two misses before taking the well offline, while others treat any miss as a shut-in event depending on the risk of a stranded plunger. This is a well-specific decision that balances nuisance shut-ins against the danger of continuing to cycle a well whose plunger is not arriving.

Configure the protective response the non-arrival triggers. The safe default is to close the well and raise an alarm so an operator can investigate before the well is cycled again, because continuing to open a well whose plunger did not arrive risks stranding it or making the situation worse. The response should also make the failure clearly visible to operators rather than burying it. Setting this response is where the alarm becomes protection, following the well plan's guidance on how to handle a non-arrival.

Make sure the alarm is actionable, not just noisy. A non-arrival alarm should reach whoever can respond and carry enough context - which well, how many misses, current pressures - to act on. Tying it into a clear response so operators know what to do when it fires is what makes it useful, and it benefits from the same thinking as any good alarm response procedure. An alarm nobody acts on protects nothing.

Validate the Alarm on Real Cycles

After configuring the timeout, the miss count, and the response, watch the well run through real cycles and confirm the alarm behaves. Successful normal arrivals should not trip the alarm, even the slower ones, which confirms the timeout is not too tight. Watching a stretch of normal cycles pass cleanly is the evidence that you have not created a nuisance alarm that operators will learn to ignore, which would defeat the purpose.

Confirm the alarm actually fires on a genuine non-arrival. If a real miss occurs during the validation period, verify the alarm triggers within the intended window and the protective response executes - the well closes and the alarm is raised and delivered. If you cannot wait for a natural miss, confirm through the controller's logic that a simulated absence of arrival within the timeout would trigger correctly, without forcing an unsafe real test on the well.

Tune the timeout if the validation shows it is mis-set. If normal slow arrivals are tripping the alarm, lengthen the timeout; if genuine misses are taking too long to catch, tighten it within the bounds the well's variation allows. Record the final settings alongside the well's arrival baseline so the alarm can be reviewed later against how the well actually behaves. A non-arrival alarm set from and validated against real cycles is one you can trust to protect the well without crying wolf.

Common Mistakes

The most common mistake is setting the arrival timeout from a generic number instead of the well's own arrival history, which either nuisance-trips on normal slow arrivals or lets real failures sit too long. Set it from the observed spread of successful arrivals.

The second is configuring the alarm to fire but not to drive a safe response, so a non-arrival is announced while the controller keeps cycling a well whose plunger did not arrive. The third is never validating on real cycles, which lets a mis-set timeout go unnoticed until it either floods operators with false alarms or misses a genuine failure.

Frequently Asked Questions