PLC Simulator
debugging
tools
fault diagnosis
ladder logic
how to

How to Use the PLC Variable Table and Cross-Reference (With Examples)

By PLC Simulation Software7 min read

How to Use the PLC Variable Table and Cross-Reference

Every serious PLC programming environment includes two tools that are often overlooked by beginners: the variable table (also called the watch table, monitor table, or force table) and the cross-reference. When you encounter a fault and the scan-cycle highlight shows you a FALSE rung, these two tools tell you why it is false.

PLC variable table and cross-reference debugging tools overview

The Variable Table

The variable table lets you monitor the current state of any variable, bit, or register in the PLC in real time — not just the ones visible in the current ladder view.

What you can monitor:

  • Any named tag or device address (X0, M100, Motor_Run, Tank_Level)
  • Timer and counter accumulators and done bits
  • Data registers (D0, DB10.DBX0.0, etc.)
  • Analog input raw counts and scaled values

In the simulator: Open the Variable Table panel from the toolbar. Click + to add a variable. Type the tag name or device address and it appears in the list with its current value, updating each scan.

A typical variable table pairs each tag name with its data type, device address, and a comment:

Sample PLC variable table listing tag name, type, address and comment

Example: Why isn't Timer T1 expiring?

You expect a motor to start 5 seconds after a start command. It never starts. You check the output coil rung — it is FALSE. The input to that rung is the T1 done bit. You need to know: is T1 running? Has it accumulated any time?

  1. Open the variable table
  2. Add T1.IN (IEC) or T1 (Mitsubishi device) to the watch list
  3. Also add T1.ACC (IEC) or the timer current value
  4. Run the program and press start

If T1.IN stays FALSE, the timer is not even started — the problem is upstream of the timer rung. If T1.IN is TRUE but T1.ACC is stuck at 0, the timer instruction may not be executing (check if the rung leading to the timer is conditional and not being satisfied). If T1.ACC is incrementing but much slower than expected, you have a timer resolution issue — revisit the preset and clock source.

Force mode in the variable table

The variable table also allows forcing — setting a variable to a specific value regardless of what the program computes. Forcing is powerful for isolating faults: you can force an input TRUE to test what the logic would do if the field device was working correctly.

Safety rule: Always check the Force List before disconnecting from a PLC. Never leave forces enabled. An unexpected forced bit can cause unexpected machine movement when the machine is restarted by someone else. The simulator flags all active forces prominently in the interface.


The Cross-Reference

The cross-reference is a tool that shows every rung in the entire program that reads or writes a specific tag or device address.

Why it matters: In a 200-rung program, a single bit might be read by 8 rungs and written by 3. If you want to understand why a bit is TRUE, you need to find every rung that sets it. If you want to understand why a change to one rung caused unexpected behaviour elsewhere, you need to find every rung that reads it.

Diagram of a PLC cross-reference linking one tag to every rung that reads or writes it

The same tags show up in the rungs themselves — here a Start contact and a timer done bit driving the motor coil, all traceable through the cross-reference:

Ladder rung whose Start, timer and motor tags appear in the PLC cross-reference

In the simulator: Open the Cross-Reference panel. Type a tag or device address. The tool shows every rung that references it, with a column indicating whether each reference is a read (contact) or write (coil).

Example: M100 is TRUE, but I don't know where it gets set

You are looking at a sequencer that is stuck on step 4. The sequencer advances based on a comparison: IF Step_Counter = 4 AND M100 THEN advance. But M100 is TRUE when it should not be. Why?

  1. Open the cross-reference for M100
  2. Find every rung that writes M100 — there are three
  3. Rung 12 sets M100 when a sensor is blocked
  4. Rung 45 sets M100 when a timer expires
  5. Rung 87 resets M100 on the next cycle start

Using the cross-reference, you find that rung 45 — a timer done bit — is staying TRUE because the timer is never being reset. The timer is latched in the done state. Now you have a clear path to the fix.

That sequence — cross-reference the output, list every rung that writes it, then watch those tags — is the repeatable path for any unexpected output:

Flowchart for using the PLC cross-reference to debug an unexpected output

Cross-reference in the fault module

The cross-reference is especially powerful in fault injection exercises. When the simulator injects a fault that changes the behaviour of a contact or coil, the cross-reference lets you quickly find every place that variable appears — shortcutting the need to read every rung manually.

The fault injection guide has more on using these tools in fault sessions.


Make the tools work for you: tag naming

Both tools are only as good as your tag names. A variable table full of bare addresses is far harder to debug than one full of meaningful names:

Checklist of good PLC tag-naming conventions

The fields themselves are near-universal, even though each vendor labels them slightly differently — learn the IEC names and the rest map across:

Table of variable table fields across IEC 61131-3, Allen-Bradley and Siemens


Variable Table + Cross-Reference + Scan Highlight: The Complete Workflow

When a machine misbehaves, these three tools work together:

  1. Scan-cycle highlight (live mode): Identify the failing output — which output rung is FALSE?
  2. Scan-cycle highlight (slow mode): Step through the rung input by input — which contact is blocking it?
  3. Cross-reference: For the blocking contact's variable — find every rung that writes it. Which one should be setting it TRUE, and is it?
  4. Variable table: Add the key variables from those upstream rungs to the watch list and monitor them for a few scans. Confirm which variable is not changing as expected.
  5. Force mode (if needed): Force the suspected variable to the expected state and observe if the fault clears. If it does, you have confirmed the root cause.

This is the diagnostic workflow every field service engineer uses on connected hardware — with better tools (a laptop, a full IDE). The simulator lets you practise it risk-free at your own pace.


Try these tools in the simulator. The variable table, cross-reference, and scan-cycle highlight are available in all curriculum exercises and the sandbox. Start with the free lessons.

Start the free curriculum →

Share:X / TwitterLinkedIn

Practice this yourself in the simulator

3 scenarios free — no install, no credit card. Write real ladder logic against a live machine model.

Try the simulator free →

Related articles

ladder logic
function block

Ladder Logic vs Function Block Diagram: When to Use Each

Ladder logic suits discrete interlocks and relay replacement; function block diagram suits analog, PID, and reusable logic. Compare LD vs FBD and pick the right one.

June 7, 2026 · 8 min read
ladder logic
examples

PLC Programming Examples and Solutions (with Ladder Logic)

Eight classic PLC programming examples with full ladder logic solutions and explanations — motor seal-in, timers, counters, traffic lights, tank control and star-delta.

June 7, 2026 · 10 min read
tutorial
ladder logic

Conveyor Belt PLC Programming: Ladder Logic Examples

Conveyor belt PLC programming explained with worked ladder logic examples — start/stop seal-in, photo-eye part counting and diverting, jam handling, plus the I/O layout, timing diagrams and a state machine for a real conveyor.

May 27, 2026 · 8 min read