PLC - what is it?
Good day, dear residents of Habr!
Having read a post about programming Siemens PLCs of the S7 series , I climbed into the Habr search, and was quite surprised that the topic of industrial automation in general, and PLC programming in particular, was covered very, very poorly. I will take the liberty to share my experience in this area, describing the basic principles of PLC programming, in particular, the production of Beckhoff .
I do building automation. It so happened that we mainly build our systems based on Beckhoff PLCs. This choice was made primarily because these controllers are freely programmable in the full sense of these words. What does it mean? Take the TAC Xenta controller, for example, and try to exchange it with an external device via RS232 using its own protocol, at the level of “byte sent - received byte”. It will not work, these controllers do not know how to do this - use only those protocols that the developer has laid down in them. But Beckhoff can. But before getting into such a jungle, let's look at the development environment? In what, in fact, language will we write?
Industrial PLCs are programmed in the languages of IEC 61131-3 . There are 5 of these languages, some manufacturers add their own. Languages do not resemble each other at all, and, watching my colleagues, I can assume that the choice of a particular language is primarily connected with what a person was doing before he entered this industry.
Of the not all supported languages, it is worth noting the CFC (continuous flow chart) language, Beckhoff supports it. This is a further development of the FBD language, one of the most significant differences, in my opinion, is support for explicit feedback in the circuits. Why is this needed? For example, such a short pulse generator will work on CFC, but not on FBD.
The TON block is a standard block, a timer with an on-delay. Logic of operation: output Q becomes TRUE when TRUE is input for IN for at least PT.
Probably the most popular PLC development environment is CoDeSys . Many manufacturers take it as a basis, and either make a library for it to work with their PLCs, or they complete the environment for themselves.
The PLC program runs in cycles. The cycle time can be from units of milliseconds to units of seconds, depending on the tasks that are assigned to this PLC. Most PLCs allow the program developer to set the cycle time, but some models do not. Many PLCs, in particular Beckhoff, allow you to create more than one cyclic task in one program and set a priority for these tasks. What does this opportunity give us?
Imagine a situation: a PLC controls an air handling unit, and a control panel is connected to it via RS232. The temperature in the rooms does not change quickly, and it just makes no sense to run the ventilation control algorithm more often than once every 50 - 100 ms. But the operator panel constantly polls the controller, and the PLC response delay of more than 10 ms is already expressed in “braking” of the user interface, and with a delay of 20 ms, the COM-port hardware buffer will be full. Having several tasks allows us to solve this problem beautifully: let the “fast” task work with the COM port and be called every 2 ms, and the “slow” one will implement the ventilation logic and be called every 50 ms. Everything works well, the operator panel does not slow down, the user is satisfied.
Everything here is very, very dependent on the manufacturer. Someone makes their embedded platform on a RISC processor (for example, the domestic Aries) - this approach is very popular. Beckhoff, on the other hand, took a different path - Windows CE 5.0 was installed on their PLC (and if they update the firmware from the official site, then 6.0), or Windows XP Embedded, and the PLC task works as a service. Quite an interesting counterargument for fans to talk about the instability of Windows.
But this is the “head” of the controller, and yet it still needs inputs and outputs to communicate with the outside world. There are two approaches:
This is what the “all in one box” approach looks like. Pictured by Carel pCO3.
And here's another option - the Beckhoff head of the CX9000 series (left in the photo) with a set of I / O modules.
Among other things, there is still a certain bus on the head that allows you to integrate the PLC into a network, and often also change its program through the same network. What kind of network it will be depends on the PLC. This may be unfamiliar to those who have not encountered industrial networks EIA-485 , Profibus , CAN, and maybe quite familiar Ethernet. It is through this network, called fieldbus, that the PLC is connected to the upper level - to the SCADA system, for example. In the photo above, 2 8P8C sockets on Beckhoff’s head are clearly visible - this is Ethernet, and Carel has 2 poor 6P4C sockets on the upper left (though not bad, though) - they did RS-485. This interface, unfortunately, does not have a common connector.
In general, this topic is not an article, but an entire book. But I will tell you what I saw from personal experience, and let it be a fly in the ointment.
For professional programmers, the development of PLCs in many ways seems to be degradation. OOP? We don’t have them, there are only structures, enumerations, and a certain semblance of a class called the “functional block”. What is Private, Public and so on, you can also forget immediately - it will not come in handy. From anywhere in your program, you can access any other location.
Dynamic memory allocation? We do not have them at all. Not sure how much data will be sent to you? Allocate a buffer with a margin, and forget about this memory - it will not work to free it. Either show the wonders of speed and process data on the fly if you manage to meet the set cycle time.
Exceptions? What are you ... I saw one miracle that tightly hung while performing a construction of the form:
It is clear that overflow does not fit foo * bar into 16 bits, but why hang something? Yes, and so that nothing but a reset for nutrition does not help.
Development environment? Not everyone has CoDeSys, many want to originalize and write their own thread. One of such self-written environments crashed with runtime error when trying to write the number 86400 to a 16-bit INT. And you say exception handling on the PLC. In the development environment, it is not always possible to do it normally.
BUT! But for lovers of that fine line that separates hardware from software, vernacular software - this is a very interesting branch of IT, really.
Hope this short review is helpful. If this topic is of interest to the habrasociety, I will tell you more about the PLC.
Having read a post about programming Siemens PLCs of the S7 series , I climbed into the Habr search, and was quite surprised that the topic of industrial automation in general, and PLC programming in particular, was covered very, very poorly. I will take the liberty to share my experience in this area, describing the basic principles of PLC programming, in particular, the production of Beckhoff .
Introduction
I do building automation. It so happened that we mainly build our systems based on Beckhoff PLCs. This choice was made primarily because these controllers are freely programmable in the full sense of these words. What does it mean? Take the TAC Xenta controller, for example, and try to exchange it with an external device via RS232 using its own protocol, at the level of “byte sent - received byte”. It will not work, these controllers do not know how to do this - use only those protocols that the developer has laid down in them. But Beckhoff can. But before getting into such a jungle, let's look at the development environment? In what, in fact, language will we write?
IEC 61131-3 standard
Industrial PLCs are programmed in the languages of IEC 61131-3 . There are 5 of these languages, some manufacturers add their own. Languages do not resemble each other at all, and, watching my colleagues, I can assume that the choice of a particular language is primarily connected with what a person was doing before he entered this industry.
- IL, instruction list. It looks like assembler. I have not seen anyone who would use it, but I suspect that old-school encoders that have punched memory cards from memory will be appreciated.
- LD, ladder diagram. Visual language for those involved in the development of relay automation circuits.
- ST, structured text. It most closely resembles the “classical” programming languages; it is somewhat similar to Pascal. That is why it is appreciated by those who, before the PLC, were engaged in programming in other languages and platforms, in particular, by me.
- FBD, functional block diagram. This kind of block scheme is loved primarily by technologists who decided to go into programming, for their clarity.
- SFC, sequential function chart. Graphic language, I won’t say anything else. Never seen to be used.
Of the not all supported languages, it is worth noting the CFC (continuous flow chart) language, Beckhoff supports it. This is a further development of the FBD language, one of the most significant differences, in my opinion, is support for explicit feedback in the circuits. Why is this needed? For example, such a short pulse generator will work on CFC, but not on FBD.
The TON block is a standard block, a timer with an on-delay. Logic of operation: output Q becomes TRUE when TRUE is input for IN for at least PT.
Probably the most popular PLC development environment is CoDeSys . Many manufacturers take it as a basis, and either make a library for it to work with their PLCs, or they complete the environment for themselves.
How does a PLC work?
The PLC program runs in cycles. The cycle time can be from units of milliseconds to units of seconds, depending on the tasks that are assigned to this PLC. Most PLCs allow the program developer to set the cycle time, but some models do not. Many PLCs, in particular Beckhoff, allow you to create more than one cyclic task in one program and set a priority for these tasks. What does this opportunity give us?
Imagine a situation: a PLC controls an air handling unit, and a control panel is connected to it via RS232. The temperature in the rooms does not change quickly, and it just makes no sense to run the ventilation control algorithm more often than once every 50 - 100 ms. But the operator panel constantly polls the controller, and the PLC response delay of more than 10 ms is already expressed in “braking” of the user interface, and with a delay of 20 ms, the COM-port hardware buffer will be full. Having several tasks allows us to solve this problem beautifully: let the “fast” task work with the COM port and be called every 2 ms, and the “slow” one will implement the ventilation logic and be called every 50 ms. Everything works well, the operator panel does not slow down, the user is satisfied.
And what do these glands have inside?
Everything here is very, very dependent on the manufacturer. Someone makes their embedded platform on a RISC processor (for example, the domestic Aries) - this approach is very popular. Beckhoff, on the other hand, took a different path - Windows CE 5.0 was installed on their PLC (and if they update the firmware from the official site, then 6.0), or Windows XP Embedded, and the PLC task works as a service. Quite an interesting counterargument for fans to talk about the instability of Windows.
But this is the “head” of the controller, and yet it still needs inputs and outputs to communicate with the outside world. There are two approaches:
- You can do “all in one box” - a head, a certain set of inputs / outputs, several configuration options - here we have more inputs, here it is smaller, here the head is more powerful, here it is weaker. So do, for example, Carel , and many others. On a small project, such an approach may justify itself in something.
- But personally it seems to me that a different flexibility gives a different approach. The head is separate, and a dialed tail from the input-output modules is connected to it via the bus. We put the modules that we need, and in the quantity that we need. So do Beckhoff and Siemens, for example.
This is what the “all in one box” approach looks like. Pictured by Carel pCO3.
And here's another option - the Beckhoff head of the CX9000 series (left in the photo) with a set of I / O modules.
Among other things, there is still a certain bus on the head that allows you to integrate the PLC into a network, and often also change its program through the same network. What kind of network it will be depends on the PLC. This may be unfamiliar to those who have not encountered industrial networks EIA-485 , Profibus , CAN, and maybe quite familiar Ethernet. It is through this network, called fieldbus, that the PLC is connected to the upper level - to the SCADA system, for example. In the photo above, 2 8P8C sockets on Beckhoff’s head are clearly visible - this is Ethernet, and Carel has 2 poor 6P4C sockets on the upper left (though not bad, though) - they did RS-485. This interface, unfortunately, does not have a common connector.
So still, how do you write programs for it?
In general, this topic is not an article, but an entire book. But I will tell you what I saw from personal experience, and let it be a fly in the ointment.
For professional programmers, the development of PLCs in many ways seems to be degradation. OOP? We don’t have them, there are only structures, enumerations, and a certain semblance of a class called the “functional block”. What is Private, Public and so on, you can also forget immediately - it will not come in handy. From anywhere in your program, you can access any other location.
Dynamic memory allocation? We do not have them at all. Not sure how much data will be sent to you? Allocate a buffer with a margin, and forget about this memory - it will not work to free it. Either show the wonders of speed and process data on the fly if you manage to meet the set cycle time.
Exceptions? What are you ... I saw one miracle that tightly hung while performing a construction of the form:
foo, bar: int;
baz: real;
foo := 2000;
bar := 2000;
baz := INT_TO_REAL (foo * bar);
It is clear that overflow does not fit foo * bar into 16 bits, but why hang something? Yes, and so that nothing but a reset for nutrition does not help.
Development environment? Not everyone has CoDeSys, many want to originalize and write their own thread. One of such self-written environments crashed with runtime error when trying to write the number 86400 to a 16-bit INT. And you say exception handling on the PLC. In the development environment, it is not always possible to do it normally.
BUT! But for lovers of that fine line that separates hardware from software, vernacular software - this is a very interesting branch of IT, really.
Hope this short review is helpful. If this topic is of interest to the habrasociety, I will tell you more about the PLC.