leikang

In previous articles, we talked about timers in PLC, different types, and how to use them. Timers don’t really need real-time to work, as they just depend on counting seconds or milliseconds depending on your settings. But for some applications, you need to know the PLC program’s real date and time for example for diagnostics purposes. In this article, we will talk about the system and local time of a PLC. Contents: Why do I need real-time in PLC? Example program and simulation What is system time? What is local time? Conclusions. Why do I need Real-time in PLC? In many applications of PLCs, you would need to know the real-time while the process is running, for many different reasons. Following are some of these reasons: Backup of the PLC to the main server. For diagnostics of the PLC, you need to have a time record for the diagnostics, to know at which time a certain event has occurred, otherwise, diagnostics information wouldn’t be very useful. For applications where you need to work with the time of day interrupts OB10 you would need to know the actual time. You might need to use local time or system time in parts of your logic where you need to handle real-time applications. For data logging, if you have important data to save and you need the time stamp for each data recording, then you need to have the right time setting for your PLC so that stored data would make sense. PLC Example Program and Simulation To better understand what is system time and local time in a PLC, we will start by creating a very simple program and use it to explain the concept of real times inside PLCs. Check the following step: In this article, we will not create any PLC logic, but we will show some configurations that are related to the system and local time in PLC, how to set them, and what are the differences. Open Siemens Tia Portal, Add a new device, and this time we will use the CPU 1512C-1 PN. See picture 1. Picture 1 – Add new PLC Compile and start a new PLC simulation. open the online & diagnostics page and check the set time of the PLC. See picture 2. Picture 2 – Online time of the PLC From the previous picture you can see that there are two different times: The PG/PC time – this is the local time of your PC itself. The Module time – this is the actual time inside the PLC itself. Both these times can be set as the same value, or they can be different. it is best to make them the same, it is better to make the module time similar to your local time, or more specifically similar to the local time of the area where the PLC will be used. See picture 3. Picture 3 – Set time of the PLC If you want module time to be the same as local time, then select Take from PG/PC and press apply. In your main OB1, drag and drop the RD_SYS_T and RD_LOC_T instructions. These are the read system time and read local time instructions. These instructions are built-in functions FCs inside the PLC and they are used to write the local time and system time of the PLC to whichever destination you choose in the output OUT of the instruction. see picture 4. Picture 4 – Add read system and local time instructions Add a new global data block, and define some tags to work with. See picture 5. Picture 5 – Create a new global data block Run your simulation again and check both times. See pictures 6 Picture 6 – Online local and system time of the PLC You see from the previous picture that the local time and system time of the PLC is the same, but they are different from the actual local time of your PC. If you remember, we have set the module time of the PLC to be similar to the PG/PC time, which is your local time. See picture 7. Picture 7 – Module time and PG/PC time As you see, on the set time page the module time is chosen to be taken from PG/PC time. But then in actual cases, they are different. Why? Why times are different? Because the default setting of the PLC local time is the UTC+0 or the Zulu time if you’re familiar with that term, you don’t change it from the online and diagnostics page, but rather from the properties of the PLC itself. See picture 8. Picture 8 – Time of day configuration in a PLC As you can see, the default setting of the PLC time of day is set to UTC+0 time, and that is why the PLC module time was different from your actual local time. Except if you were actually in London, then you wouldn’t face this problem. To correct the PLC local time we have to change that in the configuration, we need to change the time zone to the time zone we have, which is in my case the UTC+02:00. See picture 9. Picture 9 – Adjusting PLC local time to your time zone You can also see that the daylight saving time option was deactivated because it is not used in my country. You will have to activate it if it is used in your area. Now that all configurations are set correctly, go back and see the local time and system time again in the simulation. See picture 10. Picture 10 – The local time of PLC is now the same as PC You see now after adjusting the PLC time zone, the local time of the PLC and the actual local time of your area is the same. As we said before it is very important to set the right local time of the PLC, for the many reasons we mentioned above. Can you now define what is the system time and local time of the PLC? System Time in PLC Is the module time of the CPU clock. The CPU clock interprets the module time as the coordinated universal time (UTC). Accordingly, the module time is always stored without the factors “local time zone” or “summer time” in the CPU clock. The CPU clock then calculates the local time of the CPU clock based on the module time. The module time of the CPU clock is used as a template for all time processes starting from the CPU. Examples of use: Calculation of local time of CPU clock based on module time Representation of the module time in local time under “Online & Diagnostics” Entries in the diagnostics buffer of the CPU Local Time in PLC Information on the time zone and the start of daylight saving time and standard time, which you have set in the configuration of the CPU clock, is used to output the local time. Local time is the time you have on your PC or in your country which will be different from one area to another. Conclusion Many applications will require that the PLC would know the real-time or local time of the process, so that it would be able to perform certain tasks, for example, data logging and diagnostics tasks. In a future article, we will show some applications where real-time is needed for your logic The local time of the PLC should be manually configured to match the area where the PLC will be used.

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 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.

When you are working with PLC, you need to know what types of voltages are generally available in it; so that you can do the wiring accordingly. Not just power supply, but we must also be related to the input and output voltage required. Every PLC manufacturer has their own set of voltage and current ranges according to the module and CPU they provide. In this article, we will learn the PLC operating voltages generally available everywhere. PLC Power Supply In standard, PLC operates in four types of voltages – 24V DC, 24V AC, 110V AC, and 240V AC. In some PLCs, only the CPU requires a power supply and the IO modules get supply from the CPU backplane, whereas in some PLCs, all the modules including CPU, inputs, and outputs require a power supply. In any case, you will require a SMPS or transformer in the PLC panel, for converting raw power voltage. In AC supply voltage, some PLC’s offer a range of voltage from 110-240V AC. Every power supply point in the PLC has an earthing point, for providing safety to the PLC in case of any surge or short circuit. When an AC supply is used, it is mostly equipped with a protective fuse inside. DC supply too has a fuse inside, but for AC supply, it is compulsory to use it for the high amount of voltage involved. When the rated voltage is given in the CPU, it means that the voltage you are providing has been stabilized properly and controlled to a great extent. But, it is not practical for voltage to remain constant at 24V or 240V. So, a range of rated voltage comes for a PLC like 20-28V DC or 220V-245V AC. This range is predefined in every PLC so that you get an area of power supply for working with them efficiently, without any problem. Power Supply for IO Modules Now, let us come to our next topic for the power supply required for IO modules. As discussed earlier, two types of power supplies are available – one where the module is powered by the CPU backplane itself and one where the module requires an external power supply. When using the backplane, every CPU has a rating for mA that it will provide as a load to the modules connected. For example, if a CPU has a rating of 24VDC – 450mA, then it will also specify that the CPU backplane can provide this much of current to the IO modules and you can connect only that amount of modules with the CPU rack. Also, each module will specify how much current it will take when connected on a backplane bus. This can help you select the appropriate modules and CPU for a specific application. Coming to the second type of power supply, there are some modules that require an external power supply. So, in that case, you have to choose an SMPS or transformer with a higher current and load rating accordingly. This can, in turn, power up both the CPU and modules properly and also power up other components of the panel which require the same supply. Power Supply for Field Instruments Field wiring for a PLC also mostly requires DC voltage for instruments and AC voltage for high-power devices. So, the above four voltages mentioned earlier work the same for IO module common supply wiring. Also, remember that there is mostly a battery backup inside the PLC apart from the standard power supply. This ensures that the program inside the memory of the PLC remains intact in case of any power outage. Power Supply Selection for PLC When selecting the power supply, it is thus necessary to consider the following parameters generally – rated voltage, rated current, rated power, ripple and noise, voltage adjustable range, voltage tolerance, line regulation, and load regulation. Once you have selected the right power supply, you can then wire the CPU and modules to power it up properly. In this way, we understand the concept of PLC operating voltages.

Programmable logic controllers (PLC) and programmable automation controllers (PAC) are two types of industrial controllers used to automate processes and machines in manufacturing, processing, and other industrial applications. Both types of controllers have similar functions, but there are also significant differences between them. In this article, we will take about the differences, similarities, and examples of PLC and PAC. Contents: What are PLCs? What are PACs? Similarities between PLC and PAC. Differences between PLC and PAC. Examples of PLC models from various vendors. Examples of PAC models from various vendors. When is a PLC best fit? And when is a PAC? Conclusion What is a PLC? PLC stands for Programmable Logic Controller, which is a specialized industrial computer used for automation control systems. PLC is designed to operate in harsh environments and are used to control machinery in manufacturing plants, assembly lines, and other industrial settings. PLC can be programmed using 5 different languages such as ladder logic, function block diagrams, structure text, instruction list, and sequential charts. These 5 languages are approved and applied as per the IEC 61131-3 standards. What is a PAC? PAC stands for Programmable Automation Controller, which is similar to a PLC but has more advanced functionality. PAC combines the capabilities of a traditional PLC with the ability to perform much more complicated tasks and communicate with other devices and systems, making them more flexible and powerful than PLC. PAC is typically used for more complex automation and control applications in industries such as automotive, aerospace, and power generation. PAC can be programmed using the same 5 languages as PLC but also they can be programmed using C and C++, giving them the ability to handle coding more complex algorithms. Similarities between PLC and PAC The similarities between PLC are PAC are too many that it is difficult sometimes to tell if they are even different. Although there is still some difference between them. The similarities they share can be even more. Here are some of the common points between PLC and PAC: Core Functionality Both PLC and PAC are designed to provide reliable and accurate control of industrial automation systems. They are used to monitor inputs from sensors and other devices, process the information, and then output control signals to actuators and other equipment. Programming Both PLC and PAC use programming languages to create control logic that determines the behavior of the automation system. They share the 5 programming languages defined in the IEC 61131-3 standards, but PAC offer more programming language options including C and C++. Durability Both PLC and PAC are built to withstand harsh industrial environments, such as temperature extremes, humidity, and vibration. They are designed to be rugged and reliable, with long lifetimes and lower maintenance requirements. Modular Design Both PLC and PAC have a modular design, which allows for easy expansion and customization. Modules can be added or removed to meet specific requirements. Industry Standards Both PLC and PAC are built to meet industry standards for automation and control systems, such as IEC 61131. These standards ensure interoperability between devices and systems from different manufacturers. Differences between PLC and PAC The distinction between PAC and PLC can be somewhat blurry. While there is no definition of what constitutes a PAC, there are some common characteristics that differentiate PAC from PLC: Functionality While both PLC and PAC are used for automation and control applications, PAC have more advanced functionality such as motion control, process control, and data acquisition. PAC also typically have more processing power and memory than PLC. Connectivity PAC have more advanced connectivity options than PLC, including Ethernet, USB, and wireless. This makes it easier to integrate them into larger automation systems and to communicate with other devices and systems. Cost Because of their more advanced functionality and flexibility, PAC are generally more expensive than PLC. More Advanced Features PAC often have more advanced software features than PLC, such as integrated motion control, data logging, and advanced diagnostic tools. These features make it easier for engineers and technicians to monitor and troubleshoot the control system. Examples of PLC Models from various Vendors Siemens S7-1500 PLC: This is a high-performance PLC from Siemens, one of the leading automation vendors. It is designed for demanding applications and offers advanced functions such as motion control, safety, and security. See picture 1. Picture 1 – SIEMENS S7-1500 PLC Allen-Bradley CompactLogix 5370 PLC: This is a versatile PLC from Rockwell Automation that offers a wide range of I/O options and communication protocols. It is suitable for a variety of applications, including machine control and process automation. See picture 2. Picture 2 – Allen-Bradley CompactLogix 5370 PLC Mitsubishi Electric Q Series PLC: This is a reliable PLC from Mitsubishi Electric that offers high-speed processing, flexible I/O options, and advanced programming capabilities. It is suitable for a variety of applications, including automotive, food and beverage, and pharmaceuticals. See picture 3. Picture 3 – Mitsubishi Electric Q Series PLC Omron NJ Series PLC: This is a high-speed, high-performance PLC from Omron that offers advanced motion control and network capabilities. It is suitable for a variety of applications, including packaging, printing, and semiconductor manufacturing. See picture 4. Picture 4 – Omron NJ Series PLC Beckhoff TwinCAT PLC: This is a software-based PLC from Beckhoff that runs on a PC-based platform. It offers advanced functions such as motion control, CNC, and robotics, and is suitable for a variety of applications, including machine control and process automation. See picture 5. Picture 5 – Beckhoff TwinCAT CX9240 PC-based PLC Examples of PAC Models from various Vendors Emerson DeltaV DCS PAC: This is a distributed control system (DCS) PAC from Emerson. It is designed for complex continuous control applications and offers advanced functions such as process modeling, batch management, and advanced control. See picture 6. Picture 6 – Emerson DeltaV DCS PAC Schneider Electric Modicon M340 PAC: This is a high-performance PAC from Schneider Electric that offers advanced functions such as motion control, safety, and cybersecurity. It is suitable for a variety of applications, including energy, water treatment, and mining. See picture 7. Picture 7 – Modicon M340 PAC Some other examples of PAC are as follows: ABB AC 800M PAC Yokogawa ProSafe-RS PAC Phoenix Contact PLCnext Technology PAC Bosch Rexroth IndraMotion MLC PAC When is a PLC best fit? And when is a PAC? PLC and PAC are used in different types of automation applications depending on the specific requirements of that application. Here are some general guidelines on where a PLC is best fit and where a PAC is the best fit: PLCs are the best fit at: Discrete control applications: PLCs are best suited for applications that involve discrete control, such as controlling the operation of a conveyor, sorting equipment, or packaging machinery. Simple control systems: PLCs are ideal for applications that have a relatively simple control system that can be programmed using ladder logic or other similar programming languages. Cost-sensitive applications: PLCs are generally less expensive than PACs, which makes them a good choice for applications where cost is a significant factor. Small to medium-sized systems: PLCs are suitable for small to medium-sized control systems, where the number of inputs and outputs is relatively low. A conveyor system in a manufacturing plant is a good example of an automation system where a PLC is the best fit. In this application, the PLC is responsible for controlling the speed and direction of the conveyor, as well as monitoring the status of sensors and other equipment along the conveyor line. The PLC can also be programmed to handle specific production tasks such as sorting, counting, or packing. A conveyor system typically has a fixed structure and a well-defined set of operations that need to be executed in a sequential manner. PLC are well-suited for this type of application because they are designed to handle discrete control tasks and are very reliable in their operation. PLC can be easily programmed and configured to handle different types of sensors, actuators, and communication protocols. PACs are best fit at: Process control applications: PAC best suited for applications that involve process control, such as controlling the operation of a chemical plant, water treatment plant, or power plant. Complex control systems: PAC ideal for applications that have a complex control system that requires advanced algorithms and optimization functions. Large-scale systems: PAC suitable for large-scale control systems, where the number of inputs and outputs is high and the system is distributed over a large area. High-performance applications: PAC capable of handling high-performance applications that require fast data processing, real-time control, and high reliability. A power plant control system is a good example of an automation system where a PAC is the best fit. In this application, the PAC is responsible for controlling and monitoring a large number of complex processes and equipment, such as turbines, generators, boilers, and pumps. The PAC is also responsible for collecting and analyzing data from various sensors and other sources and making decisions based on that data to optimize the plant’s performance. A power plant control system is a very complex and dynamic environment, with many different processes and equipment operating simultaneously. PAC are well-suited for this type of application because they offer advanced functions such as distributed control, redundancy, and fault tolerance, which are essential for ensuring the reliability and safety of the plant. PAC can handle large amounts of data and can be programmed to perform complex algorithms and optimization tasks. Conclusion PLC and PAC are both used in industrial automation applications. They have different capabilities and are best suited for different types of applications. When selecting between PLC and PAC, it is essential to consider the specific requirements of the application. PLC typically used in discrete control applications that have a relatively simple control system. PAC used in process control applications that have a complex control system and require advanced algorithms and optimization functions.

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.

When you hear about PLC programming, the five used languages in it are – ladder logic, structured text, functional block diagram, sequential flow chart, and instruction list. Any language, once understood, can be used for writing an application code and running a machine properly. Best PLC Programming Language Figure – Sample Ladder Logic But often, new PLC programmers get confused as to what to use for writing a program. If he understands a language’s advantages and disadvantages, then he can easily determine what to use for writing a PLC program. So, it is necessary to understand the difference between them and define which language to use for coding. In this post, we will see which language is best for PLC programming. Ladder Logic Ladder Logic is the most basic type of PLC programming language. It can easily be correlated to an electrical wiring control diagram. Traditionally, electrical control wiring was used to operate outputs according to the inputs provided. The ladder Logic drawing consisting of contacts and coils was implemented in the same way in the ladder logic programming. You have a series of rungs, each rung having contacts and coils. When the rung is powered up, the coil, depending upon its type, operates accordingly. You can write as many rungs as required in a program and the code will execute accordingly. When you see it, the resemblance is similar to a ladder, and thus, the name is given ladder logic. Refer to the below diagram for understanding. You can see how simple it is to get through. In the above illustration, inputs associated with a switching device in the relay logic diagram are shown as contacts in the Ladder Diagram. The M1 output coil in the relay logic diagram is represented with an output coil symbol in the Ladder Diagram. The address numbers appearing above each contact/coil symbol in the Ladder Diagram are references to the locations of the external input/output connections to the logic controller. So, in between two end power rails, you can place the required elements and write the logic in them. The rungs execute in a cyclic manner from top to bottom. Structured Text Structured Text can be said as the local IT-level language. The resemblance of structured text language is very similar to codes that we write in a software language. As the name implies, Structured Text is a series of texts written in an assignment way. Instructions must be terminated with semicolons. When an assignment is performed, the current value of a single or multi-element variable is replaced by the result of the evaluation of the expression. An assignment consists of a variable specification on the left side, followed by the assignment operator: =, followed by the expression to be evaluated. Both variables (left and right sides of the assignment operator) must have the same data type. Refer to the below diagram for understanding. As you can see, it has different types of operations and conditions. In the above example, an if-else statement is used to evaluate an expression. If the condition is true, then the variable assigned on the output side turns on and when the condition goes false, then the variable will turn off. ST language is thus best for mathematical calculations, as it looks sober and easy to understand. Sequential Flow Chart A sequential Flow Chart is the most advanced tool when you want to write complex programs in a repetitive way or sequential way. As the name implies, SFC language allows you to write a program through a flow chart. It works in steps, branches, links, jumps, and transitions. An SFC section is a “Status Machine”, i.e. the status is created by the active step and the transitions pass on the switch/change behavior. Steps and transitions are linked to one another through directional links. Two steps can never be directly linked and must always be separated by a transition. The active signal status processes take place along the directional links and are triggered by switching a transition. Refer to the below image for understanding. The direction of the chain process follows the directional links and runs from the end of the preceding step to the top of the next step. Branches are processed from left to right. Every step has zero or more actions. A transition condition is necessary for every transition. The last transition in the chain is always connected to another step in the chain (via a graphic link or jump symbol) to create a closed loop. Step chains are therefore processed cyclically. Functional Block Diagram The Functional Block Diagram (FBD) language that is generally used in microprocessors, is available in a similar format in PLC programming too. It is a diagram of blocks connected with each other, with each block having its input and output. FBD language is very easy to troubleshoot because you can literally view the whole code in a single view, rather than scrolling up and down. This helps in quick maintenance and also increases the efficiency of the programming. Refer to the below image for understanding. As you can see, you can connect various types of functions and blocks easily by lines, which shows how a flow is happening in the logic. You just have to assign input and output pins, connect the lines between these pins and your code works accordingly. Instruction List A program written in Instruction List language consists of a series of instructions that are executed sequentially by the logic controller. Each instruction is represented by a single program line and consists of the following components – line number, current value which can be seen online only, instruction operator, and operand. Refer to the below image for understanding. You can see that each line executes one single operation only. Instead of contacts and coils used in ladder logic, you have load instructions and set/reset instructions corresponding. It is a mixture of ladder logic and structured text. That is why, it is also called as similar to an assembly language. When you go online in the PLC, you can see animated values in this window. When we see these five languages, we see that the most ones that are generally used by programmers are ladder logic, structured text, and functional block diagram. Every language has its merits and demerits. But, these three are simple to understand, interpret, and design. This helps the programmer in designing the logic properly. That does not mean that the remaining two languages are not used. It depends on the skills of the programmer on what he has to use to implement the coding. So, it is difficult to comment on the best language; but yes, out of these three too, the most used is the ladder logic.

When you develop a PLC logic, you always need timers and counters. Any cycle in an automation process is generally incomplete without the use of timers and counters. You need them to execute a task after a certain time or keep the task on / off for a certain time. Its use depends on the application to be developed. And, before going deeply into advanced instructions of PLC, a programmer must first understand these basic blocks to implement them properly and to get assistance in learning the advanced blocks more easily. In this article, we will learn the difference between timers and counters in PLC programming. What is a Timer? A timer is an instruction that is used to turn on or off an output after a certain delay. For example, if you want to turn on a lamp after 5 seconds, then use a timer to execute this task. A timer will take an input and when the input turns on, then its timing will start. After the time of 5 seconds elapses, then the timer output will turn on which turns on the lamp indirectly. This we are talking about is the normal timer on the type. A timer has more two types – timer off and pulse timer. In short, the basic function is the same – execute a task after a certain delay. Refer to the above image for understanding more correctly. A timer has four inputs and outputs – input, set value, current value, and output. An input takes the condition for starting a timer, a set value is used to take the set timer value, the current value shows the current timer value running and the output is used to turn on or off the variable connected to it. When the PLC timer gets the input and if the set value is 5 seconds, the timer starts as 1, 2, and 3, and so on till 5. When 5 seconds have been completed, the output turns on. When the input goes off, the timer’s current value immediately goes to zero. Whether the timer was running or not; if the input is off, then the timer will not start and its output and current value will be zero. This is the functioning of a TON (timer on delay) timer. What is a Counter? A counter is an instruction that is used to turn on an output after a set count has been reached. The count can either increment or decrement. For example, if you want to turn on a lamp after a push button has been pressed five times, then use a counter to execute this task. A counter will take an input and when the input turns on, then its count will increment to 1. When the input goes off, nothing will happen. When it again receives the input, the count will increment to 2. After the count of 5 elapses, then the counter output will turn on which turns on the lamp indirectly. This we are talking about is the counter-up type. A counter has one more type – counter down. In short, the basic function is the same – execute a task after a certain count. Refer to the above image for understanding more correctly. A counter has five inputs and outputs – count input, reset input, set value, current value, and output. A count input takes the condition for counting, reset input takes the condition for resetting the counter, the set value is used to take the set counter value, the current value shows the current counter value running and the output is used to turn on or off the variable connected to it. When the counter gets the count input and if the set value is 5, the counter increments to 1 and so on till 5; at the receipt of each pulse in the count input (means the count input will have to be turned on and off 5 times). When 5 counts have been completed, the output turns on. Now, even if the count input pulse is given, the counter will go on increasing after 5 and the output too will remain on. To again bring back the counter state to zero, you have to give reset input. When this input is given, the counter current value becomes zero and the output too turns off. So, it is similar to latching-type functioning. To unlatch the counter, you will have to reset it. This is the functioning of a CTU (count up) counter. Difference between Timer and Counter The main differences between timers and counters in a PLC are as follows. A timer needs to have its input continuously for turning on a variable, but a counter need not to have its input continuously. So, a timer works on continuous conditions, whereas a counter works on pulse conditions. If the timer input is removed, then its output will go back to zero states; but if the counter input is removed, then to the counter will hold its last value. A timer does not have reset input, whereas a counter requires reset input to get back the counter to its original state. The types of timers are – timer on, timer off, and timer pulse. The types of counters are – counter up and counter down. A timer set value can be in seconds, minutes, or milliseconds; but a counter set value is a fixed integer.

In this advanced PLC logic, detect different part sizes and sort them as per box sizes and place them in the trays. The parts are nothing but different size boxes such as small, medium, and large. The robot places different size boxes randomly on the conveyor. Then the system detects the box size and moves to the respective conveyor and places them in the respective trays. Sorting & Distribution Line PLC Programming The below simulation shows the sorting and distribution line system operation. Inputs and Outputs Type Device No. Device name Operation Input X0 Starting point (Supply) ON when the part is detected. Input X1 Upper ON when the part is detected. Input X2 Middle ON when the part is detected. Input X3 Lower ON when the part is detected at the right end. Input X4 Sensor ON when the part is detected at the right end. Input X5 Sensor The conveyor moves forward when Y1 is ON. Input X6 Detect part ON when the part is detected in front of the pusher. Input X10 arting point (Unload) ON when the unloading robot is at the start point. Input X11 Part on table ON when the part is on the table. Input X12 Robot operation finished ON when the robot operation is finished. Output Y1 Conveyor forward The conveyor moves forward when Y2 is ON. Output Y2 Conveyor forward Moves toward the front when Y3 is ON. Output Y3 rting wing The conveyor moves forward when Y4 is ON. Output Y4 Conveyor forward The conveyor moves forward when Y5 is ON. Output Y5 Conveyor forward Extends when Y6 is ON and retracts when Y6 is OFF. The pusher cannot be stopped in the mid-stroke. Output Y6 Pusher The robot moves part to tray when Y7 is ON. A process cycle begins. Output Y7 Unload command The robot moves the part to tray when Y7 is ON. A process cycle begins. Output Y10 Red Lit when Y10 is ON. Output Y11 Green Lit when Y11 is ON. Output Y12 Yellow Lit when Y12 is ON. Program Description Initiating the push button PB1 (X20) on the control panel triggers the Supply command (Y0), thereby setting the robot in motion for moving the object. Once the robot has completed its task of moving the part and reverting to its original position, the Supply command (Y0) is deactivated. Activating the Supply command (Y0) propels the robot to provide a part. Activating the switch SW1 (X24) on the control panel instigates the conveyors to proceed forward. Conversely, deactivating the switch causes the conveyors to halt. Conveyor-carried parts of varying sizes, namely large, medium, and small, are sorted by input from the Upper (X1), Middle (X2), and Lower (X3) sensors and delivered to designated trays. Large parts are directed to the rear conveyor when the Sorting wing (Y3) on the split conveyor is activated, followed by the part being transported on the conveyor and eventually descending from the right edge. Medium parts are led to the front conveyor when the Sorting wing (Y3) on the split conveyor is deactivated and subsequently transferred to the tray by the robot. Small parts are routed to the rear conveyor upon activation of the Sorting wing (Y3) on the split conveyor. Once the Detect part sensor (X6) in the split conveyor is activated, the conveyor is brought to a halt and the part is nudged onto the tray. When the Robot detects a part on the table (X11), the Unload command (Y7) is activated. Once the robot finishes its operations, indicated by the Robot operation finished (X12) status turning on (which happens when a part is deposited on the tray), the Unload command (Y7) is deactivated. Provided the switch SW2 (X25) on the control panel remains activated, an automatic supply of a new part occurs under the following conditions: When the robot initiates the transportation of a medium part. When a small part is added to the tray, or a large part descends from the right edge of the conveyor. The display lights flash in the following manner: The red light indicates the robot is in the process of supplying a part. Green light signifies the conveyor is in motion. Yellow light is illuminated when the conveyor is at a standstill. PLC Program

In this advanced PLC program, PLC based product sorting machine system is used to carry different products using the lift to separate the parts based on size. Here there are three positions available based on the size like small, medium, and large. The conveyors are used to transfer the products and place them on the trays. PLC Based Product Sorting Machine System The below simulation shows the PLC sorting system using the lift operation. Inputs and Outputs Type Device No. Device name Operation Input X0 Upper ON when part is detected. Input X1 Middle ON when the lift is at a lower position. Input X2 Lower ON when the part is detected. Input X3 Part on lift ON when the part is detected. Input X4 Lower lift position ON when the lift is at the middle position. Input X5 Middle lift position ON when the lift is at middle position. Input X6 Upper lift position ON when the part is on the lift. Input X10 Sensor ON when the part is detected at the left end. Input X11 Sensor ON when the part is detected at the left end. Input X12 Sensor ON when the part is detected at the right end. Input X13 Sensor ON when the part is detected at the left end. Input X14 Sensor ON when the part is detected at the right end. Input X15 Sensor ON when the lift is at the upper position. Output YO Supply command One part is supplied when YO is ON: Metal cylinder repeats in order S, L, M, L, M, S. Output Y1 Conveyor forward ON when the part is detected at the right end. Output Y2 Lift up command The lift moves up when Y2 is ON. The lift stops when Y2 is OFF. Output Y3 Lift down command The lift moves down when Y3 is ON. The lift stops when Y3 is OFF. Output Y4 Lift rotation command The conveyor moves forward when Y1 is ON. Output Y5 Lower conveyor forward Lift rotates to transfer part to conveyor when Y4 is ON. Lifts rotates back to the original position when Y4 is OFF. Output Y6 Middle conveyor forward The conveyor moves forward when Y5 is ON. Output Y7 Upper conveyor forward The conveyor moves forward when Y6 is ON. Program Description The entire system comprises two components: General Control and Lifter Management. General Control: Activating the PB1 (X20) button on the operational panel initiates the Supply command (Y0) for the hopper. Deactivating the PB1 (X20) button turns the Supply command (Y0) off. Upon activation of the Supply command (Y0), the hopper delivers a part. The conveyors initiate movement when the SW1 (X24) on the control panel is activated. Conversely, the conveyors halt movement when the SW1 (X24) is deactivated. Upon detecting a part by the sensor X10, X12, or X14 positioned to the left of the conveyor, the corresponding conveyor initiates, transporting the part to the right-end tray. Three seconds post a part passing by the sensor X11, X13, or X15 to the right of the conveyor, the conveyor halts. Parts of varying sizes (large, medium, small) on the conveyor are sorted by the inputs of the Upper (X0), Middle (X1), and Lower (X2) sensors. Lifter Management: Once the Part on the lift sensor (X3) in the lift is activated, the part is transported to one of the following conveyors based on its size: Large part: Directed to the Upper conveyor Medium part: Directed to the Medium conveyor Small part: Directed to the Lower conveyor The commands for Lifting Up (Y2) and Lifting Down (Y3) are managed based on the lift’s position, detected by the following sensors: Upper: X6 Middle: X5 Lower: X4 Upon the part’s transfer from the lift to the conveyor, the Lifter Rotation command (Y4) is initiated. Post the transfer of a part, the lift returns to its initial position and remains on standby. PLC Logic

When you are working in a PLC system, it is necessary to understand what faults occur in the PLC modules. If a PLC programmer does not understand what fault is coming in the PLC and how to solve it, then he will take a very long time to troubleshoot the system. Every PLC and its modules have LEDs on them for visual easing and troubleshooting. Their detailed description is also given in their user manuals. So, it is important to understand how these LEDs function and once you get them, fault diagnosis becomes a very easy task for PLC programmers. In this post, we will learn the concept of fault diagnosis in PLC. PLC Fault Diagnosis Let us have a look at some of the most general types of faults which can be identified with PLC LED’s: Run LED is used to denote whether the module is functioning properly or not. If it is on continuously, then it means that the module is working properly. If this LED is off, then the module is faulty or off. Err LED is used to denote whether the module is in error or not. If it is on continuously, then it is an internal module error. If it is flashing, then it means either the module is not configured properly or there is some issue in the PLC hardware connected to it. If it is off, then it means there is no fault in the module. I/O LED is used to denote the exact status of the PLC IOs connected with the module. If it is on continuously, then it means there is some supply voltage error or short circuit. If it is off, then it means there is no error in the IO’s connected. Channel LED is used to show the status of individual channels. If the LED is on continuously, then it means the channel is functioning properly. If it is flashing, then there is some error in it (broken wire or value out of range). If it is off, then it means the channel is not configured at all. Some communication modules like Modbus RTU have a truth table of the LEDs, signifying each value of the same. LED Indications in PLC They are mostly as in the below table: Note: The LED indications may vary based on the PLC model and brand. The above table is an example from one of the PLC models in the market. Some communication modules like Modbus TCP/IP have slightly complicated LED diagnostics. But it is important to understand them for troubleshooting. The module is running if the run LED is on and stopped if the LED is off. If Err LED is flashing, then it means the module is in error and if it is flashing, then it means either the module is not configured properly or there is some issue in the backplane if it is connected. If the network status LED is off, then it means that the module is not communicating with any device; if it is on, then it is communicating with at least one device; if it flashing, then it means some duplicate IP address has been detected or some time out error. In this way, we saw some general fault diagnoses in PLC.

When you are working in a PLC system, you know that the most basic thing to take care of is memory. What program you write, and how much memory has been consumed; is a very important factors in determining PLC performance. For this, it is necessary to understand how memory structure is organized and defined in a PLC. PLC Memory Organization Without knowledge of memory organization, it would be difficult to predict how much exact program you have to write. In this post, we will see memory organization in PLC. Memory in a PLC is divided majorly into two types – data files and program files. Data Files The data file is the location of memory which stores information like memory words, status words, input variables, output variables, communication variables, timers, counters, and other in-built library functions provided by the PLC manufacturer. Let us have a look at each example one by one. Memory words – Memory words are Boolean variables, integer variables, double integer variables, and floating variables. Suppose a PLC has allocated 100 memory variables for usage. Out of these, only 5 variables are used. The first variable is bit type, storing either 0 or 1. The second variable is an integer, signed or unsigned. The third variable is also an integer. The fourth variable is a double integer, signed or unsigned. If a variable is a double integer or float, it consumes two memory variables. So, the fifth memory variable will be a double integer. Status words – Status words store information about PLC. It comes in two types – status bits and status integers. Input variables – They store data regarding digital inputs and analog inputs of the PLC. Output variables – They store data regarding digital outputs and analog outputs of the PLC. Communication variables – They store data regarding communication protocols used in PLC. They can be Modbus, Ethernet, Can-Open, etc. Apart from these, other in-built libraries if used to come in data files memory. They are timers, counters, pulse blocks, etc. Program Files As the name defines, program files store data regarding logic written, subroutines, and interrupts. This is the main consuming part of memory in PLC. If the PLC code written is more, then program file consumption will be large and if the code written is less, then program file consumption will be less. All the logic, be it a ladder, functional block diagram, structured text, sequential flow chart, or instruction list, comes in program files memory. Also, user-defined function blocks and user-defined data types come in program files. Memory organization in PLC is stored in either internal storage or internal and external SD cards. When there arises a situation where the internal memory storage is getting full and you need more data for the writing PLC program, then you need to insert an external SD card for extending program memory. In that case, both the data files and program files are extended. Many PLCs have an online animation window, which shows current memory usage. It can be viewed either online or offline. This helps in better memory planning.

Be it industrial automation or any other PLC system, every device or equipment reaches a stage after a certain period of time, where there arises a need to either change it or upgrade it. Upgrading and Migration A PLC, if served for more than 10 years for example, will reach a stage where its technical support no longer exists or the PLC is not available for replacement as it has become obsolete. In this case, you are left with two options – either to migrate to a completely new set of PLCs or upgrade the firmware and program. This difference is really important to understand, as it helps in choosing the right work for the same. In this post, we will learn the difference between upgrading and migrating PLC systems and understand how to implement the correct one. Why is Migrating or Upgrading PLC Systems Required? Before going into the topic, it is first of all necessary to understand why we need to do the same. Suppose you have been using an “X” PLC for almost 15 years down the line. It is not like the program will start to malfunction suddenly; it is a completely different theory and entirely depends on how the programmer has written the code. PLC Code once written executes the same way for a lifetime as it is. The issue starts with hardware and support. A PLC manufacturer mostly won’t keep this “X” PLC in production for such a long period of time if it is not stable or has many limitations in programming. Sooner, this PLC will start to become obsolete and its replacement will not be available. Even the system integrator or the PLC manufacturer itself will not be able to provide its technical support as the staff for the same will be shifted to a newer brand or its programming cable is also no longer available. In that case, if suddenly the PLC system fails due to some reason, then you are left with no option but to wait for a longer downtime period to end. Also, if you are still able to get this PLC from somewhere, then its cost will be super-high and out of budget. With the current supply chain disruptions and the recent scarcity of new industrial automation solutions and parts, it’s not feasible to estimate exactly how long it might take to source a new unit. In that case, you are left with two options – either to migrate to another brand or upgrade the existing one to a newer firmware CPU or program. So, it is this reason why migration and upgradation play an important role in industrial automation. Also, new solutions bring with them reduced errors, and risks, stronger technical support, service expertise, less capital investment, and efficient operation of plant. What is the Migration of the PLC System? First of all, let us understand the simpler one of the two. Migration means to completely replace an old system with a new system. This is similar to a citizen migrating from his previous city to a new city. Suppose you have an old PLC that has some hardware defects in it after it has been found 10 years old. Two digital inputs of the CPU have become faulty and the CPU is no longer available in the market. Also, due to some bad luck, the system integrator which provided the PLC has shut down his business or shifted to some newer brands. In that case, migrating means you will need to buy a PLC of some other brand. Before buying, you will need to consider factors like IO counts, IO wiring, communication port availability, programming capacity, memory capacity, speed of execution, how much it can be expanded, etc. Once you get through all this, you will then need to buy a new one and write a new program in it according to the manufacturer’s software. Also, you need to share the previous IO list with the new vendor, so that he will do the IO mapping in PLC accordingly and will reduce time to wire the IO’s in the electrical panel. Once done, you can replace the old PLC with the new one and use the system accordingly. Although new and consistent programming standards can’t be fully applied using this approach, the overall functionality remains as close to the original as possible, and the program can be improved to some extent. What is Upgrading of PLC Systems? Let us take a second case of upgrading the PLC system. You have the same PLC of the manufacturer as discussed before and its failure has occurred. Now, you find that some higher level of PLC of the same manufacturer is available, with similar coding style and IO functionalities. Even the vendor is available for support. Instead of changing the vendor to a newer one or completely changing the PLC brand, you will just need to upgrade your system to a newer and higher one. This new CPU will have to be either rewritten with the new coding or just plugged and played, depending on the software. An upgrade thus, requires a more comprehensive IO wiring and PLC coding to be done as we update the system. Also, rewriting new codes from scratch allows the programmer to eliminate the bugs he had observed in older systems and also plan for efficient and reliable logic in a simpler manner. This is a clean slate approach to upgrading a system. Difference between Migrating and Upgrading PLC systems Migration means switching to a completely new PLC manufacturer, whereas upgrading means switching to a newer CPU of the same PLC manufacturer. Migration is cheaper than upgrading, as it requires less downtime, less new hardware, less programming time, and designing infrastructure. Migration is less risky than upgrading, as you already have the program available of the older one, and you just need to copy-paste the same. Though 100% copy is not possible, functionalities can be similar in a large way due to this approach. Migration can lead to new hardware and this can take time for engineers to understand the system quickly so that then they can maintain and troubleshoot it. In this case, upgradation is much easier. Migration is less reliable and efficient than upgrading because you do not know how this new PLC will function now in spite of studying it so much. Migrating and upgrading is a tricky thing to do and requires the detailed expertise of engineers and programmers involved in it. Also, what action to take varies from system to system. Once done, it can make your task completely easier. In this way, we saw the concept of upgrading and migrating PLC systems.

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.

In this article, you will learn the PLC example to control LEDs via switches and understand the ladder logic explanation. This PLC example is designed for engineering students to learn and practice the ladder logic. The implementation of the same PLC program for industrial usage will be different. PLC Example Design a PLC ladder logic for the following application. We are using three switches to control three LED’s. If any 1 Switch is ON, then LED I will be ON. If any 2 Switches are ON, then LED II will be ON. If all the 3 Switches are ON, then LED III will be ON. In the previous article, we discussed the same PLC example using toggle switches, Learn the logic. Inputs The required digital inputs are listed below. Switch 1: I0.0 Switch 2: I0.1 Switch 3: I0.2 Outputs The required digital outputs are listed below. Motor 1: Q0.0 Motor 2: Q0.1 Motor 3: Q0.2 Ladder Diagram to Control LEDs Via Switches Ladder Logic Explanation For this application, we have used EcoStruxure Machine Expert Basic v1.2 software for the PLC programming. In the above program, we have used Normally Open Contacts as well as Normally Closed Contacts for Switch 1 (I0.0), Switch 2 (I0.1), and Switch 3 (I0.2) In Rung0, when any 1 switch (Normally Copen Contact) is turned ON and the other 2 switches (Normally Closed Contacts) are OFF, then LED 1 will turn ON. To turn ON LED 2 Rung1, any 2 switches that are as Normally Open Contacts should be ON and the other remaining 1 switch as Normally Closed Contact should be OFF. For LED 3 to be ON, switch 1, switch 2 and switch 3 in Rung2 are connected in series, thus implementing AND logic gate. LED 3 will TURN ON when all the three switches are turned ON. When Any 1 Switch is ON The signal flows through switch 1 as it is in true state. In false state, switch 2 and switch 3 also pass signal to the outputs. Therefore, LED 1 will be ON. LED I will TURN ON when switch 2 is turned ON and switch 1 and switch 3 are OFF as these are in normally closed contact state. When switch 3 will be ON and other 2 switches which are normally closed contacts will be OFF, then LED 1 will turn ON. Turning ON more than one switch will break the circuit. The Normally Closed Contact, when in true state, will not allow signal. As a result, LED 1 will be OFF. When Any 2 Switches are ON LED 2 will TURN ON when switch 1, switch 2 are turned ON and Switch 3 is OFF. The switch 3 as Normally Closed Contact, in false state, will allow signal to pass through it. When switch 1 and switch 3 are turned ON and switch 2 is OFF, LED 2 will turn ON. Switch 2 will allow signal when in false state. The signal flows through switch 2 and switch 3 as these are in true state. In false state, switch 1 also pass signal to the outputs. Therefore, LED 2 will be ON. When more than two inputs are turned ON, the Normally Closed Contact used for the third switch will not close the circuit in true state. Therefore, the LED 2 will get OFF. When All 3 Switches are ON When all the three switches SWITCH 1 (I0.0), SWITCH 2 (I0.1), SWITCH 3 (I0.2) are turned ON, LED 3 will be ON and will turn OFF other Two outputs.

Learn the PLC logic example on multiple switches and motors with the ladder diagram. This PLC logic example is prepared for the engineering students to learn and practice the ladder logic. The design of the same PLC program for industrial usage will be different. PLC Logic Example Problem Statement: Design a PLC ladder logic for the following application. There is a use of four toggle switches to control four motors. If Switch 1 is ON, then Motor I will be ON. If Switch 2 is ON, then Motor I and Motor II will be ON. If Switch 3 is ON, then Motor I, Motor II, and Motor III will be ON. If Switch 4 is ON, then Motor I, Motor II, Motor III, and Motor IV will be ON. Inputs of PLC The list of the digital inputs for this PLC logic is mentioned below. Switch 1: I0.0 Switch 2: I0.1 Switch 3: I0.2 Switch 4: I0.3 Outputs of PLC The required digital outputs are listed below. Motor 1: Q0.0 Motor 2: Q0.1 Motor 3: Q0.2 Motor 4: Q0.3 Multiple Switches and Motors Ladder Logic Here is the PLC logic for the given problem statement. Program Explained For this example, we used Schneider PLC software for programming. In the above PLC program, we have used Normal Open Contact for Switch 1 (I0.0), Switch 2 (I0.1), Switch 3 (I0.2) and Switch 4 (I0.3) Switch 1, Switch 2, Switch 3, and Switch 4 are connected in parallel for Motor 1, thus implementing OR logic gate. For Motor 2, inputs switch 2, switch 3, and switch 4 are connected in parallel, thus implementing OR logic gate. Switch 3 and switch 4 are implementing OR logic gate i.e., connected in parallel for Motor 3. Only Switch 4 is connected to Motor 4. For Motor 1 to be ON, either Switch 1 or Switch 2 or Switch 3 or Switch 4 should be ON. To turn ON Motor 2, either Switch 2 or Switch 3 or Switch 4 should be ON. When Switch 3 or Switch 4 is ON, then Motor 3 will turn ON. Motor 4 will turn ON when Switch 4 is turned ON. PLC Simulation Results Next, we will see the PLC simulation results with different input switch ON and OFF combinations. When Switch 1 is ON When the toggle switch 1 is turned ON, the current flows through it (here we are using the term “Current” in case of an electrical circuit, so here you can assume it as “Current” or simply call it as “Signal”). As a result, Motor 1 gets ON. Other motors will remain OFF because Switch 1 is not connected to them. When Switch 2 is ON The current will flow through switch 2 when it is turned ON that will turn ON Motor 1 and Motor 2. It is so because switch 2 is connected to Motor 1 and Motor 2 only. When Switch 3 is ON When Switch 3 is turned ON, the current flows through it that will turn ON three motors i.e., Motor 1, Motor 2 and Motor 3. The input switch 3 is connected to these outputs only. Motor 4 will remain OFF as Switch 3 is not connected to it. When Switch 4 is ON Switch 4 will turn ON all the motors when turned ON. Switch 4 is connected to all the motors, when turned ON, Motor 2, Motor 2, Motor 3 and Motor 4 will turn ON.

This is the PLC Program to implement SR flip flop in PLC. Learn the PLC programming with this example logic. SR Flip Flop using PLC Ladder Logic Problem Description Implement a program for SR flip-flop logic in PLC using ladder language. Problem Diagram PLC Solution As we know, more complex systems cannot be controlled with combinational logic alone. The main reason is that we cannot, or choose not to add sensors to detect all conditions. In these cases we can use event to estimate the condition of the system. SR flip flop is used for Latch on or unlatch – to lock something ON or turn it OFF. Most PLC has special instruction for SR flip flop function. so no custom logic required for such types of PLCs. SR flip flop first executes SET function and then RESET function. Note :- Here we are considering simple function of SR flip flop instruction without using special instruction or using latch function. Here we are using simple latching circuit for SR flip flop function. Here as shown in figure two push buttons or two inputs are taken for program implementation. When user will press SET button or 1 is received at S input, Q output will be ON and if RESET button pressed or 1 received at R input, Q^ will be ON. List of inputs/outputs Digital Inputs Set Input :- I0.0 Reset input :- I0.1 Digital Outputs Q output :- Q0.0 Q^ output :- Q0.1 M memory Relay coil 1 :- M0.0 Relay coil 2 :- M0.1 PLC Ladder Diagram to implement SR flip-flop Program Explained For this PLC program we use S7-300 PLC and TIA portal software for programming. We can implement this logic by using other PLC also. Network 1: Here we used NC contact of relay coil 1(M0.0) so when reset button is pressed, Q output (Q0.0) is OFF. Network 2: Here we used NC contact of relay coil 2 (M0.1) so when set button is pressed, Q^ output (Q0.1) is OFF. Network 3: Here when we press RESET button (I0.0), relay coil 1(M0.0) will be latched. Network 4: Here when we press SET button (I0.1), relay coil 2(M0.1) will be latched. If both the inputs are low during power up, Q^ output (Q0.1) will go high because of its order. If both the inputs are Note :- Above application may be different from actual application. This example is only for explanation purpose only. We can implement this logic in other PLC also. This is the simple concept of implementing SR flip function without instruction. we can use this concept in other examples also. All parameters considered in example are for explanation purpose only, parameters may be different in actual applications. Result

This is a PLC Program to read the temperature in PLC. Learn PLC programming using example problems and solutions. Read Temperature in PLC Problem Description Write a PLC program in which we can monitor the actual temperature. Here we are using an external temperature controller and its output is also connected to PLC for monitoring the temperature of material in the tank. Problem Diagram Problem Solution RTDs devices with resistance that changes with temperature changes in a linear way. This resistance value will change as temperature changes and by supplying a constant current, the measured voltage drop across the resistor can be used to determine the new resistance, and thus the temperature. RTDs come in a variety of types, with the most common type is a PT100. It’s made from platinum that has been calibrated to be 100 ohms at 0 degrees C. In above application, we want to measure material temperature of the tank, for that we use RTD sensor which will measure temperature of the tank and give signal to the temperature controller. Temperature controller will send signal in the form of voltage (0-10V DC).If RTD detect 0degree temperature, it will send 0V DC and if maximum temperature detected, it will send 10V DC to PLC. Temperature controller is directly connected to the PLC so PLC will read voltage. Note: – Here we consider simple application for explanation. We need to measure material temperature of the tank by using RTD sensor. And also consider other components for control purpose. Assume Scaling range of temperature controller is 0-100°C=0 to 10V DC and according to this signal PLC consider 0 to 27648. I/O List M memory Analog value from the temp controller :- MW100 Actual value from the temp controller :- MD104 Multiplication :- MD108 Actual temperature in °C :- MD112 PLC Ladder diagram to read the temperature PLC Logic Explanation For this application, we used S7-300 PLC and TIA portal software for programming. We can implement this logic by using other PLC’s also. Network 1: In this network, we implement logic for value conversion. It is necessary to convert value from INT to DINT for multiplication purpose or for calculation. So by using conversion instruction analog value from the RTD (MW100) is converted into actual analog value (MD104). Note:- Temperature controller provides 0-10V DC signal to PLC. ADC converter or analog input module will convert this analog signal into digital form, and the range of this digital signal is 0 to 27648. This digital range may change from one PLC to another. Network 2: we have the RTD temperature range which is 0 to 100 degc and the output voltage range is 0 to 10V DC. So we need to scale this voltage output in terms of temperature reading. Here multiply the value as per equation and final value will be stored in MD108. Note:-Here temperature controller and temperature measurement range is 0-100°C. Network 3: Now for final result multiplied value is divided by 27648, result will be stored in MD112 (Actual temperature in °C). Note:- Above application may be different from actual application. This example is only for explanation purpose only. We can implement this logic in other PLC also. This is the simple concept of temperature reading in S7-300 PLC, we can use this concept in other examples also. All parameters considered in example are for explanation purpose only, parameters may be different in actual applications.

This is a PLC Program to implement analog scaling in S7-300 PLC. Control Valve Scaling Problem Description Implement PLC program in S7-300 for analog scaling. Problem Diagram Problem Solution Analog inputs come from different sensors or transmitters. Transmitters convert physical quantity into electrical signal. We can measure many physical quantity by using analog sensors such as temperature, pressure, level, distance, flow etc. Of course we can measure all physical quantity by using analog sensors, but for example and explanation purpose here we take one example of control valve. As shown in figure, here we consider one control valve and it has 4-20mA output (valve feedback) and 4-20mA input (valve command) for operation. Hence, when PLC will give 20mA to flow control valve, valve will be open 100% and for 4mA it will be 0% (close). In other way flow control valve is also providing output signal that can be used for close loop system/for valve percentage indication. If valve is 100% open, PLC will get 20mA signal and for 0% it will get 4mA. Note:- We consider here close loop system for simple explanation, so operator will set control valve open command parameter in range between 0% to 100% . Now as per close loop system, control valve will provide output signal (valve feedback) and by using SCALE instruction, operator can see actual valve open parameter on graphics. List of inputs/outputs M memory Enable command-Scaling :- M0.0 Bipolar selection-Scaling :- M0.1 Actual value from the sensor or transmitter :- MW10 Error word –Scaling :- MW12 Scaled output :- MD20 Enable command-Unscaling :- M1.0 Bipolar selection- Unscaling :- M0.2 Given value from the display :- MD24 Error word-Unscaling :- MW16 Unscaled output :- MW26 PLC Ladder Diagram for Valve Scaling Ladder Logic Explained For this application, we use S7-300 PLC and TIA portal software for programming. We can implement this logic by using other PLC also. Network 1: In this network, scaling logic is executed when Enable command (M0.0) is ON. The “Scale” instruction is to convert the integer (here 4-20mA signal from the control valve or MW10) at the IN parameter which can be scaled in physical units between a low limit (0% output) and a high limit (100% output). The result or scaled output (MD20) of the instruction is output at the OUT parameter. If bipolar selection (M0.1) is ON, it is assumed that the value at the IN parameter is bipolar (range between -27648 to +27648). If bipolar selection (M0.1) is OFF, it is assumed that the value at the IN parameter is unipolar (range between 0 to 27648). Network 2: The “Unscale” instruction is used to unscaled the floating-point number (given value from the display or MD24) on the IN parameter into physical units between a low limit and and a high limit. The result of the instruction is output (unscaled output MW26) at the OUT parameter. If bipolar selection (M0.2) is ON, it is assumed that the value at the IN parameter is bipolar (range between -27648 to +27648). If bipolar selection (M0.2) is OFF, it is assumed that the value at the IN parameter is unipolar (range between 0 to 27648). Error code table: Note: The above application may be different from actual application. This example is only for explanation purpose only. We can implement this logic in other PLC also. This is the simple concept of SCALE and UNSCALE instructions, we can use this concept in other examples also. All parameters considered in the example are for explanation purposes only, parameters may be different in actual applications. Result

This is a PLC Program to control the level of parallel tanks. Learn the PLC programming using this example. Parallel Tanks Level Control Problem Description Two tanks are connected in parallel connection. We need to heat and cool the incoming material into the tanks and simultaneously control the level of the tanks. Implement the PLC program for this application. Problem Diagram Problem Solution Heating process is used to heat the material in the tank and cooling process is used to cool the material. Here consider both material are same as show in figure, inlet valve feeds material in both the tanks. Here we can use level switches for detecting the low levels and high levels for both the tanks. Use two temperature sensors for measuring the temperature of both the tanks. Outlet valves are used at the bottom of the tanks to drain the materials for further process. We will write PLC program for this application. List of Inputs & Outputs Digital Inputs Cycle START :- I0.0 Cycle STOP :- I0.1 Low level tank 1(LL1) :- I0.3 Low level tank 2(LL2) :- I0.4 High level tank 1(LH1) :- I0.5 High level tank 2(LH2) :- I0.6 Digital Outputs Inlet valve V2 for heating tank :- Q0.0 Inlet valve V3 for cooling tank :- Q0.1 Outlet valve V4 for heating tank :- Q0.2 Outlet valve V5 for cooling tank :- Q0.3 M memory Cycle ON bit :- M0.0 Register for temperature of heating tank :- MD10 Register for temperature of cooling tank :- MD14 Outlet valve V5 for cooling tank :- Q0.3 PLC Program for level control of parallel tanks Program Explanation For this application we used S7-300 PLC and TIA portal software for programming. We can implement this logic by using other PLC also. Network 1: This Network is for latching circuit. Whenever START button is pressed (I0.0), Cycle ON (M0.0) bit will be ON. Cycle can be STOP by pressing STOP PB (I0.1). Network 2: When heating tank level low (I0.3) is detected, inlet valve V2 (Q0.0) will be ON. If level high of tank 1(I0.5) is not detected and START (I0.0) button is pressed, inlet valve V2 (Q0.0) will be ON. Network 3: If level low of tank 2 (I0.4) is detected, inlet valve V3 (Q0.1) will be ON. If START button is pressed and high level of tank 2 (I0.6) is not detected, inlet valve V3 (Q0.1) will be ON. Network 4: If cycle is ON and actual temperature of heating tank (MD10) is greater or equal than set temperature (70°C), outlet valve V4 (Q0.2) will be ON Network 5: If cycle is ON and actual temperature of cooling tank (MD14) is less or equal than set temperature (20°C), outlet valve V5 (Q0.3) will be ON. Note :- This example is only for explanation purpose only. We can implement this logic in any PLC or using relay logic. Above application may be different from actual application or may be a part of the plant logic. Result

A counter is a PLC instruction that either increments (counts up) or decrements (counts down) an integer number value when prompted by the transition of a bit from 0 to 1 (“false” to “true”). Counter instructions come in three basic types: up counters, down counters, and up/down counters. Both “up” and “down” counter instructions have single inputs for triggering counts, whereas “up/down” counters have two trigger inputs: one to make the counter increment and one to make the counter decrement. PLC Counter Instructions To illustrate the use of a counter instruction, we will analyze a PLC-based system designed to count objects as they pass down a conveyor belt: In this system, a continuous (unbroken) light beam causes the light sensor to close its output contact, energizing discrete channel IN4. When an object on the conveyor belt interrupts the light beam from source to sensor, the sensor’s contact opens, interrupting power to input IN4. A push-button switch connected to activate discrete input IN5 when pressed will serve as a manual “reset” of the count value. An indicator lamp connected to one of the discrete output channels will serve as an indicator of when the object count value has exceeded some pre-set limit. We will now analyze a simple Ladder Diagram program designed to increment a counter instruction each time the light beam breaks: This particular counter instruction (CTU) is an incrementing counter, which means it counts “up” with each off-to-on transition input to its “CU” input. The normally-closed virtual contact (IN sensor object) is typically held in the “open” state when the light beam is continuous, by virtue of the fact the sensor holds that discrete input channel energized while the beam is continuous. When the beam is broken by a passing object on the conveyor belt, the input channel de-energizes, causing the virtual contact IN sensor object to “close” and send virtual power to the “CU” input of the counter instruction. This increments the counter just as the leading edge of the object breaks the beam. The second input of the counter instruction box (“R”) is the reset input, receiving virtual power from the contact IN switch reset whenever the reset pushbutton is pressed. If this input is activated, the counter immediately resets its current value (CV) to zero. Status indication is shown in this Ladder Diagram program, with the counter’s preset value (PV) of 25 and the counter’s current value (CV) of 0 shown highlighted in blue. The preset value is something programmed into the counter instruction before the system put into service, and it serves as a threshold for activating the counter’s output (Q), which in this case turns on the count indicator lamp (the OUT counts reached coil). According to the IEC 61131-3 programming standard, this counter output should activate whenever the current value is equal to or greater than the preset value (Q is active if CV ≥ PV). This is the status of the same program after thirty objects have passed by the sensor on the conveyor belt. As you can see, the current value of the counter has increased to 30, exceeding the preset value and activating the discrete output: If all we did not care about maintaining an accurate total count of objects past 25 – but merely wished the program to indicate when 25 objects had passed by. we could also use a down counter instruction preset to a value of 25, which turns on an output coil when the count reaches zero: Here, a “load” input causes the counter’s current value to equal the preset value (25) when activated. With each sensor pulse received, the counter instruction decrements. When it reaches zero, the Q output activates. A potential problem in either version of this object-counting system is that the PLC cannot discriminate between forward and reverse motion on the conveyor belt. If, for instance, the conveyor belt were ever reversed in direction, the sensor would continue to count objects that had already passed by before (in the forward direction) as those objects retreated on the belt. This would be a problem because the system would “think” more objects had passed along the belt (indicating greater production) than actually did. One solution to this problem is to use an up/down counter, capable of both incrementing (counting up) and decrementing (counting down), and equip this counter with two light-beam sensors capable of determining direction of travel. If two light beams are oriented parallel to each other, closer than the width of the narrowest object passing along the conveyor belt, we will have enough information to determine direction of object travel: This is called quadrature signal timing, because the two pulse waveforms are approximately 90 deg (one-quarter of a period) apart in phase. We can use these two phase-shifted signals to increment or decrement an up/down counter instruction, depending on which pulse leads and which pulse lags. A Ladder Diagram PLC program designed to interpret the quadrature pulse signals is shown here, making use of negative-transition contacts as well as standard contacts: The counter will increment (count up) when sensor B de-energizes only if sensor A is already in the de-energized state (i.e. light beam A breaks before B). Counter will decrement (count down) when sensor A de-energizes only if sensor B is already in the de-energized state (i.e. light beam B breaks before A). Note that the up/down counter has both a “reset” (R) input and a “load” input (“LD”) to force the current value. Activating the reset input forces the counter’s current value (CV) to zero, just as we saw with the “up” counter instruction. Then Activating the load input forces the counter’s current value to the preset value (PV), just as we saw with the “down” counter instruction. In the case of an up/down counter, there are two Q outputs: a QU (output up) to indicate when the current value is equal to or greater than the preset value, and a QD (output down) to indicate when the current value is equal to or less than zero. Note how the current value (CV) of each counter shown is associated with a tag name of its own, in this case parts counted. The integer number of a counter’s current value (CV) is a variable in the PLC’s memory just like boolean values such as IN sensor A and IN switch reset, and may be associated with a tag name or symbolic address just the same. This allows other instructions in a PLC program to read (and sometimes write!) values from and to that memory location.

Perhaps the most important yet elusive concept to grasp when learning to program PLCs is the relationship between the electrical status of the PLC’s I/O points and the status of variables and other “elements” in its programming. This is especially true for Ladder Diagram (LD) programming, where the program itself resembles an electrical diagram. Making the mental connection between the “real” world of the switches, contactors, and other electrical devices connected to the PLC and the “imaginary” world of the PLC’s program consisting of virtual contacts and relay “coils” is most fundamental. The first fundamental rule one should keep in mind when examining a Ladder Diagram PLC program is that each virtual contact shown in the program actuates whenever it reads a “1” state in its respective bit and will be at rest whenever it reads a “0” state in its respective bit (in the PLC’s memory). If the contact is a normally-open (NO) type, it will open when its bit is 0 and close when its bit is 1. If the contact is a normally-closed (NC) type, it will close when its bit is 0 and open when its bit is 1. A 0 bit state causes the contact to be in its “normal” (resting) condition, while a 1 bit state actuates the contact, forcing it into its non-normal (actuated) state. Another rule to remember when examining a Ladder Diagram PLC program is that the programming software offers color highlighting ( Note 1 ) to display the virtual status of each program element: a colored contact is closed, while an un-colored contact is open. While the presence or absence of a “slash” symbol marks the normal status of a contact, its live color highlighting shown by PLC programming software reveals the “conductive” status of the elements in real time. Note 1 : It should be noted that in some situations the programming software will fail to color the contacts properly, especially if their status changes too quickly for the software communication link to keep up, and/or if the bit(s) change state multiple times within one scan of the program. However, for simple programs and situations, this rule holds true and is a great help to beginning programmers as they learn the relationship between real-world conditions and conditions within the PLC’s “virtual” world. Mis-conceptions of PLC Ladder Logic The following table shows how the two types of contacts in a PLC’s Ladder Diagram program respond to bit states, using red coloring to signify each contact’s virtual conductivity: Just as a pressure switch’s contacts are actuated by a high pressure condition, and a level switch’s contacts are actuated by a high level condition, and a temperature switch’s contacts are actuated by a high temperature condition, so a PLC’s virtual contact is actuated by a high bit condition (1). In the context of any switch, an actuated condition is the opposite of its normal (resting) condition. The following simplified illustration (The electrical wiring shown in this diagram is incomplete, with the “Common” terminal shown unconnected for simplicity’s sake.) shows a small PLC with two of its discrete input channels electrically energized, causing those two bits to have “1” statuses. The color-highlighted contacts in the programming editor software’s display shows a collection of contacts addressed to those input bits in various states (colored = closed ; un-colored = open). As you can see, every contact addressed to a “set” bit (1) is in its actuated state, while every contact addressed to a “cleared” bit (0) is in its normal state: Remember that a colored contact is a closed contact. The contacts appearing as colored are either normally-closed contacts with “0” bit states, or normally-open contacts with “1” bit states. It is the combination of bit state and contact type (NO vs. NC) that determines whether the virtual contact will be open (un-colored) or closed (colored) at any given time. Correspondingly, it is a combination of colored highlighting and virtual contact type that indicates the real-world energization status of a particular PLC input at any given time. The main problem of students/engineers have comprehending PLC Ladder Diagram programs is that they over-simplify and try to directly associate real-world switches connected to the PLC with their respective contact instructions inside the PLC program. Students/Engineers mistakenly think the real-world switch connecting to the PLC and the respective virtual switch contact inside the PLC program are one and the same, when this is not the case at all. Rather, the real-world switch sends power to the PLC input, which in turn controls the state of the virtual contact(s) programmed into the PLC. Specifically, I see students/engineers routinely fall into the following mis-conceptions: Mistakenly think the contact instruction type (NO vs. NC) needs to match that of its associated real-world switch Mistakenly think color highlighting of a contact instruction is equivalent to the electrical status of its associated real-world PLC input Mistakenly think a closed real-world switch must result in a closed contact instruction in the live PLC program To clarify, here are the fundamental rules one should keep in mind when interpreting contact instructions in Ladder Diagram PLC programs: Each input bit in the PLC’s memory will be a “1” when its input channel is powered, and will be a “0” when its input channel is unpowered Each virtual contact shown in the program actuates whenever it reads a “1” state in its respective bit, and will be at rest whenever it reads a “0” state in its respective bit A colored contact is closed (passes virtual power in the PLC program), while an un-colored contact is open (blocks virtual power in the PLC program) In trying to understand PLC Ladder Diagram programs, the importance of these rules cannot be overemphasized. The truth of the matter is a causal chain – rather than a direct equivalence – between the real-world switch and the contact instruction status. The real-world switch controls whether or not electrical power reaches the PLC input channel, which in turn controls whether the input register bit will be a “1” or a “0”, which in turn controls whether the contact instruction will actuated or at rest. Virtual contacts inside the PLC program are thus controlled by their corresponding real-world switches, rather than simply being identical to their real-world counterparts as novices tend to assume. Following these rules, we see that normally-open (NO) contact instructions will mimic what their real-world switches are doing, while normally-closed (NC) contact instructions will act opposite of their real-world counterparts. The color highlighting of coil instructions in a Ladder Diagram PLC program follows similar rules. A coil will be “on” (colored) when all contact instructions prior to it are closed (colored). A colored coil writes a “1” to its respective bit in memory, while an un-colored coil instruction writes a “0” to its respective bit in memory. If these bits are associated with real-world discrete output channels on the PLC, their states will control the real-world energization of devices electrically connected to those channels. To further illuminate these fundamental concepts, we will examine the operation of a simple PLC system designed to energize a warning lamp in the event that a process vessel experiences a high fluid pressure. The PLC’s task is to energize a warning lamp if the process vessel pressure ever exceeds 270 PSI, and keep that warning lamp energized even if the pressure falls below the trip point of 270 PSI. This way, operators will be alerted to both past and present process vessel over-pressure events. 120 volt AC “line” power (L1 and L2) provides electrical energy for the PLC to operate, as well as signal potential for the input switches and power for the warning lamp. Two switches connect to the input of this PLC: one normally-open pushbutton switch acting as the alarm reset (pressing this switch “unlatches” the alarm lamp) and one normally-open pressure switch acting as the sensing element for high process vessel pressure: The reset pushbutton connects to discrete input X1 of the PLC, while the pressure switch connects to discrete input X4. The warning lamp connects to discrete output Y5. Red indicator LEDs next to each I/O terminal visually indicate the electrical status of the I/O points, while red-shaded highlighting shows the virtual power (Note 2 ) status of the “contacts” and “coils” in the PLC’s program, displayed on the screen of a personal computer connected to the PLC through a programming cable. With no one pressing the reset pushbutton, that switch will be in its normal status, which for a “normally-open” switch is open. Likewise with the pressure switch: with process pressure less than the trip point of 270 PSI, the pressure switch will also be in its normal status, which for a “normally-open” switch is open. Since neither switch is conducting electricity right now, neither discrete input X1 nor X4 will be energized. This means the “virtual” contacts inside the PLC program will likewise be in their own normal states. Thus, any virtual contact drawn as a normally-open will be open (not passing virtual power), and any virtual contact drawn as a normally-closed (a diagonal slash mark through the contact symbol) will be closed. This is why the two normally-open virtual contacts X4 and Y5 have no highlighting, but the normally-closed virtual contact X1 does – the colored highlighting representing the ability to pass virtual power. Note 2 : For a PLC program contact, the shading represents virtual “conductivity.” For a PLC program coil, the shading represents a set (1) bit. If the process vessel experiences a high pressure (> 270 PSI), the pressure switch will actuate, closing its normally-open contact. This will energize input X4 on the PLC, which will “close” the virtual contact X4 in the ladder program. This sends virtual power to the virtual “coil” Y5, which in turn latches itself on through virtual contact Y5 (Note 3 ) and also energizes the real discrete output Y5 to energize the warning lamp: Note 3 : It is worth noting the legitimacy of referencing virtual contacts to output bits (e.g. contact Y5), and not just to input bits. A “virtual contact” inside a PLC program is nothing more than an instruction to the PLC’s processor to read the status of a bit in memory. It matters not whether that bit is associated with a physical input channel, a physical output channel, or some abstract bit in the PLC’s memory. It would, however, be wrong to associate a virtual coil with an input bit, as coil instructions write bit values to memory, and input bits are supposed to be controlled solely by the energization states of their physical input channels. If now the process pressure falls below 270 PSI, the pressure switch will return to its normal state (open), thus de-energizing discrete input X4 on the PLC. Because of the latching contact Y5 in the PLC’s program, however, output Y5 remains on to keep the warning lamp in its energized state: Thus, the Y5 contact performs a seal-in function to keep the Y5 bit set (1) even after the high pressure condition clears. This is precisely the same concept as the “seal-in” auxiliary contact on a hard-wired motor starter circuit, where the electro-mechanical contactor keeps itself energized after the “Start” pushbutton switch has been released. The only way for a human operator to re-set the warning lamp is to press the pushbutton. This will have the effect of energizing input X1 on the PLC, thus opening virtual contact X1 (normally closed) in the program, thus interrupting virtual power to the virtual coil Y5, thus powering down the warning lamp and un-latching virtual power in the program:

Although it seems each model of PLC has its own idiosyncratic standard for programming, there does exist an international standard for controller programming that most PLC manufacturers at least attempt to conform to. This is the IEC 61131-3 standard, which will be the standard One should take solace in the fact that despite differences in the details of PLC programming from one manufacturer to another and from one model to another, the basic principles are largely the same. There exist much greater disparities between different general-purpose programming languages (e.g. C/C++, BASIC, FORTRAN, Pascal, Java, Ada, etc.) than between the programming languages supported by different PLCs, and this fact does not prevent computer programmers from being “multilingual.” I have personally written and/or analyzed programs for over a half-dozen different manufacturers of PLCs (Allen-Bradley, Siemens, Square D, Koyo, Fanuc, Moore Products APACS and QUADLOG, and Modicon), with multiple PLC models within most of those brands, and I can tell you the differences in programming conventions are largely insignificant. After learning how to program one model of PLC, it is quite easy to adapt to programming other makes and models of PLC. PLC Programming languages The IEC 61131-3 standard specifies five distinct forms of programming language for industrial controllers: Ladder Diagram (LD) Structured Text (ST) Instruction List (IL) Function Block Diagram (FBD) Sequential Function Chart (SFC) Not all programmable logic controllers support all five language types, but nearly all of them support Ladder Diagram (LD), which will be the primary focus of this book. Programming languages for many industrial devices are limited by design. One reason for this is simplicity: any programming language simple enough in structure for someone with no formal computer programming knowledge to understand is going to be limited in its capabilities. Another reason for programming limitations is safety: the more flexible and unbounded a programming language is, the more potential there will be to unintentionally create complicated “run-time” errors when programming. The ISA safety standard number 84 classifies industrial programming languages as either Fixed Programming Languages (FPL), Limited Variability Languages (LVL), or Full Variability Languages (FVL). Ladder Diagram and Function Block Diagram programming are both considered to be “limited variability” languages, whereas Instruction List (and traditional computer programming languages such as C/C++, FORTRAN, BASIC, etc.) are considered “full variability” languages with all the attendant potential for complex errors.