Investigate AS-Wide Connections That Cannot Be Deleted After PCS 7 Migration
Inspect the managed AS-wide partner state and NetPro IDs before attempting to remove connections that became defective after migration. Siemens documents question-marked and one-sided links when projects are moved or changed while disconnected, and warns against manually deleting system-managed NetPro connections. That mechanism is relevant to the reported twin-to-live transition, but the exact deletion failure and supported repair remain unresolved without the actual CFC version and project evidence.
Table of Contents
- Why the Migration Sequence Matters
- Inspect the Managed Connection Evidence
- Preserve Both Partners Before Recovery
- Do Not Replace the Communication Blindly
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
Why the Migration Sequence Matters
The reported project moved from PCS 7 V8.1 to V9.0 SP3, then between a twin and live system. Connections were reportedly editable after the version update and became defective after the return from the twin system. Subsequent NetPro/station-name changes were reported, but they do not establish a proven cause.
Siemens documents that moving projects out of a multiproject can leave question-marked AS-wide links and can produce one-sided connections if partners are changed while disconnected. This is a relevant documented mechanism, not proof of the particular failure. CFC V9.0 SP5, section 10.8.2.
Inspect the Managed Connection Evidence
For the documented CFC V9.0 SP5 inspection method:
- Open the chart reference data for the affected configuration.
- Select View > AS-wide interconnection.
- Inspect the listed partner information and NetPro IDs.
- Compare both ends and the available partner project with the last known working baseline.
Siemens states that system-managed S7 connections must not be manually deleted in NetPro and their IDs must not be changed. Section 10.8.2. Confirm the installed CFC component version before applying the exact command wording.
Preserve Both Partners Before Recovery
Use this project-specific investigation:
- Archive the affected multiproject and retain the version that still had working connections.
- Record the complete deletion error and the connections showing question marks.
- Map each source and destination block I/O, including renamed or moved stations.
- Compare the last working twin-system state with the live return, separating AS and PC-station changes.
- Identify whether the condition is one-sided connection state, a missing partner or another defect before selecting a correction.
- If deletion still fails, provide the evidence and project transition history to product support rather than editing generated connection data by hand.
Reorganization and full compilation were already reported as unsuccessful; repeating them without new evidence is not an established repair.
Do Not Replace the Communication Blindly
The request to delete and replace the links with send/receive communication is a redesign proposal. It does not identify a method for removing the inconsistent managed state.
Any redesign needs an explicit mapping, data types, command ownership, update requirements, failure response and migration plan. Preserve the original behavior until a supported correction or reviewed replacement is established. No send/receive API, connection deletion utility or database edit is invented here.
Verification
After an established supported recovery in a project copy, check both connection ends and compile the affected configuration. Confirm that intended partner links and warnings agree with the design.
Only under an approved deployment plan should runtime data exchange and communication-failure response be checked. Successful offline deletion or compilation alone does not demonstrate correct process communication. No recovery, compile or download was performed.
Limitations and Operational Precautions
The actual CFC version, full deletion diagnostic and confirmed project repair are absent. The reference explains a relevant managed-link mechanism and inspection procedure, but the specific removal problem remains unresolved.
Retain both project partners and a restorable baseline. Do not manually delete managed NetPro connections, change their IDs or purge project data as a shortcut. Separate project repair from any subsequent production communication redesign and download.
Engineer FAQ
Did the version upgrade itself demonstrably break the connections? The reported working checkpoint after upgrade argues for investigating the later transition separately.
Are question marks proof of one specific cause? No; inspect partner state and project history.
Is send/receive replacement an established repair? No; it is a separate redesign requiring review.