Why should M and T be avoided in PLC programs? The core logic of programming standardization.
1. Fundamental Flaws of Global Variables
In PLC programming, global variables such as M (memory relay) and T (timer) are widely used but have inherent weaknesses: unclear ownership and a scope that covers the entire program.
The M and T in German PLCs, D and H in Japanese PLCs, and any globally visible variables in tagged programming share the same characteristic: lack of module boundary protection.
When a piece of logic directly uses M0.0 to pass a state and T37 to implement a delay, that segment of the program is tightly bound to the global variable space of the current project.
2. Core Goals of Standardized Programming
The fundamental goal of programming standardization is to achieve reusability and maintainability of programs, allowing program modules to be quickly and reliably assembled like LEGO blocks in different projects. To achieve this goal, a basic premise must be met: completely resolve the issue of global variable dependencies.
If the hurdle of variable conflicts cannot be overcome, each reuse will require manual checking of addresses, logic modifications, and retesting, making “standardization” merely a formality.
3. Real Dilemmas Caused by Global Variables
The development model that relies on global variables will ultimately lead to the following types of problems:
High reuse costs:
When reusing code across projects, it is necessary to check each variable for conflicts, manually adjust addresses, and retest, which may require more effort than rewriting the logic.
Difficulties in debugging and maintenance:
As the program scales, the risk of the same variable being used in multiple places increases sharply, creating hidden dangers that are hard to trace.
During the device lifecycle, if later enabled functions expose design flaws, it may incur extremely high costs for on-site repairs.
Low knowledge transfer and collaboration efficiency:
Programs that heavily rely on personal experience are difficult for others to understand and take over, and personnel turnover may lead to project maintenance stagnation.
Case Insight: A device malfunctioned due to an M point being reused in two logic segments. This issue was not triggered until two years after the device acceptance, ultimately requiring an engineer to travel across cities for repairs, significantly increasing costs. This exemplifies the hidden costs of global variables.
4. How to Achieve True Programming Standardization
1. Abandon global variables and adopt encapsulation principles.
Core principle: All device or functional logic must be encapsulated in independent function blocks (FB) or functions (FC).
Implementation method:
Exchange data with the outside through interface parameters (Input/Output/InOut).
All internal variables should be placed in local static variables (Static) for complete isolation.
If state needs to be maintained, use background data blocks (DB) or structure instances.
2. Adopt object-oriented (OO) design concepts.
Abstract physical devices (such as cylinders, motors, valves) as object classes.
Attributes: Encapsulated in structures or UDTs (User Defined Types) (e.g., current state, manual commands, fault codes).
Methods: Implement behavior logic (e.g., automatic operation, manual debugging, error handling) through function blocks.
Further optimize code structure through inheritance and polymorphism (supported by advanced PLC platforms).
3. Build a standardized module library.
Accumulate verified standardized function blocks covering common device and process control functions.
New project development shifts to a model of “selection-assembly-parameter configuration,” significantly reducing coding and debugging workload.
5. Value Transformation Brought by Standardization
Implementing standardized programming can bring fundamental changes to engineers and enterprises:
Traditional model vs. Standardized model
Repetitive coding, frequent travel vs. Module reuse, significantly reduced on-site debugging time
Fire-fighting maintenance, overwhelmed vs. Remote monitoring and parameter adjustment, efficient support
Personal experience barriers, reliance on senior engineers vs. Knowledge stored in module libraries, newcomers can quickly get started
Value reflected in overtime and man-hours vs. Value reflected in architectural design and efficiency improvement
Ultimately, engineers can be liberated from tedious repetitive labor, focusing on more valuable process optimization and system innovation, achieving mutual growth for individuals and enterprises.
Conclusion: Avoiding the use of global variables such as M and T is the first step towards PLC programming standardization. Its essence is to use technical means to avoid inherent pain points, elevating programs from “one-time project code” to “reusable standard modules.” This is a transformation of thinking patterns, a key leap from experiential craftsmen to methodological engineers.
Disclaimer: This article is reprinted from the internet, and the copyright belongs to the original author. If there are any copyright issues, please contact us in a timely manner for deletion. Thank you! For more knowledge content, please scan the code to contact me and receive a free introductory Siemens electronic book.
