Studio 5000 Logix Designer is the programming software for Rockwell Automation ControlLogix and CompactLogix controllers. Logix ladder is built from a small set of instructions that almost every rung uses: contacts that read a bit, coils that write one, timers, counters and compare blocks. This page explains nine of them in the vendor's own terms, then shows the equivalent in IEC 61131-3 and lets you run a short exercise.
Every instruction below works on named tags, not on fixed addresses. A tag is a typed variable such as Motor_Run (BOOL) or Pump_Timer (TIMER). That is the first habit to unlearn if you come from older PLC-5 or SLC 500 work, where the address told you the file and the bit.
What the browser editor does and does not simulate
The exercises run in our browser Allen-Bradley dialect, which is a learning subset: XIC, XIO, OTE, OTL, OTU, TON, TOF, CTU and one-shots as R_TRIG. Timers use the IEC style (PT in, Q out) instead of the Logix TIMER structure with PRE, ACC and DN, and the editor does not simulate GRT, LES, MOV or JSR. Each unit says where this differs from real Logix Designer.
Studio 5000 PLC scan time: what the Logix scan does
A Logix controller runs its logic inside tasks. A continuous task restarts as soon as it finishes; a periodic task runs on a fixed interval; an event task runs when a trigger fires. Each task owns programs, and each program owns routines of ladder, structured text or function block logic. The time one pass through a task takes is its scan time.
Inside a rung, instructions run left to right and rungs run top to bottom, so a bit written by one rung is already updated when a later rung reads it. Input and output module data, however, are exchanged with the controller on their own schedule (the requested packet interval of each module) rather than frozen once per scan, so a physical input can change between two rungs of the same scan. Programs that must see one consistent value copy the input into an internal tag at the top of the routine.
Logix Designer reports last and maximum scan time for each task in the task properties while online. A long scan delays every output the task writes, which is why a timer-sensitive rung belongs in a periodic task with a known interval rather than in a continuous task whose scan time drifts as code is added.
A contact asks a yes-or-no question about a bit: is it on right now? If the answer is yes the rung can keep passing power to the right; if no, the rung stops there. XIC is the Logix way to ask "is this bit on?".
What it does exactly
XIC stands for Examine If Closed. It looks at one BOOL tag, and the instruction is true when the tag holds 1 and false when it holds 0. It only reads the tag. It never writes it, so any number of XIC instructions can examine the same bit.
Two XIC instructions one after the other on a rung are in series, so both bits must be on. Two on separate branches are in parallel, so either one is enough. The tag can be a physical input, an internal bit, an output bit, or a timer or counter status bit.
The IEC and editor equivalent
XIC is the IEC normally open contact. In this editor it is written XIC KEY_A, and in IEC ladder text it is | KEY_A |.
What the scan does with it
XIC reads the value the bit holds at the moment the controller reaches that instruction in the scan. A rung above can change an internal bit and the XIC below sees the new value in the same scan.
TAG KEY_A I:0/0 BOOL
TAG KEY_B I:0/1 BOOL
TAG LAMP O:0/0 BOOL
XIC KEY_A XIC KEY_B OTE LAMP
Two permit keys in series: the lamp needs both.
Common mistakes
Assuming XIC means "the button is pressed". It means the bit is 1. A stop button wired normally closed reads 1 when it is not pressed, so XIC on that bit is true at rest.
Forgetting that XIC on an output bit reads what the program last wrote, not the real voltage at the terminal.
What you can now do: You can read any XIC rung as a yes-or-no question and write a series permit from two bits.
Sometimes you want a rung to run only while something is not happening: while there is no fault, or while a door is not open. XIO asks the opposite question to XIC: is this bit off?
What it does exactly
XIO stands for Examine If Open. It is true when the tag holds 0 and false when it holds 1, so for any bit exactly one of XIC and XIO is true on a given scan. Like XIC it is read-only.
The usual use is a blocking condition: XIC Request XIO Fault OTE Run_Allowed. The fault bit means "a fault exists", so the rung needs it to be 0. The wiring decides which instruction a field device needs: a normally closed stop button reads 1 at rest, so it is examined with XIC, and an XIO is only right for that button if it was wired normally open.
The IEC and editor equivalent
XIO is the IEC normally closed contact, written NOT FAULT in structured text and | NOT FAULT | in this editor's ladder text. In the AB dialect here it is XIO FAULT.
What the scan does with it
XIO evaluates at its position in the scan, like any contact. A fault bit set by an earlier rung blocks a later XIO on the same pass.
TAG REQUEST I:0/0 BOOL
TAG FAULT I:0/1 BOOL
TAG RUN_LAMP O:0/0 BOOL
XIC REQUEST XIO FAULT OTE RUN_LAMP
A requested run is allowed only while no fault is present.
Common mistakes
Choosing XIO because the real button is "normally closed". Pick the instruction from the value the bit holds in the state you want to detect, not from the contact symbol in the electrical drawing.
Putting the XIO on a bit that nothing ever writes, so the rung is always true and the fault logic never blocks anything.
What you can now do: You can use XIO to block a rung on a fault and explain why a normally closed field device often needs an XIC.
An output instruction is where a rung finally does something: it writes a bit that turns on a lamp, a contactor or another rung's condition. OTE is the plain output that follows its rung.
What it does exactly
OTE stands for Output Energize. When the rung in front of it is true it writes 1 to its tag, and when the rung is false it writes 0. Because a false rung writes 0, an OTE bit is not held: the output drops the moment the conditions drop.
Each OTE should be the only OTE for its tag in the whole program. If two rungs both write the same bit with OTE, the rung scanned last decides the result for that scan, and the earlier rung looks as if it did nothing. Joining the conditions with a parallel branch ahead of a single OTE removes the conflict.
The IEC and editor equivalent
OTE is the IEC output coil, written := in this editor's ladder text, as in | START | := LAMP ;.
What the scan does with it
OTE writes its tag immediately in memory, so a later rung in the same scan can examine the new value. A physical output module only receives the value when the controller next sends output data, not at the instant of the write.
TAG ALARM_1 I:0/0 BOOL
TAG ALARM_2 I:0/1 BOOL
TAG HORN O:0/0 BOOL
(XIC ALARM_1 OR XIC ALARM_2) OTE HORN
One OTE with a parallel branch instead of two competing OTEs.
Common mistakes
Writing the same bit from two OTE rungs, then wondering why one of the conditions never works. Search the project for the tag name before adding another OTE.
Expecting an OTE to remember. If the output must stay on after the trigger disappears, use a seal-in contact or OTL and OTU instead.
What you can now do: You can spot a duplicate-OTE bug and merge competing rungs into one output rung.
Some things should stay on after the thing that caused them has gone: a high-level alarm that blipped, a fault that tripped a machine. A latch is a bit that stays on until someone deliberately clears it.
What it does exactly
OTL stands for Output Latch and OTU for Output Unlatch. When its rung is true, OTL writes 1 to its tag; when the rung is false it does nothing at all. OTU does the mirror image: it writes 0 when its rung is true and leaves the tag alone otherwise.
The pair is normally used on the same tag in two separate rungs, so the alarm is set by one condition and cleared by another. Because a false rung leaves the bit as it was, the bit keeps its value through any number of scans until the unlatch rung fires.
The IEC and editor equivalent
OTL and OTU are the IEC set and reset coils. This editor's dialect uses OTL ALARM and OTU ALARM; in Siemens terms they are S and R, and in Mitsubishi terms SET and RST.
What the scan does with it
If an OTL rung and an OTU rung for one bit are both true in the same scan, the rung that comes later in the routine wins, because it writes last. Place the unlatch rung after the latch rung when clearing should take priority.
TAG LEVEL_HIGH I:0/0 BOOL
TAG ACK I:0/1 BOOL
TAG ALARM O:0/0 BOOL
XIC LEVEL_HIGH OTL ALARM
XIC ACK OTU ALARM
The alarm latches on the level signal and clears on acknowledge.
Common mistakes
Latching an alarm with no unlatch rung, so the only way to clear it is to download or force the tag.
Using OTL for an ordinary run output, which keeps a motor energised after the operator stops caring about it. Reserve latches for states that must be remembered.
What you can now do: You can latch a remembered condition and clear it with a separate rung, and say which rung wins when both are true.
A timer lets a rung wait before it does something: start the pump three seconds after the request, so the valve has time to open. The on-delay timer starts counting when its rung goes true and reports done when the time is up.
What it does exactly
In Logix a timer is a tag of the TIMER type. It holds a preset PRE and an accumulated value ACC, both in milliseconds, plus three status bits: EN (enabled), TT (timing) and DN (done). TON starts ACC from zero when its rung becomes true and adds the elapsed time each scan. When ACC reaches PRE, DN turns on.
If the rung goes false before the time is up, TON resets: ACC goes back to zero and the status bits clear, so a short pulse never finishes the delay. The thing that drives the pump is not the request but the timer's DN bit, examined with an XIC.
The IEC and editor equivalent
IEC TON has input IN, preset PT, output Q and elapsed time ET. Q matches the Logix DN bit and ET matches ACC. In this editor, write TON T_PUMP PT:3000 and read T_PUMP.Q.
What the scan does with it
The timer adds the real time elapsed since the last scan, not a count of scans, so the delay is the same however fast the controller scans. The DN bit is updated when the TON instruction executes, so a rung placed above the TON sees last scan's DN.
TAG PUMP_REQ I:0/0 BOOL
TAG PUMP_RUN O:0/0 BOOL
TAG T_PUMP TON
XIC PUMP_REQ TON T_PUMP PT:3000
XIC T_PUMP.Q OTE PUMP_RUN
The pump follows the timer's done bit, not the request.
Common mistakes
Driving the output from the request bit as well as the timer, so the output comes on at once and the delay does nothing.
Putting the TON on a rung that is only true for one scan, such as a one-shot output. The timer resets the next scan and never reaches PRE.
What you can now do: You can delay an output with TON, name the PRE, ACC and DN parts, and explain why the timer rung must stay true.
An off-delay timer does the opposite of an on-delay: it keeps something running for a while after the cause has gone. A cooling fan that runs on after the motor stops is the classic case.
What it does exactly
TOF is also a TIMER tag with PRE, ACC, EN, TT and DN. When its rung is true, DN is on and ACC is held at zero. When the rung goes false, the timer starts counting up. DN stays on until ACC reaches PRE, then DN turns off.
So the done bit is on while the rung is true and for PRE milliseconds afterwards, and the output the timer drives behaves like a delayed turn-off. If the rung goes true again while the timer is counting, ACC resets and DN stays on.
The IEC and editor equivalent
IEC TOF has IN, PT, Q and ET, and its Q follows the same rule: on with IN, then off PT after IN falls. In this editor write TOF T_FAN PT:4000 and read T_FAN.Q.
What the scan does with it
Nothing special happens on the scan the rung drops: the done bit is still on, and the timer begins accumulating on that scan and the following ones. The fan output therefore stays on for the full preset measured in real time.
TAG MOTOR I:0/0 BOOL
TAG FAN O:0/0 BOOL
TAG T_FAN TOF
XIC MOTOR TOF T_FAN PT:4000
XIC T_FAN.Q OTE FAN
The fan keeps running for four seconds after the motor stops.
Common mistakes
Reading the done bit as "the timer finished timing". For a TOF, done being on means the output should still be on.
Using a TON with an inverted rung to fake a run-on. It works only until the inverted rung is false for a different reason.
What you can now do: You can build a run-on with TOF and say what its done bit means on the way up and on the way down.
A counter remembers how many times something has happened: parts past a sensor, boxes onto a pallet. A count-up counter adds one each time its input switches on and tells you when it has reached the target.
What it does exactly
A Logix counter is a COUNTER tag with a preset PRE, an accumulated count ACC and status bits including CU, CD, DN, OV and UN. CTU adds 1 to ACC each time its rung goes from false to true. DN turns on when ACC is greater than or equal to PRE.
The count does not fall when the rung goes false. It is cleared only by a separate RES instruction that names the same counter tag, which also clears DN. Counting continues past the preset, so DN stays on until the reset.
The IEC and editor equivalent
IEC CTU takes CU, a reset input, a preset PV, and gives Q and the count CV. This editor writes CTU PART_COUNT IN:PART_SENSOR R:RESET_PB PV:5 and reads PART_COUNT.Q. A Logix RES rung is the reset input here.
What the scan does with it
The counter counts a transition, not a level: a sensor that stays on for one hundred scans adds one, not one hundred. A transition shorter than one scan can be missed entirely, which is why fast sensors need a faster task or a high-speed input.
TAG PART_SENSOR I:0/0 BOOL
TAG RESET_PB I:0/1 BOOL
TAG BATCH_FULL O:0/0 BOOL
TAG PART_COUNT CTU
CTU PART_COUNT IN:PART_SENSOR R:RESET_PB PV:5
XIC PART_COUNT.Q OTE BATCH_FULL
Five parts fill the box; the reset clears it.
Common mistakes
Forgetting the RES rung, so the next batch starts with a full counter and the done bit already on.
Putting the counter on a rung that is true for several scans and expecting each scan to count. Only the false-to-true change counts.
What you can now do: You can count rung transitions to a preset and clear the counter with a separate reset.
A held button stays on for many scans, but sometimes you want one action per press: toggle a light once, add one to a count. A one-shot turns "the button is on" into "the button has just gone on".
What it does exactly
The Logix ONS instruction is placed in a rung with a storage bit, a BOOL tag that remembers the rung condition from the previous scan. The instruction is true for exactly one scan when the rung condition changes from false to true, and false on every later scan while the condition stays true.
Logix also has OSR and OSF, which take a storage bit and a separate output bit, for rising and falling edges. A rung that must act once per press places the ONS in front of the action, for example in front of an OTL or an instruction that changes a value.
The IEC and editor equivalent
The IEC equivalent is the R_TRIG function block, whose Q output is true for one scan on a rising edge. This editor has no ONS instruction, so the exercise writes R_TRIG EDGE CLK:BTN and reads EDGE.Q.
What the scan does with it
A one-shot true for a single scan can be seen only by rungs that run after it in that same scan, or by a bit it sets. A rung above the ONS in the routine sees the pulse a full scan late or misses it.
Compare instructions ask whether one number is bigger or smaller than another, so a rung can react to a level, a temperature or a count instead of an on/off switch.
What it does exactly
GRT is true when Source A is greater than Source B, and LES is true when Source A is less than Source B. Both are strict: if the two values are equal, neither is true. GEQ and LEQ include the equal case, and EQU and NEQ test for equal and not equal.
The sources are tags or constants of a numeric type. A compare instruction is an input instruction like a contact: it passes the rung when its test holds and has no output of its own, so it sits in front of an OTE or another action.
The IEC and editor equivalent
The IEC functions are GT, LT, GE, LE, EQ and NE. The editor runs the IEC form: IS_HIGH := GT(LEVEL, 70);. This editor does not simulate GRT or LES in the AB dialect, so the exercise uses the IEC dialect.
What the scan does with it
A compare reads the two values at its position in the scan. If a value comes from an analog input that updates between scans, two compares of the same tag in different rungs can disagree, so compare a copied value when it matters.
It is the time one pass through a task takes. A Logix controller runs logic inside tasks, and Logix Designer shows the last and maximum scan time for each task while online. A longer scan delays every output that task writes, so timing-sensitive logic belongs in a periodic task with a known interval.
How is a Logix timer different from an IEC TON?
A Logix timer is a TIMER tag with a preset PRE and an accumulated value ACC in milliseconds and the status bits EN, TT and DN. An IEC TON has IN, PT, Q and ET. The behaviour is the same: DN matches Q and ACC matches ET. The browser editor uses the IEC style, so you read T_PUMP.Q where Logix has T_PUMP.DN.
Why does my output drop when two rungs use OTE on the same tag?
Both OTE instructions write the tag every scan, and the rung scanned last wins. The earlier rung looks as if it did nothing. Join the conditions with a parallel branch ahead of a single OTE, or use OTL and OTU if the bit must be remembered.
Which Logix instructions does the browser editor simulate?
XIC, XIO, OTE, OTL, OTU, TON, TOF, CTU and one-shots written as R_TRIG. It does not simulate GRT, LES, MOV or JSR in the Allen-Bradley dialect, so those units run as the IEC equivalent.
Training material. Follow your site procedures, local electrical code and the manufacturer's instructions. Lockout/tagout and a qualified person are required for real equipment.