RSLogix-style ladder, timers and tags
Allen-Bradley PLC simulator: XIC/XIO rungs, OTE latches, TON timers and counters
Direct answer
An Allen-Bradley PLC simulator lets you build and run RSLogix-style ladder without a controller or a Studio 5000 license. This browser version accepts XIC, XIO, OTE, OTL and OTU with named timer and counter blocks, runs them against modeled machine I/O and grades the observed behavior. It teaches transferable logic; it is not Rockwell firmware or a Logix project emulator.
This guide is written for students, maintenance technicians and PLC programmers who will meet RSLogix 500 or Studio 5000 projects at work and want to practice reading and writing Allen-Bradley-style ladder before they have controller access. The intended result is specific: the learner can predict what each rung writes on every scan, choose deliberately between OTE and an OTL/OTU pair, use timer and counter done states correctly, and name the behaviors that still have to be confirmed on a Rockwell controller.
XIC and XIO examine a bit, not a device
XIC is true when its referenced bit is 1 and XIO is true when it is 0. Neither instruction knows how the field device is wired. A normally closed stop button holds its input at 1 while healthy, so the run rung examines it with XIC, which surprises learners who expect XIO to mean stop.
OTE rewrites its bit every scan
OTE copies the rung result into its bit on every scan: a true rung sets it and a false rung clears it. That makes OTE non-retentive and means the last OTE written to a tag decides its value. OTL sets a bit and OTU clears it only while their rungs are true; between those events the bit keeps its state.
Timer status members
A Logix TON carries EN, TT and DN status bits plus a preset and an accumulator counted in milliseconds. EN follows the rung, TT is true while timing, DN turns on when the accumulator reaches the preset, and a false rung resets the timer. RSLogix 500 timers use a selectable time base instead, so the same preset number can mean a different duration.
Counters count transitions
CTU adds one on each false-to-true transition of its rung, not on every scan the rung stays true; the CU bit stores the previous rung state to detect that edge. DN sets when the accumulator reaches the preset and counting continues past it until a reset clears it. CTD decrements on the same kind of transition.
Tag names versus file addresses
RSLogix 500 locates data by file type and position: I:1/0 for an input bit, B3:0/5 for an internal bit, T4:2.DN for a timer done bit, N7:10 for an integer. Logix controllers use named tags with controller or program scope, and alias tags that point at module data. The simulator TAG line joins both ideas by binding a name to a legacy-style address.
Scan order and I/O timing
Rungs are solved top to bottom, so a bit changed on rung 5 is already new when rung 9 reads it but still old when rung 2 reads it in the same scan. SLC-style controllers exchange I/O between scans; Logix controllers update I/O asynchronously at each module RPI, so an input can change mid-scan unless it is buffered. The simulator uses the synchronous read, solve, write model.
- 01
Write the I/O list first
Declare every input and output with a TAG line, a descriptive name and an address, and record whether each field contact is wired normally open or normally closed.
Evidence: Every rung references a named tag and the normally closed stop is examined with the correct instruction.
Avoid: Starting with rungs and inventing tag names mid-program.
- 02
Build the seal-in rung
Put XIC Start in parallel with XIC Motor, in series with the stop condition, driving OTE Motor.
Evidence: Start holds the output through the parallel branch and stop drops it on the next scan.
Avoid: Using OTL and OTU for a run command that must drop out when a permissive or power is lost.
- 03
Add a delay with TON
Enable a TON from the condition that must persist and drive the next action from the timer done output, not from the enable.
Evidence: The output changes only after the preset and stays off if the condition breaks early.
Avoid: Driving the output from the same condition that enables the timer, which makes the delay do nothing.
- 04
Count real events
Feed a CTU from a sensor that goes false between parts and give it a separate reset condition.
Evidence: One part produces one count and the done output appears exactly at the preset.
Avoid: Forgetting the reset, so the second batch starts with the counter already done.
- 05
Trace one scan at a time
Change inputs slowly with the live rung highlighting on and write your prediction for each rung before it evaluates.
Evidence: The prediction matches the highlighted rung and the output state for every input change.
Avoid: Watching only the final output lamp and guessing which rung failed.
- 06
Recreate in Rockwell software
Rebuild the proven pattern in RSLogix 500 or Studio 5000 against the real I/O configuration and test it online under site procedures.
Evidence: The same test cases pass on the target controller, including power-up, mode change and fault recovery.
Avoid: Assuming browser results cover prescan, first-scan, RPI timing or retentive memory behavior.
| Observed symptom | Inspect | Interpretation | Next proving action |
|---|---|---|---|
| Output ignores a rung that is clearly true | Cross-reference every OTE that writes the tag and the order of those rungs | Duplicate destructive bit: two OTEs write the same bit and the lower rung overwrites the upper one on every scan. | Merge the conditions into one OTE rung with parallel branches, or use an OTL/OTU pair on purpose. |
| Motor keeps running with start and stop both pressed | Rung order of the OTL and OTU instructions and the conditions on each rung | When both rungs are true in one scan the instruction solved last decides the bit; an OTL below its OTU makes start dominant. | Place the OTU after the OTL, or add the stop condition to the OTL rung so stop always wins. |
| TON never reaches done | The enable condition over several seconds, the accumulator and any brief drop of the enable | A TON resets its accumulator whenever its rung goes false, so a chattering sensor or a one-scan pulse restarts timing. | Hold or debounce the enable; in Logix use an RTO with a RES where accumulated time must survive interruptions. |
| Counter increments once, then stops | The rung feeding the CTU, the reset condition and the accumulator value | A CTU needs a new false-to-true transition for every count; a feed that stays true, or a reset held on, blocks further counts. | Confirm the feed goes false between parts and the reset is false while counting. |
| One-shot logic fires unpredictably | The storage bit of each ONS and whether any is shared or written by other logic | ONS remembers the previous rung state in its storage bit; sharing or overwriting that bit corrupts edge detection. | Give every ONS a unique storage bit; in the learning dialect practice the same edge with R_TRIG or an explicit memory-bit rung. |
| Converted RSLogix 500 logic reacts to the wrong input | Alias tags, module slot, and the original I:slot/bit address against the Logix Local:slot:I.Data.bit path | A conversion maps file addresses to tags; an alias pointing at the wrong slot or bit gives correct logic with the wrong signal. | Toggle one field input at a time and confirm exactly one expected tag changes. |
Product evidence / 05
What the browser practice can actually demonstrate
The Allen-Bradley learning dialect parses XIC, XIO, OTE, OTL and OTU with series and parallel branches, TON, TOF and TP timers, CTU, CTD and CTUD counters, and R_TRIG and F_TRIG edge blocks. A TAG line binds a readable name to a legacy-style address such as I:0/0, and scenario checks pass only on observed input-to-output behavior.
What is the difference between OTE and OTL in Allen-Bradley ladder?
OTE writes its bit true or false on every scan to match the rung, so the output drops as soon as the rung goes false. OTL only sets the bit, which then stays on until an OTU rung clears it, even if the OTL rung goes false. Use OTE for most outputs and OTL/OTU only where retained state is intended.
What is a duplicate destructive bit?
It is a bit written by more than one non-retentive output, typically two OTEs on the same tag in different rungs. Each scan the lower rung overwrites the upper one, so the upper rung appears to do nothing. Combine the conditions into a single OTE rung using parallel branches, or deliberately use a latch and unlatch pair.
What is the difference between TON, TOF and RTO?
A TON sets its done bit after its rung has been true for the preset time and resets when the rung goes false. A TOF keeps done true for the preset time after the rung goes false. An RTO accumulates time like a TON but keeps the accumulated value when the rung goes false and needs a RES to clear it.
How do I reset an Allen-Bradley counter?
In RSLogix 500 and Studio 5000 a RES instruction addressed to the counter clears its accumulator and status bits while its rung is true. In the simulator learning dialect the CTU block takes a reset input instead. In both cases keep the reset false while counting, or every new count is immediately cleared.
Why is a normally closed stop button examined with XIC?
A normally closed stop contact keeps the input energized, so the input bit is 1 while the button is released. XIC is true while that bit is 1, which lets the rung run, and pressing stop drops the bit and breaks the rung. A broken wire also stops the machine, which is why stop circuits are wired this way.
Does the simulator support ONS, OSR and RTO?
Not in the current Allen-Bradley learning dialect. It accepts TON, TOF and TP timers, CTU, CTD and CTUD counters and R_TRIG and F_TRIG edge blocks. You can practice the same ideas with those blocks or with an explicit memory-bit rung, then use the real Rockwell instructions when you move to RSLogix 500 or Studio 5000.
Can I import an RSLogix or Studio 5000 project?
No. The simulator does not open or export .ACD or .RSS files, module configurations or tag databases. Rebuild the specific rungs you want to study in the learning dialect using synthetic tag names, and do not paste proprietary plant logic into a training account. Validate any production change in the Rockwell software and on the target controller.
Does the simulator scan like a ControlLogix controller?
Only at the level of rung order. The simulator reads inputs, solves the program top to bottom and then writes outputs on a deterministic teaching clock. A ControlLogix or CompactLogix controller runs tasks with their own periods and priorities and updates I/O asynchronously at module RPIs, so timing-sensitive logic must be retested on the target.