Debugging Structured Text with live values and test cases

The Core Idea

Debugging turns a report of wrong behavior into a repeatable observation, an explanation, and a checked correction. Live values show what happened, and a test case preserves the conditions that caused it.

What you will learn

• Turn a symptom from the field into a triggering condition you can reproduce on demand.

• Reproduce it with Pause, the Tags list, and Step one scan, and read the values that cause it.

• Use test cases to find faults nobody reported, and to prove a repair kept everything that worked.

Why it matters

An intermittent fault is easier to fix when you can reproduce it deliberately and show that the repair still works under nearby conditions.

The problem

A packing line counts bottles into cases of 10. The program has been running for a month, and this report came in from the line:

"After we press Reset, the count sometimes shows 1 instead of 0. It doesn't happen every time."

"Sometimes" means the fault needs a particular combination of inputs. Your first job is to find that combination, the triggering condition, so you can make the fault happen whenever you want. The simulator scans every 100 ms.

Reproduce it

With a mouse you cannot hold RESET and press BOTTLE at the same moment, which is why the line only sees the fault "sometimes". The Tags list can do it: press Pause, click RESET_PB and PART_EYE to TRUE, and press Step one scan. COUNT reads 1. Set both back to FALSE and step again: it stays 1.

Find and fix it

The repair embed runs in Debug mode. Its checks are test cases: each sets up inputs over time and states what the outputs must be. Press Run checks before you change anything. One failing check is the reported fault. The other is a fault nobody reported yet, so read its condition, reproduce it, and fix both. A hidden check makes sure a bottle standing at the eye through Reset still counts only once. Editing pauses the program, so press Run to try your version.

Passing the checks records Structured Text progress on debugging with test cases.

What happened and why

The two defects needed different conditions, and only test cases found both:

The first was reported because operators saw it. The second hides on a real line: the case moves on at 10 bottles, so COUNT rarely reaches 11 and FULL rarely lights at all. A test case that walks the count through 9, 10, and 11 finds it in under a second.

That is the method:

1. Reproduce the symptom, and narrow it to a triggering condition: the inputs and the scan where it happens.

2. Watch the values in that scan: pause, set the inputs, and step one scan. Read which line wrote the wrong value.

3. Write the condition as a test case, so the fault stays fixed.

4. Fix the cause, then run every check. A repair is finished only when the old behaviour still passes.

Common mistakes

• Fixing only the reported fault: the boundary defect stays, waiting for the day a case is not moved on in time. Run every check after a repair.

• Clearing the edge memory on Reset: a bottle standing at the eye then looks new on the next scan and counts again. Reset changes the count, not what the eye last saw.

• Testing = 10 instead of >= 10: FULL lights for the 10th bottle and goes out with the 11th. "At least 10" is >=.

• Changing the program before you can reproduce the fault: without the triggering condition, you cannot tell whether a change fixed it or the fault just has not happened yet.

Platform notes

• On real controllers, use the online monitor, a watch table, or trend to see live values, and forces or a test mode to set inputs. Forcing outputs or inputs on a running machine moves real equipment: follow your site's rules before you do.

• Some platforms can record values scan by scan around a trigger. Recording the scan where a condition first becomes TRUE answers "which line wrote this?" without stopping the machine.

Enable JavaScript to run the embedded simulator and complete the interactive exercises.