Trace in TIA Portal: how to find a phantom fault

The objective is to learn how to use the Trace tool in TIA Portal to investigate abnormal behavior in an industrial system.

The example starts from a very common plant situation: a machine stops, it does not leave a clear alarm and, when we arrive to check it, everything seems to be fine again. It is a typical case of intermittent stop diagnostics and an intermittent fault in a Siemens PLC.

This type of fault usually comes with phrases we have all heard at some point:

• “The machine fails, but when I arrive everything is fine again”.
• “I do not know whether the problem is in the sequence or in the physical signal”.
• “The state machine changes too fast and I cannot see anything online”.

This is where Trace is especially useful: it lets the PLC watch the important signals and then reconstruct what really happened.

Trace is a diagnostic function that records PLC variables during execution and displays them on a time chart.

It can work with analog signals, binary signals, DB variables, memory bits, inputs, outputs and peripheral data, depending on the device. Basically, it is a tool for recording PLC signals with time context and analyzing them afterwards as curves.

Siemens provides an official document with the complete information for the Trace editor: Trace Editor function manual.

We have a machine running normally.

Suddenly, we get a call because it has stopped and has not left any alarms. In this example we simulate it with a random fault in the PLC.

They tell us that they have reset it several times, that the machine starts running again, but after some time the fault comes back.

At this point we can start looking at the PLC, check which conditions stop the machine, follow cross-references, open watch tables and use the usual tools.

However, time goes by and we still cannot find the fault. So we decide to use Trace, watching all the signals that affect the machine's General Permission, normally built from a chain of OK conditions. If just one of them drops, the permission disappears and the machine stops.

The alarms for those permissives seem to be correctly configured and should give us the clue.

So, what is happening? How do we continue?

We use the Siemens S7-1500 Trace tool in TIA Portal to see what is causing the stop that we cannot identify in the program.

We add all the signals that we know can cause stops. The idea is not to watch one variable, but to prepare a PLC signal recording that captures the full context around the general permission.

We define how many samples we want to record and whether the sampling will be based on time or on scan cycles.

The trigger is a key part. We define when the recording should start and which signal will start it. We also configure a pretrigger in TIA Portal, meaning some time before the trigger signal, so we have more context.

Once the Trace is ready, we load the configuration into the PLC so it can run inside the controller.

We can also adjust the curve configuration: colors, groups and other visual details that make the capture easier to interpret.

We activate the Recording process. From that moment, the Trace is armed inside the PLC, waiting for the trigger condition. If we configured a pretrigger, it will also keep the context before the event so we can analyze what happened just before.

At this moment the PLC has everything prepared. We can leave TIA Portal and come back when the fault happens again, as long as the CPU is not restarted or powered off before recovering the measurement.

After some time, we know the fault has occurred. We open the Trace again, without overwriting it, and in the time diagram we see two important things:

1. The condition that starts the recording has occurred: DB_Demo_Maquina.Trace_Trigger_Parada.
2. The recording has already finished at this point.

The Trace shows that the “phantom” signal removing the general permission is DB_Demo_IO.Puerta_Cerrada.

Once the recording is complete, we can add it to Measurements. This keeps it saved for later analysis.

Now we know that the signal causing the stop is DB_Demo_IO.Puerta_Cerrada. The logical question is: if there was an alarm, why did it not appear?

Thanks to the Trace information, we know that the drop lasts only a few milliseconds and we know the exact signal. With the forensic analysis already focused, we review that alarm in detail.

The surprise is that the time configured for the permissives is the default FB value. In this case it is 5 seconds.

Logically, with such a short signal drop, there is not enough time for the alarm to appear. The condition that stops the machine is not the alarm, but the physical signal directly.

The actions are clear:

1. Align the permission logic with the diagnostic logic, so every condition capable of stopping the machine also generates a visible alarm or event.
2. Adjust the alarm detection time so it matches the real dynamics of the signal. In this didactic example, it is lowered to 0 milliseconds to detect the drop instantly.

When it happens again, we will now have a visible alarm on the HMI. Once the problem is clear, we can ask maintenance to check the sensor, the wiring or the physical cause involved.

1. Trace captures what we cannot see online: especially when the signal changes very quickly.
2. The pretrigger gives context: we do not only see the trigger, we also see what happened just before.
3. Saving the measurement avoids losing the proof: once the fault is captured, it is worth keeping it for calm analysis.
4. An alarm does not always explain the stop: if the alarm time is too high, the condition can remove the permission without becoming visible.
5. The final goal is not just to find the signal: it is to leave a diagnosis that lets maintenance act on the sensor, wiring or physical element.

• Siemens PLC and TIA Portal articles
• Secure Siemens PLC Communication with HMI and PC/PG
• PROFINET Fundamentals