Trigger a trace from a CODESYS Test Manager test case

Can a test case start a trace recording?

Yes: give the trace a trigger variable the test can write, configure the trace to start on a rising edge of that variable, and toggle it from a test step placed at the behavior under test. The test run then produces a recording.

Two operations hide behind that sentence. What gets recorded is defined in the trace configuration: its variable list and its trigger settings. When it gets recorded is decided by an edge on the trigger variable, which only the test case produces. A trace full of variables with no trigger has nothing to start it. A test step writing an unconfigured variable has nothing to start. The trigger-variable route keeps both halves visible in the project. The test case reads as a normal sequence of input and output steps, and the start condition sits in the trace configuration where any engineer who opens the project can find it.

What do you need before you configure the trigger?

You need three things in place. First, a trace configuration that already contains the signals under test. Second, a Boolean in the application whose FALSE state means idle. Third, a trigger condition set to the rising edge of that Boolean, downloaded to the controller with the normal project workflow.

• The trace. It already holds the variables your test compares. If you have never configured one, the vendor's trace example data sheet describes TraceExample.project, a sample project that records and stores variable values through the trace object and the visualization trace element.
• The trigger variable. One Boolean that only the test case writes, idle at FALSE.
• The trigger condition. Rising edge on that Boolean. An edge makes the start a single event in time. A level condition instead ties recording to how long the variable sits TRUE.
• A downloaded configuration. Activate or download the project to the controller the way you send any change. A trigger configured in the editor but left undownloaded starts nothing.
• Test Manager itself. It programs and executes automated tests of applications and libraries developed with CODESYS, on 32 and 64 bit runtimes, per the vendor's release notes.
• A clean rehearsal. If you first run the trace in the simulator and it dies with an AccessViolation, clear that before wiring the test. Fix a trace AccessViolation in the CODESYS simulator covers that separate problem.

How do you connect a trigger variable to the trace?

Add the Boolean to the trace configuration. Select it as the trigger source in the trace's trigger settings. Set the condition to rising edge. Those settings live in the trace configuration editor of your installed version, and the edge is what makes FALSE the unambiguous idle state.

1. Add a Boolean to the application and name it for the job, for example TraceArm. The name is yours; nothing in the tool requires a particular one.
2. Include it in the trace configuration's variable list, next to the signals under test.
3. In the trace configuration's trigger settings, choose TraceArm as the trigger source and rising edge as the condition.
4. Download or activate the project to the controller as you would any change.
5. Prove the link by hand before the test case touches it: run the trace, set TraceArm TRUE once from the development environment, and watch recording begin. A bench test at this point separates a configuration mistake from a test-sequence mistake later.

How do you toggle the trigger from the test case?

Write the Boolean TRUE from the test step that marks the behavior itself, not from a step at test start. The trace opens on the edge, so the position of that step decides what the recording covers.

1. Set TraceArm FALSE at the start of the case and let it sit there. One full PLC scan at FALSE is the minimum an edge detector needs, because the detector compares the current scan with the previous one.
2. Run the stimulus the case already performs: set inputs, issue commands, wait for the plant to respond.
3. Set TraceArm TRUE from the step at the event. If the event is a drive reaching speed, the TRUE belongs at the step that confirms it, so the record opens where the interesting data starts.
4. Let the run finish, confirm both transitions in the controller or the test monitor, and set TraceArm FALSE before the case ends.

Hold the idle state generously. The example below shows the arithmetic and the cost is milliseconds.

What does an example run look like?

A conveyor start test traces three variables, samples every 10 ms and covers a 2 s speed ramp. One run stores 600 values from the ramp: 2 s divided by 10 ms is 200 samples, and 200 samples for each of 3 variables is 600.

The 10 ms interval, 2 s ramp, 5 ms scan, 100 ms idle hold and 1500 rpm target are example values. Set your own and redo the same arithmetic.

1. Set TraceArm FALSE and wait 100 ms. At a 5 ms scan, the variable sits low for 20 scans, twenty times the one-scan minimum, so the edge detector is armed.
2. Set TraceArm TRUE from the step that issues the drive start command. The record opens at the command, so the whole 2 s ramp falls inside it.
3. Wait 2 s, then compare the final speed against the 1500 rpm target.
4. Set TraceArm FALSE before the case ends.

Arithmetic:

• Ramp samples per variable: 2 s = 2000 ms; 2000 ms / 10 ms per sample = 200 samples.
• Values from the ramp: 200 samples x 3 variables = 600 values.
• Idle scans before the edge: 100 ms / 5 ms per scan = 20 scans, against a minimum of 1.

Result: the trace holds the full ramp from command to target speed, and TraceArm is back at FALSE, so run two arms itself.

How do you check that the trace captured data?

Check three things in order. A green test step tells you the write ran and nothing more. Confirm the Boolean changed in the controller, the trace shows your variables moving, and the captured window lines up with the stimulus.

A recorded window shorter than the run is usually a display question, and the display side has its own answer: showing full test duration on a live trend chart walks that fix.

Why does the trigger work once and then stop?

Because the edge already happened. A rising-edge trigger needs the Boolean at FALSE for at least one PLC scan before the next TRUE, and a case that ends with TraceArm still TRUE gives the detector nothing to see on run two.

Return the variable to its idle state inside the case, every time, so each run manufactures its own transition. Confirm the FALSE in the monitor, then the TRUE, then the FALSE again. Then run the case twice back to back and check both records exist. A repeat run that produces a second recording shows the re-arm works. If you configured a level condition instead of an edge, a stuck TRUE holds the trigger at its active state, and the same idle-state discipline clears it.

How do you get the trace into the test report?

Treat retrieval as a separate operation with its own step. The trigger starts acquisition. Getting the data into the report needs the export or attachment facility your installed Test Manager documents, sequenced after the record is complete and checked by opening the artifact.

Neither the trigger Boolean nor a passing result moves a file. Where the export step lives depends on the version: the installed Test Manager's documentation lists its test actions and its scripting interface, and that is where the export or report attachment step is named. Sequence it after the run, then open the report and confirm the trace artifact is present and readable. A retrieval failure then surfaces as a failed artifact check instead of a silent gap in the report. When the export carries leading columns your report template skips, the column cleanup in removing the first two columns from trend .trd exports is the pattern to copy.

When should you script the trace instead?

Script when test steps reach the limit of what they control. The trace release added a scripting driver that can create trace objects, configure them by adding variables and control when recording runs, which covers runs that need a trace created or reconfigured for each pass.

The two mechanisms sit at different layers. The scripted route builds, configures and controls the trace object itself, and it is documented in the vendor's trace release notes. The test-step toggle produces the per-run start mark inside the sequence. Combining them is ordinary practice: a script prepares the configuration between runs, the case fires the edge at the event.

Recommendation: Drive the trace with a test-writable Boolean on a rising edge whenever one test run needs one recording. FALSE before the stimulus, TRUE at the event, FALSE again before the case ends, with both transitions visible in the controller. Reach for the scripting driver when each run also needs the trace itself created or reconfigured. Add report export last, and only after a hand-run has produced a trace you have opened and read.

Questions