Testing and debugging ST: the watch table, forcing and simulation

Four tools

Every environment gives you the same four under different names:

Watch table first

Do not guess. Put the variables that tell the story in the table: the step number, the timer's Q and ET, the filtered value, the alarm latch. Eighty percent of bugs show up the moment you compare what you see with what you expected. In this site's lab the table updates once per scan.

Forcing, and why it is dangerous

A force does not change the program; it disconnects a value from reality. A forced output stays forced across a program download, and on some controllers across a power cycle. The rules:

• Never force an output on connected equipment without written permission and a person standing at the device.
• Never force a safety input.
• Write every force down, remove it before you leave, and confirm the force list is empty.
• If a force is needed for the station to run, you are not testing, you are hiding a fault.

The cleaner way to test is an internal simulation variable in the program: it is visible in the code and it disappears with the code.

Single scan

It freezes time. Execute one cycle, read the table, understand. Excellent for finding out in which scan exactly a value changes, and for watching edge detection work. What it is useless for: anything that depends on real time passing, because timers count the clock, not scans.

Simulation

• PLCSIM and PLCSIM Advanced in TIA Portal: a virtual controller that talks to the program and the HMI.
• CODESYS simulation: runs the project on your laptop with one click, breakpoints included.
• This site's lab: an editor, a virtual tank with a pump and a valve, and a watch table, for learning and quick experiments.

Simulation finds logic bugs. It does not find wiring bugs or the real timing of a motor. Treat it as stage one of three: simulate, then bench-test with a real controller and switches, then commission on site.

Breakpoints

CODESYS and TwinCAT let you set a breakpoint on an ST line. Be clear about what happens: the controller halts there, outputs hold their last value, and timers keep counting. On real equipment that means freezing a machine mid-stroke. Breakpoints belong in simulation and on the test bench, not on a running line.

Eight mistakes that keep happening

1. = instead of := — Pump = TRUE; is a comparison with a discarded result, not an assignment. Most compilers reject it; a few accept it quietly.
2. A missing semicolon — the error is usually reported on the next line, so look above the line named.
3. A missing END_IF — the compiler complains about the end of the block while the real cause is a condition opened far earlier.
4. A timer called in a branch that does not run every scan — the classic ST bug. An instance only advances when it is called.
5. Integer division — 7 / 2 is 3. Convert to REAL first, or multiply before you divide.
6. An undetected edge — compare the current state with the previous one, or use R_TRIG. Without it, one button press counts once per scan.
7. Writing an output twice — Pump := TRUE; in one place and Pump := FALSE; in another: the last assignment wins and the first vanishes without a trace.
8. An uninitialised RETAIN — after a battery change or a cold download the batch counter or the setpoint starts at zero. Check them on the first scan.

The lab program has a bug

The program loaded under this lesson is supposed to fill the tank to 60%, hold for 3 seconds, then open the drain valve. Run it and the level stops at 60% and nothing else happens.

The cause is on the list above: the timer is called inside IF Start THEN. Start is a momentary button, so the timer instance only advances while your finger is on it and never completes its three seconds. The watch table says so plainly: Hold.ET stays at zero.

The fix: take the timer call out of the condition so it runs every scan. Delete the IF Start THEN line and its END_IF, leaving the call at program level:

AtLevel := Level >= 60.0;
Hold(IN := AtLevel, PT := T#3s);

The starting condition belongs in the timer's IN, never in a condition wrapped around the call. That rule alone prevents the whole class of bug.