Angry Birds on PLC?

In the previous topic, I promised to describe in more detail the features of industrial PLC programming, and why such programming more and more resembles the development of ordinary software. I have already written about the language of IEC61131-3 ST (industrial dialect of Pascal), this habratopic can also be considered a good introduction. This post is about PLC compilers, development environments, programming features and the evolution of language and ecosystem.

There are only three major manufacturers of IEC61131 compilers - CoDeSys, KW and Siemens. The Siemens compiler is used in Siemens products, and almost all other vendors license the CoDeSys or KW compiler. Thus, the 3 most famous compilers are developed in small German towns.

Compilers of rare languages ​​have a common problem - their producers do not have such resources as, for example, the gcc community or the icc command. Therefore, it is not possible to optimize the backend for ever-changing architectures, and use the latest instruction sets. The code compiled by such a not very optimizing compiler “stumbles” right away - on the front end / decoder of the processor. Numerous front end stalls are clearly visible in the results of the analysis of Vtune, caused by misses on I-cache (the prefetcher fails, especially on Nehalem and earlier) and other reasons. Also, many exotic or "young" backend compilers stumble upon the well-known features of Atom processors. Of course, the most true solution would be to use LLVM. It is strange that no one had thought of this before. However, a similar idea came to KW engineers — they simply compiled IEC61131 into the CLR. Well, the performance of the CLR is already quite adequately optimized by Microsoft. Well, where the CLR is, there is C #. Another KW feature is the ability to mix IEC61131 and C #. And develop all this in Microsoft Visual Studio.

How else can you get the performance of the PLC program, comparable to the performance of the same program written in C? For example, you can write the IEC61131-3 translator to C, and then use the C compiler. So does the small Canadian Geb Automation team. Watching their progress with interest. You can also write performance-critical C modules and call them from the PLC code. Make an analog JNI for IEC61131. Almost everyone supports this approach - for example, Siemens, B & R, Beckhoff (the rest, probably, too, but personally I have not come across, because the feature is not very standard yet).
')
IDE manufacturers adapted for PLC development are much more than compiler manufacturers. Their list almost coincides with the list of popular vendors of iron PLC (+ KW and CoDeSys, which almost do not make their own hardware). Their development environments are produced by Siemens, Rockwell, Phoenix, Omron, Beckhoff, B & R, CoDeSys, KW. Almost all of them write their own environments with a unique drag and drop, but, as I wrote above, KW uses MS Visual Studio. Beckhoff recently replaced its CoDeSys based environment with her own plugin for MS Visual Studio. It allows you to develop and debug PLCs in a popular and developed development environment, but inside it has a CoDeSys compiler (which, unlike the KW compiler, produces immediately machine code, not CLR code).

One of the interesting features of the PLC development is that the same code can be written and viewed from different angles - the underassembler IL, the strange Pascal ST, the circuit block FBD, the electrical logic LD. One of the important features (and generally raison d'être) of an IDE for a PLC is the transition and translation between these forms. It makes these IDEs a little similar to the founder of the genre of drawing pictures that generate code, and the code that redraws the picture directly in the IDE - Delphi. Interestingly, when developing a PLC, you can go up one more level of abstraction, and use MathWorks Simulink . The well-known manufacturer Matlab has a special product for PLC developers that allows generating IEC61131-3 ST code from Matlab functions, Simulink models and flow diagrams. This is how it looks.



Click on the button “Generate PLC Code” and the graphic model from the image is converted to “almost Pascal”.

With Angry Birds in the title of the post, I, of course, got excited. Although you can write it on the PLC, and even with real actuators, I have so far only seen Mahjong, implemented on IEC61131-3 ST, which can be run on an industrial controller with HMI.



Actually, except for the HMI, it does not touch anything, but it can be fixed. The title picture is also a program on IEC61131, it controls a robot that plays tic-tac-toe against a person. I took this picture last November at the CoDeSys booth at SPS Drives. With Angry Birds, many people associate app stores - the main distribution channel that made this game famous. Recently appeared the first App Store for PLC programs! So there was a unique opportunity to catch a popular toy for another store. I do not know how applicable the app store model is in this area - as long as I counted only 50 applications from three manufacturers in it.

Thus, the following common-site technologies - Visual Studio, Matlab, linking with code in C, CLR / C #, and even the app store - are sneaking into the development of the PLC in an exotic language. Of course, it would be superfluous to mention that all the compilers and environments described above allow generating code for many processor architectures used in automation, including X86. As an Intel employee, I am very pleased that x86 platforms are being used in this area more and more often.