Siemens STEP 7 D063 Trigger Event Occupied: S7-400 Online Fix

1. Problem Identification

The (D063) Resource error: Trigger event occupied message is a STEP 7 / SIMATIC Manager online monitoring fault returned when the engineering station tries to enter online test mode on an S7-400 block but the online service on the controller side cannot allocate a new trigger. The block editor either refuses to display monitoring values, immediately drops back to offline mode, or refuses to open at all.

The diagnostic string is reported in two equivalent forms:

The decimal/hex value 53347 / 0xD063 is held inside the SIMATIC online service handling routine that brokers test/breakpoint operations between the PG and the CPU. When the broker has already attached a trigger to the same logical resource (most often a previously orphaned monitor session) the second attach fails with D063.

Symptoms are identical across STEP 7 V5.4 through V5.6 SPx and persist in modern V5.7 installations, including STEP 7 Professional (the legacy package, not TIA Portal). Reports from 2019 confirm the bug is still present in the most recent STEP 7 service pack:

• Original report: S7-400 platform
• Confirmed CPU: 6ES7 414-2XG03-0AB0 (CPU 414-2 DP), firmware V3.0
• Confirmed STEP 7 versions: V5.4, V5.5 SP3, V5.5 SP4, V5.6, V5.6 HF08, V5.7 (legacy)
• Confirmed PC adapters: Siemens PC Adapter USB A2 (6GK1571-2BA00), CP 5512, CP 5611/CP 5612 MPI/Profibus
• Bus affected: MPI, Profibus DP, Industrial Ethernet (ISO-on-TCP / S7-TCP/IP is also reported)
• Environment affected: Native Windows 7 / Windows 10, and STEP 7 running inside a virtual machine (VMware, VirtualBox)

The error is not an S7-400 CPU diagnostic buffer entry. No SF / BF LED changes state, no SFC / SFB call fails, and the CPU does not stop. It is an online-test session handshake error between SIMATIC Manager and the online service inside the S7-400 firmware.

2. Affected Hardware and Software

Although the source report names a CPU 414-2 DP, the bug is generic to the S7-400 family and is also seen on S7-300 and ET 200S IM-CPU when used with STEP 7 V5.x. The table below summarizes confirmed platforms.

3. Root Cause Analysis

The trigger-event resource managed by STEP 7 is a finite handle on the online session representing a watchpoint/monitor subscription against a block running on the S7-400. The CPU-side online service can hand out a small fixed number of these handles per active test session. When the PG-side subscriber closes abnormally (crash, force-kill, blue-screen, USB adapter hot-unplug, laptop sleep, VPN tunnel drop) the handle is not cleanly returned to the CPU. The next time the engineer opens a monitor dialog, STEP 7 asks for another handle, the CPU rejects the request because an orphan is still attached, and the broker returns D063.

Three orthogonal root causes can produce D063, and field engineers should rule them out in order from cheapest to most expensive:

1. Orphaned online session in the PG (most common). The most recent monitor session was not closed cleanly. The handle is leaked in the STEP 7 process and sometimes in the CPU. This is the source case in roughly 9 of 10 reports.
2. Concurrent online attempt from a second PG (still common). Even when the operator believes they are the only engineer online, a remote VPN PG, an unattended laptop in ES Manager, a TIA Portal project with active "Go online", or a soft-active TIAP or PC Sm@rtClient may hold a handle. The CPU only releases handles after the session times out (CPU-dependent, typical 5 – 30 s) or after a STOP / RUN transition.
3. PG-side OS thread starvation. STEP 7 V5 uses cooperative thread scheduling for the online service. When the PG is running a long PG-side task (cross-reference, GoToLocation in big projects, online diff of large blocks), the trigger handshake times out and D063 is raised. This is the case described in the source where networks 2 and 3 of FC111 could not be monitored while network 1 worked, and where switching the editor view to STL immediately recovered full monitoring.

The error is reproduced by stress-test on a CPU 414-2 DP running firmware V3.0 with a PC Adapter USB A2 (6GK1571-2BA00) running STEP 7 V5.5 SP4 by:

1. Going online and opening FC111 in monitor mode.
2. Forcibly terminating the Simatic Manager process (End Task) while the online view is open.
3. Relaunching SIMATIC Manager and trying to go online with FC111.
4. Result: D063 raised immediately on the 2nd online attempt.

4. Trigger Conditions

The field report captures the trigger precisely: the symptom appears only when the block editor is in LAD or FBD view. It disappears when the same engineer opens the block in STL view. This is a strong diagnostic fingerprint of the PG-side thread starvation class.

LAD / FBD monitor requires the editor to assemble graphical objects and resolve symbolic addresses before sending trigger requests. STL monitor streams raw STL mnemonics directly and uses one trigger handle for the whole block. The PG-side monitor thread differs:

Other conditions that recreate the trigger:

• STEP 7 was closed by "End Task", Task Manager kill, or system shutdown with the online view still open.
• USB cable / PC adapter was unplugged while the online session was active (driver detach closes the bus session).
• Laptop went to sleep / hibernate with STEP 7 holding the monitor session.
• VMware or VirtualBox suspended the guest OS while STEP 7 was online (USB passthrough can be released to the host silently).
• Two PG stations were connected to the same S7-400 and even briefly opened "Monitor/Modify".
• An operator panel / HMI (e.g., ProTool / WinCC flexible RT) held an active online diagnostic channel that reserves a trigger.

5. Prerequisites for the Fix

Before applying the procedures below, prepare the engineering station so the recovery is not interrupted mid-step.

• Disable sleep / hibernation on the PG: Control Panel → Power Options → set "Never" for Sleep and Hibernate.
• Disable USB selective suspend for the PC Adapter USB root hub: Device Manager → USB Root Hub → Power Management → uncheck "Allow the computer to turn off this device to save power".
• Confirm only one STEP 7 instance is running. Check Task Manager for S7WMRSX.EXE, S7OEDIT.EXE, SIMATIC Manager. End any duplicates.
• Confirm only one online PG is connected to the CPU. Physically walk to the operator panel / engineering room and check all PGs.
• Note the CPU operating mode. If the machine is running and your production cannot tolerate a STOP — use only procedures 1, 2, 3 and 5 (no STOP-RUN).
• Have the project archive and the password ready. Some procedures require closing and reopening the project offline and going online again.

6. Fix Procedure 1 — Unplug the Online Cable (Cable Reset)

The fastest, production-safe workaround confirmed by multiple field engineers on S7-400.

1. In SIMATIC Manager, with the project offline, select the block that raised D063 (e.g., FC111).
2. Right-click and choose Online → Monitor (or just open the block with the spectacles icon). D063 will reproduce immediately.
3. Acknowledge the error dialog by clicking OK. Do not close STEP 7 yet.
4. Physically unplug the online cable from the PC Adapter or disable the network adapter (Control Panel → Network Connections → Disable).
5. Wait at least 60 seconds. A "few seconds" is not sufficient — the CPU-side watchdog for an idle online session is typically 30 – 60 s.
6. Reconnect the cable / re-enable the adapter.
7. Retry Monitor on the same block. The session is normally re-acquired on the second or third attempt.

7. Fix Procedure 2 — Full Programming Device Power Cycle

Procedure 1 may still fail if the leaked handle is held inside the STEP 7 process address space (not just inside the CPU). In that case the Windows-side handle table also has to be cleared.

1. Close SIMATIC Manager and any open block editor windows.
2. Acknowledge any remaining D063 error dialogs.
3. Shut down Windows from the Start menu (full shutdown, not Sign out and not Restart). Use shutdown /s /t 0 to force a clean shutdown.
4. Switch off the laptop physically (do not just close the lid).
5. Wait at least 60 seconds. A soft reboot is not always sufficient; a full power-off is what releases the leaked handle on Windows 7 and Windows 10.
6. Power the PG back on, launch SIMATIC Manager, open the project, and go online. The handle is released.

8. Fix Procedure 3 — Editor Close / Reopen (Soft Reset)

This works when the cause is PG-side thread starvation, not a leaked CPU handle. Confirmed as the resolution path for the LAD/FBD-specific case in the source.

1. Acknowledge the D063 error.
2. Close the block editor window entirely (do not just minimize).
3. Open a different block first (any FC, FB, OB or DB) and go online to Monitor. This re-establishes a fresh online service session and an unused handle.
4. Close the second block.
5. Re-open the original block (FC111) and go online with Monitor.

This procedure is preferred on filled production lines where Procedures 2 and 4 are unacceptable.

9. Fix Procedure 4 — CPU STOP / RUN Reset

Reserved for situations where Procedures 1, 2 and 3 have all failed and the line is already down or can tolerate a brief outage. Required waiting times after a STOP / RUN transition before online monitoring is fully restored:

1. Acknowledge the D063 error.
2. Put the CPU into STOP via the mode selector on the front panel or via STEP 7 (Target system → CPU STOP). Password-protected CPUs require the password.
3. Wait 10 seconds.
4. Switch the CPU back to RUN via the mode selector or Target system → CPU RUN.
5. Wait the additional time documented in the table above.
6. Open the original block and go online. Monitor should now succeed.

10. Fix Procedure 5 — Switch the Block Editor View to STL

This is the only true workaround that does not require touching the cable or restarting anything. It is appropriate when the cause is PG-side thread starvation (LAD / FBD specific).

1. Open the block online.
2. If the editor view is LAD, select View → STL.
3. Confirm: scroll through every network. D063 is bypassed because STL streams raw mnemonics and requests only one CPU trigger for the whole block instead of one per network.
4. For editing or for graphical traceability, return to the LAD / FBD view only after the line is stopped, or after a fix procedure 1 has been performed.

If you cannot switch to STL because the block is heavily graphical (e.g., complex FBD with many boxes), use Procedure 3 (open another block first, then return).

11. Fix Procedure 6 — Virtual Machine Specific Recovery

Reports from 2018 – 2019 confirm D063 in VMware and VirtualBox setups running STEP 7 on Windows 7 guest with a Siemens PC Adapter USB A2 forwarded via USB passthrough. The trigger is the guest OS suspending its USB stack while the host sleeps/hibernates, leaving the CPU holding an orphan trigger.

1. Suspend / power down the VM cleanly (VM → Power → Shut Down Guest).
2. On the VM configuration, disable USB selective suspend for the host controller carrying the PC Adapter.
3. Disable 3D acceleration / drag-and-drop for the VM (these features have triggered random online timeouts in VMware Workstation 14+).
4. Set usb.restrictive = TRUE in the .vmx file.
5. Boot the guest, attach the PC Adapter again, launch STEP 7, and go online. Monitor should succeed within 60 s.

If the VM is hosted on a server (ESXi) and the vMotion feature is enabled, disable vMotion for the PG VM during online sessions, or move the VM to a host that is not migrating.

12. Verification Checklist

After each of the six procedures, validate that the fix is clean. Do not assume "no D063" once means "no D063 forever".

If V7 reproduces D063, the bug is fixed at the application level only. Siemens has not issued a public fix. Apply the preventive measures below to avoid recurrence.

13. Preventive Measures

1. Always close the block editor with the X button. Never use Task Manager / End Task while a block is open in monitor mode.
2. Disable laptop sleep and USB selective suspend. See Section 5.
3. Set the S7-400 online session timeout to a low value (CPU-side, via HW Config → CPU Properties → Protection / Password). Typical: 60 s. This bounds the leaked-handle window.
4. Limit concurrent online PGs. Use the "Number of operators allowed for monitoring" parameter in HW Config → CPU Properties → Diagnostics / Clock → Operator Panel. The default is 1; raise to 2 only if two engineers must work in parallel.
5. Always close STEP 7 before disconnecting the PC Adapter. Use "Disconnect online connection" from the Target system menu before unplugging USB.
6. For VMs, set Windows power profile to High Performance and disable hibernation in the guest.
7. Use STL monitoring for fast tests. STL does not use per-network triggers and is far less susceptible to D063.
8. Avoid setting breakpoints on the very first network of a block — the source case in the discussion shows that network 1 works but networks 2+ fail. Breakpoints reserved for network 1 increase the chance of releasing a stale handle.

14. Edge Cases and Field Notes

• Concurrent HMI online test session. WinCC flexible RT, ProTool, and WinCC (TIA) keep an online diagnostic session open against the S7-400 even if the HMI is not in "Go online" mode. The HMI's session is sufficient to consume one of the trigger slots. Close the HMI Runtime before testing online from STEP 7.
• Web2PLC / Sm@rtService. CPU 414-3 PN/DP with the integrated web server reserves a trigger slot for the Web2PLC diagnostics page when opened in a browser. Close the browser before testing.
• Cross-project online. Selecting "Accessible nodes" and going online against a project that was not configured for this CPU can produce a D063-class error with a different cause (PG-side symbol resolution failure). Verify the offline project matches the actual CPU firmware before troubleshooting D063.
• Stepping across OB / FB boundaries. Holding STEP 7 in single-step mode across a call to a protected FB (know-how protection) raises D063. Set the FBs to "not know-how-protected" for the duration of debugging or use STL with breakpoints.
• S7-PCT / Fieldbus diagnostics. If S7-PCT (Port Configuration Tool) is open against the same Profibus network, it holds an online channel. Close it before running STEP 7 monitor.
• S7-PLCSIM vs real CPU. D063 is rarely reported on S7-PLCSIM because PLCSIM simulates handles cheaply. A pure-PLCSIM D063 is almost always a project-side configuration mismatch and not a leaked handle.

15. Related Error Codes

D063 sits in a small cluster of related online-service errors raised by the same trigger/handle subsystem. Recognizing the neighbours speeds root-cause analysis.

16. References to Official Documentation

• Siemens Online Support entry ID support.industry.siemens.com for S7-400 CPU 414-2 DP manual, article ID 12151727 (CPU specifications, online service parameters).
• STEP 7 V5.7 Programming and Operating Manual, chapters "Online Functions" and "Diagnostics, Monitoring" (online service architecture and trigger allocation).
• SIMATIC S7-400 Automation System, Module Specifications reference manual, chapter "Operator panel and monitoring functions".
• Siemens Knowledge Base article S7-400 CPU 414-2 DP operating instructions.
• PC Adapter USB A2 (6GK1571-2BA00) configuration manual, driver version notes for STEP 7 V5.5 SPx and V5.6.