Most control loops are treated as if they live alone: one measurement, one valve, one job. But when two loops share the same piece of process, each one's valve also disturbs the other one's measurement, and the two controllers can end up quietly working against each other. That coupling is loop interaction, and its signature is an oscillation that shows up only when both loops are in automatic at the same time.
Loop interaction in one line: Loop interaction is the coupling that occurs when two or more control loops share a process so that each loop's manipulated variable affects the others' controlled variables. Strong interaction can make the loops fight, producing oscillation that appears only when both are in auto. It is resolved by choosing the right pairing of measurements to valves, detuning one loop, or adding decoupling.
Imagine a process where two things must be held steady at once and two valves are available to do it, but neither valve affects only one of the two things. A classic case is blending, where two streams set both a total flow and a ratio: opening either valve changes both the total and the ratio, so the flow controller and the ratio controller are pulling on the same physical levers. Distillation columns, where reflux and reboiler both affect top and bottom compositions, are another textbook example, as are pressure-and-flow pairs on shared headers.
When the loops are coupled, each controller sees the other's action as a disturbance. The first controller moves its valve to correct its own error; that move disturbs the second controller's measurement; the second controller corrects, which disturbs the first; and around it goes. If the interaction is mild the loops settle a bit sluggishly and no one notices. If it is strong and the tunings are aggressive, the two corrections reinforce each other and the pair oscillates, hunting back and forth in a rhythm that neither loop shows when it runs alone.
The tell-tale symptom is exactly that conditional behavior. Put either loop in auto by itself, with the other in manual, and it is stable and well-behaved. Put both in auto and a slow, sustained oscillation appears, often with the two measurements swinging out of phase with each other as they trade the disturbance back and forth. Operators sometimes chase this for weeks by retuning one loop at a time, which never works, because the problem is not in either loop individually - it is in the coupling between them.
The first and cheapest fix is correct pairing: deciding which measurement each controller should manipulate which valve to control. Some pairings leave the loops nearly independent while others maximize the fight, and picking the wrong one guarantees trouble no matter how carefully you tune. A structured way to make this choice is the relative gain array, a numerical measure of how much each valve affects each measurement with the other loops open versus closed; it turns pairing from a guess into a calculation. Good pairing alone often reduces interaction to a level where the loops coexist happily.
When pairing cannot fully separate the loops, the next lever is detuning. If you deliberately make one loop faster and the other slower - a wide separation in response speed - they stop competing on the same timescale. The fast loop handles its variable before the slow loop reacts, and the slow loop no longer feels the fast one as a persistent disturbance. This is a pragmatic, low-cost move that trades a little performance on the detuned loop for stable coexistence, and it is often all a plant needs.
For the strongest interactions, where you genuinely need both loops fast and tight, decoupling adds explicit compensation so that a move on one valve is automatically offset to cancel its effect on the other loop's measurement. Feedforward-style decoupling and true multivariable control both do this, at the cost of a model of how the loops interact and the effort to maintain it. Decoupling is powerful but heavier to build and keep working, so the usual escalation is pairing first, detuning next, and decoupling only when the process really demands it.
Loop interaction is easiest to diagnose from data that shows both loops together over time, which is exactly what a SCADA historian provides. The definitive test is to trend both controlled variables and both controller modes on one time axis and look at the moments when the modes change. If the oscillation reliably starts when the second loop goes to auto and stops when it returns to manual, and if the two measurements swing out of phase during the oscillation, you have interaction rather than a single mistuned loop. That mode-correlated evidence is hard to see from a local faceplate but obvious on a shared trend.
The likely causes to work through, once interaction is confirmed, are a poor measurement-to-valve pairing, two loops tuned equally aggressively so they compete on the same timescale, or a genuinely tightly coupled process that needs decoupling. The diagnostic steps follow the same order as the fixes: verify each loop is stable alone, then trend both in auto to confirm the out-of-phase oscillation, then evaluate whether swapping the pairing or slowing one loop calms it before reaching for full decoupling. Working in that order avoids the common trap of endlessly retuning individual loops.
In a cloud SCADA platform like Merobix, the practical value is having every loop's process variable, setpoint, output, and mode recorded together and viewable from any browser, so an engineer can review a plant upset after the fact and see the interaction signature without being on site during it. The platform does not replace the control system's tuning or decoupling logic, which live in the DCS or PLC, but by making the multi-loop picture visible and by alarming on sustained oscillation it turns an intermittent, hard-to-reproduce complaint into concrete evidence that points straight at pairing and detuning as the cure.
Because the oscillation is created by the two controllers reacting to each other, not by either loop on its own. With one loop in manual, its valve holds still and cannot feed a disturbance back into the other loop, so the loop in auto stays stable. Only when both are actively correcting can their moves reinforce each other into a sustained swing, which is why putting one loop in manual is the quickest confirming test.
The relative gain array is a numerical tool for choosing the best pairing of measurements to valves, which is the first defense against interaction. It quantifies how much each valve influences each measurement with the other loops open versus closed, and the resulting numbers flag pairings that will fight and pairings that will stay independent. Loop interaction is the plain-language problem; the relative gain array is one of the structured methods used to diagnose and avoid it.
Detuning is simpler and usually tried first: slowing one loop so the two no longer compete on the same timescale often reduces interaction to an acceptable level with no new hardware or models. Decoupling is more powerful because it actively cancels one loop's effect on the other, but it needs a process model and ongoing maintenance. Reach for decoupling only when the process truly requires both loops to stay fast and tight at once.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.