Search the Community

In the last articles, we discussed how to establish a connection between two PLCs using the TCON and TDISCON blocks and how to move data between them using the TSEND and TRCV blocks. Transferring Data Across PLC Systems In this article, we will learn a new instruction that can be used to communicate and transferring data across PLC systems using TSEND_C and TRCV_C blocks. TSEND_C The TSEND_C instruction is a TIA Portal instruction that is used to set up and establish a connection between two PLCs. Once the connection has been set up and established, it will be automatically maintained and monitored by the PLC. The TSEND_C instruction is executed asynchronously and has the following functions: Setting up and establishing a communication connection similar to TCON block. Sending data via an existing communication connection similar to TSEND block. Terminating or resetting the communication connection similar to TDISCON. Hence, the name compact is giving to the TSEND_C as it acts as more than 3 blocks in the same time. TRCV_C The TRCV_C instruction is also a TIA Portal instruction that is used to set up and establish a connection between two PLCs. Once the connection has been set up and established, it will be automatically maintained and monitored by the PLC. The “TRCV_C” instruction is executed asynchronously and implements the following functions in sequence: Setting up and establishing a communication connection similar to TCON. Receiving data via an existing communication connection similar to TRCV. Terminating or resetting the communication connection similar to TDISCON. Hence, the name compact is given to the TRCV_C as it acts as more than 3 blocks at the same time. Using TSEND_C and TRCV_C in our PLC project In the last article, when we needed to establish and move to send data from PLC_1 into PLC_2 we had to use three different blocks in each PLC. See picture 1. picture 1. Logic inside PLC_1 As you can see, we used the TCON and TDISCON blocks to establish and reset the connection and we used TSEND to send the data from PLC_1. And the same was done for the PLC_2. See picture 2. picture 2. Logic of PLC_2 Again, we used the TCON and TDISCON blocks to establish and reset the connection and we used TRCV to receive the data from PLC_1. Now, we want to replace all these blocks and try to use the TSEND_C and TRCV_C instead to achieve the same functionality. First, in PLC_1 where we need to send data, we will use the TSEND_C block, just drag and drop the block inside the main OB1. See picture 3. picture 3. Add TSEND_C block. As the TSEND_C is essentially a function block, you will be asked to create a data instance. See picture 4. picture 4. Create an instance for the TSEND_C The TSEND_C looks similar to the TSEND block in the sense that you need to make some configurations and add some signals. See picture 5. picture 5. TSEND_C block Now, we need a signal for the REQ and Data to send and also to configure the connection. For the REQ signal, we created a SendData tag. Also, we can just drag and drop the data block that we created last article which we need to send it to PLC_2, we can just drag it and drop at the DATA input of the block. See picture 6. picture 6. Configuration of TSEND_C block. To configure the connection parameter for the block, we can press the small configuration icon on top of the block to open the configuration view. The configuration view will look something very similar to that of the TCON block. See picture 7. picture 7. Connection parameter of TSEND_C We already showed how to configure the connection parameter in previous articles, so we can just do the same as we did with the TCON block, see picture 8. picture 8. Configuration of connection parameter With this connection configuration, we finished all configurations of the TSEND_C. Notice how much faster it was compared to configuring TCON, TDISCON, and TSEND blocks. Now, we need to add the TRCV_C to the PLC_2 so it can receive the data sent from PLC_1. In the main OB1 of PLC_1 just drag and drop the TRCV_C into your logic. see picture 9. Remember to create a data instance for the TRCV_C block. picture 9. Add the TRCV_C Once the TRCV_C is added to your logic, we need to configure it. As we did with the TSEND_C we need to add a signal to enable the data receive and also we need to add the data block we will save the data inside. See picture 10. picture 10.TRCV_C We defined a RecieveData tag as the EN_R signal. See picture 11. picture 11. Define EN_R tag Remember to uncheck the “optimized block access” option of the data block or the block won’t work as we showed last articles. Next, we need to configure the connection parameters of the TRCV_C block, as we did with the TSEND_C just keep in mind that the unspecified Partner PLC is now the PLC_1 see picture 12. picture 12. Connection parameter of TRCV_C PLC Project Simulation Now that we have configured the TSEND_C and TRCV_ C block, we want to simulate our project and see how they will work but first, we will create a simple logic to automatically update the data of PLC_1 which will be sent to PLC_2. See picture 13. picture 13. Simple logic to update data automatically. Now let’s compile and start a simulation for our project. The first thing you will notice is that PLC_1 and PLC_2 will try to establish a connection right away because we set up the TSEND_C and TRCV_C they automatically try to establish a connection. That is why there will be a connection between the two PLCs. See picture 14. Picture 14. Connection is established directly. As you can see the connection between the PLCs is directly established, because the CONT parameter in the TSEND_C and TRCV_C is set to TRUE, which means the block will automatically try to establish a connection with the partner PLC. We can put any controlling signal in here to control the connection establishment. The other thing you can see is that the REQ of the TSEND_C and the EN_R of the TRCV_C are set to FALSE, and that is why there will not be any data moving between the PLCs. See picture 15. picture 15. No data transfer between PLCs. If the REQ signal of the TSEND_C is set to true, the PLC_1 will try to send the data but it will wait for the other PLC to enable the data to be received, see picture 16. picture 16. REQ is true. As you can see the SendData is TRUE, but no data was sent because the RecieveData is still false. The PLC_2 will only receive data from PLC_1 only when the ReceiveData is set to true. See picture 17. picture 17. Data is sent to PLC_2 As you can see when the RecieveData is true. Data will be sent from PLC_1 into PLC_2, However, you can see that the data inside the two PLCs are different because the data of PLC_1 changes automatically as per the simple logic we made before. That means the EN_R signal allows the transfer of data one time, when I need to transfer data again this signal has to become false and then true again. Check out the attached TIA Portal project and see the data transfer between PLCs.

S7-1200 PLC is a compact, modular, and cost-effective solution that offers a wide range of features and flexibility for small to mid-sized automation applications. These features include communication options, memory, CPU performance, and IOs configuration. When you have a process that you need to control, you should choose the PLC and configure it to best fit your process requirements. In this article, we will discuss the hardware configuration of S7-1200 PLC and we will give an example of how to configure it in the Siemens Tia portal. Contents: What is the hardware configuration of a PLC? Importance of hardware configuration. Simple project example. How to configure our PLC with the given example? Hardware configuration of CPU. IOs hardware configuration. HMI configuration. Conclusion. What is the hardware configuration of a PLC? The hardware configuration refers to the specific components of the PLC, such as the CPU, memory, input/output (I/O) modules, communication ports, power supply, and any additional modules or accessories that may be needed and added to the system. The hardware configuration of a PLC also includes enabling or disabling some of the CPU features, depending on the device, its capabilities, and the requirements of your process. The hardware configuration steps for a PLC typically involve the following: Select the appropriate PLC model based on the application requirements. Identify the input/output requirements for the system, which include the type and number of sensors, actuators, and other devices that will be connected to the PLC. Choose the communication protocol and network topology that will be used to connect the PLC to other devices and systems. Determine the power supply requirements for the PLC and its peripherals. Mount the PLC in an appropriate location and connect all the necessary cables and wires. Configure the PLC software to communicate with the hardware components and set up the appropriate logic and control functions. The specific steps for hardware configuration may vary depending on the PLC model and the application requirements, but these are the basic steps that are typically involved in the process. In this article, we will talk about the hardware configuration that is done in the TIA Portal platform. That means we will assume that you know your application and that you have already chosen your PLC model and the Power supply to feed it. You can refer back to previous articles where we discuss how to choose the PLC and power supply that best fits your application. Importance of Hardware Configuration in PLC Proper hardware configuration ensures the system is reliable and robust. If the hardware components are not configured correctly, they may not work as intended, resulting in system failures or errors Hardware configuration affects the performance of the system. By choosing the right hardware components and configuring them appropriately, the system can operate at maximum efficiency and speed and can handle a high volume of inputs and outputs. Hardware configuration impacts the scalability and flexibility of the system. The choice of hardware components and their configuration should take into consideration future expansion or modifications to the system, to ensure that the system can easily accommodate changes or upgrades. Hardware configuration affects the cost of the system. By selecting the appropriate hardware components and configuration, unnecessary costs can be avoided, and the overall cost of the system can be minimized. S7-1200 Hardware Configuration We will assume a simple PLC project and see how we can configure the PLC into our project before we start writing our code. Temperature Control System for a Reactor using PLC The project involves controlling the temperature of a reactor using a PLC. The system should measure the temperature of the reactor and adjust the temperature by controlling the flow of a cooling fluid. The project uses four thermocouples to measure the temperature, two solenoid valves to control the flow of the cooling fluid, and a motor to drive the impeller of the reactor. I/O Configuration Inputs: Thermocouples 1 – 4: these are 4 analog inputs that measure the temperature at different locations inside the reactor. Emergency Stop Pushbutton: This is a digital input that is used to stop the system in case of an emergency. Temperature Set Point Potentiometer: This is an analog input that allows the operator to set the desired temperature setpoint. Outputs: Solenoid Valve 1 and 2: these are 2 digital outputs that control the flow of the cooling fluid through the reactor pipes. Motor Control: This is a digital output that controls the speed and direction of the motor that drives the impeller. Heater Control: This is a digital output that controls the heating system of the reactor. System Operation: The system waits for the operator to set the temperature setpoint using the potentiometer. The PLC reads the temperature setpoint and compares it to the current temperature of the reactor, which is measured by the four thermocouples. If the reactor temperature is below the setpoint, the PLC activates the heater control output to increase the temperature. If the reactor temperature is above the setpoint, the PLC activates one of the solenoid valve outputs to increase the flow of the cooling fluid and decrease the temperature. The PLC continuously monitors the temperature and adjusts the heater and cooling systems to maintain the desired setpoint. The PLC also controls the motor that drives the impeller to mix the contents of the reactor. If the emergency stop pushbutton is pressed, the PLC deactivates all the outputs and stops the system. The PLC project can be further expanded and modified to include additional functionality, such as alarms, data logging, or remote monitoring, depending on the specific requirements of the project. However, we will not care about coding the PLC logic of this system, rather we will use this example to explain how to hardware configure the PLC to fit our project. This includes: Selecting the PLC CPU. Selecting the IO modules. Assigning the input and output tags to the hardware modules. Assigning an IP to the PLC for communication. Assigning a protection password. Configuring the local time of the PLC. Configuration the HMI and set the connection with PLC. How to configure PLC with the given example? Below we will discuss the basic PLC project creation with the required hardware. The hardware configuration of the CPU: Selecting the CPU: When you start a new project in TIA Portal, you should configure a new device and add it to your project. See picture 1. Picture 1. Configure a device for your project As you can see from the previous picture, the TIA portal already shows you that the first step should be configuring a new device. In the previous article, we discussed how to choose the PLC that fits your process, so we will not mention that here again, for our project as it is a simple project we will choose the CPU 1214C AC/DC/RLY. See picture 2. Picture 2. Add a new controller to the project CPU Properties: Depending on the CPU that you have selected for your project, different CPU features and properties will be available. You can enable or disable these features depending on your needs. Some of the features will need extra configuration to be made. See picture 3. Picture 3 – Properties of CPU As you can see in the previous picture there are many properties that you can set for your CPU in the project. We will mention some of these properties which you will need to configure in each project you make, some other properties are used only in special cases. Communication: This is a very important configuration for any PLC project; your project will most probably have different modules and devices that need to talk to each other. Setting up the communication between your PLC and these devices is important for your project. By selecting the CPU you already have defined how the communication will be. Some CPU only works with Profinet, some only work with Profibus and some have the ability to use both. The selected PLC for this example only works with Profinet. From the Profinet interface you will set the IP address for your PLC, this IP should be unique in the project; you can’t use the same IP for two different modules. See picture 4. Picture 4 – Profinet interface Cycle time: This is another important property for your PLC, as you know; the cycle time of your program will depend on how much code you have written and how long it will take the PLC to execute this code. In the cycle time properties, you can set the cycle monitoring time, if the PLC takes longer than this set time to execute the program, then the PLC will give an error. See picture 5. From this property you can also determine the minimum cycle time for your CPU, you can do that if you triggered the “Enable minimum cycle time for cyclic OBs”. You then can write the minimum cycle time that you want, and the PLC will adjust its performance to match this time. Off course this time is limited by the CPU performance capability, so you can’t lower this time below a certain limit. Picture 5 – Cycle time Property System and clock memory bits: System memory bits and clock memory bits are built-in bits inside the CPU that the operating system used to indicate certain events in the PLC. For example, there is a memory bit that will change to TRUE only at first scan or a memory bit that will be TRUE if diagnostic status changes, there are also some dedicated clock memory bits like a bit representing a clock of 10Hz or a bit representing a clock of 2Hz. These bits can be very useful in some applications and can save a lot of programming code to obtain the same functionality. See picture 6. picture 6 – Enable system and clock memory bits You can enable the use of one or both memory bytes; you can also determine the address of these bytes as you can see from the picture. Time of Day: Another very important property of your PLC is setting the time inside your PLC. In almost any project you make, you will need to know the real-time to be able to assign certain actions with different dates. In the previous article, we talked about local and system times inside the PLC and how to use them. This property of the CPU allows you to set the local time to the time zone that you want. See picture 7. Picture 7 – Local time property Protection and security: From this property, you can determine the access level and password protection for your PLC. See picture 8. Picture 8 – Protection and security property The previously mentioned properties are the most commonly configured properties with almost any PLC project you would do. There are some other properties that are less likely to be used with simple programs such as Web servers and OPC UA. The next step in the Hardware configuration of your project is configuring the IOs. IOs hardware configuration: Another important step of your project is the configuration of your IOs, which means deciding how many IO modules you need and what kind of IO modules you need. When deciding about your IOs, you should consider some key points like having some spare IO points and choosing the IO modules that fit the input sensors and output actuators inside your project. See picture 9. Picture 9 – Adding analog input module As we mentioned in our example project, we have 4 thermocouples used as analog inputs to my PLC, so I need to add an analog input module with at least 4 input channels because the selected PLC only has 2 analog input channels. Another thing is that the thermocouple is a special type of analog input that requires a dedicated input module. That is why we chose the AI 8xTC module, which has 8 input channels dedicated to being used with thermocouples; we choose the 8-channel module and the 4 to have spare channels for future use in case we need to expand our project. If you go to the properties of the AI 8xTC module you will see that you can configure each input channel individually, you can choose the type of thermocouple, scale of measurement, and other properties. See picture 10. Picture 10 – Configuring input module Next, you will need to define your IOs tags and assign each input or output you have to a proper IO point in your PLC or in the IO modules. See picture 11. Picture 11 – Assign input tags Then you continue to assign the rest of the inputs and outputs tags, see pictures 12 and 13. Picture 12 – Assign input tags for the PLC Picture 13 – Assign output tags to your project HMI Configuration Your PLC project will probably need an HMI, after selecting your HMI there are different configurations you can make. In this article, we will only show how to configure the communication between the HMI and the PLC. As you see from the previous picture, you select an HMI by adding a new device and then select an HMI. See picture 14. Picture 14 – Selecting an HMI There are different ways to set the communication between the HMI and the PLC, but the easiest way is through the network view page. See picture 15. Picture 15 – Setting HMI connection Inside the network view page, you can set the connection between the HMI and the PLC by simply clicking on the small green square representing Profinet from the HMI and dragging it to the PLC. TIA Portal will then draw a green line between the two modules and it will automatically give the HMI an IP address to set the communication between them. Conclusion Hardware configuration is a very critical step of any PLC project. The proper hardware configuration of your PLC will ensure that the needed functionalities of the project are met. Hardware configurations include selecting IO modules, enabling or disabling certain CPU properties, and configuring different devices like HMI with your PLC.

This article is about the PLC programming troubleshooting method. In industrial PLCs where thousands of inputs and outputs are used, and we know how lengthy PLC programs are, depends on the application or plant usage. Troubleshoot Siemens PLC Programs Some times, People may change the logic parameters unknowingly and it may lead to a fault. Even some faults are created during the logic design stage due to the complexity of the design. The siemens plc software has different handy tools available in it to troubleshoot the faults generated in the programs. Faults can be like overlapping of addressing, multiple same output instances, memory bit address overlapping, many times a single program is used to work over and over, etc. To find out such problems, there are four types of windows available in the siemens software which will help us to troubleshoot the issues. They are: Cross Reference Call Structure Assignment List Dependency Structure Let discuss how to use them in our program for troubleshooting and where to find them in the software. Cross Reference Cross-reference is used to find all the digital & analog inputs and outputs used in the logics. It will help us to know about the number of times the I/O’s are used in the program and also take users directly to the specific location of the I/O’s in the logic pages. Here is an example of one of the programs, in which you can see how the cross-reference table looks like. It contains all the information like addressing, the language of the program, used inputs and outputs, etc. Call Structure When you want to know which block is used in programming then call structure is used. This is a reversal of cross-reference function in which we get to know that how many times SFC, FB block are used in OB (Organization Block) and here we get to know that how many times OB used in SFC and FBs. Assignment List The assignment list is a very useful feature when it comes to knowing that how many inputs, outputs, timers and counters used in our application and how many of them are still remaining, so we can use them in future logics. Dependency Structure Dependency structure is used to show where each and every block used within the programming. But in step 7 it won’t take you directly on location however in TIA PORTAL it will take you to the location where the program is written. NOTE: To open these windows in step 7, use the info as shown in Drawing. After clicking on display you have the options. In TIA PORTAL, follow the below step shown in the drawing.

In a previous article, we discussed what is a function block FB, how it works in a PLC program, and how to create and use one. In this article, we will talk about data block instances of different function block types in Siemens Tia Portal and when to use each type. Contents: What is a function block FB? Different options of data instances. Single Instance. Parameter Instance. Multi-instance. What is a Function Block? A function block or an FB is simply a block that contains code logic. You use this FB to achieve specific functionality through the pieces of code written inside. When calling a function block into your code you will be asked to assign a data block also called data instance to be associated with this FB, to save the values of the FB parameters. Not all parameters inside an FB are saved in the data instance, but we will get to that later. When calling a function block, you have 3 different options for associating a data block instance with this function call. These different options will depend on where you are calling your FB. So, in a nutshell. A function block FB is basically a function FC with a dedicated data block DB, this data block is used to store the values of the function block parameters. Different Options for Data Instances We have 3 different options for a data instance of a function block, these options are: Single Instance. Parameter Instance. Multi-Instance. The three different call data instances come from the 3 different call methods: You can call a function block FB inside the main OB1 which will give you the option of: Single instance. You can call the function block FB inside a function FC, which will give you two options Single instance Parameter instance You can call the function block inside another function block, which will give you the three available options for creating a data instance Single instance Parameter instance Multiple instances Single Data Instance First, let’s start by creating a function block FB, as we mentioned before, we create a function block by clicking add a new block and choosing the type of block we want. See picture 1. Picture 1 – Creating a function block FB Now, let’s call the ReusableFB that we created inside our main OB1. See picture 2. Picture 2 – Calling the FB inside the main OB1 As you see from the previous picture, when calling an FB inside the main OB1 you will be asked to assign a data instance to be associated with this FB call. In this case, there will be only one option, which is the single instance. After choosing a single instance option, a data block will be created and associated with the FB call. See picture 3. Picture 3 – Single instance created The created single instance will be used to store the values of some of the FB parameters. Like the inputs, outputs, In Out, and static parameters. Other parameters of the FB will not be stored, like temp and constants. See pictures 4 and 5. Picture 4 – Data is saved inside the data instance Picture 5 – Data saved from the FB into the data instance. Now, let’s create a simple logic inside the FB to help us understand the data instances better. This logic will add a constant value of 15 to a static variable and then move the result to the output. See picture 6. Picture 6 – Create a simple logic Now, go back to the main OB1 and notice how your FB call is now. See picture 7. Picture 7 – Update the FB call after each change Any change you make to the logic inside the FB, will result in the need for updating the Function block call, so that the changes you made can be applied. You can update the block call by right click the FB call and pressing the update block call option or by recompiling your PLC code. See picture 8. Picture 8 – Updating the FB call After updating the block call, the changes you made in the FB code will be applied and employed in the block call. As you see in picture 9. The FB now expects an input signal of type bool to be provided and the FB will give an output of type int. Picture 9 – Inputs and outputs are now associated with the FB call Let’s simulate our code and see how the PLC will behave. See the next animation showing a simple simulation of the PLC logic so far. As you see from the animation, whenever the start signal is TRUE, the function will be executed and the output keeps changing. And once the start signal is no longer available the Output will remain at the last value recorded. The use of the data instance here is that the values of the static variable and the output variable are saved inside the single instance, so when the start signal comes back again, the function will continue from the last recorded values. Very Important Note You should never use the same single instance for two different calls of an FB. See the next animation. As you see from the animation, we have two different FB calls, but both calls are associated with the same single instance, which is why even when the start2 signal was FALSE, the Output2 value was changing with Output1. As you would expect the change in the data instance of the 1st call will also be affected in the 2nd call because they have the same memory block. See picture 10. Picture 10 – Never use the same data instance with different FB calls If you used the same data instance with different FB calls, then your function block is no longer reusable. Even if the inputs/outputs parameters are different for each different FB call. As you saw from the last video (animation) both calls had the same results even though 2nd call doesn’t even have an enable input signal. Another very important note We said before that if you call your FB from a higher-level FC, you will have two options for the associated data instance; these options are the single instance and the parameter instance. See picture 11. Picture 11 – Using a single instance with an FB called from an FC If that happened, and you will call an FB inside an FC, You should never use a single instance for your FBs. To know why that is. See picture 12 Picture 12 – Calling the higher-level FC more than once As you see from picture 12, when you call the higher-level FC in your logic more than one time, you will not be asked to assign a data block, because FCs don’t need one. But you know that there is a called FB inside the FC, this FB has a single instance associated with it. So now the 3 FC calls have the same data instance for the FB call. So, your function FC is no longer reusable. What to do? The best option for when you need to call an FB inside an FC is to use the parameter instance. Parameter Instance As we said before, if you called an FB inside an FC you shouldn’t choose the single instance but rather the parameter instance is better for your reusability purposes. A parameter instance will save the data instance of the FB called into the In Out area of the FC block interface. Allowing you to enter a new data instance for each FC call. See pictures 13 and 14. Picture 13 – Assign parameter instance when calling an FB inside an FC Picture 14 – Each FC call will need a new data instance As you see from the previous picture, whenever you call the FC inside your program, it will ask for a data instance for the reusable FB inside the FC. But, using this way you will have to create the data instance yourself. See picture 15. Picture 15 – Create a new data instance To create a new data instance, you do the same as creating an FC or an FB, but this time you choose the DB option. And make sure that you select the DB type to be the same as the FB called. Now, your FC can be reused as many times as you want, you just have to create an instance for each call. See picture 16. Picture 16 – Assign the DB to the FC call Multi-instance Database A multi-instance DB simply means that the DB of the called FB will be stored inside the DB of the higher-level calling FB. This option is only available if you call an FB from another FB. Let’s create another FB to use it as a higher-level FB. After creating this HigherLevelFB, call it from the main OB1, and off-course the only option of calling will be a single instance as shown before. See picture17. Picture 17 – Call the HigherLevelFB from the main OB1 Now, call the ReusableFB from the HigherLevelFB. And choose the Multi-instance option. See picture 18. Picture 18 – Assign multi-instance DB When you choose the Multi-instance option, the created DB will be stored inside the static parameters of the calling FB. See picture 19. Picture 19 – Instances are saved inside static parameters You can call the ReusableFB many times, each time you call it the multi-instance will be stored inside the static parameter. See picture 20. Picture 20 – Calling the ReusableFB many times As you can see the data instance of the lower-level FB will be saved inside the data instance of the higher-level FB. It is best for better program structure and easy-to-read logic. Conclusion Creating function blocks inside your code will require associating a data block with each FB call you to make in your logic. This data block or also called data instance has different options depending on the type of block that is calling your FB. Be careful when choosing the type of data instance, as some options may not be suitable for your case as we showed before. And sometimes this can lead to problems in your logic and your function can no longer be reusable. Using multi-instance can help better organize your program structure, as all called FBs will store their DBs inside the main calling FB.

In the previous article, we talked about data blocks, and we discussed the two different types of data blocks, the global data block and the data instances of function blocks FBs. In this article, we are going to discuss what is meant by optimized data block access and standard data block access in Siemens Tia Portal. Contents: What are optimized and standard data blocks? Simple program example. What are Standard DBs? What is the offset? What are optimized DBs? Advantages of using optimized DBs. Conclusions. What is optimized and standard data block access? First, these are not new types of data blocks; we said we only have two different types, the global DB and the instance DB. Optimized data block access is a feature for the data block. You can activate or disable this feature from the properties of the data block you have created. The optimized data block feature is only available for S7-1200 and S7-1500 PLCs not for s7-300 or s7-400 The standard setting for data blocks when working with S7-1200 or S7-1500 PLCs is that they are optimized, if you want a standard data block you will have to set that yourself. So, what is optimized and standard blocks? To understand the difference, we will make a simple program and try to show how an optimized block differs from a standard block. Simple Program Example: In this example we will not create any PLC logic or code any instructions, we will just create 2 global data blocks, DB1 will be called OptimizedDB and DB2 will be called StandardDB. Inside both data blocks, we will declare 4 variables of data types Bool, Int, Real, and Word respectively. See picture 1. Picture 1 – Create two global DBs The first thing you will notice is that both data blocks are exactly the same, that is because as we said the default setting when creating a data block is that it will be optimized, so we need to change the setting of DB2 to make it a standard block, to see if something will change. We do that from the properties of that DB2. You access the properties of DB2 by right click the data block and press properties. See picture 2. Picture 2 – Change DB2 to standard block access Once you de-select the optimized block access attributes that you see in picture 2 and press OK, a warning message will pop up, see picture 3. Picture 3 – Change block access Pop-up Once you press OK, your DB2 will have been converted to standard block access. See picture 4. To see what difference did that make. Picture 4 – DB2 is now a standard block What we can directly see is that DB1 and DB2 are not the same anymore. The standard block access option represented in DB2 has an additional column called offset. In front of each variable in the offset box, there is a … written, this will change once you compile your program. Let’s compile and see what happens, see picture 5. Picture 5 – Compile your program to reload the offset Now, the offset is filled in with as you can see 0.0, 2.0, 4.0, and 8.0 respectively. So, what is that offset? What does it mean? We will get to that later, but now, Let’s create another STANDARD block and declare the same 4 variables, but this time we will change the order of the variable data types, see picture 6. Picture 6 – Create another standard block DB3 You see from the last picture the offset of DB2 and DB3 is different, why the offset values are different when we changed the order of data types? They are the same data types but in different order. Let’s create another standard DB, and declare the same 4 variables but again in a different order. Compile your PLC code and now compare the offset of the 3 DBs. See picture 7. Picture 7 – Three different DBs with three different offsets The same thing happened again. What are Standard DBs? What is the offset? Data blocks with standard access have a fixed structure. When you declare a variable inside a standard DB this variable will be assigned a fixed address within this DB. The address of this variable is shown in the “Offset” column. So, what we were seeing inside the offset in previous pictures was the address assigned for each variable. Because the structure of standard DBs is fixed, you can only work inside the DBs with fixed memory capacity, this is 16 bits area or 2 bytes. This is the reason for the different addressing of the same variables when we changed the order of declaration. For more explanation see picture 8. Picture 8 – Simple representation of DB2 Picture 8 shows a simple representation of the standard data block DB2. As we said before a standard DB has fixed memory blocks of 16 bits, so, when we declare Variable_1 to be of data type BOOL, this Variable will occupy the whole 16 bits even though it only needs a 1-bit memory. That is why you see the rest of the area marked red because it is not used but can no longer be used. So it is a lost memory. With Variable_2 the data type INT needs 16 bits, so it is using 2 whole bytes. Same with Variable_4 which is of data type WORD. With Variable_3 we occupied 4 bytes because it is of data type REAL. This is why the offset for DB2 is 0.0, 2.0, 4.0, and 8.0 respectively. The same concept is executed for DB3 and DB4. But because the data type order of the variables is different the memory representation will be different and hence the offset will be different. See pictures 9 and 10 for DB3 and DB4. See if you can understand the representation based on the previous explanation. Picture 9 – Memory representation of DB3 Picture 10 – Memory representation of DB4 So, when you work with a standard DB you have to be careful when declaring your variables, knowing that there would be a loss of memory each time you define a new BOOL variable. If you declare the new variable at the end of your DB list, the offset will extend to include your new variable. But if you declare the new variable between your old or at the start of the DB something else will happen. See picture 11. Picture 11 – Declare a new variable The first thing you will notice is that your offset is now lost, and you have to compile your code to re-establish the new offset. See picture 12. Picture 12 – Re-establish your offset by recompiling your code Did you notice how the addressing of the Variables (OFFSET) has now changed? For example, the offset of the REAL tag was 2.0 but after we added the new TestVariable the addressing of the same REAL tag (OFFSET) is now 4.0, see picture 13. Picture 13 – Offset change after adding TestVariable So, when adding a new variable the addressing of all old variables was changed. That means any instruction in your program that need to write of read the value of a certain variable will now be looking at the assigned address in the instruction but now the address has different data than expected. So simply put, your whole logic is now messed up. That will lead to a lot of trouble. Not to mention now you have extra lost memory after you added the new variable. See picture 14. Picture 14 – Add a MOVE instruction Let’s add a MOVE instruction to move a value of 1 into the Variable_2 tag. See how the address of the MOVE output is %DB2.DBW2. Now, let’s add a new variable of type INT to DB2. See picture 15. Picture 15 – Add new INT variable When you add the new variable, the offset is lost and the PLC no longer knows where the destination of the OUT1 of the MOVE instruction is. We need to compile the program to reload the new offset. See picture 16. Picture 16 – New address of OUT1 Do you see how the OUT1 address is now different? It is now %DB2.DBW4 instead of %DB2.DBW2. This is a very big disadvantage of using standard data blocks. What are Optimized DBs? The difference between optimized data blocks and standard data blocks is that variables inside an optimized data block are not assigned to a fixed address, but rather a symbolic name is given for the variables, plus the structure of the data block is not fixed as the standard data blocks, so there is no memory loss and no change in the addresses when declaring new tags. See picture 17. Picture 17 – Declaring new tag in optimized blocks So, declaring new tags in optimized data blocks will not affect the rest of the tags, as they are defined by symbolic names rather than absolute addressing. An optimized data block will not allow you to use addresses when working with the tags defined inside of it. See picture 18. Picture 18 – Absolute addressing with optimized blocks As you see in the last picture, absolute addressing is not allowed with an optimized data block and only symbolic names are allowed. See picture 19. Picture 19 – Using symbolic names with optimized DBs Advantages of Data blocks with Optimized Access Data blocks with optimized access have no fixed defined structure. The data elements (tags) are assigned only a symbolic name and no fixed address within the block is used. The elements are saved automatically in the available memory area of the block so that there are no gaps in the memory. This makes for optimal use of the memory capacity and avoids lost memory compared to standard DBs. This provides the following advantages: You can create data blocks with any structure without paying attention to the physical arrangement of the individual tags. Quick access to the optimized data is always available because the data storage is optimized and managed by the system. Access errors, as with indirect addressing or from the HMI, for example, are not possible. Because there are now addresses, just unique symbolic names for each tag. You can define specific individual tags as retentive. In standard DBs you can only define the whole block as retentive. Conclusion Optimized data blocks have a lot of advantages compared to standard DBs. Using symbolic names helps avoid any address changes of tags when adding new variables to your block. With optimized blocks, no memory area is lost. Opposite of what happens when using standard DBs.

In previous articles we discussed different types of Blocks in SIEMENS TIA Portal, we talked about function blocks FBs, functions FCs, and data blocks DBs. In this article we will take about another type of block in SIEMENS PLCs, these are the organization blocks, and in this article, we will discuss the most important organization block of them all, which is the Main Organization Block or OB1. Contents: What are organization blocks? Different types of OBs. What is OB1? Cycle time monitoring. Simple program example. Conclusion. What is an Organization Block (OB)? Organization blocks, you can think of them as functions FCs or function blocks FBs. But the difference is, you don’t call them, the operating system of the PLC calls these organization blocks, whether the operating system calls the OB cyclically as OB1 or whether it gets called when a certain event occurs, either way, the operating system takes care of it. You only need to create the block and add whatever logic you want inside the block. Sometimes you don’t even need to add any code inside the OB, just creating the OB itself can provide many benefits, which we will see when discussing some of those OBs. Organization blocks are the interface between the PLC operating system and the user program. Any PLC will have two different programs, the runtime program which is the operating system of the PLC, and the user program which is the logic or code that the PLC programmer will write to control a certain process. This two different software need to talk with each other, and the organization blocks OBs are how that is done. Organization blocks OBs are used to perform a lot of tasks, some of which are listed below: Startup characteristics of the automation system Cyclic program processing Interrupt-driven program execution Error handling. Different Types of Organization Blocks As organization blocks are basically the tools of the operating system to perform a lot of tasks. Different tasks require different OB, and that is why you have many different OBs inside a PLC, how many different OBs will depend on the type of PLC you are using, but here are some of the most common OBs you can find in almost all of SIEMENS PLC: Main Cyclic OB1. Time interrupts OBs. Time of day OBs. Software errors OBs. Hardware errors OBs Many more Organization blocks are available for use with your logic. See picture 1. Picture 1 – Different Organization Blocks available in TIA Portal In this article, we will discuss the most important organization block of them all, which is the Main Cyclic Interrupt OB1. Main Cyclic Interrupt OB1 The main cyclic OB1 is the organization block which is responsible for cyclically executing your logic by the PLC. Whenever you create a new project and add a PLC, the Main OB1 will be automatically created by the software. These are the minimum needed blocks for a PLC code. See picture 2. Picture 2 – Main OB1 is created automatically Inside this Main OB1, you can either write your whole PLC program if it is a small project. If your project is quite large, then you probably have some functions FCs of function blocks FBs that you need to execute. In that case, you will use the Main OB1 to call them. Off course, you don’t have to call every FC or FB by the OB1, but if your OB1 is not the first block of your nesting calls, then it will not be executed. See picture 3. 146- Picture 3 – Calling your blocks by OB1 The essential basis of your PLC code is the cyclic behavior, meaning you need your code to be executed continuously. When the processing of your logic has been completed, the operating system starts processing it again. That is done through the use of the main OB1, you put and call all of your logic and code inside this OB1 and the operating system will make sure to continuously execute it. You should know that, even if you can’t create an OB1 block as it is automatically created when adding a new PLC, you can create more than one cyclic interrupt block. OB1 is a cyclic interrupt, that the operating system will automatically and continuously call and executed whatever logic is inside. However, for large PLC projects where you have so many functions and function blocks in your PLC logic, you can use more than one cyclic interrupt OB to better structure your code to make it easy to read and follow. In that case, you would create another cyclic interrupt, see picture 4. Picture 4 – Creating more than one cyclic OB When you have created several program cycle OBs, these are called one after the other in the order of their OB numbers. The program cycle OB with the lowest OB number is called first. See picture 5. Picture 5 – Program cycle with more than one cyclic OB After the cyclic program is complete, the operating system updates the process images as follows: It writes the values from the process image output to the output modules. It reads the inputs at the input modules and transfers these to the process image input. The previous two steps plus the execution of the PLC program are called a scan cycle. See picture 6. Picture 6 – Scan cycle of a Siemens PLC Cycle Time Monitoring Cycle time refers to the runtime of the cyclic program, including the runtime of all nested program parts like FCs, FBs, and higher-priority OBs. If you have created several program cycle OBs, each program cycle OB contributes to the cycle time. The operating system monitors whether the cycle time remains smaller than the configured maximum cycle time. If it exceeds the maximum cycle time, PLC will either go to STOP mode or call OB80 depending on your programming. Apart from monitoring the maximum cycle time, it is also possible to guarantee a minimum cycle time. To do this, the operating system delays the start of a new cycle until the minimum cycle time has been reached. You can configure the minimum and maximum cycle time in the configuration properties of your PLC. See picture 7. Picture 7 – Configure the minimum and maximum cycle time Simple Program Example in PLC Picture 8 – PLC Program Example To better understand the PLC program cycle and OB1 execution, let’s create a simple program. This program will use an add instruction that will accumulate a value of 1 into a memory area each 1 scan cycle. See the following simulation. As you see from the animation, the add instruction is being executed very fast; this is how fast the scan cycle is. It will depend on how powerful your PLC is. But mainly the scan cycle is in the range of milliseconds. Conclusion Organization blocks are the interface between the PLC operating system and your control program. Main Cyclic OB1 is cyclically executed by the operating system. You will execute your logic by including it inside one or more Cyclic OBs. The scan cycle time is the time used to execute your logic 1 time.

In a previous article, we discussed what an organization block is, and we talked about one very important organization block, which is the main OB1. In this article, we will continue discussing the different OBs and this time we are talking about the time of day interrupt organization blocks or OB10. Contents: What is time of day Interrupt OB10? How to create and use OB10? Simple program example. Important Rules for the time of day interrupts. Conclusions. What is a Time of Day Interrupt (OB10)? As the name suggests, a time of day interrupt is an organization block that will interrupt the execution of the main cycle of your PLC program at a certain time of the day. This interrupt time (date and time) can be specified to occur once at a specified time or to occur periodically at specified time intervals, for example, every minute, hour, day, week, and some other options. You can have more than one time-of-day interrupt in the same program, they don’t have to have the same logic or code, each one can have its own functionality and also each one can be configured separately to occur at a specified time. How to Create and Use OB10? To create a time of day interrupt you follow the same steps you would do if you need to add any new block into your logic. See picture 1. Picture 1 – Add a time of day interrupt Press the Add new block option in the project tree on the left, choose organization block, and then choose a time of day interrupt as shown in the previous picture. Now you can open the OB10 and add whatever PLC logic you want to execute when this block is called, by called we mean that the interrupt event or time has occurred and so the operating system will interrupt the main cycle and execute the OB10. We will write a very simple code into the OB10 to help us better understand how this OB10 block works. In this logic, we used add instruction to add a value of 1 to a memory area that we called TimeOfDayInterruptCounter and then put the result of the summation back in the same area. That way we can have a counter for the execution of the OB10. Each time the OB10 will be called and executed, the value of TimeOfDayInterruptCounter will increase by 1. See picture 2. Picture 2 – Add your logic to the OB10 Now that we have created the OB10 and written some logic inside, we need to configure the set time of the OB10 and how many times we want it to interrupt our main cycle. To configure the time and interval setting of the OB10 we need to go to the properties page of the OB10. See picture 3. Picture 3 – Properties of OB10 In the properties of the OB10, you will find a lot of settings and attributes that you can configure. What we need now is the time of day interrupt page so we can set up when the OB10 will be called and how many times. See picture 4. Picture 4 – Time of day interrupt setting As you see from the last picture, you can set the execution of OB10, the start date, and the time of day at which the OB10 should be executed. For the sake of simulation, we made the execution interval to be every minute so that every minute the OB10 will be called and executed. That means starting from the date of 3/23/2023 and time 09:25 AM the value of TimeOfDayInterruptCounter will increase by 1 every minute. You have the option of setting the time according to the PLC system time or local time as you see from the last picture. In a previous article, we talked about the system and local time of the PLC, what each time mean, and how to configure and use them. As we said before the local time is the time you see now on your PC. So it is the actual time of the region where the PLC will be used. You have to configure the local time for the PLC, depending on where it will be used. See picture 5. Picture 5 – Setting the local time for the PLC Simple PLC Program Example We added a time of day interrupt OB10 to our PLC program and we have set it so it will be executed every minute. We also have configured the local time of the PLC. We created a simple logic of an ADD instruction to accumulate the value of the TimeOfDayInterruptCounter by 1 each time the OB10 is executed. We will add another instruction, but in the main OB1, this instruction is RD_LOC_T or read local time, so we can see how the local time is progressing and compare it with the execution of OB10. See picture 6. Picture 6 – Simple program example Compile your PLC program and start a new simulation. Notice that we will set the time of day interrupt occurrence so that the OB10 can be called and executed while we are simulation the PLC logic. See the following simulation. As you see from the animation, the value of TimeOfDayInterruptCounter is zero at the start and then it will be increased by 1 every minute starting from time 09:25 AM indicating that the OB10 is being executed every minute. Important Rules for the Time of Day Interrupts If you set a time interrupt in such a way that the corresponding OB is to be processed once, the start time must not be in the past (relative to the real-time clock of the CPU). If you set a time interrupt in such a way that the corresponding OB is to be processed periodically, but the start time is in the past, then the time interrupt OB is processed the next time it is due according to the current time. The date of periodic time interrupts must correspond to a real date. For example, the monthly repetition of a time interrupt OB with a start date of 1/31 is therefore not possible. In this case, an OB is only started in the months that have 31 days. A time interrupt activated during startup is not executed until the startup has been completed. A startup deletes all time interrupts that were set and activated by an instruction in the user program. Conclusion OB10 is an organization block that can be configured to interrupt the cycle of your program at a certain day and time. This interrupt can either occur once or periodically every certain amount of time. No specific reason why would you need an OB10, as it depends on your process and your logic. And yes, you can achieve the same functionality using your personal code, but it is an available and easy-to-use built-in function. And you know how to use it.

In previous articles, we discussed what an organization block is, and we talked about the main cyclic interrupt OB1 and the time of day interrupt OB10. In this article, we will continue discussing the different OBs, and this time we are talking about the Time Delay Interrupt organization block or OB20. Contents: What is OB20? How to call OB20? Parameters of SRT_DINT instruction. Example Program. Conclusion. What is Time Delay Interrupt (OB20)? OB20 is an organization block that is called and executed by the operating system, but we have to tell the operating system when to call this OB20. The operating system gets the information from the user PLC program to call this OB20, it will wait for the delay time configured then it will call and execute whatever logic is inside the OB20. We create an OB20 block from Add a new block in the project tree. See picture 1. Picture 1 – Create a new OB20 block Now that I have created a time delay interrupt, when will it be executed? And how to configure the time delay of the block execution? Again, OB20 is an organization block, which means you don’t call the block to be executed, but you tell the operating system when it can call it and execute whatever functionality is written inside. How to Tell the Operating System to Call the OB20? To tell the operating system that we want to call the OB20, we use the SRT_DINT or start time delay interrupt, see picture 2. Picture 2 – Start time delay instruction Parameters of SRT_DINT instruction As you see from the last picture, you can use the SRT_DINT instruction to call the OB20. but you need to configure some parameters, for the instruction to work. EN: the instruction will not be executed until a negative edge signal is presented at the EN input. That means you have to assign a condition of the set of conditions to enable signal and the instruction will only work when this condition is true then false again. OB_NR: you assign the number of the delay interrupt that you need to call, in our case 20 as we created OB20, but we can create more than one delay interrupt and then we will have to call each one with a separate SRT_DINT instruction. DTIME: that is the delay time you want to wait before executing the OB20, we will set this time to 5 seconds for the sake of simulation. SIGN: Identifier that appears when the time-delay interrupt OB is called in the start event information of the OB. Example PLC Program To better understand the OB20, we will create a simple logic to see how an OB20 can be called and executed. We will build this PLC example on the previous logic we made for the OB1 and OB10 in previous articles. Inside the OB20 we will create a logic that counts how many OB1 cycles have been called and executed within the 5 seconds delay time that we have configured for the OB20. See picture 3. Picture 3 – Logic inside OB20 In the last picture, you see that we used MOVE instruction to push information on cycle counts at the start of the OB20 call and after it has been executed. See picture 4 for the rest of the logic. Picture 4 – Calculate how many cycles count inside 5 sec After that, we will subtract the two values of cycle counts to get how many cycles have been executed within the five seconds delay. Now that we have created the logic we want, how can we call the OB20? As explained before we have to use the SRT_DINT instruction. We will use this instruction inside the OB10 which we have configured before to be executed every minute. That means the OB20 will also be called and executed every minute but with a delay time of 5 seconds. In the previous article we built a logic that calls how many times the OB1 is being called and executed, we also built another logic that will call the OB10 every minute. In this example, we will use the call of the OB10 to call the OB20. See picture 5. Picture 5 – Calling the OB20 through OB10 We said before that the SRT_DINT needs a negative edge signal at the EN for the call to start. That is why we used the TimeOfDayInterruptEnabled signal which we know it will be true when OB10 is executed and then go back to false giving us the edge signal we need. Now that all PLC logic is complete, let’s compile and run a new simulation. See the following simulation of our project. You see in the animation at first the values of cycle counts are zeros but when the OB10 is called and the TimeOfDayInterruptEnabled is true logic will wait 5 seconds then the count values will be updated with cycle counts. Conclusion OB20 is an organization block called and executed by the operating system. We can tell the operating system to call the OB20 with the SRT_DINT instruction.

In previous articles, we discussed different types of organization blocks, like the main OB1 which is the main cyclic program block, in this article we will take about another cyclic organization block. The OB30 or cyclic interrupt OB. Contents: What is cyclic interrupt OB30? What is the main OB1 cycle? Why do I need OB30? How to configure cyclic interrupts? What if I have more than one cyclic Interrupt? Conclusion. What is Cyclic Interrupt OB30? A cyclic interrupt OB30 is an organization block that gets called and executed at specified and exact time intervals, unlike the main cyclic OB1 which is continuously called and executed the cyclic interrupt will be called at time intervals which you should configure when creating a cyclic interrupt OB. For example, if I created an OB30 with a time interval _also called cycle time_ of 20ms, that means the operating system will interrupt the main cycle OB1 and calls the OB30 each 20ms. You have to make sure that the runtime of a cyclic interrupt OB must be smaller than its time interval. Otherwise, it could still happen that the next call of the OB30 will arrive while this call of the OB30 is still being executed. In this case, the operating system generates a time error that might lead to PLC going to STOP mode. What is the Main Cycle OB1? The main cyclic OB1 is the organization block which is responsible for cyclically executing your logic by the PLC. Whenever you create a new project and add a PLC, the Main OB1 will be automatically created by the software. The essential basis of your PLC code is the cyclic behavior, meaning you need your code to be executed continuously. When the processing of your logic has been completed, the operating system starts processing it again. That is done through the use of the main OB1, you put and call all of your logic and code inside this OB1 and the operating system will make sure to continuously execute it. Main OB1 cycle time refers to the runtime of the cyclic program, including the runtime of all nested program parts like FCs, FBs, and higher-priority OBs. If you have created several program cycle OBs, each program cycle OB contributes to the cycle time. The operating system monitors whether the cycle time remains smaller than the configured maximum cycle time. If it exceeds the maximum cycle time, PLC will either go to STOP mode or call OB80 depending on your programming. Why do I need OB30? Someone could argue that I can put whatever functionality inside the OB30 in the main OB1 and try to get away with it depending on the very fast performance of most PLCs nowadays. This can be OK sometimes, but not every time. Depending on the performance of your PLC, the main cycle time could be something between 1 to 150ms; it can be different but this is the standard configuration, this cycle time depends on so many factors, like the size of your PLC program, and interrupts inside your logic and other factors that will most likely make the run time of your cycle not stable. Now, if you need to do certain functionality exactly each 10ms, not 9ms and not 11ms. Now you can’t depend on the main OB1, as the result might not be as desired. In this case, you use the cyclic interrupt OB30, you configure it to the 10ms you want and the operating system will make sure to call and execute this function every 10ms exactly. That is why it is called interrupt; because it will interrupt the execution of the main OB1 to call and execute your OB30. Examples of Functionality that Needs OB30 PID controller processing. Safety circuits monitoring. Monitoring communication between machines. All previous examples have the need to continuously monitor and check your parameters at certain times, as they relate to real physical quantities or to machine safety. The execution of such functions shouldn’t be delayed as they affect the safety and continuity of your process. How to Configure Cyclic Interrupts? When you create a cyclic interrupt, there are some parameters you need to configure. See picture 1 for adding a new OB30. Picture 1 – Add new cyclic interrupt OB30 When creating a cyclic interrupt, you can find many parameters you can set in the properties of the block see picture 2. Picture 2 – Properties of OB30 The most important parameters that you need to consider are as follows: Cycle time Use the parameter “Cycle time” to set the period of time between two calls of the cyclic interrupt OB. It is an integer multiple of 1 µs. Phase offset Here, you set the time period by which the start times are shifted as compared to the multiple of the cycle time. See picture 3 for cycle time and phase offset configuration. Picture 3 – Setting the cycle time and offset of OB30 Priority of the cyclic interrupt OB This is another important parameter you have to consider when configuring a cyclic interrupt, as you might have more than one cyclic block, if in case two different OBs need to be called at the same time, the operating system will call and execute the block with a higher priority number. You should know that the PLC main program cycle OB1 has priority number 1 which is the lowest priority level a block can have. That is why OB1 can be interrupted by any other block call. See picture 4. Picture 4 – Setting the priority of OB30 What if I have more than one Cyclic Interrupt? It is not uncommon that you would have more than one cyclic interrupt in your logic. If you have two PID controllers in your PLC logic then you might need two cyclic interrupts to handle each PID. In that case, you need to make sure that the calling and execution of different cyclic interrupts will not be overlapped. For example, if you have OB30 with an interval cycle time of 5ms and OB31 with a cycle interval of 10ms, that means the second call of the OB30 will also be the time for calling OB31. This might lead to logic errors, even if you set the priority of one of them to be higher than the other, it will mess up your cycle time for the lower priority block. See picture 5. Picture 5 – Overlapping of calling different cyclic interrupts In that case, a phase offset may be advisable when you are using multiple cyclic interrupt OBs. If their cycle times have common multiples, you can use a phase offset to prevent simultaneous start times. See picture 6. Picture 6 – Offset between different OB calls So, to avoid this overlapping, we will set the offset time of OB31 to be 1 ms. That means the counting for the OB31 time interval will be offset by 1ms than the starting time of OB30. See picture 7. Picture 7 – Offset setting of OB31 Conclusion Cyclic interrupts are very useful for time-critical tasks that shouldn’t face any delays. You can have more than one cyclic interrupt in your logic. Use the offset setting of the cyclic interrupts to avoid simultaneous start times. Use priority setting to control the order of executing different cyclic interrupts.

In previous articles we started discussing different Organization blocks of TIA Portal PLCs, we talked about what OBs are, and we discussed some of the OBs like OB1- Main cyclic, OB10, and OB20 the time of day delay and time delay interrupts respectively. In this article, we will talk about the OB100 or the startup organization block in Siemens Tia Portal. Contents: What is OB100? Why need OB100? Important notes during startup. Simple program example. What is Start-up Organization Block (OB100)? OB100 or the startup OB is an organization block that is called and executed by the operating system once at the startup of the PLC, meaning once each transition from STOP to RUN mode. The main cycle OB1 will not be called and executed until all startup functions inside OB100 are executed. You can have more than one start-up OB in your PLC logic if that happens then the operating system will call and execute all of them one by one starting from a lower OB number to a higher number. I.e. if you have OB100 and OB123, then OB100 will be called and executed first then OB123. After the OB100 is executed the operating system will read the input modules into the PII and starts the main cycle program OB1. Why need OB100? You use OB100 for a lot of tasks that you might want or need to perform before you start your cyclic logic, for these reasons are: Initialize variables. Reset system modules. Recalibrate sensors/actuators. Check for alarms and safety conditions before starting your process. Even if you haven’t created a startup OB for your logic, the operating system still has many tasks that it needs to execute before starting your main logic, some of these tasks are: Clear non-retentive memories Clear the PIQ Call and execute startup OBs, if any. Update PII Enable outputs after changing to RUN mode. Did you notice that the last task of a startup routine is to enable the outputs? That is why the first step of executing the main cycle program OB1 is to write the PIQ into the output module. Important Notes during Start-Up Note the following points regarding the “STARTUP” mode: The outputs on the modules are disabled. The process image is initialized. The process image is not updated. In order to read the current state from inputs during “STARTUP”, you can access inputs via direct I/O access. In order to initialize outputs during STARTUP, values can be written via the process image or via direct I/O access. The values are output at the outputs during the transition to the “RUN” mode. The non-retentive bit memories, timers, and counters are initialized. The non-retentive tags in data blocks are initialized. During startup, no cycle time monitoring is running yet. Simple Program Example In this example, we will add a start-up OB100 to our PLC logic and see how many times the OB100 is executed. See picture 1 for adding a new OB100. Picture 1 – Add an OB100 As you see from the last picture, you add startup organization blocks the same way we add a function of a function block. Inside the OB100 we just created we will add a simple ADD instruction, to accumulate how many times the OB100 is called and executed. See picture 2. Picture 2 – Accumulate execution times of OB100 Now, compile and run your program and see what will happen. See the following animation for a simulation of the PLC program. Animation 1 As you can see from the above animation, the OB100CycleCounter is 1 and it doesn’t change when the PLC mode transitions from STOP to RUN. Well, it does change but you don’t see this change. Each time the PLC goes into STOP mode and then to RUN mode again. The counter will be reset to zero and then to 1 again after the OB100 is executed. You can also see the main OB1 cycle counter changing, and the PLC stops and then runs again the OB1CycleCounter will start accumulating again. To see the change in the startup counter, we need to retain the value of the tag memory. See picture 3. Picture 3 – Retain the OB100CycleCounter tag memory After we retain the OB100CycleCounter tag, now run the PLC simulation again and see what will happen. See simulation animation 2. Animation 2 You see now from the above animation, that the startup counter increases each time I stop the PLC and then start it again. As the tag memory is now retained, the value will not be reset to zero, and that is why you see the value of the OB100CycleCounter accumulates. Now, I need to add extra functionality to my startup PLC logic, which is to know when the last startup of the PLC was. We will achieve that through a simple logic where I read the local time of the PLC at startup and move the date and time to a certain memory area. See picture 4. Picture 4 – Reading local time at start-up After you add your logic, compile and run the simulation again. See the PLC simulation animation 3. Animation 3 You can see from the above animation, that each time the PLC starts the startup date and time will be recorded in the memory area we assigned. So now I have the information regarding how many times my PLC started and when was the last start-up time. Conclusion Startup OBs are very important if you want to evaluate some functionality before you can run your cyclic process. You can use start-up OBs to initialize parameters, calibrate sensors and even check for safety conditions before allowing your process to run.

In this article, we continue our discussion about different types of organization blocks in Siemens PLC. This time we will take about the OB121 or the programming errors interrupt in the Tia portal. Contents: What are programming errors interrupt OB121? Examples of programming errors. What will happen if a programming error is detected? Simulating a programming error in TIA Portal. How can the OB121 be useful against programming errors? Conclusions. What are Programming Errors Interrupt (OB121)? OB121 is an organization block that will get called by the PLC’s operating system if a programming error occurs while running your logic. Note that we are not talking about a programming error that will be caught by the compiler when trying to download your logic into your PLC. See picture 1. Picture 1 – Some programming errors will get caught by the compiler As you see from the last picture, there is a programming error in my PLC logic; some operands are missing in the input and output of Network 1. But, this error was caught by the compiler before even downloading the logic into the PLC. The error in picture 1 is not the programming error type that can trigger the need to call OB121. Errors in your PLC program that can’t be found by the compiler, but still can cause troubles in your logic while PLC is running are the programming errors we mean. These errors will trigger a call to the OB121 by the operating system. Examples of Programming Errors Here are some examples of mistakes in your PLC logic that can cause programming errors: Maximum nesting depth of block calls exceeded. You have used a NULL pointer to address an operand. Unknown instruction. The addressed string has incorrect length information. Area length error when reading. Area length error when writing. Error in timer no. Access to a DB that is not loaded; the DB number is located in the permitted area. DB does not exist. These errors and many more can cause programming errors in your PLC. You can check the Help section of the TIA Portal to find out what other reasons can cause PLC programming errors. What will happen if a Programming Error is Detected? When your PLC detects a programming error, one of three events can occur. Your PLC will show an error and go to STOP mode. Your PLC will show an error but keep running your logic. Your PLC will show an error then try to solve this error. These three events will depend basically on your PLC programming. Meaning your code will decide how the operating system will behave when detecting a programming error. Simulating a programming error in TIA Portal To better understand how the PLC will behave, we will create a simple program where we cause a programming error, and then we will see what will happen. See picture 2. Picture 2 – Simple program logic The logic we created is very simple, when the InitiateProgError has been enabled the value of 126 will be moved into DB52.DBW16 area. Note that we haven’t created DB52. so, that will be our programming error. Note that this error will not be caught during compiling or downloading into the PLC. See pictures 3 and 4. Picture 3 – Error not caught by the compiler See how the block was successfully compiled, while including a programming error. Picture 4 – Block downloaded into PLC Again, the block was downloaded into PLC with a programming error. Now, let’s simulate our PLC program and see what will happen. See animation 1 for the simulation of the PLC code. Animation 1 As you see from the above animation, the PLC ERROR LED will flash red for a few seconds then the PLC will go into STOP mode. Go to PLC online diagnostics to see what happened. See picture 5. Picture 5 – Online and diagnostics of the PLC What you saw in the animation is exactly what you see in the previous picture. They can be mentioned into 3 steps: The PLC detects the programming error which is OB52 not loaded. The operating system will trigger the call for the OB121, but there is no OB121 created in our logic. When the PLC finds out that there is no OB121 created in our logic, the operating system will initiate a request STOP. And the PLC will go into STOP mode. How can the OB121 be useful against Programming Errors? Let’s add an OB121 to our PLC code and see how things will change. See picture 6. Picture 6 – Adding an OB121 After creating and adding the OB121 into our PLC logic, let’s see what will happen in the simulation. Keep in mind that we haven’t written any PLC logic inside the OB121. See animation 2. Animation 2 As you see from animation 2, when InitiateProgError is triggered, the PLC ERROR led will flash red but the PLC will keep running. Meaning that the PLC will not go into STOP mode. Let’s check the online diagnostics to see what actually happened. See picture 7. Picture 7 – Error didn’t cause PLC stop You see from the picture that the PLC detects the error but doesn’t go into STOP mode. It will skip this error, continue the cycle and start all over again from the beginning. When it arrives at the error again, it will detect the error again, giving an alarm in the diagnostics. Skip the error and continue. That means the PLC will give the same alarm every scan cycle. And that is why in the picture you see the event keeps triggered and the alarm is repeating each scan cycle. So, just having an empty OB121 will give you the benefit of keeping the PLC running and y extension, keeping your process running. But, there is more we can do, we can try to catch this error and eliminate it. Also, we can try to show the type of programming error detected. Determine the Error Type The OB121 has an internal fault ID identifier that we can use to show the type of fault, maybe as an alarm on an HMI. Inside the OB121 we will create a simple MOVE instruction, where we will push the Fault_ID input of the OB121 to a defined memory area inside our global DB. See picture 8. Picture 8 – Identifying the error type As you see from the previous picture, when the programming error occurs, the Fault_ID will be pushed into the Data.ProgErrorID. See picture 9. Picture 9 – Programming Error Fault_ID You can see the fault ID is 3A. if you check the TIA Portal help you can find the meaning of this fault. 3A: Access to a DB that is not loaded; the DB number is located in the permitted area. Catching the Error This simply means, trying to solve the PLC programming error after you have identified the reason. This will depend mainly on what is the error and how you want to handle it. We will just simulate a solution to the error, to see how the PLC will behave. The actual solution for the error we created will be to just create the DB52 or use a data block that is already created. But for the sake of simulation, we will just add a simple contact that will open when the programming error occurs to catch this error. See pictures 10 and 11. Picture 10 – Catching the error Whenever OB121 is called, the CatchError will be set. Picture 11 – Eliminate the error Whenever OB121 is called, the CatchError will be set, and it will be used to catch the programming error in Network 1. See animation 3 for the PLC simulation. Animation 3 From the above animation, you can see that when the InitiateProgError is triggered, the PLC will go into error for a moment then the error will be cleared and the PLC is in RUN mode all the time. Conclusion Just having an empty OB121 in your logic will ensure that your PLC will not go into STOP mode if there was a programming error in your code. You can later use the OB121 to also identify the error and solve it.

Siemens is a well-known multinational company that operates in a variety of industries, including energy, healthcare, transportation, and industrial automation. Siemens was founded in 1847 and has since grown into a global corporation with operations in many countries. Siemens is known for its innovative products and services, and it has been recognized as one of the world’s most sustainable companies. In this article, we will give an overview of Siemens PLC which is a very small portion of Siemens’s various products in the industrial automation sector. Contents: Siemens in industrial automation. Siemens Different PLCs families. Overview of Siemens S7 PLCs. Simatic S7-1200. Simatic S7-1500. Simatic S7-300. Simatic S7-400. Simatic S7-ET 200 CPU Why are there a lot of different models? How to decide which type of S7 PLCs best fits my application? Conclusion. Siemens in Industrial Automation Siemens is a leader in the field of industrial automation and is known for its high-quality products and solutions. The company offers a wide range of industrial automation products, including programmable logic controllers (PLCs), human-machine interfaces (HMIs), variable frequency drives (VFDs), and industrial communication networks. Siemens also provides software solutions for industrial automation, such as the Totally Integrated Automation TIA Portal, which is an engineering framework that integrates all automation software tools in one platform. Also, Siemens has developed its own Industrial Internet of Things (IIoT) platform called MindSphere, which enables the collection and analysis of data from connected devices in industrial environments. Siemens Different PLCs families Siemens have two main families of PLCs that were developed and they are: Simatic S5 family of PLCs Simatic S7 family of PLCs The Simatic S5 series was Siemens’ previous generation of PLCs, and it is still in use in some older industrial systems. But is no longer manufactured. The Simatic S7 series is the current Siemens PLC. It offers a wide range of CPUs with varying levels of performance and functionality to meet different automation needs. The S7 series is known for its reliability, robustness, and flexibility, and is widely used in industries such as automotive, food and beverage, and pharmaceuticals. Overview of Siemens S7 PLC Siemens S7 generation of PLCs offers a wide range of CPUs with different levels of performance and functionality to meet the demands of different industrial automation processes, these CPUs will belong to one of the below sub-families: Simatic S7-1200 The Simatic S7-1200 is a compact PLC designed for small to medium-sized applications. It offers a flexible and cost-effective automation solution with its compact design, integrated communication, and programming options. Simatic S7-1500 The Simatic S7-1500 is a high-performance PLC designed for medium to large-scale applications. It offers advanced functionality such as motion control, safety, and security, making it suitable for complex automation tasks. Simatic S7-300 The Simatic S7-300 is a modular PLC that can be easily adapted to a wide range of applications. It offers high processing power, extensive communication options, and a wide range of I/O modules, making it a popular choice for many industries. Simatic S7-400 The Simatic S7-400 is a high-performance PLC designed for demanding applications that require high processing power and extensive communication capabilities. It offers a large number of I/O modules, redundancy options, and advanced diagnostics, making it suitable for complex automation tasks. Simatic S7-ET 200SP The Simatic S7-ET 200SP is a compact remote I/O system that can be easily integrated with other Simatic S7 PLCs. It offers a high degree of flexibility, scalability, and modularity, making it suitable for various automation applications. When you create a new project in TIA Portal and try to add a new device, you can find all the available and supported CPUs from different S7 families. See picture 1. Picture 1 – Different PLCs are available in the Simatic S7 generation S7-1200 PLC The Simatic S7-1200 is a versatile and cost-effective PLC that offers a range of models to meet different automation needs, making it a popular choice for small to medium-sized applications. Here’s an overview of the different models in the S7-1200 series: Simatic S7-1200 CPUs: These are the standard CPUs in the S7-1200 series, and they come in different versions, including CPU 1211C, CPU 1212C, CPU 1214C, CPU 1215C, and CPU 1217C. They offer more advanced functionality than the Basic Controllers, including built-in communication interfaces and additional I/O options. They also come in different versions, including DC/DC/DC, DC/DC/RLY, AC/DC/RLY, and AC/DC/TC. They have limited functionality but are ideal for simple control tasks. Simatic S7-1200 Safety Integrated: This is a safety-certified version of the S7-1200 that includes safety-related functions, such as safety inputs, safety outputs, and safety communication, to enhance the safety of the automation system. Simatic S7-1200 SIPLUS: This is a ruggedized version of the S7-1200 that is designed to operate in harsh environments with extreme temperatures, humidity, and vibration. See picture 2 for different models of S7-1200. Picture 2 – Different models of S7-1200 CPU S7-1500 PLC the Simatic S7-1500 is a powerful PLC that offers a range of models to meet different automation needs, making it a popular choice for demanding applications. Here’s an overview of the different models in the S7-1500 series: Simatic S7-1500 Standard CPUs: These are the standard CPUs in the S7-1500 series, and they come in different versions, including CPU 1511-1 PN, CPU 1513-1 PN, CPU 1515-2 PN, and CPU 1518-4 PN. They offer high-speed processing and advanced communication options, such as Profinet, Profibus, and Industrial Ethernet. Simatic S7-1500 Safety Integrated: This is a safety-certified version of the S7-1500 that includes safety-related functions, such as safety inputs, safety outputs, and safety communication, to enhance the safety of the automation system. Simatic S7-1500 Advanced Controllers: These are advanced versions of the S7-1500 that offer additional functionality, such as motion control, high-speed counting, and advanced communication options. Simatic S7-1500 T-CPU: This is an advanced version of the S7-1500 CPUs that have extended motion control functions such as Kinematic functions and Gearing and camming functions. Simatic S7-1500 TM NPU: This is a neural processing unit (NPU) that is designed for machine learning and artificial intelligence (AI) applications, such as predictive maintenance, quality control, and process optimization. See picture 3 for different models of S7-1500. Picture 3 – Different models of S7-1500 S7-300 PLC Simatic S7-300 CPUs: These are the standard CPUs in the S7-300 series, and they come in different versions, including CPU 312C, CPU 313C, CPU 314C, CPU 315-2DP, CPU 317-2DP, and CPU 319-3PN/DP. They offer high processing power, advanced communication options, and a wide range of I/O options. Simatic S7-300 Fail-Safe CPUs: These are safety-certified versions of the S7-300 CPUs that include safety-related functions, such as safety inputs, safety outputs, and safety communication, to enhance the safety of the automation system. Simatic S7-300 Compact CPUs: These are compact versions of the S7-300 CPUs that offer reduced size and power consumption, making them ideal for applications with limited space and power supply. Simatic S7-300 Technology CPUs: These are specialized CPUs that are designed for specific automation applications, such as motion control, temperature control, and process control. Simatic S7-300 Distributed Controllers: These are modular controllers that offer distributed I/O and communication options, making them ideal for applications that require distributed automation. See picture 4 for different models of S7-300. Picture 4 – Different models of S7-300 S7-400 PLC Simatic S7-400 CPUs: These are the standard CPUs in the S7-400 series, and they come in different versions, including CPU 412-1, CPU 414-1, CPU 414-2, CPU 416-2, and CPU 417-4. They offer high processing power, advanced communication options, and a wide range of I/O options. Simatic S7-400H CPUs: These are high-availability CPUs that offer redundancy options to enhance the availability and reliability of the automation system. Simatic S7-400F/FH CPUs: These are safety-certified CPUs that include safety-related functions, such as safety inputs, safety outputs, and safety communication, to enhance the safety of the automation system. Simatic S7-400 Distributed Controllers: These are modular controllers that offer distributed I/O and communication options, making them ideal for applications that require distributed automation. See picture 5 for different models of S7-400. Picture 5 – Different models of S7-400 Simatic S7-ET 200 PLC Simatic S7-ET 200 CPUs: These are the standard CPUs in the S7-ET 200 series, and they come in different versions, including CPU 1511C-1 PN, CPU 1513-1 PN, and CPU 1515-2 PN. They offer high processing power, advanced communication options, and a wide range of I/O options. Simatic S7-ET 200F CPUs: These are safety-certified CPUs that include safety-related functions, such as safety inputs, safety outputs, and safety communication, to enhance the safety of the automation system. Simatic S7-ET 200SP CPUs: These are compact CPUs that offer reduced size and power consumption, making them ideal for applications with limited space and power supply. See picture 6 for different models of S7-ET200. Picture 6 – Different models of S7-ET200 Why are there a lot of different models? There are many different models of Siemens S7 PLCs to provide customers with a wide range of options and features to choose from, allowing them to select the PLC that best suits their specific automation needs. Different models offer different features, processing power, memory, communication options, and I/O capabilities. Some models are designed for specific applications, such as motion control, temperature control, and process control, others are designed for general-purpose automation systems. Also, as technology advances and new automation requirements arise, Siemens continues to develop and release new models and versions of S7 PLCs with enhanced features and capabilities, providing customers with the latest automation technology to help them improve their productivity, reduce their costs, and enhance their system’s performance. How to decide which type of S7 PLCs best fits my application? Choosing the right type of S7 PLC for your application requires careful consideration of several factors. Here are some general steps to help you decide which type of S7 PLCs best fit your application: Determine the size and complexity of your automation system: If you have a large and complex automation system, you may need a high-performance PLC, such as the S7-400 or S7-1500 that can handle a large number of I/O points and advanced communication options. If your system is smaller and less complex, a smaller PLC, such as the S7-1200 or S7-300, may be sufficient. Identify the required I/O types and count: Each S7 PLC has a different range of I/O options and capacity. You need to determine the type and number of I/O points that you need for your application and select the PLC that can support them. Consider the required processing speed and performance: Different S7 PLCs have different processing speeds and performance capabilities. You need to determine the required processing speed and select the PLC that can meet your performance requirements. Evaluate the required communication options: Different S7 PLCs offer different communication options, such as Ethernet, Profibus, Profinet, and AS-i. You need to determine the required communication protocols for your application and select the PLC that can support them. Consider the required safety features: If your application requires safety functions, such as safety inputs, safety outputs, and safety communication, you may need a safety-certified PLC, such as the S7-1500F or S7-400F. Conclusion Siemens provides a wide range of industrial automation products including various models of PLCs with different functionality and performance capabilities including the S7-1200, S7-1500, S7-300, and S7-400 CPUs. The many different models of Siemens S7 PLCs are there to provide customers with a wide range of options and features to choose from. Choosing the PLC model that best fits your Process requires some points to consider before selecting the PLC, some of these points are IOs count, safety requirements, and communication options.

In this article, We will learn how to read the PLC datasheet and important notes about PLC specifications that are useful to automation engineers. Also, we will talk about what different information is provided in a PLC datasheet, and how that can be useful to me as a programmer or as an installation engineer. Contents: What information does a datasheet provide? Examples of the information in a PLC datasheet Current and voltage rating PLC memory Different blocks and data areas addressing Inputs and Outputs Specifications Communication interfaces and protocols Ambient Conditions Important notes on reading the data sheet. What information does a datasheet provide? The datasheet of a PLC will provide you with much information; this information will cover almost every feature that the PLC can provide. But some of this information won’t be as important to you as others, it depends on what is your scope with the PLC. If you are the installation engineer, then you will focus on the technical specs of the PLC like the supply voltage, type of inputs and outputs, and power rating of these IO points. You will also pay more attention to the dimension of the PLC and the Ambient conditions during PLC operation to determine the size of the electrical panel you will use for the PLC and also the cooling methods used for the PLC. How to Read the PLC Datasheet? On the other hand, if you are just the PLC programmer, then the past information might not be as critical to you, instead, you will focus on data related to for example the PLC memory, the number of IO available, and the capability of adding new modules. You will also pay attention to some other information like the programming languages supported by that PLC because not all PLCs support all programming languages. Communication and networking are also other important points you will care about as a programmer. The data sheet of a plc will always start with a general overview description of the PLC. See pictures 1 and 2 for S7-1200 and S7-1500 simple examples. Picture 1 – 1st page of an S7-1500 PLC data sheet. Picture 2 – 1st page of an S7-1200 PLC data sheet. As you can see, a general description of the PLC is given at the beginning of the datasheet. This general description will give you a basic idea about the PLC and if it fits your application or not. Examples of the information in a PLC Datasheet In this article, we will use the data sheet of an S7-1200 PLC to show some of the different information it contains. Current and Voltage Rating In a certain section of the data sheet there must be some information about the PLC voltage and current ratings, some PLCs will need a DC supply while others will require an AC supply, also the inputs and outputs of the PLC might have different ratings, which is exactly the case in our PLC, where the voltage supply to the PLC is 220AC but the ratings for IOs are DC. See picture 3. Picture 3 – Voltage and current ratings. PLC Memory Different memory capabilities of the PLC will be provided in the datasheet, this will show how much work memory you have and whether you can expand it or not, see picture 4. Picture 4 – Memory description of the PLC. Different Blocks and Data Areas Addressing In this section, you will know the different blocks that you can use with your PLC, like timers, counters, FCs, etc. And the maximum number of blocks that you can use. You will also be provided with the data areas’ memory and their retentivity. See picture 5. Picture 5 – CPU blocks are available. Inputs and Outputs Specifications This is another critical data that should be provided, through this information you will know the number of IOs provided with your PLC, and how to connect and use each IO. See pictures 6 and 7. Picture 6 – Digital inputs of the PLC. As you can see, we have 8 DI points in our PLC, 6 of which can be used for HSC (high-speed counting) inputs like encoders. It also tells you that the input voltage is 24vdc which means you can’t directly connect AC sensors of inputs to the PLC. Picture 7 – Digital outputs are available in our PLC. If the PLC has analog IOs then it will be mentioned also in the data sheet. See picture 8 Picture 8 – Analog IOs description. Communication Interfaces and Protocols The communication interfaces available in your PLC, as well as the communication protocols it can support, will also be mentioned in the datasheet. See picture 9. Picture 9 – The communication interface of the PLC. As you can see, the PLC we have only has one communication interface, which is a PROFINET interface provided as an RJ-45 port. However, the PLC itself can support many communication protocols such as PROFIBUS and AS-Interface. See picture 10. Picture 10 – Communication protocols supported. Ambient Conditions This is another very important data you should know about your PLC, as it will help decide the type of enclosure and cooling that will be best suited to your PLC. See picture 11. Picture 11 – Ambient condition of the PLC. Important notes on Reading the DataSheet of a PLC Not all the PLC data sheets contain the same information, as different PLCs will have different features and capabilities and hence, different information to show. Not all the information inside the datasheet will be important to you, that will depend on whether you are a PLC programmer or an installation engineer as we mentioned before. It’s OK if you don’t understand some of the information in the datasheet, as we said the data sheet will provide information about almost all the features supported by your PLC, you might not know about some of these features and you might not even ever need to use it. For example, the OPC UA or the web server features. So if you find some data you don’t understand, it won’t necessarily mean your PLC doesn’t fit your project. Conclusion Reading the PLC datasheet is important to help decide if the PLC is suitable for your application or not. It is also important to decide what types of IOs and voltage supply ratings you can work with. Try reading the datasheet of different PLC models and see if you can understand the basic information provided in the datasheet.

In this article we are going to talk about a major problem that happens a lot when you start programming your PLC, this is the firmware version’s common errors and how to handle them. Contents: What is the firmware version of a PLC? Why firmware version can cause trouble? How to know the firmware version of hardware PLC? How to handle firmware version errors? Conclusions. What is the firmware version of a PLC? The firmware of a PLC or a PLC module (IOs, Communication modules, etc) is simply the internal software installed in the PLC which is responsible for what the hardware can actually do. A firmware version will determine what internal feature your PLC has, like the safety protocols, internal optimizing functions, better time handling, and other different features and capabilities. A PLC with an older firmware version will have fewer features and internal capabilities than a newer firmware version PLC. Pictures 1 and 2 show you how the same hardware PLC will have different features and performance capabilities with different firmware versions installed. Picture 1 – Firmware version V4.0 Picture 2 – Firmware version V4.4 Did you notice how the same CPU is now having more features added just by updating to a higher firmware version? With the higher firmware V4.4, the CPU now has OPC UA among other features added to its performance capabilities. Why firmware version can cause trouble? Look, you usually start your PLC project by selecting the PLC then you start programming. You will select your PLC in TIA Portal according to one of two points: You already have purchased the hardware PLC, so you will select the same PLC that you actually have in the TIA Portal project. You still haven’t purchased a PLC, so you will select a PLC in TIA Portal that meets your requirement then you will buy it later. In either of the two cases, if the firmware version of the PLC selected in the TIA Portal project is different from the firmware version of the actual hardware you will have a problem. And your program won’t even be downloaded to the hardware PLC. So, you should always make sure that the firmware version of the actual PLC matches the PLC selected in TIA Portal. It is worth mentioning to know that if the firmware version selected in TIA Portal is older than the actual PLC, you won’t face any troubles with your program, you will lose some of the PLC features and capabilities, but your program will work fine. Troubles will appear if the opposite is true, if the firmware version selected in TIA Portal is newer than the actual PLC, then you will have a problem. That is why if you don’t know the firmware version of your hardware, you should select the older version in the TIA Portal project. How to know the firmware version of hardware PLC? We can know the firmware version of the hardware PLC that we have by one f two methods: From the PLC itself The firmware version of any PLC module is always written somewhere on the hardware device. See the next pictures. Picture 3 – Firmware version FS:04 Picture 4 – Firmware version is V7.0.5 From the TIA Portal software Using the TIA Portal software you can connect your PLC to your TIA Portal and search for the device then you can find the firmware version of the hardware device, see the following steps. You don’t even have to create a new project; just the project view of the TIA Portal is enough, see picture 5. Picture 5 – Project view of TIA Portal without creating a project. From online access search for your PLC. As the connection between TIA Portal and the PLC is through an Ethernet cable, then we will use the Ethernet connection option. Double-click on update accessible devices to start searching for your PLC. See picture 6. Picture 6 – Update accessible devices to search for your PLC. If there is a connection between the PLC and the TIA Portal then the software should find your PLC. See picture 7. Picture 7 – Your PLC was found by the software. Now, double-click on Online & diagnostics to show your PLC’s information. See picture 8. Picture 8 – Online information of the PLC. From the General attribute, you can find the firmware version of your PLC as shown in the previous picture. You can also find the firmware version from the Functions attribute. See picture 9. Picture 9 – Firmware version from the functions attribute. How to handle firmware version errors? First, let’s create a firmware version error scenario then we will see how to handle and fix this error. We will start by simply create a new project and then add a new device, in this PLC example we will intentionally choose a newer firmware version than the actual hardware PLC. We know that our plc firmware is V4.0, but in TIA Portal we will choose V4.4 firmware version. See picture 10. Picture 10 – Add a new PLC with a higher firmware version. Press OK to add your device and that is it, you have created a situation that will cause a firmware error. To see that let’s try to download the project to our PLC. Note that we haven’t even written any code. Just download it to the PLC. See picture 11. Picture 11 – Download to PLC failed, incompatible firmware. As you see from the previous picture, once you try to download the project to the PLC, an error will appear stating that the firmware versions of the PLC and TIA Portal are not matching. You can even see it if you try to go online. See picture 12. Picture 12 – The PLC is in an error state. To solve this error, we simply need to change the firmware version of the PLC selected in the TIA Portal project to older or the same firmware as the actual hardware PLC. To do that we go to the properties page of the PLC and select Change firmware version from the General attribute. See picture 13. Picture 13 – Change the firmware version option. Once you press the Change firmware version button, a change device window will appear; in this window, you’ll be able to change the firmware version. See picture 14. Picture 14 – Change the device window. In the change device window, you will see the current device which you have selected before and the new device which you need to match its firmware with what you actually have. Note that, when choosing a lower firmware for example V4.3 the information at the bottom of the window will show you what features you have lost when moving down to a lower firmware as you see in the previous picture. Now, change the firmware of the new device to the V4.0 version of the hardware PLC. And notice how many features and capabilities the PLC has lost just by choosing a lower firmware. See picture 15. Picture 15 – Matching the firmware between hardware PLC and Software. Press OK to confirm changes and now try to download your project once again to the PLC. You will notice that now the project will be loaded to the PLC without any errors. See picture 16. Picture 16 – The project is loaded into the PLC. A successful load of the project to the PLC indicates that the firmware version error is now fixed. You can also go online and check that from the online view of the PLC project. See picture 17. Picture 17 – Online view of the project. The green checks and circles you see in the previous picture indicate that all configurations of the software and the hardware are matching and are compatible with one another. Conclusion Firmware version errors are very common trouble to face when creating a new project in TIA Portal. A best practice is to know the firmware version of the hardware device you have and match the firmware of it to the selected device in TIA Portal. If you don’t know the firmware of the hardware device, then you should choose the oldest version of the selected module inside the TIA Portal. To avoid any firmware issues with your project.

In this article, we will take about clock memory bits in TIA Portal and Siemens PLC. And we will show how to enable the use of the memory bits and how it can help you avoid coding a lot of logic lines to obtain a simple function that your PLC already do it internally. Contents: What are clock memory bits? The need for clock memory bits. Enable clock memory in my project. Simple program example. Program simulation. Conclusion. What are Clock Memory Bits? A clock memory is a bit memory that changes its binary status periodically in the ratio of 1:1. That simply means it changes its status periodically between true and false with a pre-defined frequency. There are 8 clock memory bits pre-defined in the CPU which is why they are also called clock memory byte. You decide which memory byte of the CPU will become the clock memory byte when you enable the use of the memory byte and assign the clock memory parameters. The Need for Clock Memory Bits You don’t necessarily need the clock memory as you can create your own logic and achieve the same functionality. However, it is a good thing to have in your pocket when you need such functionality. As creating 8 separate logic for 8 clock memory bits will take some of your time and effort and might make your program unnecessarily large. You can use clock memory, for example, to activate flashing indicator lamps or to initiate periodically recurring operations such as recording actual values. Each bit of the clock bit memory byte is assigned a frequency. See the following table. Bit of the clock memory byte 7 6 5 4 3 2 1 0 Period (s) 2.0 1.6 1.0 0.8 0.5 0.4 0.2 0.1 Frequency (Hz) 0.5 0.625 1 1.25 2 2.5 5 10 Table 1. Clock memory bits frequencies according to the TIA Portal help manual. Enable Clock Memory in Siemens PLC To use the clock memory bits in your logic, you need to enable the use of the clock memory byte from the properties of the CPU. See picture 1. Picture 1 – Enable the use of clock memory byte You can choose the address of the byte you want to assign for the clock memory, just make sure it doesn’t conflict with any other memory bytes in your PLC logic. As you see from the picture, we chose the address 0, so if you need to use the 2Hz clock bit you will use the bit %M0.3 Tia Portal Conveyor Belt Example Program In a previous article, we used a simple example of a conveyor belt moving a product between the start and end of the belt. There was an indication LED that turns ON when the Belt is running. See picture 2. Picture 2 – Simple conveyor belt system We will use the same example, but this time we will make the LED more intuitive using the clock memory bits. This time we will use the clock memory bits with the LED to give an indication of different cases of the process. Process Description In a conveyor belt system controlled by a PLC, there are two presence sensors at the two ends of the belt to detect the presence of a product, when the product is detected at the start of the belt, the conveyor can be started through a start Pushbutton and when the product reaches the end the belt will stop automatically and it will not run again until a new product is detected once again at the start and the START push button is pressed. The indication LED should have more than one behavior depending on the current case of the system. These cases are as follows: If there is a product at the start of the belt but START is not pressed yet, the LED should be flashing by a frequency of 0.5Hz. If the conveyor is moving the product the LED should be flashing by a 2Hz frequency. When the product reaches the end of the belt the LED should be ON When the product is removed from the end the LED will go OFF. Project IOs We have 4 digital inputs as follows: START: start push button to run the Conveyor. STOP: stop push button to stop the conveyor at any moment. P1: Presence sensor at the start of the belt. P2: Presence sensor at the end of the belt. We also have 2 digital outputs as follows: MOTOR: when activated the Conveyor belt will start running. LED: will be activated according to the sequence mentioned before. Program Code First, we select our PLC and assign the IO tags. See picture 3 Picture 3 – Assign inputs and outputs tags Don’t forget to enable the use of the clock memory byte as shown in picture 1. We will have two networks of code, one for the control of the conveyor belt and another for the LED logic. See pictures 4 and 5 for the logic. Picture 4 – The control logic of the conveyor belt Picture 5 – The control logic of the LED As you can see, using the clock memory bits made the logic simple and easy to read. Imagine if you would create the same logic without the use of these bits, you would have used a lot of timers and your logic would have been fairly complicated. Program Simulation We explained before how to use the PLCSim to simulate our code. In this example, we will use the simulation sequence to create the same sequence of the actual process and we will see if the LED behavior will match the intended functionality or not. Start by compiling our code and start a new simulation. See picture 6. Picture 6 – Program simulation As you can see, the LED is now OFF; there are no products presences at the start or the end of the conveyor. We created a simulation sequence and see how the LED will react to different process conditions. See the following animation. See if you can notice how the LED behavior changes with different process conditions. Conclusion Clock memory bits turn on and off with a pre-defined frequency. They are very useful when you need to activate flashing indicator lamps or to initiate periodically recurring operations. Using clock memory bits will save you the time and effort consumed to obtain the same functionality through your own logic.

In this article, we will show how to take a program backup from the physical PLC to your computer using the Siemens Tia portal software. Contents: Why would You need to take a backup? How to take a backup from PLC? Notes about Backup from PLC Conclusion Why would You need to take a Backup? Imagine if you accidentally deleted your software from the PC while working on it. Or maybe you need to make an update to certain process software that has been running for 10 years and you no longer have the software code. Instead of rewriting the whole code from scratch, it will be easier to just upload the current code and make your changes to it. In this article, we will show how to easily upload the software contained inside the PLC to your PC. How to Take a Backup from PLC? TIA Portal with the new Siemens controllers S7-1200 and S7-1500 provides more advantages when taking a backup compared to them when you are working with older controllers like S7-300 or S7-400, with older controllers you would take the backup but it will not show any comments or addressing details, the software will work just fine but it will be difficult to read or understand. With the newer PLC controllers, you can now upload both the code and all associated addressing and comments, which will make reading the code very simple and make any updates to it possible. Steps to upload the software from the PLC Create a new project, but unlike what we do usually we will not add a new device rather we will press the Online and choose “upload device as a new station”. See picture 1. Picture 1 – Upload the device as a new station. This will take you to upload the device into the PG/PC window. See picture 2. Picture 2 – Upload device window. You need to choose the type of PG/PC interface as shown in the last picture and then press Start search. When the search is done, you will see all the devices that were found by your software. Note that, it’s not necessary to only find PLCs; you will also be able to find HMIs, IO modules, and every other communication module that the software can detect. See picture 3. Picture 3 – Scan complete and devices found. After the scan is complete, you can select the PLC that you need to upload and then press Upload. This will start uploading the software from the PLC to your TIA Portal. See picture 4. Picture 4 – Upload from PLC is complete. As you can see from the previous picture, the complete project saved on the PLC will be uploaded into your TIA Portal. Even with all the comments and addresses. See picture 5. Picture 5 – PLC project is uploaded As you can see, the whole PLC project was uploaded from the PLC to your PC. With all the blocks, comments, and project configurations. Notes about Backup from PLC If your PC and the PLC have different IP addresses, the TIA Portal will ask you to assign a new IP for your PC that matches the addressing of the PLC and it will even do that automatically, if you allow it. If the project on the PLC is password protected, you will be asked to write this password before the upload step starts, if you can’t provide the right password, then the upload will not start. Make sure you know that password if any. Sometimes, the TIA Portal will find your PLC, but can’t upload the project, due to different reasons, for example, the project on the PLC is written in a different TIA Portal version than what you are using right now. Either way, the reason for failed upload will be shown to you, and you can upload once these reasons are cleared. Conclusion You can upload the project on the PLC to your PC using TIA Portal. If the PLC is s7-1200 or s7-1500 the project will be uploaded with all the associated addressing and comments. If there is any reason preventing TIA Portal from uploading the project, this reason will be shown to you by TIA Portal and you can upload once you fix the problem.

In a previous article, we talked about the firmware version of your PLC and how to handle errors that might happen due to a firmware mismatch between your project in the TIA Portal and your actual PLC. In this article, we will show how to update the firmware version of your PLC. Contents: What is a firmware version? Why firmware version can cause me trouble? How to know the firmware version of your hardware PLC? How to handle firmware version errors? How to update the firmware version of your PLC? Conclusion. What is a firmware version? As we explained in a previous article, the firmware of a PLC or a PLC module (IOs, Communication modules, etc.) is simply the internal software installed in the PLC which is responsible for what the hardware can actually do. A PLC with an older firmware version will have fewer features and internal capabilities than a newer firmware version PLC. Pictures 1 and 2 show you how the same hardware PLC will have different features and performance capabilities with different firmware versions installed. Picture 1. Firmware version V4.0 Picture 2. Firmware version V4.4 You can see that the CPU is now having more features added just by updating to a higher firmware version. With the higher firmware V4.4, the CPU now has OPC UA among other features added to its performance capabilities. Why Firmware Version Can Cause Trouble? You will select your PLC in TIA Portal according to one of two points: You already have purchased the hardware PLC, so you will select the same PLC that you actually have in the TIA Portal project. You still haven’t purchased a PLC, so you will select a PLC in TIA Portal that meets your requirement then you will buy it later. In either of the two cases, if the firmware version of the PLC selected in the TIA Portal project is different from the firmware version of the actual hardware you will have a problem. And in some PLCs, your program won’t even be downloaded to the hardware PLC. So, you should always make sure that the firmware version of the actual PLC matches the PLC selected in TIA Portal. It is worth mentioning to know that if the firmware version selected in TIA Portal is older than the actual PLC, you won’t face any troubles with your program, you will lose some of the PLC features and capabilities, but your program will work fine. Troubles will appear if the opposite is true, if the firmware version selected in TIA Portal is newer than the actual PLC, then you will have a problem. That is why if you don’t know the firmware version of your hardware, you should select the older version in the TIA Portal project. How to Know the Firmware Version of Hardware PLC? We can know the firmware version of the hardware PLC that we have by one of two methods: From the PLC itself: The firmware version of any PLC or PLC module is always written somewhere on the hardware device. From the TIA Portal software: Using the TIA Portal software, you can connect your PLC to your TIA Portal and search for the device then you can find the firmware version of the hardware device. We showed how to do that in the previous article. How to Handle Firmware Version Errors? If the firmware version of the actual hardware PLC is older than the version of the PLC selected in the TIA Portal project this will cause firmware errors, and to solve these errors we can try one of the following approaches: we can select the PLC in the TIA Portal project to be with the same or older firmware version as the actual PLC. We showed that in the previous article. we can update the firmware version of the actual hardware PLC to a higher firmware version than the selected one in your project or at least to the same firmware version. And that is the scope of this article. How to Update the Firmware Version of your PLC? You can update the firmware version of your PLC in two ways: Online using TIA Portal. Off-line using Siemens Memory Card SMC. Update the firmware Online using TIA Portal: You don’t need to have an existing project open in the TIA Portal, just you need the TIA Portal software and connect the PLC to your PC. See picture 3. Picture 3. Open Tia Portal without creating a new project. When you open TIA Portal, go to online access, choose the suitable communication adapter between your PLC and your PC, and then press update accessible devices to search for your PLC. See picture 4. Picture 4. Find your PLC. After the PLC is found as you can see in the previous picture, open the PLC folder and press online and diagnosis to see the PLC firmware version. See picture 5. picture 5. The current firmware version of PLC. NOW, to update the firmware version, press the Firmware Update attribute. See picture 6. picture 6. Firmware update page. As you can see, when you press the Firmware Update attribute, you can see the current firmware update which is V4.1.3, and also you can see the Firmware Loader where you can browse for the firmware version that you want to install. Off course you have to have the firmware version on your PC first, which means we need to download the firmware version. To download the firmware version, you should log in to your Siemens account, if you don’t have one you can easily create a new account, but it will take 1 or 2 days to be activated. After that, you can search for the firmware version for your PLC. In our case, we have an S7-1200 CPU 1214C AC/DC/RLY and we will search for its firmware version using its article number. See picture 7. Picture 7. Search for the firmware version of your PLC. After that download the firmware version you want to install, in our case, we want to update our PLC to V4.4.0, so we will download this version to our PC. See picture 8. picture 8. Download V4.4.0 The downloaded file will be a zip file, you should unzip the file to get the firmware version data file and then go back to the Firmware Loader attribute and click browse to search for the firmware version. See picture 9. picture 9. Search for the firmware version file. Don’t worry about making a mistake at this step, because if the firmware version is not compatible with the PLC, you won’t be able to run the update. See picture10. picture 10. The update will not continue if the firmware doesn’t match. As you can see, when we tried to upload a firmware version for a 1215C CPU into our PLC with a 11214C CPU, it gave an error that the file is not suitable for the PLC. NOW, click browse again, but this time search for the correct firmware version. See picture 11. picture 11. No error message when the firmware version is correct. As you can see, when we choose a suitable firmware version, there was no error message and we can now press Run Update to start updating our PLC. A Firmware update window will appear once you start the update process and a success message will appear at the end, if the update went smoothly. See pictures 12 and 13. picture 12. A firmware update is running. Picture 13. firmware update finished successfully. Now that the firmware version is updated, refresh your communication by re-pressing Update Accessible Devices and checking the PLC firmware version. You will find the PLC is now of firmware version V.4.4.0 instead of V4.1.3, and that means we managed to update the firmware version of our PLC. See picture 14. Picture 14. Firmware is updated to V4.44.0 And that is how we update the firmware version of our PLC using TIA Portal. Offline using Siemens Memory Card SMC: The other method that can be used to update the firmware of our PLC is by using the SIEMENS memory card SMC. To do so, we just have to download the firmware version we want to use then we will copy the firmware version from our PLC to the SMC and then insert the SMC into the dedicated slot in the PLC. The next time the PLC is powered on, the firmware will be updated. Conclusion You can update the firmware version using the TIA portal software or the SIEMENS SMC memory card. Make sure you are choosing the firmware version exactly right, if there is a mismatch between PLC and TIA Portal the update will not start.

In a previous article, we talked about what a PID is, and we also explained the different parameters of a PID and how the system would react to changing these parameters. In this article, we will show how to program, configure and tune a PID in your TIA Portal project. Contents: How to add a PID to your logic? How to configure the PID? Basic setting process value setting Advanced setting How to perform tuning of the PID? Pre-tuning of the PID Fine-tuning What are the different tuning methods of PIDs? How to add a PID to your logic? In TIA Portal and almost every other PLC platform, you don’t have to program a PID controller as the TIA Portal already has built-in blocks for PIDs. To add a PID into your logic you just have to simply drag and drop the PID block into your code and just start configuring it for your system. Adding PID into your code is very simple, however, there is a very important point you should take into your consideration. This is the execution interval of your PID. As you know the main execution cycle is happening inside Main Cyclic OB1 and the cycle time of the OB1 depends on a lot of factors, like how long your code is, mathematical calculations in your code, and also for loops and sequences, all of these different factor would make the cycle time of your OB1 not only might it make it long but also it will make it different each cycle, depending on the coding you have. That means if you called your PID block inside the main OB1, the PID execution will depend on the cycle time of your OB1, and that is not a best practice approach. PIDs are usually used to control physical parameters like pressures, temperatures, or speeds and that means your controller needs to be very fast in figuring out any change in your process value and taking fast reactions to counter-effect this change and give you a smooth stable control that a PID should have. So if the PID is added to the main OB1 and is affected by its execution time, it might need to action delays and it will make your system not stable. What to do? A best practice is to call your PID block in a cyclic interrupt OB and set the cycle time of this cyclic interrupt to whatever value you see fit for your system, usually in the range of milliseconds depending on your application. That means, if you set the cyclic interrupt for example to 1 millisecond your PID will be called and executed every millisecond regardless of where the main OB1 cycle is. So, to add a PID into your logic we start by adding a new cyclic interrupt OB and give it a proper name. See picture 1. Picture 1. Adding a cyclic interrupt into your project. You can see from the picture that we set the cyclic time to 1000 microseconds or 1 milliseconds. So our PID will be called and executed every millisecond. Now that you added your cyclic OB to the project, you can simply drag and drop the PID block. You can find it in the Instructions tab/Technology/PID control/Compact PID. See picture 2. Picture 2. Adding the PID block. Now, add your system parameters to the PID block, the input, output, and setpoint. See picture 3. Picture 3. Assign your PID parameters. Did you notice from the last picture, you have 2 different inputs and 3 different outputs, what are those? Input: This is your input value of your process parameter in real actual physical quantities, we will use our tank simulation system, so the input here in that case is the tank fill level in liters. That means you have made your analog input scaling somewhere else in your project and you just supply the PID with the actual fill level in liters. Input_PER: This is the input value of your process parameter but comes from the analog input module. That means it will not be scaled and it will be in the range of 0-27648 and the scaling of the input will be done inside the PID. Output: In this case, the PID will give you the controller output value in the range of 0% to 100% of the maximum output value. Output_PER: The same as input_PER, the PID will give the output in the form of 0-27648. Output_PWM: In this case, the PID will give its output signal in the form of ON/OFF pulses, so either there is an output or not. And the output value is then 100% when it is ON and 0% when it is OFF. We will use the same tank simulation system we used before, and as you can see from the previous picture, we used the Input and Output_PER as our simulation is built this way. How to configure the PID? To enter the configuration view of the PID, you can either click the configuration tab in the project tree or from the small configuration icon above the PID block itself. See picture 4. Picture 4. Entering configuration view. This will take you to the functional view where you can configure the different settings of your PID. See picture 5. Picture 5. Controller type setting. The first configuration is the controller type, and here you can choose what type of control you want to use, you have a lot of options from the shown drop-down menus like temperature, pressure, length, and many more. You can also set it to general, where the system will see your values as %. In our system, we are controlling water liters inside a tank, so we will choose volume. You can also set the Manual/Auto mode of the PID. Next, you want to configure the input/output parameters. See picture 6. Picture 6. Input/output parameters. Here you can choose from the different types of inputs or outputs as we explained before. As we said we will use the Input and Output_PER. Next, you need to configure your process value setting. See picture 7. Picture 7. Process value limit. In this step, you will set the low and high limits of your process value. If you choose the Input type. Then this setting will be open to change, and you can set the limits of your process. In our case, the tank limits are 0 to 50 liters. So we set it to these values. Note that, if you choose the Input_PER this setting won’t be available to you and you can only set your process limit from the next tab. See picture 8. Picture 8. Process value scaling. If you use the Input_PER, then as you see from the previous picture you can set your process value limit with respect to the 0-27648 scaling you have. If you want to set up a warning when your process value hit a low or a high limit, then you can configure that in the process value monitoring tab. See picture 9. Picture 9. Process value monitoring. Next in the setting list you will find the PWM limits, see picture 10. Picture 10. PWM limits in here you can set the minimum ON and OFF time of your output, imagine you have a pump or a valve in your system that the PID is controlling through a PWM output, you don’t want the PID to just give your pump a train of a very fast based ON/OFF behavior because that will probably cause your pump to burn out. So you can tell the PID from this setting to turn the pump on for a minimum time before closing it and vice versa. You can have the same control with your PID if you don’t have PWM output from the next setting, the output value limits. See picture 11. Picture 11. Output value limits. You can control the low and high limits of your control output, for example, you can make the low limit 20% and that will make the PID run the pump for at least 20% of its flow. So your control range will be from 20% to 100%. Finally and most importantly, you can set your PID parameters in the configuration mode from the next tab, the PID parameters tab, see picture 12. Picture 12. PID parameters. Here you can write the tuning parameters for your PID gains P, I, and D in case you know them or in case you made the tuning yourself and you have the parameters from elsewhere. You can also choose to decide to use a PID or just a PI controller. If you don’t have these parameters, you can upload them automatically after you make tuning to your PID. How to Perform Tuning of the PID? Now that you finished your PID configuration, you can tune your controller just as easily from the commissioning tab in the project tree. See picture 13. Picture 13. Commissioning your PID On the commissioning page, you have your screen divided into 3 parts, the upper page is where you can start pre-tuning and fine-tuning the PID. In the middle, you will have a graph area to show you the real-time response of your system. You can see the controller output and the process value. And each time the set point changes, you will see the behavior of your PID to catch this new set point. Even if the set point didn’t change but for example the demand from our tank supply is increased, you will see the PID reaction to supply that demand and also keep the set point at its required value. In the third area, you will have the online status of your controller and you can also decide the operating mode of your PID. See the following simulation video showing the auto-tuning procedure of the PID in the TIA Portal. From the video, you can see that after pre-tuning is done, our PID found the P, I, and D parameters to best suit our system. You can see that when the set point or the outflow changes the controller will react very quickly to bring the set point back to the required values. You can now upload your tuning parameters directly into your project with a simple button click, see picture 14. Picture 14. Upload your parameters. Once you have uploaded your parameters, you can find them in the PID parameters tab in the configuration view. See picture 15. Picture 15. PID parameters. The next step should be to perform a fine-tuning procedure to the PID from the same commissioning view, however, because we don’t have a real system and we are just simulating the behavior of the tank and pump using mathematical calculations we can’t do the fine-tuning step. When you have a real system you can make the fine-tuning where your PID will try to find the parameters that will give the system a better response and even eliminate the overshoot of your process value and directly reach the set point. In the future, if we have a real system, we can show what it looks like. What are the different Tuning Methods of PID Controller? You don’t have to make the tuning of your PID using TIA Portal; there are many different methods that try to find the best PID parameters for your system. It is mostly mathematical methods based on trial and error. I would recommend using the auto-tune feature in TIA Portal. But here are some of the methods used to achieve the same parameters. Heuristic tuning. Ziegler-Nichols tuning method Cohen-Coon tuning method Kappa-Tau tuning method Lambda tuning method And a few others. Conclusion Use a cyclic interrupt with your PIDs. Configure your PID to best suit your system. The auto-tune feature in TIA Portal is very useful and effective.

There are many ways where PLCs can communicate and talk to each other, in this article we will talk about one of these methods which is how to establish Siemens communication between PLCs using the i-device function to make PLC-to-PLC data transfer. What is the I-Device function? The I-Device function can be used to exchange data between two PLCs very easily. An I-Device is simply a PLC that is used as an IO device. That means the PLC will act as an IO module providing inputs and receiving outputs with the other PLC. I-device function enables PROFINET to communicate not only with subordinate devices like IO controllers, but also IO communication with other higher-level or central controllers as an IO device. Siemens Communication between PLCs Most of the S7 family PLCs support the I-Device feature but some controllers don’t depending on the firmware version for example: S7-300 (from firmware version V3.2) S7-1200 (from firmware version V4) You can simply know if your controller has the I-device feature or not by going into your PLC PROFINET interface properties and checking for the “operating mode” option. See pictures 1a and 1b. picture 1a. PLC doesn’t support I-device From the picture, we can’t see the “operating mode” option, so we know that PLC doesn’t support the I-device feature. Picture 1b. PLC supports the I-device feature As you see from the picture, this PLC supports the I-device feature. A PLC with the “Intelligent IO device” configuration is called an I-Device. An I-Device is like a standard IO device and needs to be handled like one. This means that the I-Device is also connected to a higher-level IO controller. So , an I-device will act as an IO module, but it is also still a PLC, so it still acts as a controller if you want it to. Data exchange concept The guiding principle of the I-Device method is to use the known process image in a CPU. From the higher-level IO controller’s view, communicating to an I-Device is similar to communicating to a distributed IO with the usual read and write processes at inputs and outputs. From the I-Device’s view, data transfer to a higher-level IO controller is also analog to the data transfer to the local or assigned distributed IO via inputs and outputs. I-device Configuration options There are two possibilities for configuration: Configuring an I-Device within a project. Configuring an I-Device that is used in another project When configuring an I-Device for another project, STEP 7 enables you to do this by exporting a configured I-Device in a GSD file. The GSD file can be imported in the other project or the other engineering system like other GSD files. This allows not only for communication within the project, but also communication across projects and data exchange between different manufacturers in a tried and tested way. We will show that in another article. In this article, we will show the Configuration of the I-device within the same Siemens PLC project. I-device configuration within the same PLC project We will assume that we have two PLCs in our project, CPU 1516-3 PN/DP which will act as the controller in this configuration, and CPU 1214C which will act as the I-device. Start by adding the two PLCs into your TIA Portal project and setup a Profinet connection between them. See picture 2. picture 2. Setup connection between two PLCs. Now, we need to configure the CPU 1214C PLC as an I-device. You do that by going to the Profinet interface properties and from the operating mode option you click on the IO device option. See picture 3. picture 3. Select IO device. After that, you need to assign the I-device to a higher-level controller which is the CPU 1516-3 PN/DP PLC in our project. To do that just select that PLC from the Assigned IO controller drop-down list. See picture 4. picture 4. Assign the I-device to the controller. After that, the I-device is now connected and assigned to the controller PLC. See picture 5. picture 5. The I-device is assigned to the controller PLC. The next step is to exchange the data between the I-device and the controller with what is known as transfer areas. Creating a transfer area Transfer areas are the IO areas that are used to exchange data between the I-Device and the higher-level IO controller. Go to the “I-Device Communication” section. Click the first field of the “Transfer areas” column. TIA Portal will create a predefined name that you are able to change. As you can see from picture 6. picture 6. Create a transfer area Select the type of communication relationship: currently, only CD can be selected. See picture 7. Picture 7. Choose CD communication option. Once you select the CD option, a transfer area will be created and the addresses of the IO controller and I-device will be automatically created. See picture 8. Picture 8. Transfer area is created. The addresses are pre-assigned automatically, if required, you can adjust the addresses to your environment and specify the length of the transfer area to be transferred consistently. To create another transfer area as before, just press the “add new”, see picture 9. picture 9. Add new transfer area. As we said before, data exchange is based on the simple processing image concept, which means you always send an output and receive an input. Also note that the arrow you see in previous picture indicates the flow of information between the I-device and the controller. So if I send data from the controller to the I-device then the arrow will be from the controller to I-device and the address of controller will be output and address of I-device will be input and vise verse as you can see from previous picture. Also keep in mind that it is always better to rename your transfer areas to proper indicating names. See picture 10. Picture 10. Rename your transfer areas. Loading the PLC project To load the PLC project data, select both controllers one after the other in the project navigation and load the project into the respective module. Note that, because we don’t have actual hardware devices, we can’t simulate this feature.

In this article, we will discuss yet another way of communicating between two PLCs, whether they are in the same project or two different PLC projects. In this article, we will talk about the PUT command in Siemens PLC which can be used to send or put data from one PLC into a second PLC. What is the PUT Command? In general, the PUT command is a TIA Portal built-in function block FB that is used exclusively for S7-Family CPUs to put data from a local PLC to a remote partner PLC. When using the PUT command, I would have two PLCs, where I need to send data from one PLC called local to another PLC called partner. Some configurations must be done to the partner PLC, to enable it to be accessed by the other PLC. In addition to a Profinet connection between the PLCs. We will create a sample project to show how to use the PUT command. PUT Command in Siemens PLC We will assume a sample project where we have two PLCs in the same project, PLC_1 which will act as the local PLC and PLC_2 which is the partner PLC. We want to write an integer from the local to the partner PLC. Sample PLC project First, let’s create a new project and add the two PLCs. See picture 1. picture 1. Add the local and partner PLCs. What I need now is to configure PLC_2, the one that will receive the data to be able to receive this data. And PLC_1 will be used with the PUT command. The 1st thing I need to do is allow the access of the PUT command to the PLC_2 that will receive the data. See picture 2. picture 2. Allow PUT command access. As you see from the picture, we allow the PUT command to access the PLC_2 from the Properties of the PLC_2, in the Protection and Security option, click on the “Permit access with PUT/GET communication from the remote partner” Now, I am allowed to put data from any remote partner to PLC_2 using the PUT command. The 2nd thing is to prepare a space or memory in PLC_2 to the data that will be put in it. We will assume that we want to PUT an integer value into that PLC, so I will prepare a memory according to that. See picture 3. picture 3. Prepare area to receive data. And that is it; this is the entire configuration you need to prepare from the PLC_2 side to be able to receive data through PUT command. Next, we set up the data being sent from the PLC_1. We will create a data block to hold the data sent to PLC_2 and inside this data block, we will define an integer tag to be PUT into PLC_2. See picture 4. picture 4. Create a data block to hold the sent data. We defined an integer tag “SendMeToPLC_2” that we want to send to PLC_2. See picture 5. picture 5. Define the data to be sent. Note that, for PLC_1, we don’t need to allow the access with PUT command option. We activate this feature in the PLC that will receive data, not the PLC that will send it. Now, let’s use the PUT command in our programming, in the main OB1 we will drag and drop the PUT command FB. See picture 6. picture 6. Add the PUT command to OB1. Note that, the PUT command is found in the S7 communication folder, as it is an exclusive function for S7 family PLC, because it involves safety issues. Remember in picture 2 when we allowed the use of PUT command it was in the Security and Protection attribute of the PLC properties as it is related to PLC safety and protection. The PUT command is essentially a function block, so when adding it to my logic I will be asked to create a data instance. See picture 7. picture 7. Create a data instance for the PUT command. After you press OK, the PUT command is now added to your PLC logic. See picture 8. picture 8. PUT command After we added the PUT command, now we need to configure it, we have two parameters to configure for the PUT command. The connection between PLCs The block that will be PUT from PLC_1 to PLC_2 To go to the configuration view of the PUT command, press the small blue icon shown in last picture. In the connection parameter, you will set the communication between the local (PLC_1) and partner (PLC_2) PLCs. See picture 9. picture 9. Connection parameter. As you can see, the Local PLC is set to PLC_1 which is the PLC where the PUT command is used. The partner side is still empty and that is where we should assign PLC_2. If you click on the drop-down list you will have two options for a partner. See picture 10. picture 10. Partner connection The partner is the PLC that will receive the data; you will find that you have two options to select from: PLC_2 [CPU 1516-3 PN/DP] Unspecified Because both PLCs are in the same project, when I choose the PLC_2 option, all connection parameters will be automatically filled in. see picture 11. picture 11. PLC_2 as a partner On the other hand, if the partner PLC is from a different project, then I will choose the Unspecified option, and in that case, I will have to fill in some data such as the Partner PLC’s IP address. See picture 12. picture 12. Unspecified Partner As you can see, in that case, I need to fill in some data, such as the IP address and also I need to add a subnet for PLC_1. To add a subnet for PLC_1 we will go to Profinet properties of the PLC_1 and select add subnet option. See picture 13. picture 13. Add subnet. Once that is done, the connection parameter configuration will be done. See picture 14. The connection name should be Unique for each PUT command you make, TIA Portal will automatically give it a new name, but it is maybe better for you to assign a more proper name for the connection in your project. We here kept it as it is. picture 14. Connection parameter is done The next step in the PUT command configuration is the Block parameter setup. In these parameters we specify the trigger for the PUT command, meaning what signal will start the PUT command action. And also what data will be put from PLC_1 and where will it be stored in the PLC_2. See picture 15. picture 15. Block parameter setup For the Start Request (REQ) signal we have defined an input tag (SendData %I0.0). And as we mentioned before we have already defined the tag that will be send to PLC_2 and where it will be stored inside the PLC. Completing the block parameter configuration will conclude the configuration of the PUT command. See picture 16. picture 16. Calling of a PUT command So, in summary, when the REQ signal is triggered, the data in SD_1 will be sent to ADDR_1.

In a previous article, we talked about the PUT command and how we use it to communicate between two PLCs wither they are in the same project or in two different projects. In this article, we are going to talk about the GET command used for the Siemens PLC-to-PLC communication project for data exchange. What is the GET command? Just like the put command a GET command is a TIA Portal built-in function block FB that is used exclusively for S7-Family CPUs to get data from a remote partner PLC to a local PLC. Opposite to the PUT command, instead of putting data from PLC_1 into PLC_2 the GET command will get data from the PLC_2 into PLC_1. When using GET command, I would have two PLCs, where I need to get data from one PLC called partner to another PLC called local. The Local PLC is where the GET command will be programmed. In addition to a Profinet connection between the two PLCs. Some configurations must be done to the partner PLC, to enable it to be accessed by the other PLC. We will create a sample project to show how to use the GET command. Siemens PLC-to-PLC Communication Project We will assume a sample project where we have two PLCs in the same project, PLC_1 which will act as the local PLC and PLC_2 which is the partner PLC. To create a situation where we need to use the GET command, we will assume that we want to read/get an integer from the partner PLC_2 to the local PLC_1. First, let’s create a new project and add the two PLCs. See picture 1. picture 1. Create a new project and add two PLCs. Now, we need to configure the partner PLC_2 to enable the GET access from PLC_1. We also need to prepare the data that will be moved from PLC_2 into PLC_1. First, we need to allow the access of the GET command to the PLC_2 that will give the data. See picture 2. picture 2. Allow GET command access. As you see from the picture, we allow the GET command to access the PLC_2 from the Properties of the PLC_2, in the Protection and security option, click on the “Permit access with PUT/GET communication from remote partner” Now, I am allowed to read/get data from the partner PLC_2 using the GET command. NEXT, we want to create the data that will be moved to the PLC_1, we assumed that PLC_1 wants to get an integer from PLC_2. We will define an integer tag named “ SendDataToPLC_1” this integer tag will be read from PLC_2 into PLC_1. See picture 3. picture 3. Define data to be moved to PLC_1 And that is it; this is the entire configuration you need to prepare from the PLC_2 side to be able to receive data through the GET command. NOW, we go to PLC_1, in PLC_1 we want to create logic where we use the GET command to read data from the PLC_2. As we did in the last article, we will just drag and drop the GET command into our Main OB1. See picture 4. picture 4. Drag and drop the GET command Note that, the GET command is found in the S7 communication folder, as it is an exclusive function for S7 family PLC, because it involves safety issues. Remember in picture 2 when we allowed the use of GET command it was in the Security and Protection attribute of the PLC properties as it is related to PLC safety and protection. When you drag and drop the GET command into your, you will asked to create a data block instance as the GET command is essentially a function block FB. See picture 5. picture 5. Create a data instance for the GET command. Now, that we added the GET command to our logic, we need to start configuring the GET block as we did before with the put command. To open the configuration views of the GET command press the small blue icon on top of the block. See picture 6. picture 6. Open configuration view. We have two main parameters to configure, the connection parameter and the block parameter. See picture 7. picture 7. GET block configuration. As you can see from the picture, the Local PLC is the PLC where the GET command is called. Whereas the Partner PLC is the one that will give the data, it is also the same one which we allowed the GET access for. In our project the partner PLC is PLC_2. You can see also from the picture that the partner is empty and we have to select the PLC. See picture 8. picture 8. Different option in the partner list As you can see, we have two different options to select from for the Partner PLC. Unspecified is when the PLCs are of different TIA Portal project and if the PLCs are of the same TIA Portal project, then you will find the other PLC in the list. When you choose the PLC_2 option as our PLCs are in the same project, the connection configuration will be automatically filled in. See picture 9. picture 9. PLC_2 as partner Because both PLCs are in the same project, when I choose the PLC_2 option, all connection parameters will be automatically filled in. On the other hand, if the partner PLC is from a different project, then I will choose Unspecified option, and in that case I will have to fill in some data such as the Partner PLC IP address. See picture 10. picture 10. Partner PLC as unspecified. As you can see, when the partner is Unspecified, then you will need to manually add some information such as the partner PLC IP address. You can also see that we need to add a subnet to the local PLC_1. To do that, you just go to the Profinet properties of the PLC_1 and select to add a new subnet. See picture 11. Picture 11. Add subnet for PLC_1 After adding a new Subnet to PLC_1, the connection parameter configuration will be complete. See picture 12. picture 12. Connection parameter is complete. The next configuration we need to take care of is the block parameter. In the block parameter we define the data that will be moved between the two PLCs and also the trigger signal that will allow the start of execution of the GET block. See picture 13. picture 13. Block parameter. As you can see, we need to define the trigger signal for the GET block and we also need to define what data will be moved from PLC_2 (Read area ADDR_1) and where will this data go (Store area RD_1). We already define the ADDR_1 before which is the SendDataToPLC_1 integer tag we defined inside PLC_2. NOW, we will define the store area for that integer tag and the trigger signal. See picture 14. picture 14. Define trigger signal and store area After we defined the trigger signal, ADDR_1 and the RD_1, we will fill in these parameter to the block configuration. See picture 15. Picture 15. Fill in the block parameter Now, the configuration of the GET block is finished and you can see that the Block is now ready to be downloaded and run. See picture 16. picture 16. GET block The GET block is now configured and once the trigger signal is active the block will read the ADDR_1 from PLC_2 and write it into RD_1 in PLC_1.