How to Build a Sample Automation Project in CODESYS

Adopting a new automation platform can create steep learning curves and raise concerns about vendor lock-in. CODESYS addresses these challenges with a hardware-independent development environment based on IEC 61131-3. It offers a unified workflow for programming, I/O mapping, visualization, and deployment across multiple hardware platforms.

This article demonstrates how to build a complete automation project in CODESYS, from initial setup to runtime testing. Readers will configure the device tree, map I/O channels, program logic in Structured Text, design visualizations, connect to a runtime environment, and apply debugging strategies to verify operation. Alongside practical instructions, the article highlights best practices for project organization, library management, and secure deployment.

Although the tutorial uses CODESYS’s built-in simulator for accessibility, the same workflow applies to hardware platforms available from DigiKey, such as CODESYS-enabled PLCs, industrial Raspberry Pi controllers (e.g., Seeed EdgeBox-RPI-200), and HMIs with integrated runtime. By the end, readers will have established a clear framework for building a functioning automation application in CODESYS, with insight into techniques that support scalability and reliability in industrial environments.

Project setup

The first step is to set up a new project in the CODESYS Development System. From the template list, select Standard Project and assign a descriptive name such as MotorControlDemo. When prompted for a device, choose CODESYS Control Win V3, which provides a Windows-based runtime for simulation without dedicated hardware. This allows testing the full workflow before deploying to platforms such as PLCs or industrial Raspberry Pi modules.

The project opens with a device tree, which organizes controllers, I/O channels, and communication links. For this example, the tree contains a controller object, digital inputs for start and stop buttons, and digital outputs for a motor and indicator lamp. To connect these signals to control logic, declare Boolean variables such as StartButton, StopButton, MotorOn, and LampOn in the global variable list or program editor. In simulation, toggling these values mimics hardware behavior. On hardware, they bind directly to physical I/O points.

Figure 1: Boolean variable declarations for motor control I/O. (Image Source: Author)

Clear, consistent naming at this stage is a best practice that minimizes debugging effort and simplifies scaling when new functions or devices are added.

Programming logic

With the project structure in place, the next step is implementing control logic in Structured Text (ST), one of the IEC 61131-3 languages supported by CODESYS. ST uses a Pascal-like syntax that combines readability with expressive power, supporting clear implementation of sequential routines and state-based logic.

The demonstration project requires a simple start/stop latch: pressing the start button energizes the motor and lamp, while pressing the stop button de-energizes both. This is expressed in ST as shown in Figure 2.

Figure 2: Structured Text implementation of start/stop latch logic. (Image Source: Author)

This example illustrates the fundamentals of ST, including conditional statements, Boolean logic, and variable assignment. Because the variables were defined during project setup, they map directly to I/O channels, bridging hardware signals and program execution.

For larger projects, organization is key. Initialization code can set default states, while cyclic tasks monitor inputs and drive outputs. Function blocks and libraries help encapsulate logic, reduce redundancy, and improve readability. The same ST code developed in simulation can later be deployed to DigiKey-available hardware, such as compact PLCs or PACs, with only minor modification. This portability reinforces the value of CODESYS as a hardware-independent environment. Notably, separating initialization, cyclic monitoring, and error handling is a best practice that improves readability and ensures predictable execution as projects expand.

Configuring devices and I/O mapping

With the project structure and variables in place, the next step is linking the variables to hardware—or simulated I/O—through I/O mapping. In CODESYS, this is handled in the Device Editor’s I/O Mapping tab, where each channel is paired with a project variable.

Start by inserting a controller and its I/O modules under the device tree. For example, a module can be added with two digital inputs and two digital outputs. Once a device with I/O capability is present, the I/O Mapping tab activates, displaying a table of input and output channels with columns for variable names, addresses, and data types. While device descriptions typically supply default names and addresses, these can be modified to match the system wiring or naming conventions.

On the I/O Mapping tab, variables can be mapped to channels in three ways: link an existing variable (e.g., StartButton, MotorOn), generate a new implicit global variable within the interface, or edit addresses directly to match project requirements. Variables mapped to inputs are read-only by definition, and each variable can be mapped to only one channel.

In production environments, mapping also requires attention to electrical interface specifications, including signal levels, module ratings, and grounding. These factors are beyond the scope of this tutorial, but remain critical for hardware deployment.

For documentation or bulk editing, mappings can be exported or imported as CSV files. Exporting mapping data to CSV is a best practice, as it provides documentation for audits and a reliable reference for team collaboration.

Visualization and HMI

With logic in place, the next step is to create a user interface that controls and monitors the system. CODESYS offers an integrated Visualization toolset, which supports multiple deployment modes—WebVisu, TargetVisu, and CODESYS HMI—allowing visualization to run on web browsers, local displays, or dedicated devices.

In the device tree, under the Application node, add a Visualization Manager object, then add one or more Visualization screens such as MainVisu. On each screen, drag UI elements such as buttons, lamps/indicators, trace displays, or trend graphs. These elements are tied to program variables (e.g., StartButton, LampOn) via the element’s property dialog.

For example, to display motor status, place a lamp element and set its variable link to LampOn. When the variable is TRUE, the lamp lights; when FALSE, it stays off. This direct binding between variables and elements enables intuitive runtime interaction.

Deployment mode options

Once the interface is designed, the next step is to decide how the visualization will be deployed to operators or external systems. CODESYS supports several deployment modes, each targeted at different performance and network requirements:

• WebVisu: Runs as HTML5 in a web browser, with the device acting as a web server over HTTP/HTTPS. It enables remote access without a dedicated display.
• TargetVisu: Runs on a display directly attached to the controller or device. Efficient for embedded systems that combine control and HMI in one unit.
• CODESYS HMI: A separate runtime instance dedicated to visualization, capable of connecting to multiple controllers.

When choosing a deployment mode, consider performance, display needs, and network topology. Although WebVisu is flexible, controllers might need to support the HTTP server and additional loads. TargetVisu reduces network latency, yet requires local display support, while HMI mode scales for multi-controller systems.

Real-world hardware example

As a hardware reference, the Maple Systems cMT3072XHT 7" HMI available on DigiKey features an integrated CODESYS runtime and display, allowing it to host the visualization screens created in the project directly.

Best practices for visualization design include using library screens and parameter interfaces to build reusable templates. The designer should also configure alarm and trace displays to display only critical variables, minimizing controller load. This allows for support of multi-language and unit conversions with text lists and variable scaling. Additionally, lock element positions with snaplines or containers to maintain consistent layouts across screen sizes.

With the visualization connected, the application is now fully interactive. The user can start and stop the motor, monitor indicators, and view live statuses through the HMI. This completes the visualization stage and prepares the project for runtime testing.

Deployment and runtime testing

Once programming and visualization are complete, the project must be deployed to a runtime environment. CODESYS supports several options, from the built-in Control Win SL simulator to licensed runtimes on industrial hardware.

From the Online menu in the Development System, select the target device or simulator and establish a connection. Download the compiled project to the runtime, with the IDE displaying transfer status and highlighting any configuration mismatches. After loading, switch the controller into RUN mode to begin execution.

The built-in Windows runtime enables quick verification without hardware, while CODESYS runtimes also execute on embedded Linux platforms such as the KUNBUS Revolution Pi (RevPi) Connect 4, available from DigiKey. This open-source industrial Raspberry Pi module demonstrates how the same project can scale seamlessly from simulation to field deployment.

Debugging and best practices

Beyond live monitoring, CODESYS provides an integrated debugging environment to refine and maintain projects. Breakpoints, single-step through logic, and analysis of execution flows can be manually set and performed. The Trace tool extends diagnostics by recording variable histories for later analysis, often used in post-event reviews.

For troubleshooting, CODESYS can generate force variables (Figure 3) that temporarily override mapped signals.

Figure 3: Force variable naming convention syntax in CODESYS. (Image Source: Author)

These are especially useful for commissioning or simulating conditions such as button presses. When a force signal is active, CODESYS substitutes the forced value for the mapped signal. Because forcing can disrupt real-time execution, it should be applied with caution and only on channels already mapped.

Long-term reliability depends on structured project management. The Library Manager supports modular design and centralized version control, while defined placeholders ensure consistent builds across hardware targets. Maintaining stable library versions reduces compatibility risks when deploying or upgrading.

Alongside these structural safeguards, day-to-day best practices are equally important. These include validating projects in the simulator before moving to hardware and using breakpoints or forcing carefully in production to avoid disrupting real-time cycles. It is also good practice to archive known-good builds and library sets for quick rollback, while documenting variable mappings and providing visualization links to support a smooth team handover.

Conclusion

CODESYS accelerates design-to-deployment by unifying project setup, I/O mapping, logic programming, visualization, and debugging in one environment. The workflow extends across DigiKey platforms, including CODESYS-enabled PLCs, industrial Raspberry Pi controllers, and HMIs, providing a practical framework for transitioning from concept to scalable automation.