WinCC flexible 2008 can detect PLC communication loss on an MP377 by allowing a simulated internal tag to cross an analog-alarm limit. The key distinction is execution path: communication loss suppresses the tag’s Change Value event, while the analog alarm evaluator can still activate an alarm and call the connection-lost screen.
Event-path mechanism
The term watchdog here means a value that remains below an alarm limit only while its reset action continues to execute. Configure the internal tag PulseEverySecond to rise periodically. Its Change Value event calls ComCheck, which resets the tag to zero:
' reset Pulse every second
SmartTags("PulseEverySecond") = 0During normal operation, the simulated value changes from 0 to 1, the event runs, and the script returns it to 0. When PLC communication is interrupted, the observed Change Value processing stops. The reset therefore stops, but an analog alarm configured on the same tag can still activate after the simulated value passes its limit.
This distinction also explains why displayed diagnostic tags may appear frozen after disconnecting the Profibus cable while the alarm-based action still occurs. A frozen display or an unexecuted change script does not prove that every internal runtime subsystem has stopped. Tag-event dispatch, screen updates, simulation, and alarm evaluation are separate paths.
Check 1: Required detection interval
Choose the triggering method from the maximum acceptable detection time.
| Method | Observed constraint | Decision |
|---|---|---|
| Task Scheduler | Fastest stated interval is one minute | Reject when communication loss must be reported in seconds |
| Simulated internal tag |
cycle 5 was used; the reported basis was five 200 ms periods |
Use for the alarm watchdog path |
| PLC heartbeat bit | The PLC sets the bit; an HMI script clears and tests it | Use only when a dependable periodic HMI script trigger already exists |
Check 1: compare the required response with the scheduler’s one-minute minimum. Expect the scheduler to be unsuitable for a two-second target. Proceed to the simulated-tag check. The demonstrated alarm configuration produced a nominal delay of about 10 seconds, so it does not establish a two-second implementation.
Check 2: Connected-state watchdog action
Create PulseEverySecond as an internal tag. In the Loaded event of every operational screen, call SimulateTag with cycle 5, maximum 100, and minimum 0. This placement matters: omitting the call from a screen leaves the monitoring chain dependent on the previously loaded screen’s runtime state.
Attach ComCheck to the tag’s Change Value event. The essential action is the reset shown above. Temporary diagnostic tags such as StartTime and ComCount can prove that the callback runs:
SmartTags("StartTime") = Timer
SmartTags("ComCount") = SmartTags("ComCount") + 1Check 2: run with the PLC connected and display PulseEverySecond or the diagnostic counter. Expect periodic activity, while PulseEverySecond repeatedly returns to 0 and does not reach the alarm level. If no change occurs, correct the internal-tag declaration, screen Loaded event, simulation configuration, and Change Value assignment before testing a cable failure.
Check 3: Disconnected-state branch
Interrupt the PLC connection only under an approved test condition, then observe both the script diagnostics and the alarm action.
| Reading | Meaning | Next check |
|---|---|---|
ComCount stops and no alarm activates |
The change callback stopped, but the alarm path or simulated accumulation is incomplete | Inspect the limit, alarm class, activation event, and active-screen simulation call |
ComCount stops and the alarm activates |
The two execution paths have separated as required | Test navigation to the connection-lost screen |
ComCount continues |
The tested interruption did not reproduce the target failure behavior | Read the panel communication status and confirm that PLC data exchange actually stopped |
Check 3: with the connection absent, expect the Change Value script diagnostics to stop. With a limit of 10 and the stated nominal one-second increment, expect the tag to rise beyond 10 and activate the analog alarm after about 10 seconds. Treat that delay as the result of this configuration, not as a fixed MP377 communication timeout.
Resolving configuration procedure
- Create the internal tag
PulseEverySecond. - Add
SimulateTagto theLoadedevent of every screen from which communication monitoring must remain active. - Configure the simulation with
cycle 5, maximum 100, and minimum 0. - Create the script
ComCheckand resetPulseEverySecondto 0 within it. - Assign
ComCheckto the tag’sChange Valueevent. - Configure an analog alarm for
PulseEverySecondwith limit value 10. - Assign the alarm’s
Activateevent to open the connection-lost screen. - Restore communication and verify that the reset path prevents another alarm activation.
The alarm limit and simulated increment determine the watchdog portion of the delay. They do not by themselves define total response time; runtime scheduling and event processing also contribute. Reducing the limit to claim a faster response requires an on-panel timing test because no validated two-second settings are supplied.
Verification readings and recurring pitfalls
- Check 4: normal connection. Expect periodic tag activity, repeated resets to 0, and no analog-alarm activation.
-
Check 5: screen navigation. Visit every monitored screen. Expect its
Loadedevent to start the same simulation path and the alarm to remain inactive while connected. - Check 6: physical disconnection. Remove the tested communication path under controlled conditions. Expect the change-event diagnostics to freeze, followed by alarm activation at the configured limit.
-
Check 7: alarm action. Expect the alarm’s
Activateevent to display the connection-lost screen even thoughComCheckno longer runs. - Check 8: recovery. Reconnect the PLC. Expect periodic resets to resume; test and configure the desired screen-return and alarm-clear behavior separately.
| Pitfall | Failure produced | Correction |
|---|---|---|
Using only Change Value to report the outage |
The reporting action disappears with the event path it is meant to diagnose | Use the analog alarm’s Activate event for the final action |
| Using the Task Scheduler for a seconds-level requirement | Worst-case detection extends to the stated one-minute interval | Use the simulated-tag alarm path |
| Declaring the watchdog as an external tag | The test becomes dependent on the failed PLC link and may show irregular timing | Keep PulseEverySecond internal |
| Equating a heartbeat failure with cable loss | A stopped PLC program and a failed connection produce the same result | Use separate PLC-status and communication diagnostics when the operator must distinguish them |
FAQ
Why does my WinCC flexible tag-change script stop after PLC communication fails?
The MP377 test showed that Change Value processing stopped when the Profibus connection was removed. Put the outage action on the analog alarm’s Activate event instead of relying on the suppressed callback.
Why does the simulated tag alarm work when displayed tags are frozen?
Screen updates, tag-change callbacks, and analog-alarm evaluation use different runtime paths. The displayed values and callback can stop updating while the alarm evaluator still detects that PulseEverySecond passed its limit.
Why not use the WinCC flexible 2008 Task Scheduler?
The stated fastest scheduler interval is one minute, which cannot satisfy a seconds-level loss indication. The demonstrated simulated-tag configuration used cycle 5 and a limit of 10 for about a 10-second alarm delay.
How do I perform the final PLC link-loss verification?
With normal communication, expect PulseEverySecond to reset to 0 without an alarm. Disconnect the tested link, expect the change-event diagnostics to stop and the analog alarm to open the connection-lost screen, then reconnect and confirm that periodic resets resume.