- Email: [email protected]
Design, implementation and validation of a system for the dynamic reconfiguration of open architecture machine tool controls
International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Design, implementation and validation of a system for the dynamic reconfiguration of open architecture machine tool controls K.D. Oldknow, I. Yellowley
*
Department of Mechanical Engineering, University of British Columbia, 2324 Main Mall, Vancouver, B.C. V6T 1Z4, Canada Received 8 August 2000; accepted 11 October 2000
Abstract This paper discusses the design and implementation of a system and protocol for the automatic configuration and dynamic reconfiguration of distributed machine tool control systems. A novel servo controller, based on a Field Programmable Gate Array (FPGA) hardware architecture is used to demonstrate the feasibility of the configuration system. 2001 Elsevier Science Ltd. All rights reserved.
1. Introduction Current trends in the manufacturing industry have led both academic and industrial researchers to conclude that traditional “closed” CNC machine tool control systems do not provide the functionality, flexibility or cost effectiveness necessary for manufacturers to keep pace with the rapidly shifting demands of the marketplace. This has resulted in a wave of so-called Open Architecture control system projects, each with an independent set of goals and priorities [1,2,4–18,20]. As summarised by Teltz and Elbestawi [1], the advantages that these open architecture systems should offer are derived from the following benefits: 1. the economies of scale gained from using standardised hardware 2. the ability to integrate system functionality in a hardware independent manner. It was further pointed out that, while many open architecture control systems realise the first of
* Corresponding author. Tel.: +1-604-822-2781; fax: +1-604-822-2403. E-mail address: [email protected] (I. Yellowley).
0890-6955/01/$ - see front matter 2001 Elsevier Science Ltd. All rights reserved. PII: S 0 8 9 0 - 6 9 5 5 ( 0 0 ) 0 0 1 0 9 - 7
796
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Nomenclature t z ⍀(s) q(s) wn qR(s) a b BLU D(s) D(z) E(s) E(z) G0(s) Im Je KA KDA Kenc Kp KT Ktach R(s) R(z) s U(s) z
Velocity loop time constant (s) Closed loop damping ratio Angular velocity of DC Motor shaft (rad/s) Angular position of DC Motor shaft (rad) Closed loop natural frequency (rad/s) Axis reference position (BLU) Continuous-time lead/lag filter parameter Continuous-time lead/lag filter parameter Base Length Unit: smallest resolvable position change in a CNC system Digital Filter Laplace domain transfer function Digital Filter Z-transform domain transfer function Position error in the Laplace domain (BLU) Position error in the Z-transform domain (BLU) Zeroth-order hold DC Motor armature current (A) Effective polar moment of inertia reflected to the motor shaft (Kg*m2) Servo Amplifier voltage/current gain (A/V) Digital to Analog (D/A) converter gain (V/BLU) Encoder feedback gain (BLU/rad) Lead/lag filter gain DC Motor torque constant (N*m/A) Tachometer feedback gain (V/(rad/s)) Digital Filter output signal in the Laplace domain (BLU) Digital Filter ouput signal in the Z-transform domain (BLU) Laplace Transform variable Servo Amplifier reference voltage (V) Z-Transform variable
these benefits, the resulting advantages are often diminished by a failure to meet the second. This is particularly true when the purpose of the controller includes the optimisation, in real time, of the machining cost. The technique for doing this is known as Adaptive Constraint Optimisation, and requires the ability to integrate novel hardware and software for the simultaneous monitoring of and reaction to multiple potentially active constraints [3,8,19,20]. 2. Integration of process and motion in an open controller One control architecture that is particularly well-suited to the integration of multiple constraintbased process control with CNC motion control is the UBC Open Architecture Control System
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
797
[3,18,19,20]. Shown schematically in Fig. 1, the reference architecture is based on a distributed model involving several processing entities and two communication channels. While several of these entities may actually be present on a single processor (i.e. boundaries in the reference model are logical rather than physical), the reference architecture provides the basis for the system’s functionality. The primary master (labeled Master 1) in Fig. 1 is the CNC Master, responsible for (among other things) user interface tasks and the generation of first-stage motion increments in a twostage interpolation scheme. The second master processor (labeled Master 2) is optional, and is typically used for CAD/CAPP/CAM activities. One slave servo controller is present for each physical axis on a machine tool. These servo controllers receive the first-stage interpolated increments from the CNC Master over the backplane communication channel, which may be an internal channel (in a single-processor implementation), a backplane (such as STD/STD32), or a network (e.g. Ethernet). The first-stage increments are then broken down into second-stage increments required by the controller at the loop closing frequency using either a linear or parabolic blended algorithm [18]. It can be seen in Fig. 1 that the servo controllers are connected to each other, as well as to any process monitoring boards, via a second communication channel incorporating a Frontplane Bus and Synchronization line. This second channel allows the servo controllers to implement a dynamic interpolation algorithm, which facilitates the adaptive control of machining processes in response to multiple constraints, as well as the integration of novel hardware into the system. The dynamic interpolator operates by examining the value present on the Frontplane Bus before closing the position control loop. The bus is made up of one or more open collector lines, which can be written to simultaneously by all connected processors (the open collector lines have the effect of ANDing the value written by the processors). In the simplest case of a single stateline, the interpolator has two courses of action. If the value present on the stateline is logic high, then the next second-stage increment is added to the position buffer. If the value is logic low, no increment is added but the control loop is closed in the normal fashion. In this way, any servo
Fig. 1. UBC open architecture control system reference model.
798
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
controller or process monitor in the system can adaptively control the system in response to the impending violation of a process constraint (examples include, chip thickness, shank stress, spindle torque and contouring accuracy). A more complex, multi-bit stateline approach has also been implemented [20]. In this approach, the dynamic interpolator probes the Frontplane Bus for a multi-bit integer value. Based on this value, the interpolator can do any of the following: 1. Add a single motion increment to the position error buffer (normal operation). 2. Add no motion increments to the position error buffer (response to an impending constraint violation). 3. Add multiple increments to the position error buffer (response to lower-than expected values of chip thickness, shank stress, etc.) 4. Subtract increments from the position error buffer (reducing the current error or physically reversing the axis). As in the single stateline implementation, the processor that writes the most-limiting value to the frontplane will dictate the rate at which the process proceeds. Clearly, the architecture described allows for the integration of system functionality in a simple, robust manner. The purpose of the work described in the following sections is to enhance the modularity and functionality of the architecture through the introduction of dynamic reconfigurability, while preserving the openness and extensibility of the system.
3. Reconfigurability and its advantages As mentioned in the introductory paragraphs, economies of scale in the production of Open Architecture control system components can be gained through hardware standardisation. In fact, this idea can be generalised into the more powerful concept of hardware independence (also referred to as vendor neutrality). Rather than standardising at the electrical signal (e.g. bus) level, hardware independence typically involves abstraction at the software level. In this approach, hardware device behaviour is encapsulated as a class definition (in object-oriented terms) and presented to the rest of the system as a well-defined neutral interface. By writing an appropriate class definition and incorporating it into the system, any device that satisfies the functional requirements of a given logical device can be used. Through this technique, a control system becomes reconfigurable, i.e. hardware (and software) modules can be replaced in the system without requiring code changes outside the scope of the class definition or affecting the behavioural operation of the system. Reconfiguring a system in this way most often requires a software re-build (i.e. compile, link) so that the alternate class definition(s) can be incorporated in the system. Obviously this requires shutting down the machine tool and re-starting after the software has been modified. The approach can therefore be referred to as static reconfigurability. This type of reconfigurability allows machine tool builders and integrators to assemble working systems by selecting modular components from vendors offering the current best combination of technology and cost. A system can be further enhanced, however, by introducing the concept of dynamic reconfigur-
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
799
ability, which refers to the ability to reconfigure the system at run-time (i.e. without requiring a system shut-down). During the development of control system components, dynamic reconfigurability allows communication and control methods to be tested, evaluated, modified and replaced without going through a re-start. This facilitates extremely rapid debugging and optimisation, leading to a compressed development cycle. In addition, dynamic reconfiguration allows the redistribution of process monitoring tasks as process conditions and requirements change. This is particularly useful in the multiple-constraint-based optimisation of variable machining cost, in which varying processes require different sets of potentially active constraints to be monitored. 4. Design and implementation of an open configuration system and protocol The approach taken to providing the dynamic reconfigurability described in the previous section has been the development of an Open Configuration System and Protocol. The system is implemented in an object-oriented extension of the Forth programming language [21] and is based on the abstraction of system control hardware into a Virtual Machine Tool (VMT). The software structure of the Open Configuration System, as well as its relationship to high-level system software and low level control hardware is shown in Fig. 2.
Fig. 2. Open configuration system software structure.
800
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
As shown, the configuration system presents a VMT interface to high-level software (path planning, user interface, etc.). Calls made to the interface are handled by the VMT objects (axes, PLC, process monitors) using a combination of hardware independent methods and hardware dependent methods. While hardware independent methods are defined within the object class definitions, hardware dependent methods are made up of references into a software entity called the Binding Table. The Binding Table translates these references into the appropriate methods used to interface with the physical hardware. As an example, the most common hardware dependent methods used in the implementation of an axis controller are listed below. 앫 앫 앫 앫 앫 앫 앫 앫 앫 앫 앫
sendFheader: sendFincrement: readFposition: readFvelocity: readFaccel: readFerror: flushFbuffer: reset: halt: enable: setFfilter:
An attempt is made here to follow good software design practices by clearly indicating a method’s functionality through its name. The dynamically reconfigurable nature of the system is derived from the means by which the Binding Table translates references and executes corresponding methods. This is done through the use of a technique known within the Forth programming environment as Vectored Execution. Essentially, the Forth language is made up of a dictionary of words (analogous to functions, procedures or routines in other languages). The environment is interpretive, allowing the programmer/user to add words to the dictionary at any time. Now, the run-time behaviour of a given word can be extracted and represented by a single memory reference called an Execution Token (XT). An XT can be passed between words, stored as a variable, and executed by other words in the system. The Binding Table then acts as a storage space for a series of XT’s that represent the low-level methods required to interact with the physical system devices. When the system is started, the binding table entries are empty as shown in Fig. 3 (this screen dump was generated from a demonstration of the Open Configuration System, implemented in the SwiftForth environment on a PC running Windows 98). The VMT, however, is in place and the interface can be used as the foundation for high-level software. In this way, the CNC system software can be built without any knowledge of the underlying hardware. With the VMT in place, the XT’s corresponding to the hardware dependent methods can be bound to the appropriate references, resulting in a fully configured system as shown in Fig. 4. At this point, while the system is functional and can be used to control the underlying machine tool, the Binding Table remains fully reconfigurable. That is, XT’s stored in the table cells can be modified and/or replaced dynamically.
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Fig. 3.
801
Binding table with virtual machine tool built (no low-level devices bound).
4.1. Tokenised Configuration Stream (TCS) There are several ways in which device method XT’s can be defined and stored in the Binding Table. For example, it can be done by the user through the interpretive interface (useful in rapid development and evaluation of system components). Alternatively, a text file containing the appropriate Forth code can be retrieved from a storage device and interpreted. Most uniquely, a stream of tokenised code can be retrieved from the firmware of the system device itself. This is the method used in the start-up sequence defined by the configuration protocol. This Tokenised Configuration Stream (TCS) approach has its roots in the Open Firmware standard that was developed by Sun Microsystems [22]. (Similar approaches have been applied to run-time firmware debugging [24] and plug-and-play satellite systems [23].) At start-up, the open configuration system probes all available communication channels for compatible devices. When a device is found, a tokenised (i.e. byte-coded) stream is retrieved from the firmware of the device. The tokenisation scheme is an extended version of the Open Firmware standard, and can be directly translated into Forth code. Once this translation has been done, the Forth code is interpreted by the system. When interpreted, the code registers the device
802
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Fig. 4.
Binding table with hardware dependent device methods bound.
in the system, defines the methods required to communicate with the device, and binds these to the appropriate VMT methods through the Binding Table. Effectively then, the ‘device driver’ is stored in the firmware of the device itself. 4.2. Communication Channel Bindings In order to retrieve the TCS from the firmware of a system device, the Open Configuration System must be able to communicate with the device. However, as previously noted, the vendor neutrality of the approach means that the system may have no knowledge about the device present. The solution employed is the use of Communication Channel Bindings, which abstract each communication channel as an object within the system. Very simple methods are provided to utilise the channel, as shown in the Standard Parallel Port example shown in Table 1. These simple methods represent the limited degree to which the device must be compatible with the system in the absolute sense. Once the TCS has been retrieved from a device, the translated code can make use of the available Communication Channel methods to communicate with the device through arbitrarily complex schemes.
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
803
Table 1 Standard parallel port (SPP) methods and stack diagrams Method Name
Token
Stack diagram
Describe: OpenPort: ClosePort: ReadStatus: WriteData: WriteControl: Detect: GetTCS:
n/a 0x601 0x602 0x603 0x604 0x605 n/a n/a
( ( ( ( ( ( ( (
-- ) -- ) -- ) -- n ) n -- ) n -- ) -- flg ) 2– flg )
5. System validation: an FPGA-based servo controller Validation of the Open Configuration System and Protocol has been coupled with the development of a Field Programmable Gate Array (FPGA) based servo controller. FPGAs offer flexibility approaching that of general-purpose processors and the custom application efficiency of Application Specific Integrated Circuits (ASICs). While application development time for an FPGA solution is slightly longer than that for a general-purpose processor due to time spent developing the FPGA configuration, it is dramatically shorter than the ASIC development cycle. The reduction in Nonrecurring Engineering (NRE) costs versus ASICs and the reduction in non-required functionality versus general-purpose processors result in extremely cost effective architectures [26]. The prototype controller has been implemented in a 20 000 gate Xilinx FPGA, with the design shown schematically in Fig. 5. A TCS is embedded in the controller and can be retrieved during
Fig. 5. FPGA based servo controller design.
804
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
start-up. Once the system has been configured, the VMT interface can be used to control the device. The device operates at a loop closing frequency of 4 kHz, and is capable of controlling a single machine tool axis with the dynamic interpolation capabilities defined by the UBC Open Architecture Control System reference architecture. As shown in Fig. 5, the design is comprised of nine interacting logical blocks. Using the Very-large-scale-integrated Hardware Description Language (VHDL), these blocks are designed to be independent state machines operating on a synchronous clock signal. That is, the FPGA architecture allows the various components of the servo controller to be implemented in a true multiprocessing fashion. Through this multiprocessing approach, activities such as second stage interpolation, digital filtering, quadrature decoding and pulse width modulation can be achieved on a single chip with a relatively slow clock speed of 12 MHz. Beyond the single, low-cost FPGA chip, minimal external circuitry is required in the servo control application. An external 32k RAM chip is used to store first stage interpolated increments passed over the backplane channel (a Standard Parallel Port in this case). While interfacing to a digital servo amplifier is a straightforward endeavour, an analog reference signal can also be generated using a simple filter to convert a 0 to 3.3V pulse-width-modulated (PWM) FPGA output signal to a ⫺10 to +10 V continuous reference signal. The prototype controller has been integrated into a laboratory test stand in the Manufacturing Engineering Laboratory at the University of British Columbia to verify its operation and test its performance. The test stand is comprised of a current-controlled brushed DC motor loop (with tachometer and encoder feedback), a servo amplifier, and the combination of a Celeron 333 MHz PC with the VMT interface implemented in SwiftForth and the prototype FPGA controller connected via a Standard Parallel Port. The control loop block diagram is shown in Fig. 6, while a photograph of the test stand is shown in Fig. 7. Using the technique put forward by Seethaler and Yellowley [25], the behaviour of this Type 1 system can be specified as a simple quadratic through the use of a lead-lag filter defined by the continuous time transfer function s+a D(s)⫽Kp· . s+b This allows the velocity loop dynamics to be cancelled by setting the lead parameter equal to the inverse of the velocity loop time constant, i.e. 1 KA·KT·Ktach . a⫽ ⫽ t Je
Fig. 6. Velocity controlled servo loop block diagram.
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
805
Fig. 7. Laboratory test stand photograph.
The damping ratio and natural frequency of the resulting second order system can then be specified by setting b⫽z and K p⫽
wn2·t . KDA·Kenc
A +5V step input was used as an input signal to determine the test stand velocity loop time constant. The value of the time constant was determined to be approximately 10 ms. Using the technique mentioned above, the lead lag parameters were adjusted to yield a damping ratio of 0.707 and a natural frequency of 25 Hz for the overall position control loop. The VMT interface was then used to generate a 4000 BLU per second ramp input for the servo controller to track. The results are shown in Fig. 8. As shown, the servo controller was able to track the ramp closely, with the following error settling to a steady-state value of approximately 7 BLU (as can be expected for a Type 1 system). 6. Conclusions It has been recognised that the ability to reconfigure an Open Architecture machine tool control system for a variety of hardware platforms provides significant advantages, particularly in the cost effectiveness of the control (this is driven by the property of vendor neutrality). The ability
806
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Fig. 8. Position loop ramp response.
to dynamically reconfigure the system provides further significant advantage. This includes the ability to re-distribute monitoring tasks based on process conditions, as well as a reduction in development cycle time resulting from “on-the-fly” development and testing. In accordance with these concepts, an Open Configuration System and Protocol has been developed that allows the dynamic reconfiguration of controllers implemented according to the UBC Open Architecture Control System Reference Model. The system improves the vendor neutrality of the system by implementing an object-oriented virtual machine tool that abstracts the behaviour of the control components of the system. Low-level device specific routines are called through a reconfigurable software switch known as a Binding Table, which facilitates dynamic reconfiguration of the system. By storing device specific code in the firmware of the devices themselves (in a tokenised form), hardware devices are able to instantiate themselves in the system, define the methods required to interface with them, and bind these methods into the binding table. A novel FPGA based servo controller has been developed to demonstrate the feasibility of the Open Configuration System approach. The controller is designed to control a single machine tool (or robotic) axis, in accordance with the UBC Open Architecture reference model. The design can be synthesized to fit in a 20 000 gate FPGA, and has been implemented on a prototyping board incorporating a Xilinx FPGA, external RAM chip and minimal analog circuitry. The controller has
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
807
been integrated into a laboratory test stand, and tested for correct operation as well as conformance with the Open Configuration System and Protocol.
Acknowledgements The authors gratefully acknowledge the support of the Natural Science and Engineering Research Council of Canada (NSERC).
References [1] R.W. Teltz, M.A. Elbestawi, Design basis and implementation of an open architecture machine tool controller, Transactions of NAMRI/SME XXV (1997) 229–304. [2] Y. Altintas, W.K. Munasinghe, A hierarchical open-architecture CNC system for machine tools, Annals of the CIRP 43 (1) (1994) 349–354. [3] R. Ardekani, I. Yellowley, The control of multiple constraints within an open architecture machine tool controller, Transactions of the ASME Journal of Manufacturing Science and Engineering 118 (1996) 388–393. [4] C.P. Bailo, C.J. Yen, Open Modular Architecture Controls at GM Powertrain: Technology and Implementation, Proceedings of SPIE 2912 (1991) 52–63. [5] N.A. Erol, Y. Altintas, M. Ito, Modular tools for motion control and process control system design, Proceedings of SPIE 2912 (1996) 13–23. [6] GM Powertrain Group (GMPTG), Open, Modular Architecture Controls at GM Powertrain: Technology and Implementation, Version 1.0, GM Powertrain Group Manufacturing Engineering Controls Council (1996). [7] Y. Koren, C.C. Lo, Advanced controllers for feed drives, Annals of the CIRP 41 (2) (1992) 689–698. [8] TH. Lundholm, A flexible real-time adaptive control system for turning, Annals of the CIRP 40 (1) (1991) 441–444. [9] P. Lutz, W. Sperling, OSACA – the vendor neutral control architecture, in: Proceedings of the European Conference on Integration in Manufacturing, Dresden, Germany (1997) 10pp. [10] G. Pritschow, C.H. Daniel, G. Junghans, W. Sperling, Open system controllers – a challenge for the future of the machine tool industry, Annals of the CIRP 42 (1) (1993) 449–452. [11] F. Proctor, W. Shackleford, C. Yang, Simulation and implementation of an open architecture controller, Proceedings of SPIE 2596 (1995) 196–204. [12] C. Sawada, O. Akira, Open Control Architecture OSEC-II: Architecture overview and prototype systems, in: IEEE Symposium on Emerging Technologies and Factory Automation, ETFA ’97, Los Angeles (1997) 543-550. [13] S. Schofield, P. Wright, Open architecture controllers for machine tools, part 1: Design principles, ASME Journal of Manufacturing Science and Engineering 120 (1998) 417–424. [14] W. Sperling, P. Lutz, Designing applications for an OSACA control, in: Proceedings of the ASME International Mechanical Engineering Congress and Exposition, Dallas (1997) 5 pp, ASME, New York, NY. [15] E.D. Tung, M. Tomizuka, Feedforward tracking controller design based on the identification of low frequency dynamics, Transactions of the ASME Journal of Dynamic Systems, Measurement and Control 115 (1993) 348–356. [16] G. Weinert, Java based open architecture controller, in: Proceedings of the 7th International Symposia on Manufacturing with Applications (ISOMA), World Automation Congress 2000, Wailea (2000) 6pp, TSI Press, Albequerque, New Mexico. [17] P. Wright, Principles of open-architecture manufacturing, Journal of Manufacturing Systems 14 (3) (1995) 187–202. [18] I. Yellowley, P. Pottier, A note on a simple method for the improvement of interpolation accuracy in a general purpose, multiprocessor based motion controller, International Journal of Machine Tools & Manufacture 29 (2) (1989) 287–292.
808
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
[19] I. Yellowley, P.R. Pottier, The integration of process and geometry within an open architecture machine tool controller, International Journal of Machine Tools & Manufacture 34 (2) (1994) 277–293. [20] I. Yellowley, R. Ardekani, L. Yang, R. Seethaler, Development of robust extensible architectures for machine tool control, Proceedings of SPIE 2912 (1996) 72–81. [21] A. McKewan, Object-Oriented programming in ANS Forth, Forth Dimensions March/April Edition (1997) 14–29. [22] W.M. Bradley, D.M. Kahn, J. Rible, M. Williams, IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices – IEEE Std. 1275-1994, Institute of Electrical and Electronics Engineers, New York, 1994. [23] R. Caffrey, H. Shaw, L. Wagner, Developing plug-and-play spacecraft systems: NASA Goddard Space Flight Center’s (GSFC) Essential Services Node (ESN), AIAA-IEEE Digital Avionics Systems Conference Proceedings 1 (1997) 2. [24] B. Eckert, Firmware Factory User’s Manual, http://www.geocities.com/SiliconValley/ Cable/3439, 1999. [25] R. Seethaler, I. Yellowley, The regulation of position error in contouring systems, International Journal of Machine Tools & Manufacture 36 (6) (1996) 713–728. [26] A.K. Sharma, Programmable Logic Handbook – PLDs, CPLDs & FPGAs, McGraw-Hill, New York, NY, 1998.
Design, implementation and validation of a system for the dynamic reconfiguration of open architecture machine tool controls K.D. Oldknow, I. Yellowley
*
Department of Mechanical Engineering, University of British Columbia, 2324 Main Mall, Vancouver, B.C. V6T 1Z4, Canada Received 8 August 2000; accepted 11 October 2000
Abstract This paper discusses the design and implementation of a system and protocol for the automatic configuration and dynamic reconfiguration of distributed machine tool control systems. A novel servo controller, based on a Field Programmable Gate Array (FPGA) hardware architecture is used to demonstrate the feasibility of the configuration system. 2001 Elsevier Science Ltd. All rights reserved.
1. Introduction Current trends in the manufacturing industry have led both academic and industrial researchers to conclude that traditional “closed” CNC machine tool control systems do not provide the functionality, flexibility or cost effectiveness necessary for manufacturers to keep pace with the rapidly shifting demands of the marketplace. This has resulted in a wave of so-called Open Architecture control system projects, each with an independent set of goals and priorities [1,2,4–18,20]. As summarised by Teltz and Elbestawi [1], the advantages that these open architecture systems should offer are derived from the following benefits: 1. the economies of scale gained from using standardised hardware 2. the ability to integrate system functionality in a hardware independent manner. It was further pointed out that, while many open architecture control systems realise the first of
* Corresponding author. Tel.: +1-604-822-2781; fax: +1-604-822-2403. E-mail address: [email protected] (I. Yellowley).
0890-6955/01/$ - see front matter 2001 Elsevier Science Ltd. All rights reserved. PII: S 0 8 9 0 - 6 9 5 5 ( 0 0 ) 0 0 1 0 9 - 7
796
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Nomenclature t z ⍀(s) q(s) wn qR(s) a b BLU D(s) D(z) E(s) E(z) G0(s) Im Je KA KDA Kenc Kp KT Ktach R(s) R(z) s U(s) z
Velocity loop time constant (s) Closed loop damping ratio Angular velocity of DC Motor shaft (rad/s) Angular position of DC Motor shaft (rad) Closed loop natural frequency (rad/s) Axis reference position (BLU) Continuous-time lead/lag filter parameter Continuous-time lead/lag filter parameter Base Length Unit: smallest resolvable position change in a CNC system Digital Filter Laplace domain transfer function Digital Filter Z-transform domain transfer function Position error in the Laplace domain (BLU) Position error in the Z-transform domain (BLU) Zeroth-order hold DC Motor armature current (A) Effective polar moment of inertia reflected to the motor shaft (Kg*m2) Servo Amplifier voltage/current gain (A/V) Digital to Analog (D/A) converter gain (V/BLU) Encoder feedback gain (BLU/rad) Lead/lag filter gain DC Motor torque constant (N*m/A) Tachometer feedback gain (V/(rad/s)) Digital Filter output signal in the Laplace domain (BLU) Digital Filter ouput signal in the Z-transform domain (BLU) Laplace Transform variable Servo Amplifier reference voltage (V) Z-Transform variable
these benefits, the resulting advantages are often diminished by a failure to meet the second. This is particularly true when the purpose of the controller includes the optimisation, in real time, of the machining cost. The technique for doing this is known as Adaptive Constraint Optimisation, and requires the ability to integrate novel hardware and software for the simultaneous monitoring of and reaction to multiple potentially active constraints [3,8,19,20]. 2. Integration of process and motion in an open controller One control architecture that is particularly well-suited to the integration of multiple constraintbased process control with CNC motion control is the UBC Open Architecture Control System
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
797
[3,18,19,20]. Shown schematically in Fig. 1, the reference architecture is based on a distributed model involving several processing entities and two communication channels. While several of these entities may actually be present on a single processor (i.e. boundaries in the reference model are logical rather than physical), the reference architecture provides the basis for the system’s functionality. The primary master (labeled Master 1) in Fig. 1 is the CNC Master, responsible for (among other things) user interface tasks and the generation of first-stage motion increments in a twostage interpolation scheme. The second master processor (labeled Master 2) is optional, and is typically used for CAD/CAPP/CAM activities. One slave servo controller is present for each physical axis on a machine tool. These servo controllers receive the first-stage interpolated increments from the CNC Master over the backplane communication channel, which may be an internal channel (in a single-processor implementation), a backplane (such as STD/STD32), or a network (e.g. Ethernet). The first-stage increments are then broken down into second-stage increments required by the controller at the loop closing frequency using either a linear or parabolic blended algorithm [18]. It can be seen in Fig. 1 that the servo controllers are connected to each other, as well as to any process monitoring boards, via a second communication channel incorporating a Frontplane Bus and Synchronization line. This second channel allows the servo controllers to implement a dynamic interpolation algorithm, which facilitates the adaptive control of machining processes in response to multiple constraints, as well as the integration of novel hardware into the system. The dynamic interpolator operates by examining the value present on the Frontplane Bus before closing the position control loop. The bus is made up of one or more open collector lines, which can be written to simultaneously by all connected processors (the open collector lines have the effect of ANDing the value written by the processors). In the simplest case of a single stateline, the interpolator has two courses of action. If the value present on the stateline is logic high, then the next second-stage increment is added to the position buffer. If the value is logic low, no increment is added but the control loop is closed in the normal fashion. In this way, any servo
Fig. 1. UBC open architecture control system reference model.
798
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
controller or process monitor in the system can adaptively control the system in response to the impending violation of a process constraint (examples include, chip thickness, shank stress, spindle torque and contouring accuracy). A more complex, multi-bit stateline approach has also been implemented [20]. In this approach, the dynamic interpolator probes the Frontplane Bus for a multi-bit integer value. Based on this value, the interpolator can do any of the following: 1. Add a single motion increment to the position error buffer (normal operation). 2. Add no motion increments to the position error buffer (response to an impending constraint violation). 3. Add multiple increments to the position error buffer (response to lower-than expected values of chip thickness, shank stress, etc.) 4. Subtract increments from the position error buffer (reducing the current error or physically reversing the axis). As in the single stateline implementation, the processor that writes the most-limiting value to the frontplane will dictate the rate at which the process proceeds. Clearly, the architecture described allows for the integration of system functionality in a simple, robust manner. The purpose of the work described in the following sections is to enhance the modularity and functionality of the architecture through the introduction of dynamic reconfigurability, while preserving the openness and extensibility of the system.
3. Reconfigurability and its advantages As mentioned in the introductory paragraphs, economies of scale in the production of Open Architecture control system components can be gained through hardware standardisation. In fact, this idea can be generalised into the more powerful concept of hardware independence (also referred to as vendor neutrality). Rather than standardising at the electrical signal (e.g. bus) level, hardware independence typically involves abstraction at the software level. In this approach, hardware device behaviour is encapsulated as a class definition (in object-oriented terms) and presented to the rest of the system as a well-defined neutral interface. By writing an appropriate class definition and incorporating it into the system, any device that satisfies the functional requirements of a given logical device can be used. Through this technique, a control system becomes reconfigurable, i.e. hardware (and software) modules can be replaced in the system without requiring code changes outside the scope of the class definition or affecting the behavioural operation of the system. Reconfiguring a system in this way most often requires a software re-build (i.e. compile, link) so that the alternate class definition(s) can be incorporated in the system. Obviously this requires shutting down the machine tool and re-starting after the software has been modified. The approach can therefore be referred to as static reconfigurability. This type of reconfigurability allows machine tool builders and integrators to assemble working systems by selecting modular components from vendors offering the current best combination of technology and cost. A system can be further enhanced, however, by introducing the concept of dynamic reconfigur-
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
799
ability, which refers to the ability to reconfigure the system at run-time (i.e. without requiring a system shut-down). During the development of control system components, dynamic reconfigurability allows communication and control methods to be tested, evaluated, modified and replaced without going through a re-start. This facilitates extremely rapid debugging and optimisation, leading to a compressed development cycle. In addition, dynamic reconfiguration allows the redistribution of process monitoring tasks as process conditions and requirements change. This is particularly useful in the multiple-constraint-based optimisation of variable machining cost, in which varying processes require different sets of potentially active constraints to be monitored. 4. Design and implementation of an open configuration system and protocol The approach taken to providing the dynamic reconfigurability described in the previous section has been the development of an Open Configuration System and Protocol. The system is implemented in an object-oriented extension of the Forth programming language [21] and is based on the abstraction of system control hardware into a Virtual Machine Tool (VMT). The software structure of the Open Configuration System, as well as its relationship to high-level system software and low level control hardware is shown in Fig. 2.
Fig. 2. Open configuration system software structure.
800
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
As shown, the configuration system presents a VMT interface to high-level software (path planning, user interface, etc.). Calls made to the interface are handled by the VMT objects (axes, PLC, process monitors) using a combination of hardware independent methods and hardware dependent methods. While hardware independent methods are defined within the object class definitions, hardware dependent methods are made up of references into a software entity called the Binding Table. The Binding Table translates these references into the appropriate methods used to interface with the physical hardware. As an example, the most common hardware dependent methods used in the implementation of an axis controller are listed below. 앫 앫 앫 앫 앫 앫 앫 앫 앫 앫 앫
sendFheader: sendFincrement: readFposition: readFvelocity: readFaccel: readFerror: flushFbuffer: reset: halt: enable: setFfilter:
An attempt is made here to follow good software design practices by clearly indicating a method’s functionality through its name. The dynamically reconfigurable nature of the system is derived from the means by which the Binding Table translates references and executes corresponding methods. This is done through the use of a technique known within the Forth programming environment as Vectored Execution. Essentially, the Forth language is made up of a dictionary of words (analogous to functions, procedures or routines in other languages). The environment is interpretive, allowing the programmer/user to add words to the dictionary at any time. Now, the run-time behaviour of a given word can be extracted and represented by a single memory reference called an Execution Token (XT). An XT can be passed between words, stored as a variable, and executed by other words in the system. The Binding Table then acts as a storage space for a series of XT’s that represent the low-level methods required to interact with the physical system devices. When the system is started, the binding table entries are empty as shown in Fig. 3 (this screen dump was generated from a demonstration of the Open Configuration System, implemented in the SwiftForth environment on a PC running Windows 98). The VMT, however, is in place and the interface can be used as the foundation for high-level software. In this way, the CNC system software can be built without any knowledge of the underlying hardware. With the VMT in place, the XT’s corresponding to the hardware dependent methods can be bound to the appropriate references, resulting in a fully configured system as shown in Fig. 4. At this point, while the system is functional and can be used to control the underlying machine tool, the Binding Table remains fully reconfigurable. That is, XT’s stored in the table cells can be modified and/or replaced dynamically.
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Fig. 3.
801
Binding table with virtual machine tool built (no low-level devices bound).
4.1. Tokenised Configuration Stream (TCS) There are several ways in which device method XT’s can be defined and stored in the Binding Table. For example, it can be done by the user through the interpretive interface (useful in rapid development and evaluation of system components). Alternatively, a text file containing the appropriate Forth code can be retrieved from a storage device and interpreted. Most uniquely, a stream of tokenised code can be retrieved from the firmware of the system device itself. This is the method used in the start-up sequence defined by the configuration protocol. This Tokenised Configuration Stream (TCS) approach has its roots in the Open Firmware standard that was developed by Sun Microsystems [22]. (Similar approaches have been applied to run-time firmware debugging [24] and plug-and-play satellite systems [23].) At start-up, the open configuration system probes all available communication channels for compatible devices. When a device is found, a tokenised (i.e. byte-coded) stream is retrieved from the firmware of the device. The tokenisation scheme is an extended version of the Open Firmware standard, and can be directly translated into Forth code. Once this translation has been done, the Forth code is interpreted by the system. When interpreted, the code registers the device
802
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Fig. 4.
Binding table with hardware dependent device methods bound.
in the system, defines the methods required to communicate with the device, and binds these to the appropriate VMT methods through the Binding Table. Effectively then, the ‘device driver’ is stored in the firmware of the device itself. 4.2. Communication Channel Bindings In order to retrieve the TCS from the firmware of a system device, the Open Configuration System must be able to communicate with the device. However, as previously noted, the vendor neutrality of the approach means that the system may have no knowledge about the device present. The solution employed is the use of Communication Channel Bindings, which abstract each communication channel as an object within the system. Very simple methods are provided to utilise the channel, as shown in the Standard Parallel Port example shown in Table 1. These simple methods represent the limited degree to which the device must be compatible with the system in the absolute sense. Once the TCS has been retrieved from a device, the translated code can make use of the available Communication Channel methods to communicate with the device through arbitrarily complex schemes.
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
803
Table 1 Standard parallel port (SPP) methods and stack diagrams Method Name
Token
Stack diagram
Describe: OpenPort: ClosePort: ReadStatus: WriteData: WriteControl: Detect: GetTCS:
n/a 0x601 0x602 0x603 0x604 0x605 n/a n/a
( ( ( ( ( ( ( (
-- ) -- ) -- ) -- n ) n -- ) n -- ) -- flg ) 2– flg )
5. System validation: an FPGA-based servo controller Validation of the Open Configuration System and Protocol has been coupled with the development of a Field Programmable Gate Array (FPGA) based servo controller. FPGAs offer flexibility approaching that of general-purpose processors and the custom application efficiency of Application Specific Integrated Circuits (ASICs). While application development time for an FPGA solution is slightly longer than that for a general-purpose processor due to time spent developing the FPGA configuration, it is dramatically shorter than the ASIC development cycle. The reduction in Nonrecurring Engineering (NRE) costs versus ASICs and the reduction in non-required functionality versus general-purpose processors result in extremely cost effective architectures [26]. The prototype controller has been implemented in a 20 000 gate Xilinx FPGA, with the design shown schematically in Fig. 5. A TCS is embedded in the controller and can be retrieved during
Fig. 5. FPGA based servo controller design.
804
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
start-up. Once the system has been configured, the VMT interface can be used to control the device. The device operates at a loop closing frequency of 4 kHz, and is capable of controlling a single machine tool axis with the dynamic interpolation capabilities defined by the UBC Open Architecture Control System reference architecture. As shown in Fig. 5, the design is comprised of nine interacting logical blocks. Using the Very-large-scale-integrated Hardware Description Language (VHDL), these blocks are designed to be independent state machines operating on a synchronous clock signal. That is, the FPGA architecture allows the various components of the servo controller to be implemented in a true multiprocessing fashion. Through this multiprocessing approach, activities such as second stage interpolation, digital filtering, quadrature decoding and pulse width modulation can be achieved on a single chip with a relatively slow clock speed of 12 MHz. Beyond the single, low-cost FPGA chip, minimal external circuitry is required in the servo control application. An external 32k RAM chip is used to store first stage interpolated increments passed over the backplane channel (a Standard Parallel Port in this case). While interfacing to a digital servo amplifier is a straightforward endeavour, an analog reference signal can also be generated using a simple filter to convert a 0 to 3.3V pulse-width-modulated (PWM) FPGA output signal to a ⫺10 to +10 V continuous reference signal. The prototype controller has been integrated into a laboratory test stand in the Manufacturing Engineering Laboratory at the University of British Columbia to verify its operation and test its performance. The test stand is comprised of a current-controlled brushed DC motor loop (with tachometer and encoder feedback), a servo amplifier, and the combination of a Celeron 333 MHz PC with the VMT interface implemented in SwiftForth and the prototype FPGA controller connected via a Standard Parallel Port. The control loop block diagram is shown in Fig. 6, while a photograph of the test stand is shown in Fig. 7. Using the technique put forward by Seethaler and Yellowley [25], the behaviour of this Type 1 system can be specified as a simple quadratic through the use of a lead-lag filter defined by the continuous time transfer function s+a D(s)⫽Kp· . s+b This allows the velocity loop dynamics to be cancelled by setting the lead parameter equal to the inverse of the velocity loop time constant, i.e. 1 KA·KT·Ktach . a⫽ ⫽ t Je
Fig. 6. Velocity controlled servo loop block diagram.
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
805
Fig. 7. Laboratory test stand photograph.
The damping ratio and natural frequency of the resulting second order system can then be specified by setting b⫽z and K p⫽
wn2·t . KDA·Kenc
A +5V step input was used as an input signal to determine the test stand velocity loop time constant. The value of the time constant was determined to be approximately 10 ms. Using the technique mentioned above, the lead lag parameters were adjusted to yield a damping ratio of 0.707 and a natural frequency of 25 Hz for the overall position control loop. The VMT interface was then used to generate a 4000 BLU per second ramp input for the servo controller to track. The results are shown in Fig. 8. As shown, the servo controller was able to track the ramp closely, with the following error settling to a steady-state value of approximately 7 BLU (as can be expected for a Type 1 system). 6. Conclusions It has been recognised that the ability to reconfigure an Open Architecture machine tool control system for a variety of hardware platforms provides significant advantages, particularly in the cost effectiveness of the control (this is driven by the property of vendor neutrality). The ability
806
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
Fig. 8. Position loop ramp response.
to dynamically reconfigure the system provides further significant advantage. This includes the ability to re-distribute monitoring tasks based on process conditions, as well as a reduction in development cycle time resulting from “on-the-fly” development and testing. In accordance with these concepts, an Open Configuration System and Protocol has been developed that allows the dynamic reconfiguration of controllers implemented according to the UBC Open Architecture Control System Reference Model. The system improves the vendor neutrality of the system by implementing an object-oriented virtual machine tool that abstracts the behaviour of the control components of the system. Low-level device specific routines are called through a reconfigurable software switch known as a Binding Table, which facilitates dynamic reconfiguration of the system. By storing device specific code in the firmware of the devices themselves (in a tokenised form), hardware devices are able to instantiate themselves in the system, define the methods required to interface with them, and bind these methods into the binding table. A novel FPGA based servo controller has been developed to demonstrate the feasibility of the Open Configuration System approach. The controller is designed to control a single machine tool (or robotic) axis, in accordance with the UBC Open Architecture reference model. The design can be synthesized to fit in a 20 000 gate FPGA, and has been implemented on a prototyping board incorporating a Xilinx FPGA, external RAM chip and minimal analog circuitry. The controller has
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
807
been integrated into a laboratory test stand, and tested for correct operation as well as conformance with the Open Configuration System and Protocol.
Acknowledgements The authors gratefully acknowledge the support of the Natural Science and Engineering Research Council of Canada (NSERC).
References [1] R.W. Teltz, M.A. Elbestawi, Design basis and implementation of an open architecture machine tool controller, Transactions of NAMRI/SME XXV (1997) 229–304. [2] Y. Altintas, W.K. Munasinghe, A hierarchical open-architecture CNC system for machine tools, Annals of the CIRP 43 (1) (1994) 349–354. [3] R. Ardekani, I. Yellowley, The control of multiple constraints within an open architecture machine tool controller, Transactions of the ASME Journal of Manufacturing Science and Engineering 118 (1996) 388–393. [4] C.P. Bailo, C.J. Yen, Open Modular Architecture Controls at GM Powertrain: Technology and Implementation, Proceedings of SPIE 2912 (1991) 52–63. [5] N.A. Erol, Y. Altintas, M. Ito, Modular tools for motion control and process control system design, Proceedings of SPIE 2912 (1996) 13–23. [6] GM Powertrain Group (GMPTG), Open, Modular Architecture Controls at GM Powertrain: Technology and Implementation, Version 1.0, GM Powertrain Group Manufacturing Engineering Controls Council (1996). [7] Y. Koren, C.C. Lo, Advanced controllers for feed drives, Annals of the CIRP 41 (2) (1992) 689–698. [8] TH. Lundholm, A flexible real-time adaptive control system for turning, Annals of the CIRP 40 (1) (1991) 441–444. [9] P. Lutz, W. Sperling, OSACA – the vendor neutral control architecture, in: Proceedings of the European Conference on Integration in Manufacturing, Dresden, Germany (1997) 10pp. [10] G. Pritschow, C.H. Daniel, G. Junghans, W. Sperling, Open system controllers – a challenge for the future of the machine tool industry, Annals of the CIRP 42 (1) (1993) 449–452. [11] F. Proctor, W. Shackleford, C. Yang, Simulation and implementation of an open architecture controller, Proceedings of SPIE 2596 (1995) 196–204. [12] C. Sawada, O. Akira, Open Control Architecture OSEC-II: Architecture overview and prototype systems, in: IEEE Symposium on Emerging Technologies and Factory Automation, ETFA ’97, Los Angeles (1997) 543-550. [13] S. Schofield, P. Wright, Open architecture controllers for machine tools, part 1: Design principles, ASME Journal of Manufacturing Science and Engineering 120 (1998) 417–424. [14] W. Sperling, P. Lutz, Designing applications for an OSACA control, in: Proceedings of the ASME International Mechanical Engineering Congress and Exposition, Dallas (1997) 5 pp, ASME, New York, NY. [15] E.D. Tung, M. Tomizuka, Feedforward tracking controller design based on the identification of low frequency dynamics, Transactions of the ASME Journal of Dynamic Systems, Measurement and Control 115 (1993) 348–356. [16] G. Weinert, Java based open architecture controller, in: Proceedings of the 7th International Symposia on Manufacturing with Applications (ISOMA), World Automation Congress 2000, Wailea (2000) 6pp, TSI Press, Albequerque, New Mexico. [17] P. Wright, Principles of open-architecture manufacturing, Journal of Manufacturing Systems 14 (3) (1995) 187–202. [18] I. Yellowley, P. Pottier, A note on a simple method for the improvement of interpolation accuracy in a general purpose, multiprocessor based motion controller, International Journal of Machine Tools & Manufacture 29 (2) (1989) 287–292.
808
K.D. Oldknow, I. Yellowley / International Journal of Machine Tools & Manufacture 41 (2001) 795–808
[19] I. Yellowley, P.R. Pottier, The integration of process and geometry within an open architecture machine tool controller, International Journal of Machine Tools & Manufacture 34 (2) (1994) 277–293. [20] I. Yellowley, R. Ardekani, L. Yang, R. Seethaler, Development of robust extensible architectures for machine tool control, Proceedings of SPIE 2912 (1996) 72–81. [21] A. McKewan, Object-Oriented programming in ANS Forth, Forth Dimensions March/April Edition (1997) 14–29. [22] W.M. Bradley, D.M. Kahn, J. Rible, M. Williams, IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices – IEEE Std. 1275-1994, Institute of Electrical and Electronics Engineers, New York, 1994. [23] R. Caffrey, H. Shaw, L. Wagner, Developing plug-and-play spacecraft systems: NASA Goddard Space Flight Center’s (GSFC) Essential Services Node (ESN), AIAA-IEEE Digital Avionics Systems Conference Proceedings 1 (1997) 2. [24] B. Eckert, Firmware Factory User’s Manual, http://www.geocities.com/SiliconValley/ Cable/3439, 1999. [25] R. Seethaler, I. Yellowley, The regulation of position error in contouring systems, International Journal of Machine Tools & Manufacture 36 (6) (1996) 713–728. [26] A.K. Sharma, Programmable Logic Handbook – PLDs, CPLDs & FPGAs, McGraw-Hill, New York, NY, 1998.