The project rebuild produces 502 library-related errors after the application target is changed from an embedded display/PLC to CODESYS Control Win V3 x64. Leave the original device configuration intact and use simulation mode for office testing. Retargeting creates a different runtime environment and turns a logic-test job into a library, compiler, and licensing migration.
Skip the quick fixes that change the project
Do not begin by deleting every library and adding replacements. That can alter dependency resolution, visualization behavior, and the application ultimately returned to the machine. The same warning applies to repeatedly rebuilding or selecting newer library versions: neither action supplies a missing system component or makes an incompatible compiler identity valid.
Installing licenses at random is another poor first move. A message that says a system library was not added or that no valid license was found describes two possible conditions. Determine which runtime the project now targets before buying, activating, or transferring anything.
Keep the working machine project as the reference. If experimentation requires dependency changes, use a separate copy and record every change. Get the test running first; investigate a permanent desktop-runtime port only if that port is an actual project requirement.
Check whether the target changed
| Reading or observation | Meaning | Next check |
|---|---|---|
| The project still targets the embedded display/PLC | The original device profile and its library expectations remain selected. | Enable simulation and compile without replacing the device. |
The target now reads CODESYS Control Win V3 x64
|
The compiler must resolve dependencies against the Windows runtime rather than the embedded target. | Read the first compiler-version and system-library diagnostics. |
| The target identity is unclear | Further library work may be applied to the wrong branch. | Open the device configuration and compare it with the untouched project. |
The application source may be unchanged while the build environment is not. A target selection controls which runtime components, system libraries, compiler compatibility rules, and licenses apply. Copying the project does not copy the embedded runtime into the development computer.
Read the first dependency errors
Sort the messages by their function instead of treating all 502 errors as separate logic defects.
| Diagnostic | What it identifies | Action |
|---|---|---|
element collections 3.5.17.0 was created with unknown compiler version 3.5.15.20
|
The installed engineering environment cannot identify or accept the compiler identity stored with that library. | Stop replacing unrelated libraries. Either return to the original target and simulate, or align the engineering installation and dependency set for a deliberate port. |
CmpVisuHandler 3.5.16.0 (System) was not added, or no valid license was found |
The selected runtime does not currently provide or authorize the visualization system dependency expected by the project. | Use simulation for the immediate visualization test. For a Windows deployment, inspect the installed runtime components and licensing through official product support. |
SysProcess 3.5.16.0 (System) was not added, or no valid license was found |
A process-related system interface expected by the project is unavailable to the selected target configuration. | Do not substitute an arbitrary general-purpose library; decide whether the test actually needs this runtime function. |
SysShm 3.5.16.0 (System) was not added, or no valid license was found |
A shared-memory system interface is missing or unlicensed for the selected runtime. | Keep hardware- or runtime-dependent paths outside the office test, or build a supported Windows target deliberately. |
Start with the first dependency failure because later messages can be consequences of it. A missing visualization handler can generate many secondary errors in visualization objects, while an unrecognized compiler version can prevent a library from exposing the types required by dependent libraries.
Choose simulation or a Windows port
Use the purpose of the test as the branch condition.
| Required result | Correct branch | Reason |
|---|---|---|
| Exercise application logic and the visualization at the office | Simulation mode in the original project | It preserves the embedded target configuration and avoids resolving the project as a Windows-runtime application. |
Run the application as a deployed CODESYS Control Win V3 x64 system |
Perform a controlled port | The Windows runtime needs compatible libraries, supported system interfaces, and any required licenses. |
| Validate physical I/O, communications, or device-specific services | Use the actual target or a representative test system | Simulation cannot prove wiring, fieldbus timing, drivers, licenses, or target-specific operating-system functions. |
The successful resolving branch here is simulation: after simulation mode was enabled, the visualization operated correctly. That result also localizes the original office-build failure to the retargeted environment rather than proving a defect in the visualization logic.
Run the office test without retargeting
- Open an untouched copy of the project that still contains the embedded display/PLC device configuration.
- Confirm that
CODESYS Control Win V3 x64has not replaced the original target. - Enable simulation mode using the simulation command provided by the installed CODESYS engineering environment.
- Build the project. If the compiler still reports the same system-library messages, recheck the selected device and confirm that the build is using the original application rather than the retargeted copy.
- Start the simulated application and open
VISU. - Exercise the suspect sequence with controlled input values. Observe state transitions, interlocks, commands, and visualization feedback.
- Record any values that must be forced or substituted because no physical device is connected. Remove those test provisions before returning the project to production use.
Stop here if testing requires a real process, safety function, motion device, fieldbus node, or target-only system service. Simulation is a software diagnostic tool, not acceptance testing for the installed machine.
Verify the fix and protect the production copy
Pass the office test only when the project builds in simulation, VISU opens, operator actions update the intended application states, and the suspected behavior can be reproduced or cleared without unresolved dependency errors. Test both the command path and its permissives; a screen animation alone does not prove that the control logic reached the required state.
Before transferring anything back to the machine, disable simulation and compare the test copy with the retained production project. Confirm that the original target remains selected and that no library references, forced values, bypasses, or desktop-specific changes remain. Rebuild for the embedded target and review the complete diagnostic list.
If the requirement changes from office simulation to permanent Windows execution, treat that work as a port. Inventory each system library, identify which runtime supplies it, check compiler compatibility for 3.5.15.20, and verify licensing for the selected runtime through official documentation or support.
FAQ
Why does the same CODESYS project fail after changing the PLC target?
The source may be identical, but the target change selects a different runtime environment. CODESYS Control Win V3 x64 must resolve its own compatible system libraries, compiler identities, and licenses.
Why does CODESYS say a system library is missing or unlicensed?
The message combines two branches: the selected runtime did not add the component, or the component lacks a valid license. Check the active target first, then inspect the runtime installation and licensing instead of replacing application libraries blindly.
Can I test a CODESYS visualization without the machine?
Yes. Keep the embedded target in the project, enable simulation mode, start the simulated application, and open VISU. Use the real target for final I/O, communications, safety, motion, and target-service validation.
Stop and escalate to official support when the original target also rejects its established libraries, simulation cannot start after the target is restored, or a permanent Windows port requires unresolved system components or licenses. Provide the target identity, complete diagnostic text, installed engineering/runtime versions, and the library names and versions shown above.