PLC codes are the instructions and programs that tell a programmable logic controller what to do, such as XIC (examine if closed), OTE (output energize), TON (on-delay timer) and CTU (count up). The same phrase also covers controller and drive fault codes. This reference explains both, with PLC code examples you can run in the browser.
Watch the real browser product respond to the task on this page, then try the same practical workflow yourself. No slides, concept mockups, install, or credit card.
Try this in the browserThree meanings, one evidence path
Use the visual sequence to identify the code type first. Then open the matching reference, run the control pattern and preserve the exact diagnostic evidence before consulting the hardware manual.
Follow the workflow
Rockwell-style mnemonic codes include XIC, XIO, OTE, OTL, OTU, ONS, CTU and MOV. IEC systems express similar behavior with contacts, coils and standard function blocks such as TON, TOF and CTU.
Do this in the product
Build a contact-and-coil rung in the guided exercise, then use the PLC instruction reference for per-instruction truth tables, syntax notes and examples.
Open the exerciseUseful examples combine instructions into patterns: seal-in motor control, start permissives, alarm latches, pump alternation, traffic-light sequences, counters and analog scaling. The pattern and its edge cases matter more than copying addresses.
Do this in the product
Use the ladder logic examples and PLC projects hubs to open a matching scenario in the simulator.
Open the exerciseCPU, I/O, drive and communication fault numbers are vendor-, family- and firmware-specific. Record the exact code, state and timestamp; preserve evidence; then use the manufacturer manual. Never clear a fault repeatedly without finding the cause.
Do this in the product
Practice the evidence workflow in electrical troubleshooting and commissioning scenarios without claiming a generic table replaces the manual.
Open the exerciseIEC Structured Text uses statements such as IF, CASE, FOR and function blocks. Vendor environments add libraries and data types, so test portability rather than assuming source code will compile unchanged.
Do this in the product
Compare the same lesson across IEC, Allen-Bradley and Siemens dialect views in the product.
Open the exerciseA status bit is only meaningful in context: the input image that was sampled, the rung order, the current timer or counter state, the output update and the task that owns the code. Preserve that state before forcing, resetting or editing anything.
Do this in the product
Run a normal case, an edge case and a recovery case; compare the live I/O and test evidence before accepting the program.
Open the exerciseField reference
These tables separate instruction syntax, reusable control patterns and hardware diagnostics. Use them to choose the right reference before changing a running program.
Searches for PLC codes mix four different jobs. Start here so a ladder mnemonic is not confused with a CPU fault number or a complete control program.
| Code type | Examples | Use it for | Correct next step |
|---|---|---|---|
| Instruction mnemonic | XIC, XIO, OTE, TON, CTU, MOV | Building one operation inside ladder or Structured Text | Check operands and scan behavior in the instruction manual, then run a focused test. |
| Program pattern | Seal-in, permissive chain, alarm latch, pump alternation | Combining instructions into a reusable control behavior | Test normal, boundary, interlock and recovery cases against the machine brief. |
| Controller or I/O diagnostic | Major fault type/code, module status, channel diagnostic | Locating a CPU, task, connection, module or channel problem | Preserve the event record and open the manual for the exact controller and firmware. |
| Drive or field-device fault | Overcurrent, undervoltage, encoder, network or thermal trip | Diagnosing a VFD, servo, instrument or smart device | Record active conditions and use the exact device-family manual; do not substitute a generic list. |
Each row shows one control task as Allen-Bradley ladder instructions (read left to right, one rung per line) and as IEC 61131-3 Structured Text. Stop buttons are wired normally closed on real panels, so the healthy input is true and the rung examines it as closed (XIC), not open (XIO).
| Task | Ladder instructions (Allen-Bradley) | Structured Text (IEC 61131-3) | What to test |
|---|---|---|---|
| Motor start/stop with seal-in | Branch [XIC Start_PB | XIC Motor] → XIC Stop_PB → XIO Overload → OTE Motor | Motor := (Start_PB OR Motor) AND Stop_PB AND NOT Overload; | Motor stays on after Start is released and drops out on Stop, overload and a broken Stop wire. |
| Forward/reverse interlock | XIC Fwd_PB → XIO Rev → OTE Fwd; XIC Rev_PB → XIO Fwd → OTE Rev | Fwd := Fwd_PB AND NOT Rev; Rev := Rev_PB AND NOT Fwd; | Both directions can never be true together, even when both buttons are pressed; pair it with a hardwired interlock. |
| On-delay timer | XIC Run → TON Delay_T (preset 5000 ms); XIC Delay_T.DN → OTE Fan | Delay(IN := Run, PT := T#5S); Fan := Delay.Q; | Fan waits 5 s after Run turns on, turns off immediately with Run and restarts timing from zero. |
| Count parts | XIC Photo_Eye → CTU Parts_C (preset 12); XIC Parts_C.DN → OTE Case_Full; XIC Reset_PB → RES Parts_C | Count(CU := Photo_Eye, R := Reset_PB, PV := 12); Case_Full := Count.Q; | One count per part even when the beam stays blocked for many scans; Reset returns the count to zero. |
| Count each button press once | XIC Button → ONS Button_OS → ADD Presses 1 Presses | Edge(CLK := Button); IF Edge.Q THEN Presses := Presses + 1; END_IF; | Holding the button adds exactly one; releasing and pressing again adds one more. |
Names vary by vendor. The transferable part is the state transition: what is read, what is retained, when an edge is recognized and what must reset.
| Family | Common codes | What changes during the scan | Minimum proof test |
|---|---|---|---|
| Contacts | XIC / XIO; NO / NC contact | The rung condition reads a Boolean tag; the symbol does not change the physical wiring. | Toggle the source bit and verify both true and false paths. |
| Outputs | OTE / coil; SET-RESET; OTL / OTU | A non-retentive coil follows the solved rung; latch instructions retain state until an explicit reset. | Prove de-energization on Stop, interlock and restart. |
| Timers | TON, TOF, TP, RTO | Elapsed state advances with scan time while enabling conditions and reset rules differ. | Test just below, at and just above the preset, then interrupt and restart. |
| Counters | CTU, CTD, CTUD, RES | Counts normally change on a qualifying edge, not on every scan that the input remains true. | Hold the input true, pulse it repeatedly and verify reset and rollover assumptions. |
| Edges | ONS, OSR, R_TRIG, F_TRIG | The output is true for one execution when the remembered previous state changes. | Prove one pulse per transition and verify first-scan behavior. |
| Compare and limit | EQU, NEQ, GRT, LES, LIM; EQ, GT, LT | The rung result depends on type, sign, scaling and boundary inclusion. | Test both boundaries, one value outside each side and invalid or stale data. |
| Data and math | MOV, COP, ADD, SUB, MUL, DIV, SCALE | Values change immediately for later rungs in the same task; type conversion can truncate or overflow. | Check data types, zero division, range limits and downstream rung order. |
| Sequence and state | CASE, sequencer, step bits, state machine | Only permitted transitions should advance the process; recovery must return to a defined state. | Test every transition, aborted step, power-up state and manual recovery path. |
A numeric code without provenance is weak evidence. Capture the surrounding state before changing the plant, then consult the authoritative manual.
| Layer | Capture before reset | Likely evidence source | Unsafe shortcut to avoid |
|---|---|---|---|
| Controller and task | Mode, major/minor class, type/code, task and timestamp | Controller fault log, diagnostic buffer and programming manual | Repeatedly clearing a major fault without locating the triggering instruction. |
| Remote I/O and channel | Module state, channel state, field power and last known value | Module status page, wiring diagram and module manual | Assuming a logic fault when field power or a channel is unhealthy. |
| Industrial network | Link state, connection status, topology, device reachability and sequence of events | Managed-switch diagnostics, controller connections and device manual | Replacing a device before checking power, cabling, addressing and connection state. |
| Drive and motor | Drive trip, DC bus, current, speed command, thermal state and run source | Exact VFD/servo manual plus measured electrical and mechanical evidence | Resetting an overcurrent or thermal trip and immediately restarting the load. |
| Program behavior | Input image, rung state, retained bits, timer/counter values and commanded outputs | Online monitor, trend, event log and repeatable simulator test | Treating an energized output command as proof that the actuator moved safely. |
Core concepts
The simulator creates a repeatable result; these concepts make that result transferable to real vendor software and supervised practical work.
A short instruction identifier such as XIC or OTE. Meaning and operand rules depend on the platform.
A tested arrangement of instructions that solves a recurring control problem, including reset and fault behavior.
Code, timestamp, active state, surrounding I/O and preceding event sequence make a fault number actionable.
The same code can produce a different result when rung order, retentive state, edge detection or task timing changes. Predict the scan before editing the pattern.
Primary documentation
Standards and vendor manuals outrank generic code lists when firmware, operands, fault recovery or safety behavior matters. These links are the evidence base for this reference.
Continue in the workspace
Run the foundation exercise publicly, then use a subscription for advanced challenges, saved configurations, full attempt history, sharing, assigned paths and team reporting.
Related learning surfaces
Technical reference and worked-example guide
Direct answer
The reader can classify the code being searched, find its correct owner and verify meaning in the target context.
Written for learners and technicians trying to distinguish instruction mnemonics, sample logic, controller faults and device diagnostics.
Vendor, controller or device, software, firmware, code text or number, screen, timestamp, operating state and preceding event.
Observed code through the correct instruction reference, program context or diagnostic manual to an evidence-based next action.
One known instruction and one known fault interpreted with source and context retained.
Same number across vendors, decimal versus hexadecimal, stale alarm, translated wording, symptom code and undocumented reset.
An identity, context, source, interpretation, program, device or process-response mismatch.
The conclusion verified in current official documentation and against the actual controller or device state.
PLC code and example path
Read the instruction behavior, inspect a complete pattern, run its edge cases and then adapt it as a project.