Modular construction, in particular, based on distributed architecture and communication medium in the form of real-time Ethernet, has many advantages. First of all, controllers can be placed close to the devices they control, e.g., electric motors. This allows for a significant reduction in the length of specialist signal and control cables. In addition, if one of the devices fails, it can be easily replaced. The modular system is highly scalable because it can easily adapt to the requirements of different machines by combining various types of controllers. Modernization of a machine tool equipped with a modular control system is also facilitated.
To ensure the high precision of the machine tool, the algorithms implemented in its controllers must be performed with the highest possible frequency. Let us use the following example to illustrate the level of these requirements. In the most precise high-speed machine tools, the operating frequency of the electric drive control algorithm is usually around 20 kHz [
3]. (As a side note, it should be noted that a further increase in the operating frequency of this algorithm is usually not possible, as the parameters of their power electronic actuators, i.e., insulated-gate bipolar transistors (IGBTs), are the limitation.) The above fact shows that the time available for the controller to perform a full cycle of the control process is in the order of several tens of microseconds. At the same time, within this very short time, the controller must successively: acquire data, process them based on an appropriate algorithm, and finally transfer the calculation results to the actuators. All these stages must be completed before starting the next cycle of the control algorithm.
At this point, the specificity of control systems should be summarized. As mentioned above, a typical control algorithm requires the shortest possible processing time in most cases. This is because this value determines the total system response time, which is a critical parameter in most control systems. In addition, control systems cannot process further inputs until the current control cycle is complete. For this reason, it is not possible to apply pipelining at the level of control signals.
2.1. The Structure of a Distributed Control System
The central controller of the distributed control system (
Figure 2), i.e., the interpolator, is primarily responsible for reference trajectory generation and transmitting it via RTE to individual drives of the machine tool and for supervising their operation.
The task of generating a reference trajectory with appropriate parameters is quite a complex process [
4]. In addition, as in the case of electric servo drives, this task must be performed in precisely measured and very short interpolation cycles (for example, about 100 ms) to ensure the highest quality of machine tool work. This requirement results from the fact that, in each of these interpolation cycles, successive points of the trajectory are determined. They define set values for the servo drives that control the individual axes of the machine tool. This process is shown in the middle part of
Figure 2, where an example path shape is shown as a black semi-circle drawn in the XY coordinate system. Two consecutive points (
,
) of the reference trajectory generated by the interpolator are also visible. The greater the time interval between successive interpolation cycles, the curvature of the geometric path describing the movement of the machine tool is reproduced with lower precision.
Of course, the transfer of data between the master controller, i.e., the interpolator, and its subordinate actuators distributed in the machine’s control system must also be carried out in such cycles and must be synchronized with the operation of the interpolator. This is accomplished using a real-time communication interface.
2.2. Real-Time Ethernet
The properties of the communication medium used determine the amount of data that can be sent from the master controller to the slave controllers and in the opposite direction in a deterministic manner in a given time unit. Many of the real-time communication solutions currently available on the market are collectively referred to as real-time Ethernet solutions. These solutions are based on the physical layer compliant with the IEEE802.3 standard, i.e., Fast Ethernet. The theoretical throughput of this medium is 2 × 100 Mbit/s, i.e., 2 × 12.5 MB/s in full-duplex mode. This is a value that more than meets the requirements of numerical control systems for machine tools, in particular, if only the basic functions of such a system are taken into account, i.e., cyclical transmission of reference trajectory parameters for servo drives controlling machine elements in motion. The amount of such data is usually no more than about one hundred bytes in each communication cycle, i.e., about 1 MB per second. Communication interface support for such an amount of data can usually be successfully implemented by software executed on a single-chip microcontroller unit (MCU) or digital signal processor (DSP).
It turns out, however, that in many cases it is necessary to send up to ten times more data than just the basic data describing the reference trajectory of individual machine drives. This additional data may be required to perform advanced machine service functions or to perform a complex control algorithm. It can also be data transmitting the image from the industrial camera supervising the machining process. The total amount of data transmitted by RTE can therefore be as high as ten megabytes every second [
1]. At the same time, these data must be transmitted with full-time determinism to be useful in the control system.
The recording and analysis of large amounts of data with a time step of tens of microseconds is extremely useful in the control systems of numerical machine tools. First of all, it significantly improves all service and development work of such a system. However, to achieve this functionality, the controllers must send up to several hundred additional bytes of data in each communication cycle, i.e., several megabytes per second. It should be remembered that this transmission must be performed in a time-deterministic manner. Of course, the transmission of these additional data cannot negatively affect the controller’s performance of its basic functions, i.e., in this case controlling the electric drive motor. Such functionality requires a sufficiently efficient real-time communication medium, for example, RTE. In general, it can be stated that the higher the throughput and the lower the delay of the RTE interface, while maintaining its full-time regime, the better the parameters of the control system that can be obtained.
Typically, the only solution to meet the high real-time communication requirements mentioned earlier is to use hardware-based data processing. One example is the on-the-fly processing mechanism designed by Beckhoff and used in the EtherCAT [
5] and Sercos III solutions. The second is the dynamic frame packing mechanism used in the Profinet IRT solution [
6]. Various custom solutions are also available, such as E-LINK [
1] used by individual manufacturers.
In general, the results of the research presented in the above-mentioned publications lead to the following conclusion. Namely, the hardware processing of the data stream of the RTE interface allows for a significant reduction in delays in real-time communication compared to the implementation of analogous functions by software.
The use of the mechanism of hardware processing of data streams of the real-time communication interface requires the use of one of the four solutions listed below. The first is based on the use of an application-specific integrated circuit (ASIC) that implements the functions of a given RTE solution in hardware. Such a system is connected to a universal central unit (MCU or DSP) necessary to execute the implemented control algorithm. The second solution is to use an MCU or DSP factory equipped with all required hardware modules [
7]. The third solution is to use a signal processor with a built-in programmable real-time unit (PRU) that enables quite efficient hardware–software processing of communication interface signals [
8]. The last possible solution is to implement the required hardware functions in the programmable logic of the FPGA.
Each solution has its advantages and disadvantages. Namely, the first of the mentioned solutions is characterized by a relatively high degree of complexity of the electronic part. The printed circuit board (PCB) on which many specialized ASICs must be mounted and interconnected is large and complex. This usually results in higher costs and lower reliability compared to devices built in a compact form. In addition, the performance of such a solution may be significantly limited by the limitations of local communication interfaces connecting individual ASICs on the PCB.
The second solution, although the most convenient for the designer and the most efficient, is unfortunately not always possible to use. This is because an integrated circuit is not always available that integrates all the required hardware modules and a central unit (MCU or DSP) with appropriate parameters. In addition, other, non-obvious arguments may also prove against such a solution. Namely, dedicated integrated circuits do not allow any modification of the hardware processing algorithm implemented in them. As it turns out in practice, sometimes the possibility of such a modification is required. The reason may be the need to improve certain system functions or to fix some detected defects. An example of the latter situation can be found in [
9], where it is written “US cyber-security researchers have discovered flaws affecting dedicated crypto-authentication chips at the heart of Siemens’ S7-1500 family of industrial controllers, and related products, which could allow attackers to execute malicious code on these devices”. Another sentence is important here, which states that “because the faults are associated with the controller hardware, they cannot be fixed by software updates or patches”.
There is one more reason to use programmable circuits, such as FPGAs, instead of ASICs. As we have seen over the last dozen or so years, there may be long-term shortages in the availability of individual electronic components on the market. The reasons for this may be, for example, natural disasters, pandemics, or wars. The consequences of the lack of availability of components can be very serious. As stated in publication [
10] “commodities, materials, software, electronic components, and other replacement components discontinued at short notice or no longer available on the free market for other reasons in Germany cause damage worth billions”. When solutions based on programmable circuits are used, it is usually possible to replace a given integrated circuit with its numerous substitutes, supplied by the same or another manufacturer. This property results primarily from the high universality of FPGAs but also from their long life cycle [
11]. As a result, the production of FPGA-based controllers is characterized by potential resilience to challenges related to the availability of electronic components in the market. Moreover, FPGA-based controllers offer greater development possibilities.
The analysis presented above shows that in many respects the most attractive seem to be solutions offering not only adequately high efficiency, but also the highest possible flexibility, compactness, and energy efficiency. Flexibility should be understood as the possibility of any modification of the algorithms implemented in given systems. The greatest possibilities in this area have solutions based on programmable digital circuits of the FPGA type.
Similar conclusions can also be found in other publications. For example, in paper [
12], a fiber channel switch based on FPGA is designed and implemented due to its high speed, low latency, and high-performance transmission capacities. As the authors wrote further, its advanced capacity of transmitting and processing big data opens a bright perspective for smart manufacturing. The thesis presented above also seems to be consistent with a slightly more general and increasingly popular approach to design, collectively referred to as software-defined everything (SDx) [
13,
14]. The methodology is that components that were traditionally implemented in hardware are instead implemented using software in an embedded system, such as an FPGA. Software-defined radio [
15] is one example.