When a controller commands a control valve to 62 percent, two questions matter that the command itself cannot answer: did the card actually deliver that output, and what will it do if the controller stops talking to it? Analog output readback and configurable fault states answer those two questions. This guide explains output echo or readback, where the module measures the current it is actually driving, and the fault-state options that decide what a valve does on communication loss or a program stop. Setting the right fault state is not a checkbox; on a real process it is a safety decision.
AO Readback and Fault State in one line: Analog output readback is a diagnostic in which the output module measures the current or voltage it is actually delivering and reports that value back, so the controller can confirm the output obeyed the command and detect an open or shorted loop. The analog output fault state is the configurable behavior the channel adopts when it loses communication with the controller or the controller stops running - it can hold its last value, drive a preset safe value, or go to zero. Both features exist so a final control element behaves predictably even when the control path breaks.
An analog output command is only an instruction; readback is the confirmation. A module with output readback measures the current it is actually sourcing into the loop - the milliamps genuinely flowing to the valve positioner or drive reference - and reports that measured value back to the controller as a separate readback tag. In healthy operation the readback tracks the commanded value closely, and the small difference between them is itself informative. When the two diverge, something in the physical loop is wrong even though the command was issued correctly.
This turns the output channel into a self-checking element rather than a blind actuator. If the module commands 12 mA but reads back near zero, the loop is open - a broken wire, a disconnected positioner, or a blown output stage - and the channel can raise a diagnostic. If it commands a value but cannot drive the current up to it, the loop may be shorted or the load out of range. Without readback, an open output loop is invisible until an operator notices the valve is not moving and a process variable drifts; with readback, the module flags the exact channel immediately.
Readback also validates forcing and manual operations. When a technician forces an output during commissioning or troubleshooting, the readback confirms the field actually received the forced value rather than just the software register accepting it. That closes the loop between what the program thinks the output is and what the wire is really carrying, which is precisely the gap where subtle field faults hide.
The more consequential setting is what an analog output does when it loses its command source. Communication can drop, a network can partition, or the controller can be switched to program or stopped mode, and in every one of those cases the output card is left holding the last value it was told - unless it has been configured to do something else. Output modules provide a fault-state or hold-last-state configuration for exactly this situation, and the common options are: hold the last commanded value, drive a preconfigured fault value, or go to a defined idle such as zero or the low end of range.
Each choice suits a different process. Holding the last value keeps a valve where it was, which is sensible for a slow, stable loop where freezing the position is safer than jumping it - a level control on a large tank, for instance. Driving a preset safe value is right where a specific position is the safe one: a fuel valve that should close, a cooling valve that should open, a recycle valve that should go to a bypass position. Ramping or stepping to zero suits equipment that should back off to a benign state when unsupervised. The card typically lets you set this behavior per channel and often separately for a communication fault versus a program-mode change, because those two conditions may call for different responses.
Getting this wrong is a real hazard. A default of hold-last-value on a channel that should have failed closed can leave a valve wide open with no controller watching it, which during an upset is exactly the wrong behavior. Because the fault state governs what a final control element does at the worst possible moment - when the control system has already lost its grip on the loop - deciding it deliberately, per loop, is part of the process-safety design, not a hardware detail to accept at default.
In the field, the value of readback and fault-state configuration is that operators and engineers can see the truth about their final control elements from a distance. When the output command and its readback are both brought into SCADA as tags, an operator watching a remote skid can compare what the controller asked for against what the card actually delivered, and a persistent gap between them stands out as a loop fault without anyone driving out to swing a valve by hand. On distributed assets - injection skids, chemical pumps, choke controls on remote wells - that visibility is the difference between catching a stuck or open loop early and discovering it only when a downstream measurement goes out of spec.
Fault-state behavior is also something operations needs to understand, not just configure once and forget. Knowing that a given valve is set to fail closed versus hold-last-value tells the control room what to expect the moment communication to that node drops, and it shapes how they respond to a comm-loss alarm. Surfacing both the comm-loss status and the configured fault action in the operator interface removes the guesswork about what the field is doing when the controller is temporarily out of contact.
A cloud SCADA platform such as Merobix supports this by carrying the commanded output, the readback value, and the relevant diagnostic and communication-status tags together over the same telemetry path, and historizing them. That means an engineer can look back after an event and see exactly what each output was commanded to do, what it actually delivered, and how it behaved when the link dropped - the record needed to confirm that a control valve did the safe thing when the control system stopped talking. The card enforces the behavior locally; the platform makes it observable and auditable from wherever the operation is watched.
Readback lets the output module measure the current it is actually driving into the loop and report it back, so the controller can confirm the output obeyed the command. It detects open loops (commanded a value but no current flows), shorted or out-of-range loops, and failed output stages. Without readback, an open analog output loop stays invisible until a process variable drifts and an operator notices the valve is not responding.
That depends on which state is safe for the loop, which is why it is configurable. The usual options are hold the last commanded value, drive a preset safe value, or go to zero. A valve that should close on loss of control is set to a fault value that closes it; a slow, stable loop may be safer holding its last position. Choosing per loop is a process-safety decision, not a default to accept.
Not always - it depends entirely on the process. Holding the last value is fine for a slow loop where freezing the valve is safer than moving it, but it can be dangerous where a specific position is the safe one. If a valve should fail closed and you leave it on hold-last-value, a comm loss during an upset can strand it open with no controller watching. That is why the fault state should be set deliberately for each loop.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.