The short answer
I/O Not Updating
When the controller is running and a point does not update, either the module or the rack that holds it is faulted or inhibited, the point is forced, the program is no longer writing or reading the tag, the task that handles it is not executing, or the field wiring is not delivering the change. Check the I/O tree status first, then the force list, then whether the logic that touches the point is executing, then the module indicator against the terminal, and then the field.
Key points
- The I/O tree in the software shows every module state. A faulted or inhibited module explains every point on it.
- Forces override the field and the logic. Check the force list before anything else.
- A point that is not updating may be a task that is not running or a routine that is not called.
- Compare the module indicator, the tag, and the terminal voltage. Where they disagree is the fault.
- Remote racks add the adapter connection to the list. Its status is a tag.
Where a point can stop
A discrete input passes from a field contact to a terminal, a module channel, the module data table, the controller input tag, and the logic that reads it. An output goes the other way. At each stage the value can stop being carried forward, and the diagnosis finds the stage. The fastest order is the one that checks the widest causes first: a module fault stops every point on the module, a force stops one point everywhere, and a wiring fault stops one point at the terminal.
| Stage | What stops it | How to see it |
|---|---|---|
| Module or rack | Faulted, inhibited, removed, or a failed adapter connection | The I/O tree status; the module indicators; the rack connection tag |
| Force | A force installed on the point | The force list in the software; a force indicator on the controller |
| Task or routine | The task not scheduled or the routine not called, so the logic never reads or writes the point | Task status; the routine with online monitoring showing no execution |
| Program | The tag written from two places, an unconditional write, or an alias that points elsewhere | Cross-reference of the tag; online monitor of every write |
| Module configuration | A filter time, a data format, or a channel disabled | The module properties in the I/O tree |
| Terminal and field | Wiring, the field device, the loop power | Voltage at the terminal against the module indicator |
Diagnostic procedure
- 1
Check the I/O tree
Online, open the controller I/O configuration. Every module shows a status: running, faulted with a code, inhibited, or not present. A faulted module explains all its points; the code says why: configuration mismatch, missing, communication lost, a channel fault on an analog module.
- 2
Check the forces
Open the force list. A forced input reads the forced value regardless of the field; a forced output holds regardless of the logic. Remove forces that should not be there, and find out who installed them.
- 3
Confirm the logic executes
Find every reference to the tag with the cross-reference tool. Open the routine online and confirm it is being scanned: the rung states update, or a scan counter increments. A routine that is not called, a task that is not scheduled, or a conditional jump that skips the section leaves the point untouched.
- 4
Check for competing writes
A tag written in two places holds the last write each scan, which can look like a point that never changes. The cross-reference shows every write; an unconditional output instruction in a later rung is the usual culprit.
- 5
Compare the indicator and the tag
For an input, the module channel indicator shows the field state; the tag should match. Indicator on, tag off: the module data is not reaching the tag, which is a module fault, a mapping error, or a task that is not updating. Indicator off with the field contact closed: the terminal or the wiring.
- 6
Measure at the terminal
Voltage at the input terminal with the field device operated. Present and the indicator off: the module channel or its common. Absent: the field wiring, the device, or the loop power.
- 7
For an output, follow it out
Tag on, module indicator on, terminal voltage present: the field. Tag on, indicator off: the module or the output enable. Tag never on: the logic.
- 8
For a remote rack, check the adapter
The connection status tag and the adapter indicators. A rack with a lost connection shows all its inputs frozen at the last value on some platforms and zero on others; the status tag says which is real.
- 9
Check the module configuration
Input filter time on a discrete module set so long that a short pulse is missed; a channel disabled; an analog channel set to the wrong range or format. Compare with the I/O list.
- 10
Fix, then verify through the chain
Operate the field device and watch the indicator, the tag, and the logic respond. Command the output and watch the tag, the indicator, and the device.
Common causes by type
- Analog input frozen
- A channel fault such as open wire or over-range that holds the last value on some modules, a module fault, or a HART or smart module in a configuration state. The channel status bits say which.
- Discrete input never on
- Wrong common: a sinking input wired to a sourcing device, or the module common not connected. Voltage at the terminal with no indicator is the signature.
- Discrete output never on
- Output power missing on the module: many output modules need a separate supply connection per group, and a blown fuse on that group kills the group.
- Points on one module all frozen
- The module faulted or was inhibited; on a remote rack, the adapter dropped.
- Points update slowly
- A remote rack with a long update interval, an input filter, or a task with a long period.
- Points update, then stop after a download
- The download changed the I/O configuration or the tag mapping; a module now faults on a configuration mismatch, or a tag alias moved.
Frequently asked questions
- The module indicator follows the field but the tag does not. What is it?
- The module data is not reaching the tag: a module fault that the tree shows, a mapping or alias error, a task that owns the module and is not running, or a force on the tag. The I/O tree and the force list answer it in a minute.
- Everything on one remote rack froze at once. Why?
- The adapter connection dropped: the network, the adapter power, or the adapter itself. The rack connection status tag is faulted, and the switch port shows the link state. On reconnection the points resume; the outputs went to their fault state in between.
- A single output will not turn on and the tag is on. What is left?
- The module output enable or power for that group, a blown output fuse, a failed channel, or the field circuit. Measure at the terminal: voltage present means the field; absent means the module or its supply.
- Why do inputs work in the test rig and not in the panel?
- Sinking versus sourcing, or the module common. The test rig was wired to suit the module; the panel wiring follows a drawing that assumed the other convention. Check the module manual for the common and the current direction, and the schematic for what was wired.
Related topics
- Inputs Not ReadingA switch closes in the field and the program never sees it. How the wetting voltage, the common, sinking and sourcing, and the wiring each lose the signal, and how to find which one did.
- Outputs Not EnergizingThe program says the output is on and the equipment is not running. Where the signal gets lost between the output image and the field device, and how to find the point in a few measurements.
- PLC I/O SystemsDiscrete and analog input and output modules, sinking and sourcing, relay and transistor outputs, wiring conventions, and the module diagnostics that find field faults from the panel.
- Remote I/OExtending controller I/O to another panel or another site over a network: the adapter and the rack, the update rate and what it costs, what the outputs do when the link fails, the difference between remote I/O and a remote controller, and the wiring, addressing, and diagnostics that make it dependable.
- Tasks and Execution PriorityHow a controller schedules its work: the continuous task, periodic tasks at a fixed rate, event tasks triggered by something happening, how priority preempts, and where each kind of logic belongs.
- The PLC Scan CycleRead inputs, solve logic, write outputs, housekeeping. Understanding scan order explains most PLC behavior that looks wrong at first glance.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.