November 24, 2025 · tia-portalplc-programmingbest-practicessiemens
I once spent four hours tracking down a bug in a packaging line. The problem? MW10 was overwriting M10.3, and the symbolic name hid the conflict completely.
Alright, it was not actually me – I never used M bits from the beginning. But I have seen this happen to colleagues more than once, and it always plays out the same way: hours of frustration over something that should not have been possible in the first place.
If you are still relying on M bits (merkers) for internal logic in TIA Portal, it is worth reconsidering. They feel convenient, especially if you came from S7-300/400 environments, but in modern S7-1200/1500 systems they introduce real design, maintenance, and scalability problems. Siemens themselves recommends avoiding them in reusable applications.
Here is why, and what to use instead.
The Three Core Problems
Hidden Coupling Kills Debugging Time
This is the most dangerous issue with M bits: memory overlap.
Bits M10.0 through M10.7 physically overlap with MW10 (the word at memory address 10). If one part of your program writes to MW10 as an integer, it silently overwrites all eight individual bits. Your symbolic names look clean in the project tree, but underneath, they are stepping on each other.
The worst part is when you discover this during commissioning rather than in the office. You are staring at an HMI wondering why a bit keeps flipping, and the answer is a word write happening three function blocks away.
With DB tags, this entire class of problems disappears because the memory is type-safe. A BOOL is a BOOL. An INT is an INT. They cannot accidentally overlap.
Zero Reusability
M bits are global and absolute. Every M address is tied to a fixed location in CPU memory.
Copy a function block to another project? Now you are hunting down every M address reference and reassigning them manually. Miss one and you have a conflict that might not show up until commissioning.
Compare that to a function block built with DB tags and a proper interface. You copy the block, TIA Portal creates a new instance DB, and everything works. No address conflicts, no manual reassignment. Just copy and use.
This matters even if you never reuse code across projects. Within a single project, M bits create invisible dependencies between blocks that should be independent. You change one M address and something unrelated breaks.
Maintenance Is a Nightmare
Six months after you finish a project, someone needs to make a change. Maybe it is you. Maybe it is another engineer who has never seen the project before.
Which M bits are in use? Which ones are free? There is no easy way to answer these questions. You end up scrolling through every network in every block, hoping you did not miss one. Comments like “DON’T TOUCH – USED SOMEWHERE” start appearing in the tag list, which tells you everything about how maintainable the architecture is.
A project built around M bits is essentially a hand-crafted memory map. It works as long as the original programmer is available to explain it. The moment they are not, maintenance becomes archaeology.
Beyond the Big Three: More Reasons to Avoid M Bits
The three problems above are the most common pain points, but there are additional technical reasons worth understanding.
Symbolic names do not fix the fundamental limitations. TIA Portal lets you give M bits symbolic names, which improves readability. But underneath, they are still tied to fixed hardware addresses, still subject to memory overlap, still global shared state, and still cannot be part of structured data types. Readability improves; architecture does not.
Hardware-dependent design. FB/DB interfaces, PLC data types, and UDTs migrate cleanly across projects and CPU families. M10.0 does not. Even with a symbolic name, the underlying dependence on a fixed address remains.
Retentivity is implicit. Whether an M bit is retentive depends on CPU-level configuration and address ranges. With DB variables, retentive or non-retentive behavior is explicitly defined per variable, making system behavior clearer and more predictable.
Poor scalability. A small project with 20 M bits seems harmless. After years of modifications, it becomes 200 scattered flags. Finding a free address becomes a routine chore.
Harder testing and simulation. Testing a function block is straightforward when all state lives inside its instance DB and all inputs and outputs are typed parameters. M bits introduce global, invisible state that test tools and simulators must know about and manipulate manually.
Difficult cross-platform migration. All modern PLC platforms – Siemens, Rockwell, Beckhoff, Schneider – are tag-based. Logic designed around structured data transfers far more easily than logic tied to magic addresses like M100.0.
What to Use Instead
A modern Siemens-aligned architecture uses:
- DB tags for any global state that needs to be shared between blocks.
- UDTs (User-Defined Types) to structure related data into clean, typed groups.
- Function blocks with instance DBs for all device logic and state. Each FB instance gets its own data, no address conflicts, easy to copy and scale.
- Fully symbolic addressing across the entire PLC project.
This approach is cleaner, more reusable, easier to maintain, and scales well as your project grows. It also aligns with Siemens’ own programming style guide for S7-1200/1500 systems.
Practical Migration Tips
If you have an existing project built with M bits, you do not need to refactor everything at once. Here is a pragmatic approach:
- Stop adding new M bits. For any new logic, use DB tags and proper FB interfaces from the start.
- Refactor when you touch code. When you modify a section that uses M bits, take the extra time to convert it to DB tags.
- Start with the most problematic areas. If you have M bits that keep causing confusion or bugs, prioritize those for conversion.
- Use UDTs for related data. If you have a group of M bits that logically belong together (like machine states or operator commands), create a UDT and move them to a DB.
The goal is not perfection overnight. It is a steady improvement toward a more maintainable architecture.
Planning a project? Contact us to discuss how we can help.
