One of the simplest ways to make a PLC project scalable and easier to deploy across multiple sites, with different options / additions, is to create a dedicated configuration block. This is a single place in your program where all install dependent options live. Whether you are working in TIA Portal, Rockwell, Codesys or another platform, the concept is the same. The configuration block describes the physical system, the optional assets that exist on the installation and any constants that must remain protected from operators or HMIs.
Why Use a Configuration Block?
As projects grow, so does the amount of variation between installations. One site may have two pumps, another four. Some installations might include a clean water system or a buffer tank, while others ship without those features. By collecting these install specific details in one structured data block, you avoid scattering hard coded values and conditional logic throughout your program.
A configuration block becomes a central blueprint for the running system. It stores anything that defines the system’s capabilities, such as:
- Asset presence – Booleans, for example
Pump2InstalledorHeatingLoopEnabled - Quantities – Integers, for the number of pumps, tanks or skids
- Scaled parameters – Reals for volumes, lengths or travel distances
- Selectable subsystem modes
- Arrays or structures – Encapsulating configuration further
For engineers supporting multiple installations, this approach makes projects portable and predictable. When delivered to a new site, only the configuration block needs adjusting rather than diving through logic that should already be tested and stable.
Creating the Configuration Structure
Most PLC platforms allow you to create a user defined type (UDT) containing all required fields and then instantiate it inside a data block. Grouping everything into a UDT keeps the layout consistent across projects and makes your intent clear to whoever maintains the code later.
Each field in the configuration UDT serves a specific purpose. Booleans act as option toggles, integers and unsigned values define counts, and real numbers support calculations or limits. More complex systems benefit from arrays or nested structures for repeated equipment items.
Setting Start Values and Deployment Behaviour
Once the UDT exists, the next step is defining sensible start values. These become the default configuration for your standard installation. When deploying to a specific site, you adjust only the monitored or actual values in the PLC to match the hardware installed. It’s probably a good idea to have the most common use-case set up. The instance of the UDT will be able to override this with local setup.
It is important that the configuration block is read only at runtime. The PLC should never write back to it during operation. The configuration represents system design, not process conditions, so it should remain static once commissioned. Operators, HMIs and SCADA systems should not be able to alter it.
Best Practices in TIA Portal
Although the concept is platform agnostic, TIA Portal includes some specific settings worth applying:
- Enable Retain
- This ensures that configuration values remain intact after power cycles. If someone edits values online, they will persist across restarts.
- Maintain Start Values
- Keep start values aligned with the actual running values. If the PLC is ever fully redownloaded or hardware is changed, the configuration will revert to the start values.
- Disable HMI and OPC UA Accessibility
- Unticking these options removes temptation or accidental modification by anyone outside the engineering environment.
- Comment Everything Clearly
- A configuration block is only as good as its clarity. Future engineers should be able to interpret each option without guesswork.
Working With the Configuration at Runtime
Your running logic should only ever read from the configuration block. For example, you might conditionally enable a FB instance based on whether an asset is installed, or dynamically create loops that iterate only through the number of pumps the site uses. This lets the same core logic run on many different installations without having to handle multiple versions for different option configurations.
When new equipment is added later, commissioning becomes simple. Stop the PLC (if required), update the relevant configuration entries in engineering mode and the logic will immediately reflect the new capabilities once downloaded.
Using Configuration for Constants and Calculations
Some values used in engineering calculations are too sensitive to expose on an HMI but still vary between installations. Travel limits, vessel volumes, sensor offsets or stroke lengths often fall into this category. Including them in the configuration block keeps them protected while still keeping them adjustable during commissioning.
This also avoids burying constants inside function blocks, which can lead to mismatches between versions and unnecessary downloads when small adjustments are needed.
Supporting Teams and Documentation
A robust configuration block serves not only as a technical tool but also as documentation. New engineers can look in one place to understand what an installation is meant to contain. It often helps to include commissioning notes or references in comments so that installers know exactly what each value represents and how it affects the system.
When combined with good version control or change tracking, configuration blocks create predictable, maintainable projects that scale across multiple deployments without repeatedly modifying core logic.
Conclusion
A dedicated configuration block is a small addition to a PLC project that delivers huge value. It standardises how installations are defined, protects essential parameters, reduces commissioning time and keeps codebases clean. Whether your project is simple or highly modular, investing a little effort in a well structured UDT and data block makes future work significantly smoother.