Introduction
The method of emulating classic automation devices such as programmable logic controllers (PLC) and numerical controllers (NC) as software on powerful standard hardware has been the state of the art for many years and is now practiced by many manufacturers.
There are many benefits, but the most important is without doubt the fact that the software is mostly hardware-independent. This means, firstly, that the performance of the hardware can be specially adapted to the application and, secondly, that you can automatically benefit from its further development.
This particularly applies to PC hardware, whose performance is still increasingly at a dramatically fast rate. The relative independence from a supplier that results from this separation of software and hardware is also very important for the user.
Since the PLC and Motion Control – and possibly other automation components – remain independent logic function blocks with this method, there are only a few changes in the application architecture in comparison with classic automation technology.
The PLC determines the machine's logical processes and transfers the implementation of certain axis functions to the Motion Control. On account of the improved performance of the controllers and the possibility to use higher-level programming languages (IEC 61131-3), even complex machines can be automated in this way.
Modularization
In order to master the complexity of modern machines and at the same time to reduce the necessary engineering expenditure, many machine manufacturers have begun to modularize their machines. Individual functions, assemblies or machine units are thereby regarded as modules, which are as independent as possible and are embedded into the overall system via uniform interfaces.
Ideally a machine is then structured hierarchically, whereby the lowest modules represent the simplest, continually reusable basic elements. Joined together they form increasingly complex machine units, up to the highest level where the entire machine is created. Different approaches are followed when it comes to the control system aspects of machine modularization. These can be roughly divided into a decentralized and a centralized approach.
In the local approach, each machine module is given its own controller, which determines the PLC functions and possibly also the motion functions of the module.
The individual modules can be put into operation and maintained separately from one another and scaled relatively independently. The necessary interactions between the controllers are coordinated via communication networks (fieldbuses or Ethernet) and standardized via appropriate profiles.
The central approach concentrates all control functions of all modules in the common controller and uses only very little pre-processing intelligence in the local I/O devices. The interactions can occur much more directly within the central control unit, as the communication paths become much shorter. Dead times do not occur and use of the control hardware is much more balanced, which reduces overall costs.
However, the central method also has the disadvantage that the necessary modularization of the control software is not automatically specified. At the same time, the possibility of being able to access any information from other parts of the program in the central controller obstructs the module formation and the reusability of this control software in other applications. Since no communication channel exists between the control units, an appropriate profile formation and standardization of the control units frequently fall by the wayside.
The best of both worlds
The ideal controller for modular machines uses elements from decentralized and centralized control architecture. A central, powerful computer platform of the most general kind possible serves 'as always' as the control hardware.
The benefits of centralized control technology:
- low overall costs
- available
- fast, modular fieldbus system (keyword: EtherCAT)
- and the possibility to access all information in the system without loss of communication
are decisive arguments.
The above-mentioned benefits of a decentralized approach can be implemented in the centralized control system by means of suitable modularization of the control software.
Instead of allowing a large, complex PLC program and an NC with many axes to run, many small ‘controllers’ can co-exist in a common runtime on the same hardware with relative independence from one another. The individual control modules are self-contained and make their functions available to the environment via standard interfaces, or they use corresponding functions of other modules or the runtime.
A significant profile is created through the definition of these interfaces and the standardization of the corresponding parameters and process data. Since the individual modules are implemented in a runtime, direct calls of other modules are also possible – once again via corresponding standard interfaces. In this way the modularization can take place within sensible limits without communication losses occurring.
During the development or commissioning of individual machine modules, the associated control modules can be created and tested on any control hardware with the appropriate runtime. Missing connections to other modules can be emulated during this phase. On the complete machine they are then instanced together on the central runtime, which only needs to be dimensioned such that the resource requirements of all instanced modules (memory, tasks and computing power) are fulfilled.
TwinCAT 3 runtime
TwinCAT Runtime offers a software environment in which the TwinCAT modules are loaded, implemented and managed. It provides more basic functions so that system resources (memory, tasks, fieldbus and hardware access, etc.) can be used. The individual modules must not have been created with the same compiler. This means that they can be independent of each other and come from different suppliers.
When the runtime starts, some system modules are automatically loaded so that their properties are available to other modules. However, the properties of the system modules are accessed in the same way as the properties of normal modules, so it does not matter to the modules whether the respective property is provided by a system module or a normal module.
Unlike the PLC, where the user-defined program is executed in a runtime environment, TwinCAT C++ modules are not in such a hosted environment. This causes TwinCAT C++ modules (.tmx) to be executed as kernel modules, which are loaded by TwinCAT.