A bump test is the hands-on procedure that turns a loop into data: you put the controller in manual, step its output, and record how the process variable reacts. The resulting reaction curve is where the three numbers every tuning method needs - process gain, time constant, and dead time - actually come from. It is the data-gathering step that has to happen before any tuning calculation, and doing it safely and cleanly is what separates a reliable tune from a lucky guess. This is a procedure page: how to bump, how to read the curve, and how to stay out of trouble while doing it.
Bump Test / Step Test in one line: A bump test, or step test, is an open-loop procedure in which the controller is put in manual and its output is stepped by a fixed amount while the process variable response is recorded. The resulting reaction curve is analyzed to extract process gain, time constant, and dead time - the model parameters that tuning methods require.
The test begins by putting the loop in manual so the controller stops acting and you have direct command of the output - this makes it an open-loop test, with the feedback path broken on purpose. Before touching anything, confirm the process is at a steady, representative operating point, because a reaction curve started from a drifting baseline is nearly impossible to read cleanly. Note the starting output and the starting process variable; these are the reference the whole test is measured against.
Then step the output by a deliberate, modest amount - large enough that the process variable response clearly rises above measurement noise, but small enough that the process stays within safe limits and does not trip an alarm, overfill a vessel, or push equipment past its ratings. Choosing the step size is a judgment call: too small and the reaction disappears into the noise, too large and you risk the process. When in doubt, make it just big enough to see a clean response and no bigger.
A useful refinement is the doublet, a step in one direction followed later by an equal step back, which returns the process toward where it started and limits how far it wanders. Doublets are valuable on processes that cannot be left sitting at an off-normal condition, and repeating the bump in both directions also reveals whether the process gain is different up versus down, a common sign of valve nonlinearity or stiction. Throughout, keep a hand ready to return the loop to automatic if the process heads somewhere it should not.
Once the process variable has settled at its new value, the recorded curve contains everything you need. Process gain is the settled change in PV divided by the change in output, both in consistent units - if a 10 percent output step eventually moves the PV by 25 percent of span, the gain is 2.5. This is the steady-state number, so it must be read only after the response has genuinely flattened, not while it is still climbing.
Dead time is the flat interval at the start, between the moment you stepped the output and the moment the PV first begins to move. It is read straight off the time axis, and getting its endpoint right matters because everything after it is measured relative to the start of the actual response. The time constant is then the time from the start of that response to the point where the PV has covered 63.2 percent of its total change - the standard first-order measure of how fast the process reacts.
Those three values - gain, dead time, and time constant - are the first-order-plus-dead-time model of the loop, and they are exactly what tuning methods consume. The quality of the tune can never exceed the quality of this reading, which is why a clean, well-settled curve matters so much. A curve that never fully settled gives a wrong gain, a mistimed dead-time endpoint distorts the time constant, and both errors flow straight into the tuning constants you calculate.
The bump test depends on two capabilities that a cloud SCADA platform provides directly: the ability to command the controller output and the ability to record the process variable at high resolution. When a platform such as Merobix can place a loop in manual, step the output over a supported protocol, and historize the PV response with accurate timestamps, an engineer can run and read a bump test on a remote site from a desk rather than a truck. The reaction curve is captured to the historian and available for analysis immediately and later.
Because writing to a controller output puts a physical valve under remote command, this is exactly the kind of action that belongs behind role-based permissions and clear confirmation. A bump test is intentionally an off-normal move, and the same care that applies to any remote output command applies doubly here - the operator running the test should know the process is at a safe point and should be positioned to return the loop to automatic if the response goes further than expected.
The historized reaction curve also becomes a lasting record of the loop's dynamics at a known date. Repeating a bump months later and overlaying the two curves shows at a glance whether the process gain, dead time, or time constant has shifted - the signature of a fouling exchanger, a worn valve, or a partially plugged line. On unmanned assets, that comparison, made from stored bump data rather than a live visit, is often the earliest evidence that the physical process is changing.
Big enough that the process variable response clearly stands out from measurement noise, but small enough that the process stays within safe limits and does not trip alarms or push equipment past its ratings. There is no universal number - it depends on the noise level and how much headroom the process has. When unsure, use the smallest step that still gives a clean, readable reaction curve.
A doublet is a bump test that steps the output one way, then steps it back by an equal amount, returning the process toward its starting point instead of leaving it at an off-normal condition. It limits how far the process wanders and is useful where the process cannot sit at an off-target value. Bumping in both directions also reveals whether the gain differs up versus down, exposing valve nonlinearity or stiction.
Putting the loop in manual breaks the feedback path so the controller stops reacting, making the test open-loop. That way the process variable responds only to your deliberate output step and nothing else, which is what lets you read a clean gain, dead time, and time constant. If the controller were still in automatic, it would fight your step and corrupt the reaction curve.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.