Configuring CODESYS TargetVisu for On-Demand Startup

Tom Garrett5 min read
HMI ProgrammingOther ManufacturerTechnical Reference
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

TargetVisu appears when the PLC starts, although the operator interface is needed only later. The controlling quantity is time: the visualization process is launched during application startup rather than in response to an operator request. No current or thermal calculation decides this behavior; the relevant limit is one unwanted visible client at startup.

Startup Timing and Process State

TargetVisu is a visualization client tied to the PLC application. When its startup path is active, starting the PLC application also opens the visualization window. Hiding a page inside the visualization does not prevent the client process from starting, so page logic cannot solve a process-lifecycle problem.

The number that matters is the count of visible visualization clients before an operator requests one. The required initial state is zero; the observed state is one TargetVisu window. The correction must therefore control the client launch or replace the client architecture.

Quantity or state Required condition Where to read it
TargetVisu windows at PLC startup Zero for true on-demand operation Operating-system desktop or process view
PLC application state Running without forcing a visible client PLC runtime or engineering-system status
Visualization client type TargetVisu, Remote TargetVisu, or WebVisu Application tree and visualization configuration
Web client endpoint Reachable when requested Browser at http://localhost:8080

Platform and Client Comparison

The available control path depends on both the operating system and the visualization client. Windows provides a documented instruction for executing TargetVisu after its window has been closed. The Linux implementation described here has no equivalent method for suppressing native TargetVisu at startup and reopening it later.

Approach Platform Startup behavior On-demand action Primary limitation
Local TargetVisu Windows Window first appears and can then be closed Run the documented Execute TargetVisu instruction Does not provide a clean zero-window startup because the initial window appears
Remote TargetVisu Windows Client launch can be separated from PLC startup Start the remote client when needed Requires a remote-client deployment instead of the local client path
WebVisu Linux or Windows No native TargetVisu window is required Open the configured visualization URL in a browser Depends on WebVisu configuration, browser availability, and endpoint reachability

Recommended Architecture

Use WebVisu when the requirement is strict: the PLC must start with no visualization window, and an operator must be able to open the interface later. This is the direct workaround for Linux because native TargetVisu cannot be deferred and relaunched by the method available on Windows.

On Windows, choose between two different requirements. If a brief initial appearance is acceptable, retain local TargetVisu, close it after startup, and execute it later with the documented instruction. If no local window may appear at all, use Remote TargetVisu or WebVisu so client startup is independent of PLC startup.

Linux support for a TargetVisu product and support for on-demand native-window control are separate capabilities. A product may run on Linux without exposing the same close-and-reopen workflow available on Windows. Base the design on the required lifecycle behavior, not on the operating-system name in a product listing.

Windows On-Demand Procedure

  1. Keep TargetVisu configured in the application and start the PLC application normally.
  2. Observe that the TargetVisu window appears. Close that window directly after startup.
  3. Configure the later operator or application action to call the documented Execute TargetVisu instruction. Use the instruction definition from the installed CODESYS documentation because the evidence does not supply its call syntax or arguments.
  4. Trigger the action and confirm that a new TargetVisu window opens while the PLC application remains running.
  5. Repeat the close-and-open sequence to check that the action controls the client rather than restarting the PLC application.

This procedure controls reopening, but it does not eliminate the first visible window. Where that initial appearance violates the requirement, move to Remote TargetVisu or WebVisu.

Linux WebVisu Procedure

  1. Remove TargetVisu from the application tree so the native visualization client is no longer part of the startup path.
  2. Configure WebVisu for the application and download the revised application to the controller.
  3. Restart the PLC application and confirm that no TargetVisu window appears.
  4. When the interface is required on the same Linux system, open a browser and request http://localhost:8080.
  5. If the browser itself should present the operator interface without normal browser controls, start it in its full-screen kiosk mode.

localhost points back to the machine running the browser. This address is suitable only when that machine can reach the WebVisu service through its own loopback interface. For a browser on another device, read the controller or host network configuration and use the reachable address assigned to that system; the evidence provides no installation-specific remote address.

Verification and Recurring Pitfalls

  1. Cold-start or restart the PLC application and watch the complete startup sequence. Confirm that the selected client behavior matches the requirement: no client for WebVisu or Remote TargetVisu, or a closable initial window for local Windows TargetVisu.
  2. Verify that PLC control continues after the visualization client closes. Closing a client must not be confused with stopping the PLC application.
  3. Launch the interface using the chosen on-demand path and test navigation, displayed values, and operator commands.
  4. Close the client, launch it again, and repeat the functional test. This detects a one-time launch path that fails after the first session.

A common configuration error is leaving TargetVisu in the application tree while also adding WebVisu. That can preserve the unwanted native startup window. Another is treating browser kiosk mode as the launch-control mechanism: kiosk mode changes browser presentation, while removing TargetVisu and opening WebVisu on demand changes the client lifecycle.

If http://localhost:8080 fails, separate service configuration from network diagnosis. Check that WebVisu is present in the downloaded application, confirm the PLC application is running, and verify that the browser is on the intended host. Then read the active listener and network settings rather than substituting an unverified port or address.

FAQ

What happens if TargetVisu stays in the Linux application tree?

The native client remains associated with application startup, so its window can still appear when the PLC starts. Remove TargetVisu and use WebVisu when the required initial client count is zero.

What happens if I close TargetVisu on Windows?

The PLC application can continue running, and TargetVisu can be opened later with the documented Execute TargetVisu instruction. Verify this behavior by closing and reopening the client without restarting the PLC.

What happens if http://localhost:8080 does not open WebVisu?

Confirm that WebVisu is configured and downloaded, the PLC application is running, and the browser is on the host represented by localhost. Read the active service and network settings before changing the endpoint.

What happens if the required startup behavior is unavailable?

Stop when the installed operating system and CODESYS version offer neither the required client-lifecycle command nor an acceptable WebVisu or Remote TargetVisu architecture. Record the operating system, installed CODESYS and runtime versions, project client type, and observed startup sequence. Escalate those details to official CODESYS support for a version-specific capability check.

Back to blog