A graphic inserted from Graphics / Graphics folders / WinCC Graphics is absent in the WinCC V13 simulation, while the same TP900 project displays it after transfer to the physical panel. Simple Objects display in both environments. This symptom separates a simulator-side rendering or resource-resolution fault from a screen-layout fault.
Failure Boundary and Acceptance Criterion
The term here means that the simulator and the TP900 runtime are two separate execution targets. They consume the same project definition but do not use the same display engine, installed components, or local generated files. A correct result on the panel proves that the transferred project contains a usable graphic and that the TP900 can render it. It does not prove that the engineering workstation's simulator can resolve the same resource.
| Observation | What it proves | What remains under test |
|---|---|---|
| Simple Objects appear in simulation | The simulated screen opens and basic rendering operates | Library-graphic resource handling |
| WinCC Graphics do not appear in simulation | The fault follows the object source or rendering path | Resource generation, resolution, or simulator components |
| The graphic appears on the TP900 | The panel receives and renders the project object | The WinCC V13 workstation environment |
| WinCC V11 on another PC displays the graphic | The symptom is not universal across the tested installations | Installation, project conversion, and version-specific differences |
Check 1: Expect the identical screen to show the library graphic on the TP900 and omit it only in WinCC V13 simulation. If the physical panel also omits it, stop treating the problem as simulator-only and inspect the graphic object, visibility, layering, and transfer result.
Controlled Screen Baseline
Start with one screen containing one known-visible library graphic and one Simple Object. A controlled screen removes animation, tag state, navigation, and overlapping objects from the test. Static objects should be placed inside the visible screen area, with no tag-driven visibility or movement configured.
- Duplicate the affected screen or create a temporary diagnostic screen in the same TP900 project.
- Insert one graphic through
Graphics / Graphics folders / WinCC Graphics. - Place a Simple Object beside it as the rendering control.
- Remove animations and tag-dependent visibility from both test objects.
- Bring both objects to the foreground and verify that neither is covered by another object.
- Run the WinCC V13 simulation and open that screen directly.
If the control object appears but the library graphic does not, screen navigation, display coordinates, and general simulator startup are working. Changing repeatedly between library graphics adds little value after several graphics fail in the same controlled location; the common resource path is then the stronger discriminator.
Check 2: Expect the Simple Object to remain visible. Expect the library graphic to reproduce the failure without animation, overlap, or navigation dependencies.
Project Resource Validation
A library graphic is a referenced or generated visual resource, whereas a Simple Object is defined directly by screen-object properties. The simulator must obtain both the object definition and its visual data from the engineering workstation's generated runtime content. Stale generated content can therefore affect library graphics while leaving basic shapes intact.
- Save the project and inspect the engineering messages for missing resources, conversion notices, or compilation errors.
- Use the WinCC V13 project rebuild or complete compilation function available in the installed engineering environment, rather than relying only on an incremental simulation build.
- Close the current simulation before starting the rebuilt result so that it cannot retain an earlier runtime instance.
- Repeat the controlled-screen test without changing the graphic.
A clean build with no relevant diagnostic message removes stale project output as the immediate cause. If the graphic remains absent, preserve the test screen; it now functions as a repeatable installation test.
Check 3: Expect the project build to finish without a missing-resource or graphic-generation error. Expect the new simulation instance to use the rebuilt screen, confirmed by making one harmless visible change to the Simple Object before the build.
Simulator Path Isolation
The Field PG M4 running WinCC V13 is the failing engineering environment. Another PC running WinCC V11 does not show the symptom. That comparison narrows the search, but it changes two variables simultaneously: software version and computer installation. It cannot distinguish a V13 product behavior from a damaged or incomplete installation by itself.
- Run the controlled project on the original Field PG M4 with WinCC V13 and record whether each test object appears.
- If another WinCC V13 engineering station is accessible, run the same controlled project there without redesigning the screen.
- Compare installed WinCC components, updates, and simulator options through each workstation's software inventory or installation maintenance view.
- Compare build diagnostics. Treat the first differing error or missing component as more useful than a general version comparison.
| Result | Decision |
|---|---|
| Failure occurs only on the Field PG M4 | Correct that workstation's generated data or WinCC V13 installation |
| Failure occurs on multiple WinCC V13 stations | Escalate as a reproducible V13 simulator case with the controlled project |
| Failure follows only one project | Inspect project conversion and resource generation |
| Failure also reaches the TP900 | Return to object configuration and panel transfer diagnostics |
Check 4: Expect the same project and test screen to produce a repeatable result. A valid comparison changes only the engineering station; it does not substitute another graphic, panel type, or screen design.
Engineering-Station Correction Sequence
Apply corrections from least disruptive to most disruptive. Do not replace a valid library graphic with a Simple Object merely to hide the simulator defect; that changes the application and leaves the engineering environment unreliable for later commissioning.
- Close the simulation, save the project, and perform a complete project rebuild.
- Restart WinCC V13 and rerun the controlled screen.
- Review the installed WinCC V13 components and maintenance state on the Field PG M4. Restore missing simulator or graphics-related components through the product's supported installation-maintenance process.
- If the installation reports damaged components, repair it through that same maintenance process, then rebuild the project again.
- If a second WinCC V13 station reproduces the fault, retain the minimal project and collect the build and simulation diagnostics for Siemens support. Record that WinCC V11 on another PC and the physical TP900 display the graphic.
Do not use the V11 comparison as proof that project conversion is harmless or that V13 is defective. The decisive tests are a clean WinCC V13 installation comparison and the same controlled project.
Check 5: Expect the WinCC V13 simulator to display both test objects after the workstation correction. The TP900 result must remain unchanged.
End-to-End Commissioning Verification
Verify the correction against the actual project rather than only the diagnostic screen. This catches screen-specific visibility, layering, and navigation conditions that the controlled test intentionally removed.
- Build the complete TP900 project with the corrected WinCC V13 environment. Expect no relevant graphics or resource diagnostic.
- Start a new simulation instance and navigate to every affected screen. Expect each WinCC library graphic to appear in its intended position.
- Exercise any configured visibility, movement, or screen-change conditions. Expect graphic state to follow the associated project logic.
- Transfer the same completed build to the TP900. Expect the physical runtime and simulation to show the same static graphic content.
- Reopen the project and repeat one simulation start. Expect the correction to persist without recreating or replacing the graphic.
Check 6: Expect matching graphic presence in a fresh WinCC V13 simulation and on the TP900 after transfer.
FAQ
Can I trust the TP900 graphic if it is missing only in simulation?
The successful TP900 transfer proves that the panel can render that project resource. It does not validate the WinCC V13 simulator, so correct the workstation path before using simulation for commissioning decisions.
Does a visible Simple Object prove the simulator is working?
It proves that the screen and basic object renderer work. It does not test the resource path used by WinCC Graphics.
Can I use WinCC V11 on another PC to prove a V13 bug?
No. That test changes both the software version and the workstation. Repeat the controlled project on another WinCC V13 installation to separate version behavior from a local installation fault.
Does changing to another library graphic identify the cause?
If several library graphics fail while a Simple Object remains visible, the common simulator resource path is the useful finding. Continue with a complete rebuild and workstation comparison.
Can I close the job after the test screen works?
No. Perform the final verification on every affected production screen, start a fresh simulation, transfer the same build to the TP900, and expect matching graphic presence on both targets.