Structuring PLC Applications: Rockwell Studio 5000 vs. Siemens TIA Portal

When it comes to developing automation systems, two of the most widely used platforms are Rockwell Studio 5000 and Siemens TIA Portal. Each offers powerful tools for structuring PLC applications, but the way they approach program organization, modularity, and data management can differ significantly. Whether you're working with basic control logic or with intricate, multi-layered industrial processes, understanding the subtle nuances between these platforms is key to making informed choices on how to best design and structure your system.

In this blog article, I’ll dive into the key differences and similarities in structuring PLC applications between Rockwell Studio 5000 and Siemens TIA Portal, exploring topics such as program execution and organization, tag structuring, data handling, and encapsulating control logic.

By the end of this article, you'll understand how to efficiently structure your PLC program for either platform, making it easier to switch from one to the other.  Let’s dive in!

1 - PROGRAM EXECUTION

When working with Programmable Logic Controllers (PLCs), understanding how programs execute is critical to designing efficient and reliable automation systems.  In this section, we will explore the similarities and differences in program execution methods used by Rockwell Automation (Allen-Bradley) and Siemens.

ROCKWELL 

In Rockwell Studio5000/RSLogix 5000, particularly when using their ControlLogix and CompactLogix PLCs, program execution is structured around Tasks. Each task dictates how and when the PLC program executes. Tasks in Rockwell systems can be event-based, periodic, or continuous. Here’s a breakdown of the major task types:

• A Continuous Task executes as often as possible, which is the default mode of execution. It runs continuously, and its scan cycle depends on how much logic is present in the task. The more logic a continuous task needs to process, the slower its execution will be. Only one continuous task can exist in a Rockwell PLC program.
• Periodic Tasks run at a fixed, scheduled interval (e.g., every 10 ms). The periodic task guarantees that logic will execute on a strict time schedule, providing deterministic behaviour. You can have multiple periodic tasks in a program, each with different time intervals.
• An Event Task is triggered by an event such as a change in an axis registration input, or a module's input data status change. Event tasks provide immediate response to changes, and their execution can interrupt other tasks if configured to do so.

SIEMENS

Siemens TIA Portal uses Organization Blocks (OBs) as the backbone for program execution. OBs define the structure and control the order and manner in which code is executed in Siemens PLCs. There are different types of OBs designed for various purposes. The major types include:

• OB1 (Main Cycle): This is the default OB that executes cyclically (similar to the continuous task in Rockwell). OB1 continuously executes logic and is often used for the main program logic.
• Cyclic Interrupt OBs (OB30-OB38): These OBs are executed at predefined intervals (e.g., every 100 ms). This is similar to periodic tasks in Rockwell. Each cyclic interrupt OB is tied to a specific time interval, allowing deterministic execution at regular intervals.
• Time-Triggered OBs (OB10-OB17): These OBs are executed at a specific date and time or on a periodic basis. They function similarly to periodic tasks in Rockwell, but with more focus on real-time clocks or calendars.
• Hardware Interrupt OBs (OB40-OB47): These OBs are executed in response to hardware events, like the event tasks in Rockwell. For instance, if a module detects an error or a sensor signals a condition, the associated OB executes.
• Startup OBs (OB100, OB101, OB102): These are executed during PLC startup or after a warm restart, which can be used to initialize variables and configure system settings.
• Error OBs (OB80-OB87): These handle errors and faults, such as timeouts, I/O issues, and communication problems. This functionality is more specialized and provides the ability to manage faults within the PLC execution.

In Siemens TIA Portal, the one OB to rule them all is the OB1 - the continuous task.  This is where you’ll call your various program modules. Siemens PLCs are extremely fast, often achieving cycle times as low as 1ms, which stands in contrast to Rockwell PLCs, where a 10ms periodic task is considered "fast”.  So if you’re transitioning from Rockwell to Siemens, prepare for a noticeable increase in speed.

Now that we’ve covered how programs execute in Rockwell and Siemens, let’s explore how they are organized.

2 - PROGRAM ORGANIZATION

In this section, we'll explore which tools are available to organize programs in both Rockwell Studio 5000 and Siemens TIA Portal. Proper organization is key to maintaining clarity and efficiency in complex automation systems. And while both platforms offer powerful tools for structuring your logic, they approach it in a slightly different way. Let’s dive into the specifics of each platform and see how they compare.

ROCKWELL

Rockwell Studio 5000 (or RSLogix 5000, as it's known in older software versions) organize their logic into three hierarchical levels: Tasks, Programs, and Routines. 

Tasks determine the overall scheduling and execution of the logic. They control when and how often programs execute. There are three types of tasks: Continuous, Periodic, and Event Tasks, as described earlier.

Inside each task, you can have multiple Programs. Each program has its own local data (tags) and routines. The programs are modular chunks of code that allow you to break the logic into distinct sections for easier maintenance and better organization. Programs are essentially containers that hold the routines and the order of programs can be manually defined within the task properties.

Routines are where the actual logic - Ladder Diagram, Structured Text, Function Block Diagram, or Sequential Function Chart - is situated. The most common routine is the Main Routine, which is executed by default when the program runs. Other routines can be created and called from the main routine or other routines within the program.  Routines don’t need to have a globally unique name, they only need to be unique within their specific Program.

In the example above, two periodic tasks are set up to clearly separate equipment modules from machine modules. Within the equipment modules, a program for the Cooling Tunnel equipment module (EM) has been created. This program contains 4 routines

• R00_Main
• R01_Configuration
• R10_Conveyors
• R11_Cooling

that house the actual logic for controlling the cooling tunnel.

SIEMENS

Siemens TIA Portal takes a slightly different approach to program structuring by utilizing Program Groups and Function Blocks.

Program Groups are used to organize the various modules of your application (similar to Programs in Rockwell). These Program Groups are not called or executed within the application, they are only used as folders for organizational purposes.  Groups are always ordered alphabetically, the order cannot be chosen freely like with Programs in Rockwell.  An easy way to manually order groups in TIA Portal, is by assigning a number to the beginning of the group (e.g. “00 - Equipment Modules”).

Function Blocks are similar to Routines in Rockwell, as they hold the actual logic for controlling specific parts of your application.  In contrast to Routines in Rockwell - which only need to be unique within the Program scope - FBs, FCs, OBs, and DBs in Siemens must each have a unique name.

In the example above, a program group is created for both equipment modules and machine modules. Additionally, a sub-group for a Cooling Tunnel equipment module (EM) is added to organize all the logic related to the cooling tunnel module.
 

Both Rockwell and Siemens have powerful tools for creating a modular program structure, but they implement and name them differently. Rockwell Studio 5000 (RSLogix 5000 for older versions) uses a three-tiered approach: Tasks → Programs → Routines), that typically has a flatter structure compared to Siemens.

Siemens TIA Portal organizes programs using program groups and function blocks, following a more hierarchical structure compared to Rockwell. It’s not uncommon to see function blocks nested 2-3 layers deep in Siemens systems.

Now, let's explore how data is organized on both platforms.

3 - DATA ORGANIZATION

In complex automation systems, organizing and structuring data efficiently is key to creating scalable and maintainable programs. One of the most effective ways to achieve this is through User-Defined Data Types (UDTs), which allow PLC programmers to build custom data structures tailored to specific applications. UDTs make it easier to mirror real-world objects or systems, enhancing modularity and reusability. In this section, let's explore how UDTs are implemented and utilized in both Rockwell Studio 5000 and Siemens TIA Portal.
 

ROCKWELL

In Rockwell's Studio 5000, UDTs are created through the “Data Types” section of the program, where users can define a new UDT by specifying the fields and their data types. Once created, the UDT can be used as a tag type for variables throughout the project.

Each UDT can include a wide range of Rockwell’s primitive data types, such as BOOL, SINT, DINT, REAL, TIMER, COUNTER, STRING, etc. You can also nest UDTs within other UDTs to create more complex data structures.

The example above illustrates a user-defined data type, "UDT_Conveyor," which is composed of the following sub-structures:

• Configuration (Cfg)
• Parameters (Par)
• Status (Sts)
• Command (Cmd)
• Fault (Flt)

Each of these sub-structures is built using its own user-defined data type (e.g. UDT_Conveyor_Cfg, UDT_Conveyor_Par, etc… ).

SIEMENS

In Siemens TIA Portal, UDTs also provide a way to group multiple data elements of different types into a single structure. These UDTs are highly customizable and are used extensively to structure data in programs.

In TIA Portal, UDTs are created in the "PLC Data Types" section.  Siemens UDTs support basic data types (BOOL, INT, REAL, etc...), complex data types (ARRAYs, STRUCTs, TIMERS, and COUNTERS), and can even include other UDTs. This allows for a high degree of flexibility when defining the structure of your data.

The example above demonstrates how a single user-defined data type "UDT_Conveyor" is created in TIA Portal with various sub-structures for Configuration, Parameters, Status, Command, and Fault.  

In summary, both Rockwell Studio 5000 and Siemens TIA Portal use User-Defined Data Types (UDTs) to help organize and manage data in automation systems. UDTs make it easier to handle complex information by grouping different data types into one structure. Siemens TIA Portal offers more flexibility with Struct data types, which simplifies the process by not requiring separate UDTs for each sub-structure. In Rockwell, you need to create individual UDTs for each part, making it a bit more involved. Understanding these differences can help you choose the right method for your project.

Now that we've covered how UDTs organize data in Rockwell and Siemens, let's move on to how these platforms manage data access. In the next section, we'll look at the differences and similarities between global and local data in Rockwell and Siemens systems.

4 - HANDLING OF GLOBAL/LOCAL DATA

Comparing global and local data in Rockwell (Allen-Bradley) and Siemens TIA Portal reveals similarities and differences in how these two leading platforms handle data scoping and access within PLC programs. Here’s a breakdown of how global and local data are implemented in each system.

ROCKWELL

In Rockwell Automation ControlLogix and CompactLogix systems, data is typically organized into tags, which can be

• Global (controller-scoped) or
• Local (program-scoped)

Global Tags are defined at the controller level and are accessible from anywhere within the project, including any task, program, or routine. They serve as controller-scoped tags.

Global tags (or controller tags as they're also called) are created in the “Controller Tags” section of the Studio 5000 environment. Once created, they can be accessed by any routine, program, or task in the project, without any additional steps. Global tags are often used for sharing data across multiple programs or routines, such as status indicators, commands, or I/O data.

The example above showcases a global tag structure "EM_CoolingTunnel", consisting of:

• 3 conveyor structures - Conveyor[1..3] (assuming Conveyor[0] not being used)
• 2 cooling structures - Cooling[1..2] (assuming Cooling[0] not being used)

where both arrays were built using user-defined data types.

Local Tags are tags defined within the scope of a specific program and are not accessible outside that program. These are referred to as program-scoped tags in Rockwell systems.

Local tags are defined in the "Parameters and Local Tags" section of a specific program in Studio 5000. These tags are accessible only within the routines of that particular program. Local tags are typically used to encapsulate data specific to the operations of that program, making them modular and easy to manage (e.g. copy/paste).

SIEMENS

Siemens uses Global Data Blocks (DBs) to store and manage global variables. DBs can be accessed from anywhere in the PLC project, including any organization block (OB), function block (FB), or function (FC). Global DBs are declared independently of any specific block and are available project-wide.

Global Data Blocks are created in the "Program Blocks" section of TIA Portal by using the following 4 simple steps:

1. Add a new block
2. Select "Data block"
3. Choose "Global DB" as the block type
4. Assign a name to the data block
   
   

Global DBs can store simple data types (BOOL, INT, REAL, etc...) or complex data types like STRUCTs, UDTs or arrays.

The example above demonstrates how a global DB "EM_CoolingTunnel" was created within the "Global Data" program group. The DB contains a data structure comprising 3 conveyors (Conveyor[1..3]) and 2 cooling units (Cooling[1..2]), both of which were constructed using arrays of user-defined data types.

In Siemens, local data is available for FBs, FCs and OBs (and should only be used inside the block itself) and are handled through:

• Instance Data Blocks (FBs only)
• Temporary variables (FBs, FCs or OBs)
  
  

When using Function Blocks (FBs), instance data is stored in an Instance Data Block (Instance DB). This local data includes Input, Output, InOut, and Static memory, and it is specific to each instance of the FB. This type of data remains persistent across program scans. The Instance DB is automatically created when an FB is called.

Temporary variables (Temp) are local to the block in which they are defined and only exist during the execution of that block. Once the block execution is complete, the data is discarded.

Rockwell and Siemens TIA Portal each provide unique approaches to managing global and local data within their PLC systems. Rockwell differentiates shared and program-specific data using global and program-scoped tags, while Siemens relies on Global Data Blocks and local data in FBs, FCs, and OBs to handle data across various scopes.

Now, let's conclude this comparison with a powerful finale by diving into how both platforms handle logic encapsulation.

5 - ENCAPSULATING LOGIC

Encapsulating PLC logic is a crucial aspect of programming modern automation systems, allowing for modular, reusable, and maintainable code. Both Rockwell Automation and Siemens offer methods to encapsulate logic, but they approach it differently based on their underlying architecture. Below is a detailed comparison of how encapsulation of PLC logic is handled between Rockwell and Siemens.

 
ROCKWELL

In Studio 5000, logic is encapsulated using Add-On Instructions (AOIs). AOIs allow for the creation of custom, reusable code modules that can be instantiated multiple times within the program.

AOIs can encapsulate both the logic and the associated data. Each instance of an AOI maintains its own data, allowing for reusability and modular programming.

The example above illustrates how the control logic for both a conveyor and a cooling unit is encapsulated within individual Add-On Instructions (AOIs). The "AOI_Ctrl_Conveyor" is called three times in the application, with each call using a unique instance. Similarly, the "AOI_Ctrl_Cooling" is called twice, with each call also utilizing a unique instance in the PLC application.

SIEMENS

In Siemens TIA Portal, logic encapsulation is handled mainly through Function Blocks (FBs) and their associated Instance Data Blocks (DBs). FBs encapsulate logic and data together, ensuring that each instance of an FB has its own set of variables stored in the Instance DB.

Function Blocks can be modified during runtime, with changes requiring only a download to the PLC without causing it to enter stop mode (this is a significant advantage compared to Rockwell's Add-On Instructions where any change requires a CPU stop). 

The example above shows how all logic for controlling a conveyor is encapsulated within the "FB - Ctrl Conveyor", while all logic for the cooling unit is contained in the "FB - Ctrl Cooling".

The "FB - Ctrl Conveyor" is utilized three times by calling the block with a different instance data block (DB) for each instance. Similarly, the "FB - Ctrl Cooling" is used twice in a different part of the program, with each call utilizing a different instance DB.

Both Rockwell Automation and Siemens offer robust methods for logic encapsulation, but with distinct approaches based on their platform architecture. Rockwell uses Add-On Instructions (AOIs) to encapsulate logic and associated data, with each instance maintaining its own set of variables. Siemens, on the other hand, employs Function Blocks (FBs) and Instance Data Blocks (DBs) for similar functionality, with the added advantage of runtime editing without stopping the PLC.

 

In conclusion, both Rockwell Studio 5000 and Siemens TIA Portal provide robust tools for developing and organizing automation systems, each with unique approaches to program execution, organization, data handling, and logic encapsulation. While there are similarities between the platforms, their differences are important to understand. By mastering these concepts, you can design efficient and scalable PLC applications on either platform.

-Hans