|
|
At the grinding machines at Bueler, AustriaUsing IEC 61131-3: the point of view of a control manufacturerDipl. Ing. E. SteinerIs one programming language sufficient ?In case of a new automation project, it is mandatory to discuss which programming language and environment are to be used. Part of this decision are not only the 'burden of the past' such as compatibility requirements and existing software modules but especially the new concepts offered by the IEC 61131-3 software development environments.Given the demands and the delivery dates, the optimum result is achieved by combining various programming systems with a homogeneous basic concept. The high-performance controlWith the KEMRO system, KEBA provides an overall concept that supports "heterogeneous" programming, i.e. the usage of different programming systems.The architecture of the system software as well as the availability of approved and innovative development environments guarantee a homogeneous basic concept. The diagram shows the basic structure of the KEMRO software architecture:
This overall concept was used in a project for realizing a machine control, whereby particular importance was given to the subsystems programmed in IEC1131-3. In a future article the contents of this project, new ways in software development and the experience the OEM user gained will be presented. This article focuses to our own experience with IEC1131-3 programming in a larger project. The programming languages of the IEC1131-3 in practiceApart from the FBD (Function Block Diagram), all programming languages specified in the standard were used, that means SFC (Sequential Function Chart), ST (Structured Text), IL (Instruction List) and LD (ladder diagram).In the project we have chosen the best type of representation for the corresponding tasks:
Our experience has shown that, especially in case of SFC, the user wishes to program particular actions in any of the IEC1131-3 languages. Furthermore he wishes to represent the contents of these actions together with the SFC symbols for step and transition. The result is a very clear representation of the processes and the operations to be executed at the corresponding steps and actions. The traditional PLC tasks, the calculation of binary operations, was preferred to be specified in LD. However, this is the part the user of the machine frequently wishes to modify later. Therefore the programming language used by this machine user must be taken into account. Will he prefer LD, FBD or IL? Neither the software engineers nor the managers like the idea of developing a program part in all 3 languages. Therefore the only solution is the possibility of switching between languages. To achieve this, the language elements of the IEC 61131-3 standard will in some cases have to be reduced strongly. This, however, is not completely accepted by the users, as they are already familiar with common PLC programming languages. As solution KEBA provides, in addition to the IEC languages LD, FBD and IL, a further "language": the language LD/FBD/IL with limited language elements, but with a representation that can be entirely switched and with exactly the same behavior at runtime level. What about STDiscussions concerning the standard IEC1131-3 gave the high-level language ST little chances of distribution in the PLC world, due to the vast distribution of the IL and the high number of IL trained programmers. If a high-level language is necessary, why not "C"?Today there are only few IEC1131 applications; most of them are smaller projects. Our experience, however, has shown that the fear of using the ST was not as strong as expected. After some problems with the ST syntax, the users soon encoded all programs of the early development phases in ST. We also noticed that typical high-level language elements, such as complex data structures and control instructions were used more and more for clear program structures. Two further facts played an important role: the possibility of programming tasks in a clearer and more compact way, and it became easier to understand the "other" group in coding discussions. The close teamwork of PLC and "C" programmers was certainly an important contribution to the usage of ST. Therefore we believe that ST, if available, will soon be accepted by the users. The problem of dataThe IEC instruction code or the corresponding symbols of the graphical PLC languages hardly differ from currently used languages. It will be no problem to write now "OR %IX3.0" instead of the familiar instruction "O E3.0". Considering the above, it is correct that the user will not encounter any great difficulties when changing to programming according to IEC1131-3.But the PLC languages hardly knew terms such as declaration of variables, data types, instance or scope of variables. The IEC 61131-3 standard, however, requires that all data must be clearly defined. This requirement is true for all programming languages, even for IL! A stop is now put to the current habit "all data are global and the current usage determines the data type". Popular tricks such as writing to inputs to store an intermediate result temporarily are no longer allowed. The rigid type concept of the IEC1131-3 only allows operations on equal or exactly defined data types. And the IEC 61131-3 compiler will check this when generating the loadable code. These definitions, however, are new ground for the "typical PLC programmer". We noticed that the type concept causes problems at the beginning and requires getting used to it. But in larger projects, utilizing all possibilities offered in the standard, the advantage of generating logically clean programs clearly comes into effect in the reduction of the testing phase. We, as a company, experienced that the strategies and software support used in order to assist the programmer in defining and managing his data were not sufficient. Especially if data definitions are to be modified later - as it always happens in the course of software developments - the current support by IEC programming environments could be better. We assume that also other manufacturers will gain experience when applying the IEC1131-3 programming standards in practice, and that this will help them to improve their products. With the organization PLCopen, a platform has been created where manufacturers and users can exchange their experience. Among the tasks of PLCopen are the certification of IEC 61131-3 compliant products as well as the definitions to ensure the portability of IEC programs. As a member of the PLCopen and manufacturer of automation systems, KEBA will keep on working actively on the distribution and implementation of the IEC 1131. The applicationThe aim of the project was to realize the automation system for the new generation of real-time controlled aluminum die-casting machines produced by Bühler AG, Switzerland. Extreme demands had to be met regarding the reproducibility of the process, and special emphasis was given to the usage of the latest programming techniques.In the basic analyses of the project, the advantages of internationally standardized programming languages were pointed out. Therefore, programming the sequence controls in IEC 61131-3 was a must from the beginning. The high demands regarding the performance and the functionality of the entire system could only be fulfilled by a compact multi-master concept. The philosophy of IEC programming and other system development methods and tools - such as analysis or design tools or tools for modeling and simulation - fitted perfectly together. The program structureIEC 1131 provides tools that assist in creating clear program structures. In order to use these tools effectively it is absolutely necessary to analyse the given tasks. The first project phase concentrated on developing the concept and the requirements to be met by the control system. The main function groups were broken down into partial functions and the corresponding data was defined. Furthermore, the real-time requirements for the partial functions were specified.The result was the basis for programming the central sequence control. It was remarkable that the functions and sequences derived from the analysis directly led to IEC terms such as Steps, Transitions, Actions, Functions, Functions Blocks and Tasks. Compared to the data concept that had to be newly created, the handling of functions and function blocks hardly caused any problems in the programming phase of the project. For implementing the code, the function block principle enabled us above all to make use of data hiding. Calls such as FB (in_param:=FB1 , inout_param:=FB2) in the user programs have shown that the programmers utilized the advantages this principle offered for realizing a project. We think these structural measures essentially contributed to the elimination of a very common problem: "Who destroyed my data?" The module concept (importing program modules to other programs) supported by the programming environment provided a further possibility to structure the application software. Although the module concept is accepted in each modern programming environments, the standard IEC 61131-3 does not define any such concept. The real-time worldThe control system had to meet the time requirements of each process. Monitoring and controlling the entire process in one fast cycle - as desired by most of the users - would exceed the performance limits of any processor board. However, on closer examination of the particular tasks, not all processes turn out to be critical as to their time requirements.The IEC 1131 term Task enables to run programs and function blocks with different cycle times. In this way, particular computations can be performed within the actually required time, so the available processor performance can be optimally utilized. This matches the world of microcomputers with familiar terms as preemptive multitasking and priorities. The programmers quickly used these possibilities by consistently programming according to IEC 1131. The standard not only allows programs to run cyclical, but also event-driven. This has been used in the design phase. In this regard, the close teamwork of PLC and microcomputer programmers proved successful again. To further support event-driven processes, the KEMRO systems offers manufacturer-specific functions for mail boxes and semaphores. Due to the standardized software architecture on all masters used, these functions are available to all applications: on the microcomputer boards via operating system calls, on the PLC processor boards via functions and function blocks in conformance with IEC. Messages and semaphores are also global objects. Therefore appropriate links can be established berween master boards in the system. In this project, the communication between the automation system was entirely based on the principle of global messages. At the beginning, this principle was only considered a future consequence of the possibilities offered by the IEC 1131. Fears to leave the known PLC behavior did not come true. Cyclic as well as purely event-driven programs have their right to exist. It is up to the user to decide in which way he best reaches his goals. The system configurationFor the real-time requirements, all processor must communicate at a very high speed. The configuration of the rack-based system for the new die-casting machines consists of one MMI processor, based on an industrial PC, one sequence controller board and two processor boards for high speed control tasks (cycle time 200 µs). Besides the standard digital interface boards, a further processor board for recording measured values can be used.ConclusionAs described, all possibilities offered by the standard IEC1131-3 were utilized. Using this standard in a real application was not always easy, but the final result was to everyone's satisfaction. As manufacturer, we will make use of this practical experience for further improving our products. 
 
|
|
