Further Development of Fieldbus Technology to Support Multi-Axis Motion

Size: px

Start display at page:

Download "Further Development of Fieldbus Technology to Support Multi-Axis Motion"

Emma Hopkins
5 years ago
Views:

1 Further Development of Fieldbus Technology to Support Multi-Axis Motion Dipl.-Ing. Frank Schewe Dipl.-Ing. Jürgen Jasperneite Phoenix Contact GmbH & Co. Technology Development P.O. Box 1341 D Blomberg Germany Abstract The availability of high-speed processors means that drives are increasingly able to perform traditional control tasks. Integrated technology functions such as position control, encoder synchronization and electronic gears have made it possible to replace mechanical components with electronically synchronized independent drives. On the other hand, coordinated multi-axis motion with distributed closed-loop control places higher demands on the associated communication system. Today, proprietary or specially designed bus systems are being used for communication between drives in this field. This article will analyze the increased demands intelligent drives place on communication systems and will present a solution for these demands. To complete the picture, it will also be shown how this solution can be implemented on a standardized INTERBUS (EN 50254) fieldbus system. Background Like many other fields of modern industrial manufacturing technology, modern drive technology has also been influenced considerably by the rapid development of microelectronics. A multitude of powerful, often DSP-based micro-controllers specially designed for driving tasks are available to the drive manufacturers. This means that computational performance can be placed finely portioned close to the machine on inexpensive and compact hardware. A part of the computational performance available is used for manufacturer-specific technology functions, such as the angle synchronization, positioning and electronic gearing. Field bus systems combine these intelligent nodes to a distributed automation system. This provides scope for new automation concepts. Plant and machine functions which are less expensive and more powerful can nowadays often be realized by means of electronic equipment and software. In the field of electric drive technology electronically coupled individual drives replace the central drive with secondary shafts, kinematic units and gear units (see figure 1). The user profits from lower commissioning and setting-up times, higher flexibility as well as improved

2 Figure 1. Replacement of mechanical components with electronically synchronized drives availability of the machine. Decentralized drives allow the realization of modular machine concepts through the use of standardized partial functions. The machines can be scaled better and can be adapted optimally to the requirements of the end customer. The trend towards now realizing and coupling functions electronically which were previously realized with mechanical units and also coupled mechanically means that field bus systems now also become components in feedback signal chains. A typical example can be found in decentralized cascade controls at production machines in which the bus not only has to connect local controllers lying apart from each other, but also in particular to carry out the data transport between these controllers and the higher-level controllers. From the system point of view the bus becomes the central communications axis of the distributed automation system resulting in the following modified requirements for the bus: From the point of view of control technology the bus represents an undesired lag element due to its transport delay. Since the transport delay by the bus is unavoidable, it must be short and constant. In locally concentrated control systems the various and usually different sampling periods of the individual control loops are generally synchronized by means of an interrupt scheme. In decentralized systems this synchronization must be carried out via the bus. In locally concentrated control systems information which belongs together with respect to its time (up to a few µs) can be outputed to the interface systems or detected by the sensors simultaneously. Decentralized systems also have to ensure this time-specific data consistency despite the bus. The control systems are now usually designed by means of PC-based software programs. The distribution of the software via the bus must still be possible after the simulation of the overall system and partitioning of the software for the individual local controllers. During operation and especially during the commissioning phase it must be possible to configure and monitor the local controllers without influencing the cyclic interchange of data between the control systems.

Requirements for locally distributed control systems with bus coupling From the point of view of the control technology the transport delay of the bus represents an undesired lag element.

3 Requirements for locally distributed control systems with bus coupling From the point of view of the control technology the transport delay of the bus represents an undesired lag element. If, for example two driving axles (see figure 2) which are functionally linked but are positioned away from each other are to carry out a coordinated movement whose setpoints are supplied by a higher-level controller at a third point, these setpoints which belong together in time not only have to arrive at the local axle controllers simultaneously, but both axles must also begin simultaneously with the execution of these movement specifications. Similarly actual values (for example position values) which the local drives signal to the higher-level controller for the calculation of new specifications also have to be detected simultaneously so that the quality of the control systems is not impaired unnecessarily. This requirement that the time-specific consistency of the data is maintained during transfer in both directions of the closed signal flow requires that the sampling periods of the controllers involved must be coordinated between each other and with the bus transfer. This fulfills the requirement of a constant lag element. The requirement of a shorter lag element, on the other hand, represents an additional marginal condition. It requires rapid data transfer between the bus nodes within this synchronous time scheme. Figure 2. Example of functionally linked axles over INTERBUS The transport principle of the INTERBUS INTERBUS, standardized in EN50254, functions in accordance with the master-slave principle. The functional model can be described as a ring shift register /1/. The transporting principle can be described as follows. The slide register ring can be interpreted as a chain of data containers in which

4 each slave module (for example a local controller) as well as the master participates with its own "container" of individual length (typically 8-48 bits). At the beginning of a transport cycle the locally distributed slave modules load their input data into the container parked by them. The container will then be cyclically passed on. During a cycle each container then passes the controller and each module exactly once and is positioned at the end of the cycle at exactly the module which it left at the beginning of the cycle (each module has its own "private container"). During the cycle the master unloads the containers passing through it (it takes out the input data) and loads it with output data (data substitution). These are then positioned at the target modules at the end of the cycle. The data are enabled simultaneously (with a deviation of a few µs) at the end of the cycle at all the modules. The time-specific and positional data consistency as well as a constant and simultaneous lag element are ensured in the INTERBUS through the summation frame protocol by the architecture. Synchronization of the operations via the bus If the transport of a summation frame is triggered periodically and at equidistant intervals, all the bus nodes receive the enable signal for the data in a phase-locked time base and can synchronize their sampling period or their actual-value detection. In order to additionally synchronize the phase relation of the sampling and measuring periods the bus cycles must furthermore be numbered (see figure 3). The DRIVECOM profile /2/, for example, provides a status word specific for each individual bus node into which this flag can be entered. The lower-level controllers all receive this starting signal simultaneously and can synchronize themselves to it. If the system has several levels of motion which are not interdependent, a separate start flag can be used for each level, if desired. Figure 3. Synchronisation via the bus From this basic pulse rate it is possible to develop global periods which are a multiple of this basic pulse rate. If, on the other hand a shorter sampling time is required at the bus nodes, for example for lower-level control loops, it is possible to create a fraction of this basic pulse rate via a local timer which can be synchronized via a PLL process. Although each bus node sees the enable signal at equidistant intervals, it does not arrive at all the nodes at exactly the same time. This is due to the delay on the transfer medium and in particular to the repeater function of the modules, which, depending on the operating mode, cause a typical delay of 1.5 to 2 bit periods at a bit rate of 2 Mbit/s, i.e or 1 µs. If in the worst case to bus nodes to be synchronized lie at opposite ends of the bus, this signal arrives at these nodes which a displacement of a few µs in the case of a medium-sized installation. There are applications where this cannot be

tolerated: If the position of two axles are measured, for example with a displacement of 50 µs, and the axles rotate at a speed of 3,000 min -1, this would simulate an angle error of almost one

5 tolerated: If the position of two axles are measured, for example with a displacement of 50 µs, and the axles rotate at a speed of 3,000 min -1, this would simulate an angle error of almost one degree. However, since this delay can be calculated beforehand by means of the system configuration and furthermore remains constant, this error can be corrected by means of a local delay of the enable signal at the bus nodes. Figure 4. INTERBUS Architecture Short lag element A high net data rate is an important factor in achieving a short transport delay by the bus. This is realized by the bit rate of 2 Mbit/s and the high protocol efficiency of the summation frame. The INTERBUS topology (see figure 4) furthermore has the greatest potential of all bus topologies for further increasing the transfer rate, due to the active bus-node coupling /3/. The master-slave process used in INTERBUS, in which the slaves can only exchange data with the master within one cycle, is particularly suitable for applications in which the higher-level controller is realized on the master. This is usually the case in real applications. Parameter data channel In addition to the cyclic exchange of process data (for example setpoints and actual values), INTERBUS can be used to create parameter data channels for bus nodes when configuring the system. It is possible to communicate with the bus nodes through these data channels with a connection-orientated protocol without influencing the time-specific behavior of the process data.

6 Software downloads to the drives, changes to the controller parameters and monitoring of the controllers can thus be carried out at the same time as the cyclic exchange of process data. Conclusion and prospects INTERBUS is particularly suitable for future decentralized drive concepts since it is on the one hand highly synchronous and deterministic from its concept and on the other hand uses a topology which has the largest potential for increasing the transfer rate. However, the requirements placed on the field bus of the future are not defined exclusively by the electric drive technology. A modern field bus system must at the same time: Detect signals Synchronize drives Master dangers Connect worlds References /1/ Baginski, A., Müller, M. 'INTERBUS-S, Grundlagen und Praxis' Hüthig Buch Verlag Heidelberg 1994 /2/ DRIVECOM Profil Antriebstechnik, 1997 /3/ Meier, U., Meinhardt, S. Topologievergleich serieller Feldbusse bei hohen Übertragungsraten atp Automatisierungstechnische Praxis, 3/99

High Precision Drive Synchronisation with CANopen

High Precision Drive Synchronisation with CANopen Martin Rostan, Beckhoff Josef Langfermann, Lenze Corp. For many users and suppliers CAN is the first choice for drive communication Ð due to its reliability,