How to Troubleshoot Non-Linear Scaling and PID Ratio Control in PLCs

To troubleshoot PLC edge cases such as non-linear tank scaling and PID ratio control, engineers should validate logic against simulated process behavior before deployment. OLLA Lab provides a browser-based environment to build ladder logic, inject disturbances, observe I/O causality, and compare intended control philosophy against realistic equipment response without hardware risk.

Textbook PLC answers usually fail for a simple reason: many of them assume linear sensors, obedient actuators, and a process that does not misbehave. Real plants are less polite.

When a horizontal tank does not scale linearly, or a ratio loop starts drifting during a flow disturbance, engineers often end up in forums reading partial answers from strangers with varying levels of rigor. Some of that advice is excellent. Some of it is folklore with syntax. The risk begins when unverified logic moves straight from a browser tab to a live controller.

In a recent internal Ampergon Vallis QA exercise, engineers replicated 100 unresolved forum-style analog troubleshooting cases in OLLA Lab and found that 72 of the reported “PID tuning failures” were better explained by upstream scaling or signal-characterization errors than by controller tuning alone [Methodology: Sample size = 100 forum-style unresolved analog cases; Task definition = reproduce issue, isolate fault source, and classify dominant cause; Baseline comparator = original forum diagnosis or implied fault framing; Time window = Ampergon Vallis QA internal review, Q1 2026]. This supports one narrow point: simulation helps separate loop problems from measurement problems. It does not prove any industry-wide failure rate.

Textbook answers fail because they usually model the signal path as ideal and the machine response as immediate. Field systems rarely offer either condition.

A 4–20 mA input in a live process is not just a number to scale. It carries transmitter error, wiring noise, filtering effects, sensor lag, possible grounding issues, and sometimes the quiet sabotage of a bad installation. A valve command is not the same as valve movement. Stiction, deadband, backlash, and slow pneumatics all matter. The ladder may be correct while the process still behaves badly. Commissioning teaches that distinction quickly.

The practical error is to treat PLC logic as if it were only syntax. It is not. It is executable control intent coupled to physical behavior.

This is where a simulation environment becomes operationally useful. In OLLA Lab, users can build ladder logic in a browser-based editor, run the sequence in simulation mode, inspect variables and I/O states, and test analog behavior before any hardware is involved. That matters because “simulation-ready” should mean something specific: an engineer can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process.

A useful correction is worth making here. Many “PID problems” are not PID problems. They are scaling mistakes, bad feedback assumptions, or sequencing faults wearing a PID badge.

For related reading, see Understanding Scan Cycles: How OLLA Lab Mimics Real Hardware.

Standard linear scaling fails when vessel geometry is non-linear. A single slope-and-offset conversion is not physically correct for spherical tanks, horizontal cylindrical tanks, or any vessel where volume does not increase proportionally with level.

IEC 61131-3 gives you the programming framework for implementing the logic, but it does not rescue a bad process model. If the tank geometry is non-linear, the scaling method must be non-linear too.

What is the correct engineering approach?

The correct approach is to convert measured level to true volume using either:

• a characterized lookup table,
• piece-wise linear interpolation between breakpoints, or
• an explicit geometric equation if the controller and maintainability requirements allow it.

In most plant environments, piece-wise linear approximation is the practical answer. It is often accurate enough when properly segmented, easier to validate, and easier for the next engineer to understand at 2 AM. Elegance is optional; recoverability is not.

Why does a standard SCP instruction fail?

A standard scale-with-parameters instruction assumes:

• the input signal is linear with the measured variable, and
• the measured variable is linear with the engineering quantity you care about.

For a horizontal cylindrical tank, level may be linear with transmitter output, but volume is not linear with height. The middle of the tank accumulates volume faster per unit height than the ends. If you use a single linear scale, the displayed volume will be wrong across much of the range, and any downstream control using that value inherits the error.

How do you implement non-linear scaling in OLLA Lab?

The workflow is straightforward and testable.

Write ladder logic or equivalent compute logic that:

• finds the active segment,
• calculates the local slope,
• interpolates between adjacent points,
• outputs the estimated true volume.

1. Map the geometry Define the level-to-volume relationship using 10 to 20 breakpoints across the vessel range.
2. Build the data structure Enter the breakpoints as arrays or mapped variables in the OLLA Lab Variables Panel.
3. Execute interpolation logic
4. Simulate the process Run the tank scenario in simulation mode and vary the level signal across the full span.
5. Compare calculated versus observed state Validate that the computed volume tracks the simulated tank state across low, mid, and high ranges.

What should “correct” mean here?

Correct should be defined operationally, not cosmetically.

A non-linear scaling implementation is correct when:

• the calculated engineering value stays within the accepted error band across the full operating range,
• alarm thresholds trigger at the intended physical condition,
• control decisions based on volume or inventory remain stable,
• abnormal inputs fail predictably rather than producing nonsense values.

That last point matters. A bad sensor should not create imaginative mathematics.

Example engineering evidence to keep

If you want to demonstrate competence, do not post a screenshot gallery. Build a compact body of engineering evidence:

1. System Description Horizontal cylindrical tank with 4–20 mA level transmitter and derived volume display.
2. Operational definition of “correct” Calculated volume remains within a defined tolerance band across the operating range and drives alarms at the intended physical levels.
3. Ladder logic and simulated equipment state Interpolation routine plus simulated tank fill and drain behavior.
4. The injected fault case Linear scaling substituted for characterized scaling, or a breakpoint entered incorrectly.
5. The revision made Corrected breakpoint array, interpolation segment logic, or input validation.
6. Lessons learned Sensor linearity is not the same as vessel linearity; alarm integrity depends on the engineering model, not just the rung structure.

Labeled Media Concept

- [Language: Ladder Diagram / Compute Block] Piece-wise interpolation logic for non-linear tank volume calculation - Alt text: Screenshot of OLLA Lab Variables Panel and 3D simulation showing a horizontal cylindrical tank, with ladder logic calculating true volume from a non-linear 4–20 mA level input using breakpoint interpolation.

Ratio control is not one PID loop trying to control two flows at once. The correct architecture is usually a master-slave arrangement in which the wild flow determines the setpoint of the controlled flow.

The governing relationship is simple:

Controlled Flow SP = Wild Flow PV × Ratio Setting

That equation is the control philosophy in one line. Everything else is implementation detail, though implementation detail is where plants get expensive.

What is the common forum mistake?

The common mistake is to bind two manipulated variables into one loop or to treat ratio control as if “matching two values” were enough. It is not enough.

A proper ratio scheme typically includes:

• a wild stream that is measured but not directly controlled by the ratio loop,
• a controlled stream with its own flow controller,
• a ratio station that computes the controlled flow setpoint,
• limits, filtering, and bumpless transfer behavior,
• anti-windup handling when the slave valve saturates or the process becomes constrained.

If the slave loop is not healthy, the ratio loop is fiction. A ratio controller cannot compensate for a sticky valve, a saturated output, or a bad flow signal by wishing harder.

How should the control structure be built?

A robust implementation typically follows this sequence:

1. Measure the wild flow PV.
2. Multiply the wild flow by the desired ratio.
3. Apply any required bias, clamping, or low-flow cutoff logic.
4. Send the result as the setpoint to the slave flow controller.
5. Let the slave PID regulate the controlled stream to that setpoint.
6. Monitor for saturation, signal loss, and mode mismatch.

This is standard process control practice because it preserves causality. The wild stream moves first; the controlled stream follows in proportion.

How do you validate ratio control in OLLA Lab?

OLLA Lab’s analog tools, variables visibility, and PID-oriented simulation workflow make this testable without touching a live skid.

A practical validation sequence is:

• create two analog flow tags,
• designate one as the wild flow PV,
• compute the slave setpoint from the ratio equation,
• bind the slave setpoint to the controlled flow loop,
• run the simulation and inject a disturbance into the wild flow,
• observe whether the controlled flow tracks proportionally,
• check for overshoot, lag, saturation, and integral windup.

The point is not that the loop compiles. The point is that the process response remains coherent when the upstream condition changes.

What does a good disturbance test look like?

A useful disturbance test should include at least:

• a step increase in wild flow,
• a step decrease in wild flow,
• a noisy signal segment,
• a low-flow region where ratio logic may need cutoff or minimum handling,
• a constrained-output case where the slave valve cannot achieve demand.

If the ratio looks perfect only under ideal conditions, it is not validated. It is rehearsed optimism.

For related reading, see Beyond Discrete Logic: Mastering Analog and PID in OLLA Lab.

Simulation is the bridge between plausible advice and deployable logic. It converts a verbal suggestion into observed behavior under controlled conditions.

That distinction matters because forum answers are often incomplete in one of three ways:

• they describe the control philosophy but omit implementation details,
• they solve the nominal case but ignore fault states,
• they assume process behavior that was never actually tested.

A software-in-the-loop environment lets an engineer close those gaps before site commissioning. In operational terms, digital twin validation means comparing intended sequence and expected process response against observed simulated behavior. You do not stop at “the rung looks right.” You verify whether the valve hunts, whether the permissive drops out, whether the alarm threshold trips at the correct condition, and whether the sequence recovers cleanly after a fault.

What should be validated before deployment?

At minimum, validate:

Does each input change produce the expected output and state transition?

• I/O causality

Do start, run, stop, trip, and reset states occur in the intended order?

• Sequence integrity

Do scaling, filtering, alarming, and PID interactions behave across the operating range?

• Analog behavior

What happens under sensor loss, chattering feedback, delayed actuation, or impossible process demand?

• Abnormal conditions

Do displayed values, alarms, and permissives match the physical story of the machine?

• Operator-facing consequences

This is where OLLA Lab is credibly positioned: as a bounded validation and rehearsal environment for high-risk commissioning tasks. It is not a substitute for site acceptance testing, functional safety assessment, or plant-specific operating procedures. It is where you discover obvious logic weaknesses before the process has a chance to discover them for you.

Yaga is most useful when the problem statement exists as narrative rather than finished logic. Senior engineers often explain solutions as control philosophy, not as rung-by-rung implementation.

That is normal. A forum answer may say, in effect, “Use lead-lag on the pumps, inhibit alternation on fail, add proof timeout, and latch the common alarm until operator reset.” That is good engineering guidance, but it is not yet executable.

What is Yaga’s bounded role?

Yaga’s role is to help structure and clarify. It can assist users in turning a control narrative into a ladder-logic draft, explain instruction choices, and guide the next implementation step based on user experience level. It does not remove the need for engineering review, simulated testing, or fault validation.

That boundary is important. Draft generation is not deterministic veto.

How should engineers use it safely?

A disciplined workflow looks like this:

1. Paste or summarize the control philosophy.
2. Ask Yaga to break the narrative into states, permissives, interlocks, alarms, and outputs.
3. Build or refine the ladder logic in the editor.
4. Run the simulation.
5. Inspect variables, I/O transitions, and analog response.
6. Inject a fault.
7. Revise the logic based on observed behavior.

Used this way, Yaga reduces translation friction without pretending to certify the result. That is the right level of ambition for AI in controls work.

The article’s claims sit on established standards and process-control practice, with clear boundaries.

Relevant standards and references

- Process-control literature and standard engineering practice support:

• IEC 61131-3 defines programming languages and common software structures for programmable controllers. It supports the ladder-logic and function-implementation frame used here.
• ISA-5.1 standardizes instrumentation symbols and identification, which matters when translating process narratives into coherent tags, loops, and operator-facing logic.
• IEC 61508 frames functional safety at the system level. It is relevant to risk thinking and validation discipline, but this article does not claim that simulation alone establishes safety integrity or compliance.
• piece-wise linear approximation for non-linear measurement relationships,
• master-slave ratio control for blending and dosing applications,
• disturbance testing as part of loop validation.

What this article does and does not claim

This article supports the following claims:

• non-linear vessels require non-linear characterization if true volume matters,
• ratio control is usually implemented through a master-slave structure,
• simulation is a defensible way to validate community-sourced logic before hardware deployment,
• OLLA Lab can be used as a browser-based rehearsal environment for these tasks.

This article does not claim:

• that simulation replaces plant commissioning,
• that Yaga guarantees correct logic,
• that OLLA Lab confers certification, employability, or formal safety qualification,
• that Ampergon Vallis’s internal benchmark generalizes to the entire controls industry.

That is not modesty. It is just proper scope control.

Forum knowledge is often valuable because field problems are messy, specific, and badly covered by manuals. The engineering mistake is not reading forum advice. The mistake is deploying it untested.

Non-linear scaling and ratio control are both good examples of the broader rule. A control strategy is only as sound as the process model beneath it and the validation discipline around it. Syntax is necessary. Deployability is harder.

OLLA Lab fits this workflow as a practical validation environment: build the logic, observe the I/O, inject the disturbance, compare ladder state to equipment state, revise after the fault, and only then carry the idea toward a live process. That is the habit worth building.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)