Thirty-five compiler errors in a blank CODESYS project are library resolution failures, not code faults: the device you added references libraries the engineering PC cannot resolve. Read the first error, align the device package version with the IDE, resolve every placeholder in the Library Manager, and rebuild until the count is zero.
A CODESYS project with no code in it has nothing in the code to fail. If the build reports 35 compiler errors the moment you add the device, the fault is in library resolution, and the fix is concrete: open the Package Manager, record the installed device package version, for example 4.0.0.0, read the IDE version from its About dialog, and install the package version built for your IDE level. Then open the project's Library Manager, resolve every placeholder, and rebuild until the error count reads 0. The whole repair is 3 steps and usually done in under 15 minutes on a blank project, because dozens of messages usually trace back to one or two root causes. Do this before you add any protocol objects, because they pull in more libraries and bury the original fault deeper.
Why a blank project reports 35 errors
The build runs entirely on the engineering PC. The chain is: IDE version, then the installed device package managed through the Package Manager, then the device description carried in the project, then the library references listed in the project's Library Manager, then the compiler. Nothing on the network to the controller is involved at this stage.
Adding a device pulls in its default library set as references or placeholders. If a library is missing from the local Library Repository, or it was built for a newer compiler version than the project accepts, every symbol that depends on it turns into an error. One unresolved library can light up dozens of messages, so the count tells you the library layer is broken, and the first error names the specific break.
What each message points to
- A library or placeholder that cannot be resolved. The library is absent from the Library Repository. Install the library itself, or install the device support package that ships it; device support packages carry device descriptions and their libraries together.
- Unknown identifier or unknown type from a library. The reference is missing, or the installed version is older and lacks the symbol. Check the version shown in the Library Manager.
- A compiler or library version the project rejects as too new. The library or the device description was built for a newer IDE. Match the IDE and the package versions.
- Errors that sit on the device object itself. The device description and the installed runtime package disagree. Fix the version match first, then rebuild.
Read only the first error
Clear the message window, rebuild, and read error 1 alone. A clean rebuild of a blank project takes under a minute, so each test is cheap. The later messages are consequences of the first until the next rebuild says otherwise. Read the message text and the object it points to, and match it to the list above: a resolution failure sends you to the Library Manager, a version complaint sends you to the Package Manager. If the error count is unchanged after a fix, the repair landed outside the build path, and the first error will show which level still refuses.
Match the IDE and the device package versions
Open the Package Manager and record the installed device package version; in the worked case below that is 4.0.0.0. Read the IDE version from its About dialog. Then open the package's release notes, which state the CODESYS version the package was built against. One single-board runtime release, 4.11.0.0, for example, notes an update to Runtime Toolkit V3.5 SP19 Patch 6, so that release pairs with an IDE at that service-pack level. An IDE several service packs older leaves the package's libraries unresolvable.
Install the package version built for your IDE, or update the IDE to the level the release notes name, then restart the IDE so the device description and libraries register; the restart takes about 1 minute. If the install stalls with a CODESYS package stuck at upcoming installation, clear that fault first, because a half-installed package leaves both the device description and its libraries in a broken state.
Resolve every placeholder in the Library Manager
Open the project's Library Manager and look for entries flagged as unresolved. For each one, install the missing library into the Library Repository from the package's files, then resolve the placeholder to an installed version. Clean and rebuild.
If the count falls but stays above zero, read the new first error and repeat; a build with two bad libraries reports the second root once the first is fixed. If errors survive a clean pass through both fixes, start a new standard project with the device selected at creation and rebuild. A blank project costs nothing to recreate.
Example: 35 errors on a blank project with one device added
The inputs, all from the build at hand: a project with no user code, 1 device added, device package 4.0.0.0 installed through the Package Manager, and a build that reports 35 compiler errors, all library-related. The whole diagnosis fits in a 10-minute window: 2 minutes to read error 1, 5 minutes to install the matching package and restart the IDE, 3 minutes to resolve the placeholder and rebuild.
The rule: a blank project owns no symbols of its own, so the error count measures unresolved library references. Error 1 names the root; errors 2 through 35 are consequences of it until the next rebuild says otherwise.
The arithmetic: treat the list as 1 first error + 34 consequences = 35 messages from 1 unresolved placeholder. Fix the placeholder named in error 1, rebuild, and compare the new count against 35. A new count of 0 means the single placeholder carried all 35 and the build is done. A count above 0 but below 35 means a second root cause has surfaced; read the new error 1 and repeat. A count still at 35 means the repair landed outside the build path, most often a library installed into the repository while the project's Library Manager still holds the unresolved reference.
The result: the blank project builds at 0 errors with no unresolved placeholder flags in the Library Manager.
The decision: 0 errors is the threshold. Add the EtherNet/IP scanner or adapter object to the device tree only at 0 errors. That object brings its own libraries, and any nonzero count hides whether the new libraries resolved or cascaded. Once it runs, the protocol uses TCP 44818 for explicit messages and UDP 2222 for implicit I/O, so both ports must pass the plant firewall.
Verify the build, then log in
Three checks close the job. Build the empty project with the device only: 0 errors, and no unresolved entries in the Library Manager. Set the communication settings, scan the network for the runtime, and log in; the runtime should be found and the download should start. Check the runtime license state before you judge protocol behavior, because an unlicensed runtime runs with restrictions that look like faults; why a CODESYS library stops after 30 minutes and how to license it covers the license state and the fix.
Recommendation: Treat the whole compiler error list in a blank project as one fault. Read error 1, install the device support package built for your IDE level and restart the IDE, resolve every placeholder in the Library Manager, and rebuild until the count reaches 0. Recreate the project only if errors survive both fixes. Match the package and IDE versions on every engineering PC you set up, and the fault stays out of the next machine.
Questions
Do network problems cause compiler errors in a blank CODESYS project?
No. The build runs on the engineering PC, so a bad cable, a switch problem or a firewall cannot produce compiler errors. The network matters once the project builds clean: the IDE must find the runtime by scan to log in, and once an EtherNet/IP application runs, it uses the fixed ports the protocol assigns, TCP 44818 for explicit messages and UDP 2222 for implicit I/O, so both must pass any firewall or managed-switch rule.
What if compiler errors remain after the versions match and every placeholder is resolved?
Recreate the project. Start a new standard project, select the device at creation, and build. A blank project holds nothing worth keeping, so this costs minutes and it is the test that separates a project fault from an installation fault. The usual cause is a project created or migrated under an older compiler version, carrying settings the current build rejects.
How do I avoid this fault on the next engineering PC?
Install the IDE first, then the device support packages, and restart the IDE after every package install so device descriptions and libraries register. Record the IDE version and each package version alongside the project archive, and check a package's release notes for its CODESYS version before installing. A project with its library versions on record rebuilds without surprises on the next machine.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.