Siemens STEP7 & TIA Portal programming software series is powerful, and its modular programming approach enables clear system logic, easy maintenance, and modification, which are crucial for the design of large and complex projects. In today's article, we'll discuss how STEP7 & TIA Portal achieve modular programming design.
For a complex automation control task, we often divide it into several sub-tasks based on its internal logic relationships. These sub-tasks can further be divided into smaller sub-tasks if necessary. This approach helps simplify complex projects, making them easier to implement. Let's use a travel analogy: Suppose we're planning a trip to Europe. We need to consider how to get there (transportation), where to stay (accommodation), and what to do (shopping, sightseeing), etc. In this way, the task of "traveling to Europe" is divided into four sub-tasks: "transportation," "accommodation," "shopping," and "sightseeing." We then complete each sub-task separately (booking a flight completes the "transportation" task, booking a hotel completes the "accommodation" task, and so on). Once all the sub-tasks are completed, the entire task is also completed.
Siemens STEP7 & TIA Portal introduced the concept of simplifying complex tasks by dividing them into smaller subroutines in programming. The entire project program can be divided into smaller subprograms, each of which is programmed separately. These divided subprograms are called "blocks," and they interact with each other through logical relationships, either by calling or being called. This programming method of dividing complex programs into smaller "blocks" is known as "modular programming design."
Modular programming design enhances logical clarity and transparency in organizational structure, thus improving program comprehensibility and maintainability. It facilitates easy modifications, debugging, and error checking. Once created, these "blocks" can be reused indefinitely, reducing programming workload and enhancing work efficiency.
In the previous article, "PLC Basics: The Birth and Working Principles of PLCs," we discussed that PLC internal programs consist of two types: the operating system program and the user program. The discussion in this article focuses on the interface between the operating system and the user program, as well as the modular design of the user program itself.
The Organization Block (OB) serves as the interface between the operating system and the user program. The operating system invokes specific organization blocks to perform particular functions. User programs must be written within organization blocks to be callable.
The Organization Block (OB) can be divided into three types: the startup organization block, the cyclic organization block, and the interrupt organization block.
Startup Organization Block: When the CPU transitions from stop mode to run mode, the operating system invokes the startup organization block once (note: only once). The primary purpose of the startup organization block is to initialize certain variables.
The cyclic organization block, also known as the main program block, typically labeled as OB1, serves as the entry point for the user program. It is analogous to the "main function" in the C programming language.
The interrupt organization block is invoked by the operating system when an interrupt occurs. STEP7 specifies the numbering of interrupt organization blocks, where a specific interrupt triggers the invocation of a corresponding interrupt organization block. Inside the interrupt organization block, the user writes the interrupt handling program (refer to "How does the Interrupt Mechanism Enable Efficient PLC Operation?"). The discussion above pertains to the organizational structure of the interface between the operating system and the user program. Now, let's delve into the modular design of user programs.
In user programs, we can encapsulate code that accomplishes a specific function into a "block," referred to as a "Function Block (FB)" or a "Function (FC)." Both Function Blocks (FBs) and Functions (FCs) are collections of code capable of performing a particular function, essentially serving as subroutines. The key difference between them lies in the handling of static variables: "Function Blocks (FBs)" require a specific Data Block (DB) to store static variables, while "Functions (FCs)" do not have static variables and therefore do not require a specific Data Block.
The specific Data Block (DB) required by a "Function Block (FB)" is called an Instance Data Block (IDB). The properties of the Instance Data Block are private, meaning it can only be accessed by the Function Block (FB) to which it belongs. In contrast, another type of Data Block is the Global Data Block (GDB), which is public and can be accessed by all Function Blocks (FBs) or Functions (FCs).
When designing complex projects, it is common to divide them into subtasks and design Function Blocks (FBs) or Functions (FCs) for each subtask. Function Blocks (FBs) or Functions (FCs) can call each other, and when a called function block internally calls another function block, this type of call is referred to as "nested calling," and the number of levels of nested calling is known as the "nesting depth." Different CPUs support different nesting depths, which should be checked in the respective manuals. For example, the nesting depth for CPU 1215C is as shown in the following figure:
About STEP7 & TIA Portal's modular programming design, that's all for now..