TIA Portal Β· On the workbench Β· diagnostics

Make the machine explain itself

An operator investigating "Fault 12" needs to know which sensor, which step, why. ProDiag adds configured supervision to the program. Its criteria analysis shows the relevant operand states so the operator can investigate the cause of the alarm. Pair it with WinCC alarm classes to control how the message is displayed and acknowledged. In this example, create a clamp or tank fault, then inspect the message and the condition that triggered it.

πŸ”Ž supervisions🎯 criteria analysis🏷️ alarm classesβœ“ acknowledge
01 Β· Supervise, trip, explain

ProDiag + the WinCC alarm view

Two supervisions watch this cell. A reaction (action) supervision says Clamp_Closed must go TRUE within 2.0 s of the clamp command; an operand supervision says Tank_Level must stay below 95 %. Jam the clamp or overfill the tank to trigger an alarm in the WinCC view. The criteria analysis then shows the failed condition used by this simulation.

πŸ–₯️ WinCC Β· Alarm view0 incoming

Active & recent alarms

ProDiag: criteria analysis

No supervision has tripped. Jam the clamp or overfill the tank to inspect the operand state associated with the alarm.
Tank_Level: 40 %

The criteria-analysis line gives the operator more to investigate than a fault number. It shows which operand failed the configured check and when the supervision tripped in this example. Configure the supervisions on the program blocks, then assign an alarm class to define presentation and acknowledgement behaviour, such as Warning / Alarm / Fault. Supported WinCC views and the CPU web server can display the configured messages; their availability depends on the target and configuration.

02 Β· The four pieces

From operand to operator screen

πŸ”Ž Supervisions. Attach monitoring to your program: operand (a tag must hold a value), action/reaction (an effect must follow a command within a time), and interlock checks. Configure the condition in the editor so that the supervision generates its alarm when that condition fails.

🎯 Criteria analysis. When a supervision trips, inspect the recorded operand states to investigate the triggering condition. Those states can help distinguish the failed check from alarms that follow it, but they do not prove the physical root cause by themselves.

🏷️ Alarm classes. Warning, Alarm, Fault (and your own) set colour, priority, and whether the alarm must be acknowledged. Use the class to keep the presentation and acknowledgement requirements consistent wherever that alarm is shown.

πŸ–₯️ One source, many screens. CPU alarms can be displayed through supported WinCC Comfort/Unified panels, the TIA alarm view and the S7-1500 built-in web server. Check the chosen target and message configuration before relying on the same alarm information being available in each view.

For these supervisions, you move from writing each monitoring condition as a sequence of IF fault THEN set message to configuring the required checks. ProDiag generates supervision logic and associated messages from that configuration. You still need to decide which conditions warrant an alarm, what the operator should investigate and which acknowledgement behaviour is appropriate.

03 Β· Check yourself

Why criteria analysis?

A step times out because a clamp never reached its closed sensor. What does ProDiag's criteria analysis add over a plain "Step 4 timeout" message?