Set the VISU_SUPPRESS_VERSION_CHECK compiler define in CODESYS

Where do you enter the VISU_SUPPRESS_VERSION_CHECK compiler define?

Right-click the Application object in the device tree, choose Properties, open the Build tab, and type VISU_SUPPRESS_VERSION_CHECK into the compiler defines field, separated from any existing defines by a comma.

What you need:

• the symbol as the error prints it: VISU_SUPPRESS_VERSION_CHECK
• the Application object that pulls the visualization libraries; a project can hold more than one
• the defines already sitting in the field, so you add to them

Steps:

1. Right-click the Application object in the device tree and choose Properties.
2. Open the Build tab.
3. Click into the compiler defines field and type VISU_SUPPRESS_VERSION_CHECK. Keep every define already in the field and put a comma between it and the new symbol.
4. Confirm with OK.
5. Build the application. If the error line survives a clean compile, go to the last section of this page.

The define is stored per Application object. Two applications that both pull the visualization libraries need two entries, and a define placed on the device or inside a library's properties never reaches the application's compile. For the other symbols and checks that field can carry, the page on configuring CODESYS compiler defines and pragma checks goes deeper.

Why does CODESYS report different versions of VisuElemBase?

Visu_BasicChecks is a compile-time check that compares the version of the VisuElemBase library resolved through every reference path in the project, and your build mixes the 3.5.17.0 copy delivered with the installation with at least one different build.

The tag 3.5.17.0 (system) identifies the VisuElemBase copy delivered with the installation after the move to SP17. Different versions means at least one other reference path in the project resolves a different build. Two situations produce that. A project carried up from SP16 can still hold a library reference pinned to an explicit older version. Or a third-party library was compiled against an older visualization base and pulls its own nested copy. The check runs because visualization elements share data structures and call interfaces across these libraries, and the message's own wording gives the consequence: this may lead to a wrong behaviour of the application.

This error is about versions inside the project's library set. A mismatch between the project's device description and the runtime on the controller is a separate fault, and fixing a PLC runtime device mismatch safely is the article for that one.

How do you find the library that pulls in the second copy?

Open the Library Manager of the application, list every visualization entry with its resolved version, then expand each non-system library and look for a nested VisuElemBase reference pinned to an older build than 3.5.17.0.

1. Read the complete error text in the Messages window, not just the first line, and note the version and the (system) tag.
2. In the Library Manager of the application, list every visualization entry, every name starting with Visu, with the version each one resolves to.
3. If all entries resolve to 3.5.17.0, the second copy arrives as a dependency. Expand each non-system library, vendor libraries first, and look for a nested VisuElemBase reference.
4. A nested reference to an older build means that library was compiled against the older base. Ask the vendor for a build released for your service pack level; if one exists, update the reference and rebuild, and the error clears with no define.
5. If the entries you manage directly show mixed versions, switch the old reference to the current version and rebuild.
6. If you find no nested reference and no mixed entry, look at visualization objects carried over from earlier service packs, update them, and read the message again.

When should you suppress the check instead of aligning the libraries?

Add the define only when the mismatched versions cannot be aligned, for example when a third-party library was compiled against an older visualization base and the vendor publishes no build for your service pack, and only with every visualization screen verified on the target afterwards. Budget about 3 minutes per screen for that verification on the machine, so a project with 6 screens needs an 18-minute window before production restarts.

The branch depends on what the application does with its visualizations. An application that runs visualizations on the target has verification as part of the job: a hidden mismatch can put wrong values on a screen, and an operator acting on wrong values is the hazard that matters, so exercise every screen before the machine returns to production. An application that never shows a visualization should lose them first. Remove the Visualization Manager, the visualization objects and their library references, and the check has nothing left to compare, so no define is needed. Where the status belongs on a separate board in the plant, the guide on andon boards covers where a small screen earns its place, and the displays category lists the mounting styles built for that job.

Recommendation: trace the second VisuElemBase copy in the Library Manager and align versions wherever a current vendor build exists. Add VISU_SUPPRESS_VERSION_CHECK only to an Application whose mismatch cannot be aligned, set it once per Application object, and open every visualization screen on the target before the machine runs product again.

Worked example: what happens on a project upgraded from SP16 to SP17?

A controls project carries two Application objects and moves from V3.5 SP16 to SP17, so the steps below show the error count, the define entries and the build result at each stage with real numbers.

Take a machine project with 2 Application objects, both carrying visualizations, upgraded from V3.5 SP16 to SP17 with all libraries updated.

1. Build 1 returns 1 error, the Visu_BasicChecks line naming 3.5.17.0 (system). The compile takes about 2 minutes on a mid-size project.
2. The Library Manager lists 4 visualization entries and each resolves to 3.5.17.0. The old copy is not visible at the top level, so the next stop is the dependencies.
3. Expanding the libraries finds 1 nested VisuElemBase reference inside a third-party building-automation library, pinned to the SP16-era build. The vendor publishes no build for SP17, so the versions cannot be aligned from the project.
4. Decision: suppress on both applications. 2 Application objects × 1 define each = 2 entries in the Build tab.
5. Build 2 returns 0 errors and no Visu_BasicChecks line.
6. Download and exercise: 6 visualization screens opened on the target in an 18-minute window (3 minutes per screen), all rendering, all inputs responding, and no visualization entry in the runtime log.

The arithmetic that matters: 1 error before the define and 0 after, while the project still carries 2 VisuElemBase builds, before and after. The define moved a message; it moved no library.

How do you confirm the define worked?

Build the application and expect 0 errors with no Visu_BasicChecks line in the Messages window, reopen the Build tab to confirm the define is still present, and then download and open every visualization screen on the target.

1. Build and read the Messages window: 0 errors and no Visu_BasicChecks line.
2. Reopen the Build tab: VISU_SUPPRESS_VERSION_CHECK still in the field, with the previous defines intact.
3. Re-read the Library Manager: the version list matches what you recorded before the define, which tells you the define suppressed a message and changed no library resolution.
4. Download to the target and open every visualization screen: elements render, inputs respond, and no visualization exception appears in the runtime log. Any oddity sends you back to the dependency trace in the Library Manager.

Why does the error stay after you add the define?

Four causes cover nearly every case: a misspelled symbol, a define on the wrong object, a stale Messages window, or a second application without its own entry.

Misspelled symbol. The compiler reads the field as plain symbols and ignores an unrecognized one without a message, so a typo leaves the check active and the build failing. Copy VISU_SUPPRESS_VERSION_CHECK from the error text instead of retyping it.

Wrong level. A define set on the device or inside a library's properties has no effect on the application's compile. Move it to the Application object's Build tab.

Stale result. Run a clean, then build again. The Messages window can keep showing the previous compile until a fresh one replaces it; on a mid-size project give the rebuild its full 2 minutes before you judge the result.

Second application. The check runs per Application, so an application without its own entry keeps reporting. Add the define to each application that pulls the visualization libraries.

Questions