UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A dynamically reconfigurable system architecture and FPGA based servo controller for distributed machine… Oldknow, Kevin David 2000

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2000-0513.pdf [ 8.47MB ]
Metadata
JSON: 831-1.0080972.json
JSON-LD: 831-1.0080972-ld.json
RDF/XML (Pretty): 831-1.0080972-rdf.xml
RDF/JSON: 831-1.0080972-rdf.json
Turtle: 831-1.0080972-turtle.txt
N-Triples: 831-1.0080972-rdf-ntriples.txt
Original Record: 831-1.0080972-source.json
Full Text
831-1.0080972-fulltext.txt
Citation
831-1.0080972.ris

Full Text

A DYNAMICALLY RECONFIGURABLE SYSTEM ARCHITECTURE AND FPGA BASED SERVO CONTROLLER FOR DISTRIBUTED MACHINE TOOL CONTROL by KEVIN DAVID OLDKNOW B.A.Sc. (Eng. Phys.), The University of British Columbia, 1996 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES DEPARTMENT OF MECHANICAL ENGINEERING We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA August, 2000 © Kevin David Oldknow, 2000 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of Mechanical Engineering The University of British Columbia Vancouver, Canada Abstract This thesis presents the design and analysis of a novel system and protocol for the automatic configuration and dynamic reconfiguration of distributed machine tool control systems. The basis for the system is the UBC Open Architecture Control System reference model. A virtual machine abstraction of the underlying machine tool controller is implemented in an object-oriented extension to the A N S Forth programming language, and used to facilitate hardware independence. A reconfigurable binding table translates virtual machine method calls into appropriate hardware dependent routines. These hardware dependent routines are established in the system via the interpretive translation of a stream of tokenized code, retrieved from device firmware. The tokenizing scheme used is based on the IEEE 1275 Open Firmware standard. A Field-Programmable Gate Array based servo controller, designed to be compatible with the Open Configuration System, is also presented. The servo controller is implemented on a prototyping board incorporating a 20,000 gate Xilinx F P G A and 32 kiloByte RAM chip, with the addition of a filter to convert a pulse-width modulated signal to an analog amplifier reference signal. The controller is capable of driving a single machine tool (or robotic) axis, and has been integrated into a laboratory test-stand comprising a current-controlled DC motor loop and incremental quadrature position feedback. ii Table of Contents Abstract ii Table of Contents iii List of Tables vi List of Figures vii List of Symbols ix Acknowledgements xii 1 Introduction 1 1.1 Manufac tur ing F u n d a m e n t a l s and the N e e d for O p e n Arch i tec tures 2 1.1.1 The Metal Removal Process 2 1 7 . 2 Machining Cost 4 1.2 T h e s i s Object ive 13 1.3 T h e s i s Out l ine 13 2 Open Architecture Control Systems and Technologies 15 2.1 Introduction 15 2.2 O p e n Arch i tec ture Cont ro ls in the M a c h i n e Too l Sec to r 15 2.2.1 MOSAIC (UC Berkeley) 76 2.2.2 HOAM-CNC/ORTS (University of British Columbia) 78 2.2.3 Machining Systems Laboratory (MSL) at McMaster University 20 2.2.4 IMT/KTH Adaptive Controller (IMT/KTH Stockholm) 27 2.2 .5 Tomizuka Research Group (UC Berkeley) 23 2.2.6 Koren Research Group (University of Michigan) 2 3 2.2 .7 OSACA 24 2.2.8 OMAC 26 iii 2.2.9 OSEC 27 2.2.10 UBC Open Architecture Control System 28 2.3 Ob jec t -Or ien ted Sof tware S y s t e m s and the F O R T H P rog ramming L a n g u a g e 35 2.3.1 Object Orientation 3 5 2.3.2 Advantages in Distributed Real- Time Embedded Systems 41 2.3.3 Object-Oriented Forth Extensions 43 2.3.4 The McKewan Object-oriented Forth Extension 44 2.4 O p e n Arch i tec ture F i rmware S y s t e m s 48 2.5 F ie ld P r o g r a m m a b l e G a t e Ar ray Hardware Arch i tec tures 51 2.6 S u m m a r y 54 3 Novel Open Configuration Architecture and Protocol 56 3.1 Introduction 5 6 3.2 O p e n Conf igurat ion Ove rv i ew 57 3.3 Vi r tual M a c h i n e Represen ta t ion of a M a c h i n e Too l A x i s 60 3.4 T h e B ind ing T a b l e 63 3.5 T o k e n i z e d Conf igurat ion S t r e a m 67 3.6 C o m m u n i c a t i o n C h a n n e l B ind ings 70 3.7 S u m m a r y 72 4 Field-Programmable Gate Array (FPGA) Based Servo Controller 74 4.1 Introduction 74 4.2 X E S S Prototyp ing Boa rd 74 4 .3 Cont ro l le r Des ign Ove rv iew 75 4.3.1 Pulse Generator 7 9 4.3.2 Backplane (Parallel Port) Interface 83 4.3.3 RAM Access Arbitrator S3 4.3.4 2nd Stage Interpolator 89 4.3.5 Axis Controller Core 91 4.3.6 Digital Lead/Lag Filter 93 iv 4.3.7 Amplifier Reference Output 99 4.3.8 Quadrature Decoder. 702 4.3.9 Frontplane Interface 703 4.4 T e s t S tand Integration and Tes t ing 104 4 .5 S u m m a r y 109 5 Conclusions and Recommendations for Future Work 111 5.1 C o n c l u s i o n s 111 5.2 R e c o m m e n d a t i o n s for Future W o r k 112 References 114 Appendix I: Detailed Description of Low Level Device Methods in VM Axis Controller Model 120 Appendix II: Detailed Descriptions of Binding Table Methods 129 Appendix III: Detailed Descriptions of SPP Channel Binding Methods 132 Appendix IV: Tokenized Code Example 136 v List of Tables Tab le 2 .3 -1 . C l a s s structure in the M c K e w a n object-or iented Forth ex tens ion ( M c K e w a n 1997) 46 Tab le 3 .3-1 . L o w level dev i ce methods in the V M ax is control ler mode l 63 Tab le 3 .4-1 . B ind ing T a b l e me thods and s tack d iag rams 67 Tab le 3 .5-1 . T o k e n i z e d Conf igurat ion S t r e a m structure (as stored in dev ice f i rmware) 68 T a b l e 3 .6 -1 . S tanda rd Para l le l Por t ( S P P ) M e t h o d s 72 Tab le 4 .3 -1 . P C Para l le l Port S igna l Mapp ing 84 Tab le 4 .3-2 . By te-w ide write-only register m a p 85 Tab le 4 .3 -3 . P C _ s t a t u s _ n y b b l e va lues 87 Tab le 4 .3-4 . Current -cont ro l led se rvo loop parameters 94 Tab le 4 .3 -5 . S a m p l e filter parameter approx imat ion te rms 98 Tab le 4 .4 -1 . Descr ip t ion of se rvo test s tand c o m p o n e n t s 106 vi List of Figures Figure 1.1-1. D iag ram of the Turn ing P r o c e s s , show ing depth of cut (a), feed per revolut ion (S) and app roach ang le (v|/) 3 F igure 1.1-2. D iag ram of the end mill ing p rocess , show ing depth of cut (a), width of cut (d), feed per revolut ion (S), swep t ang le of cut (<t>s), tool length (L) and tool radius (R) 4 F igure 2 .2 -1 . U B C O p e n Archi tecture Cont ro l le r B lock D iag ram 29 F igure 2 .3 -1 . S c h e m a t i c representat ion of a procedura l appl icat ion 38 F igure 2 .3-2 . S c h e m a t i c representat ion of an object-or iented appl icat ion 39 F igure 2 .3-3 . S a m p l e c l a s s h ierarchy 40 F igure 2.3-4. Forth p rogramming language s y s t e m mode l 44 F igure 3 .2 -1 . S c h e m a t i c representat ion of O p e n Conf igurat ion S y s t e m c o m p o n e n t s 58 F igure 3 .3 -1 . U B C O p e n Archi tecture A x i s Contro l ler Behav ioura l M o d e l 62 F igure 3 .4-1 . C o n c e p t u a l representat ion of a B ind ing Tab le in the O p e n Conf igura t ion S y s t e m 64 F igure 3.4-2. L inked- l is t implementat ion of the Bind ing Tab le 65 F igure 4 .2 -1 . Pro to type F P G A B a s e d A x i s Contro l ler (Photograph) 75 F igure 4 .3 -1 . F P G A B a s e d A x i s Contro l ler B lock D iag ram 76 F igure 4 .3 -2 . P u l s e Gene ra to r top- level s c h e m a t i c 80 F igure 4 .3 -3 . P u l s e Gene ra to r register t ransfer level schema t i c 81 F igure 4.3-4. B a c k p l a n e Interface top- level schema t i c d iag ram 84 F igure 4 .3 -5 . R A M Arbitrator top- level schemat i c . 89 F igure 4 .3-6 . S e c o n d - S t a g e Interpolator top- level schema t i c 91 F igure 4 .3-7 . A x i s Cont ro l le r C o r e top- level schema t i c 92 F igure 4 .3 -8 . Current -contro l led se rvo loop b lock d iagram 93 F igure 4 .3 -9 . Current -cont ro l led se rvo loop reduced block d iagram 95 F igure 4 .3 -10 . L e a d / L a g Fil ter top- level s c h e m a t i c 99 F igure 4 .3 -11 . P W M Output top- level s c h e m a t i c 100 vii Figure 4 .3 -12 . P W M to A n a l o g Conver te r circuit d iag ram 100 F igure 4 .3 -13 . Quadra tu re D e c o d e r top- level s c h e m a t i c 102 F igure 4 .3 -14 . F ron tp lane Interface top- level schema t i c 103 F igure 4 .4 -1 . S e r v o test s tand block d iagram 104 F igure 4 .4 -2 . Pho tog raph of se rvo test s tand 105 F igure 4 .4 -3 . Ve loc i t y loop tachomete r s igna l (measu red and theoret ica l , with t ime cons tan t = 10 ms) . 107 F igure 4.4-4. A x i s r e s p o n s e to a 4 0 0 0 B L U / s e c o n d ramp input 108 viii List of Symbols v|/ A p p r o a c h ang le (deg) v F e e d veloci ty (mm/min) a Tay lo r tool life equat ion exponent , Incremental ang le in c i rcu lar interpolat ion (deg) (3 Tay lo r tool life equat ion exponen t o - m a x M a x i m u m s t ress appl ied to tool s h a n k (N/m 2 ) x Ve loc i t y loop t ime constant (s) ^ C l o s e d loop damp ing ratio Q(s) A n g u l a r veloci ty of D C Motor shaft ( rad/sec) 9(s) A n g u l a r posi t ion of D C Motor shaft (rad) con C l o s e d loop natural f requency ( rad/sec) 0 R (s ) A x i s re ference posit ion ( B L U ) < p s S w e p t ang le of cut in mil l ing (deg) a Depth of cut in turning and mill ing opera t ions (mm), Con t inuous- t ime lead/ lag filter pa ramete r A Discrete- t ime lead/ lag filter parameter b Cont inuous- t ime lead/ lag filter parameter B Discre te- t ime lead/ lag filter parameter B L U B a s e Length Unit: sma l les t reso lvab le posit ion c h a n g e in a C N C s y s t e m C i Tay lo r tool life equat ion constant C f P W M to ana log conver ter circuit capac i to r va lue. (nF) C , Too l cos t ($) C v Va r iab le mach in ing cos t per unit length ($/m) d Wid th of cut in mill ing (mm) D(z) Digital Fi l ter Z- t ransform doma in t ransfer function ix e(k) Pos i t ion error in the k t ime interval ( B L U ) E(s) Pos i t ion error in the L a p l a c e (cont inuous t ime) doma in ( B L U ) E(z) Pos i t ion error in the Z- t ransform (samp led time) doma in ( B L U ) f0Sc F P G A osci l la tor f requency (MHz ) F x App l i ed force in the x-direct ion (N) F y App l i ed force in the y-direct ion (N) G 0 ( s ) Zero th-order hold h e Equ iva len t ch ip th ickness (mm) l m D C Motor armature current (A) J e Ef fect ive polar momen t of inertia ref lected to the motor shaft ( K g * m 2 ) k D iscre te t ime s a m p l e interval, spec i f i c cutting p ressure (N /m 2 ) K A S e r v o Ampl i f ie r vol tage/current gain (AA/) K D A Digital to A n a l o g (D/A) conver ter gain ( V / B L U ) Kenc E n c o d e r feedback gain (BLU/ rad ) K p Lead / l ag filter gain K T D C Motor torque constant (N*m/A) Ktach T a c h o m e t e r f eedback gain (V/(rad/s)) l e E n g a g e d cutt ing edge length (mm) L Too l length (mm) M Bend ing momen t app l ied to tool shank (Nm) N Sp ind le s p e e d ( R P M ) R W o r k p i e c e radius in turning (mm), tool radius in mil l ing (mm), rad ius of c i rcular contour in c i rcular interpolat ion (mm) r Too l nose radius (mm) r(k) Digital filter output in the k t h t ime interval R(s) Digital Fi l ter output s igna l in the L a p l a c e doma in (BLU) R(z) Digital Fi l ter ouput s igna l in the Z- t ransform doma in ( B L U ) R1 P W M to ana log conver ter circuit resistor va lue . (Q) x R 2 P W M to ana log conver ter circuit resistor va lue . (Q) R 3 P W M to ana log conver ter circuit resistor va lue . (Q) R 4 P W M to ana log conver ter circuit resistor va lue . (Q) R 5 P W M to ana log conver ter circuit resistor va lue . (Q) R 6 P W M to ana log conver ter circuit resistor va lue . (Q) Rf P W M to ana log conver ter circuit resistor va lue . (Q) S F e e d per revolut ion (mm) s L a p l a c e T rans fo rm var iable T Too l life (min), To rque (Nm) T c Corner -po in t ca lcu la t ion f requency in c i rcular interpolat ion (kHz) t s Too l rep lacement t ime (min) T s D isc re te t ime samp l ing interval (ms) U(s) S e r v o Ampl i f ier re ference vol tage (V) V Per iphera l cutt ing veloci ty (m/sec) V Intermediate P W M to ana log conver ter circuit vo l tage (V) V a n a i 0 g A n a l o g re ference vol tage (V) V p w m Pu lse-w id th modula ted re ference vo l tage (V) V t Tangent ia l veloci ty in c i rcu lar interpolat ion (mm/sec) Vtheoreticai Theore t ica l tachometer f eedback s igna l in veloci ty loop (V) x M a c h i n e cos t rate ($/min) X , Y , Z Ca r tes i an Co-o rd ina tes z Z -T rans fo rm var iable xi Acknowledgements I would like to express my sincere gratitude to Dr. Ian Yellowley, whose unwavering support, valued advice and guidance were instrumental in the completion of this work. I would also like to thank my family, my good friends, and especially Angela for their encouragement and patience in all of my endeavours. This work is dedicated to my mother, Maureen, who has always encouraged me to follow my heart, and to my father, Dennis, who has inspired me to challenge myself. xii 1 Introduction The machine-tool industry stands at the heart of the nation's manufacturing infrastructure, and it is far more important than its relatively small size might suggest. All industries depend on machine tools to cut and shape parts. The entire industrial economy suffers if a nation's machine tools are too slow, cannot hold tight tolerances, break down often, or cost too much. (Dertouzos, Lester and Solow 1989) The above quote underscores and explains the importance of the machine tool industry to a nation's economic success. Over the last few decades, the manufactured goods industry has shifted from a manufacturer-driven marketplace to a consumer-driven one. The resulting trends toward decreasing lot sizes, increasingly flexible processes, highly demanding tolerances, increasing levels of throughput and decreasing profit margins have placed increasingly stringent demands on machine tools used in production settings. It has become generally accepted among both private industry and manufacturing researchers that traditional "closed" C N C 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. As a result, several academic and industrial research projects have been chartered to develop the "open architecture" control systems that will provide the advantages required by the manufacturing industry. It is the ongoing development of such controllers that this thesis is concerned with. 1 1.1 Manufacturing Fundamentals and the Need for Open Architectures The following paragraphs provide a brief review of manufacturing (specifically metal removal) processes, followed by a discussion of the factors affecting the cost of production in machining processes and the role that open architecture controllers can play in optimising this cost. 1.1.1 The Metal Removal Process Many different processes exist for the removal of metal from stock to produce finished (or intermediate) parts. These range from general purpose processes such as turning, milling and grinding to special-purpose processes such as gear hobbing and relatively modern processes such as electrostatic discharge machining. Figure 1.1-1 shows the geometry of a typical turning operation. This type of operation is used to produce axi-symmetric parts such as shafts. In a turning operation, the stock material is secured to a rotating spindle. The turning tool is mounted on a rigid tool post with two degrees of freedom, or axes. The first axis (most often referred to as the x-axis) controls motion of the tool in a direction perpendicular to the spindle axis, engaging the tool in the work piece and controlling the depth of cut. The second axis (z-axis) controls motion of the tool in a direction parallel to the spindle axis, controlling the feed per revolution. 2 X 4 z z Workpiece a 2T V Spindle Rotation Tool Insert S Figure 1.1-1. Diagram of the Turning Process, showing depth of cut (a), feed per revolution (S) and approach angle (vj/). Figure 1.1-2 depicts the geometry of the milling process. This process is somewhat more complex than the turning process, due the increased number of axes and the intermittent nature of tool-material contact. In milling, the workpiece is secured to a table or bed, while the tool rotates around the spindle axis. The tool then is engaged in the workpiece via motion in one or more axes. The surface to which the stock is fixed may move to provide one or more of the directions of motion, or it may remain stationary with all motion generated at the tool. 3 Figure 1.1-2. Diagram of the end milling process, showing depth of cut (a), width of cut (d), feed per revolution (S), swept angle of cut ((j)s), tool length (L) and tool radius (R). 1.1.2 Machining Cost In order to minimize overall production cost, it is necessary to realize that the cost of manufacturing is influenced at all levels of the process from conceptual design through final production. Looking at the processes described above, the level at which the machine tool control system has the opportunity to most impact this overall cost is in the real-time optimization of the machining (i.e. metal removal cost). The machining cost in these operations is affected by several factors, including: 4 X Machine cost rate ($/min) N Spindle speed (rev/min) S Feed per revolution (mm/rev) V Feed velocity (mm/min) V Peripheral cutting velocity (m/sec) T Tool life (min) ts Tool replacement time (min) ct Tool cost ($). The machine cost rate, x for a given machine tool is dependent on factors such as the purchase and financing costs for the machine, as well as operating costs and rate of depreciation. The cost rate is an aggregate measure of all pertinent costs, expressed in a time-value form ($/min). In turning operations, the spindle speed, N, represents the angular velocity (RPM or rev/min) at which the workpiece is rotated around the spindle axis as shown in Figure 1.1-1. In milling, the spindle speed refers to the rate at which the tool rotates around the spindle axis (shown in Figure 1.1-2). The feed per revolution, S (mm/rev) represents the distance by which the tool is further engaged in the workpiece with each successive complete revolution of the spindle. The direction of S is shown in Figure 1.1-1 for turning and Figure 1.1-2 for milling. The spindle speed and feed per revolution can be multiplied together to give the feed velocity, v (mm/min). The feed velocity represents the time-rate at which the tool is engaging in the work piece. 5 The peripheral velocity, V (m/sec), refers to the relative velocity between the surfaces of the cutting tool and workpiece in the direction of cutting. For example, in a turning operation the peripheral velocity can be approximately obtained by multiplying the spindle speed, N, by the radius of the workpiece. This assumes that the calculated value greatly exceeds that of the feed velocity, which it normally does. Using a similar assumption in milling, the peripheral velocity can be approximately calculated by multiplying the spindle speed, N, by the cutter radius, R. The tool life, T (min), represents the active cutting life of a tool before it must be replaced due to wear, while the replacement time and cost of a replacement tool are represented by ts (min) and Ct ($) respectively. Now, the variable machining cost per unit length, C v ($/m) in both turning and milling operations can be represented by the following equation (Yellowley and Gunn 1989). cv = x-+l-v v x-ts+C, (1.1) Since the machine cost rate, tool replacement time and tool cost are constant values, it can be immediately seen that the variable cost is a function of feed velocity and tool life. Intuitively, it can be seen that increasing the feed velocity will reduce the variable machining cost. However, the relationship is made somewhat more complicated by the fact that tool life depends in turn on peripheral cutting velocity and feed as follows (Yellowley and Gunn 1989). V-Ta-Sp=C (1.2) 6 In this equation a, p and C i are empirically determined constants, where typically 0 < a < p < 1. The value of tool life yielding the optimum value of variable machining cost can be found through a simple optimization. To do this, the feed velocity and tool life terms in equation (1.1) are replaced using the following relations. v = ^ (1.3) R and i -I -I T = Cxa - V " -S a . (1.4) This results in the following expression for variable machining cost at a given feed per revolution: where c 2 - o , ana c 3 - ( i i-Differentiating this equation for C v by the peripheral cutting velocity, V and setting the result equal to zero yields the following result. c2 ri-i) (1.6) 7 Straightforward algebraic manipulation yields the optimum value of tool life, given by: T = r}__Nc.+x-t ^ [a , (1.7) Substitution of this value into the original equation (1.1) reveals that, under optimal conditions, the variable machining cost is inversely proportional to the feed velocity as follows: Heuristically then, the approach that should be followed in selecting parameters for machining is to select the maximum possible value of feed velocity, and then set the spindle speed to yield the tool life given in equation (1.7). The constraint that dictates the maximum allowable feed velocity may well change through the course of a single machining operation, with typical constraints being: • Tool edge breakage • Tool shank breakage • Available torque • Contouring accuracy. Tool edge breakage is dependent on the cutting stress placed on the tool edge, and governed by a parameter known as the chip thickness. In the theoretical case of a turning operation using a single-point cutting tool with zero nose radius 8 (i.e. a sharp corner at the tool nose), the chip thickness is a constant value along the engaged tool edge, and simply equal to the feed per revolution, S. In practical turning and milling situations, the chip thickness is a varying parameter. Finite nose radii in turning operations result in a varying chip thickness along the edge of the tool. In milling, tool rotation results in a chip thickness that varies with time. In both cases, the varying chip thickness can be represented by a parameter known as the equivalent chip thickness, h e (Yellowley and Gunn 1989). For example, the equivalent chip thickness in a turning operation using a tool with a finite nose radius, r is given by: K = ~ , (1.9) Where the engaged cutting edge length, le is: . a - r ( l - s h w ) h = " — + r cosy TC \2 j ^ S + — (1.10) In milling, the equivalent chip thickness is given by: K=— Sin(r0 nt 2 h.=-i <t>s>n- 0-11) nt 2 where nt is the number of cutter teeth. If the equivalent chip thickness in the cutting operation exceeds the maximum allowable value, chip thickness becomes the active constraint and the feed velocity must be reduced to avoid tool edge breakage. 9 Tool shank breakage occurs in end milling operations when the resultant stress in the tool shank exceeds the critical value for the tool shank material. Stress in the tool shank is developed as a result of both transverse and torsional loading during cutting, and can be derived by modelling the end mill as a cantilevered shaft, as given in the following equation (Fisher 1988). 2 max n 3 71 • K M + (M2 +r 2 )2 (1.12) Where M = Bending moment applied to shank (Nm) T = Torque applied to shank (Nm) The bending moment applied to the tool shank can be expressed as: M = L — (1.13) Where F x and F y are the forces applied in the x and y directions, as shown in Figure 1.1-2. The torque term, T in equation (1.12) can be written as: k-a-v-R-d T = (1.14) Where = Specific cutting pressure (N/m ). 10 Should the maximum stress in the tool shank exceed the critical value for the shank material, shank breakage becomes the active constraint in the process and the feed velocity must be correspondingly reduced. As a natural result of the balance of forces, the above equation for torque also represents the torque that must be supplied by the spindle motor in the process. If the required torque exceeds the available torque, the spindle motor is in danger of stalling. In this case the torque constraint becomes active and the feed velocity must again be reduced. Contouring accuracy is the final constraint discussed here, and has a direct bearing on machining cost through part accuracy. The level of contouring accuracy achievable must correspond directly to the tolerances required for a given part. Contouring accuracy is dependent on machine dynamics and control techniques used, as well as the complexity of the contour to be followed. In essence, higher-performance systems are able to proceed at higher feed velocities while maintaining the required accuracy. When contouring accuracy becomes the active constraint, the feed velocity must be slowed to the point at which the necessary tolerances can be held. In realistic situations, the a priori process knowledge necessary to determine the value of these constraints during the off-line process planning phase is not known with a great deal of accuracy. It is therefore infeasible to set the feed velocity at its maximum value due to the fact that an overestimation in the allowable feed can lead to disastrous consequences both in terms of economics and human safety. As a result, conservative values of feed velocity and spindle speed must be chosen 11 during the process planning stage. The result, of course, is sub-optimal machining conditions. A more desirable approach, therefore, is to identify the current process state in real-time, determine the limiting constraint and adaptively control the feed velocity at its maximum allowable value. The conventional (G-Code) interface to a C N C machine, however, is based exclusively on the specification of process geometry. Adaptively controlling the process through identification of the process state (i.e. both geometric and technological factors) is not possible through the standard interface. In addition to this, the vendor-specific "closed" architectures of typical C N C machines do not allow for the easy integration of process monitoring hardware that would provide the technological information required in the adaptive control approach. What is needed is a control architecture that provides a mechanism for the easy integration of process monitoring hardware and an interface with the flexibility to use the hardware in the real time optimization of the machining process. These goals are fundamental in the design of open architecture machine tool controllers. The paragraphs above are intended to demonstrate the manner in which an open architecture control system may contribute to the optimization of machining cost. There are indeed many other ways in which these controllers can provide reduced cost and increased flexibility in the manufacturing setting. For example, the standardization of interfaces required in the definition of an open architecture system leads to the property of vendor neutrality. This property allows competing vendors to supply interchangeable components for a wide variety of systems, with the net effect 12 of driving down the cost and increasing the quality of the components (as has been seen in the personal computing industry). Also, a flexible hardware and software architecture that allows the integration of novel hardware can be used to modify a system to handle a completely new process, in addition to improving the cost effectiveness of existing processes. The potential for such improvements in the manufacturing industry provides the motivation for the work presented in this thesis. 1.2 Thesis Objective The objective of this thesis is to design a robust and systematic approach to the dynamic reconfiguration of open control system architectures, with a specific emphasis on the machine tool application. The configuration system and protocol presented are intended to increase the ability of open architecture machine tool controls to meet the requirements presented in the previous section. 1.3 Thesis Outline The remainder of this thesis is organized as follows. Chapter two provides a survey of open architecture research efforts in the machine tool sector, as well as an overview of the technologies relevant to this thesis. Chapter three presents a proposed Open Configuration Architecture and Protocol for the dynamic reconfiguration of distributed machine tool control systems. Chapter four gives a detailed discussion of the design and implementation of a novel Field Programmable Gate Array based servo controller, compatible with the architecture presented in 13 chapter three. The fifth and final chapter draws the work to a close with a series of conclusions and recommendations for future work in this area. 14 2 Open Architecture Control Systems and Technologies 2.1 Introduction Chapter 1 provided a very brief outline of manufacturing (specifically metal removal) processes, demonstrating the need for open architecture controllers in the manufacturing industry. Chapter 2 serves as a review of open architecture research efforts in the machine tool sector, discussing the design goals, enabling technologies and successes to date. Also included in the chapter is a review of the technologies relevant to the work discussed in the remainder of this thesis, including Object-Oriented Software, Open Architecture Firmware and Field-Programmable Gate Array (FPGA) hardware. 2.2 Open Architecture Controls in the Machine Tool Sector As discussed in chapter 1, the open architecture control movement has grown out of the need to move beyond traditional "black-box" controllers in order for manufacturers to achieve optimal processes, and keep up with the pace of change in today's global economy. Use of the term "Open Architecture", originally coined by Sun Microsystems, was adopted by the manufacturing community after seeing the advantages yielded in the general computing industry (Schofield and Wright 1998). 15 The earliest projects in the field that became Open Architecture Controls were sensor-based machining projects such as the Intelligent Machining Workstation (IMW) project undertaken by the U.S. Air Force, Cincinnati Millacron and Carnegie Mellon University in 1986. The IMW project lead to the Next Generation Workstation/Machine Controller (NGC) program, which produced the Specification for an Open System Architecture Standard (SOSAS) in 1993 (Schofield and Wright 1998). Several similar efforts have been made by both academic and industrial research groups, each with differing approaches and priorities for objectives. While some groups have focussed on the creation of broad technical standards, others have emphasized the development of working prototypes. In some research efforts component interchangeability is the dominant priority, while for others it is the integration of process and motion control. The following sections provide a summary of several open architecture research efforts, with the intention of providing insight into the wide variety of goals and approaches that are present among the research groups. 2.2.1 MOSAIC (UC Berkeley) The work of the research group lead by Professor Wright at UC Berkeley is based on the proposition that the benefits of open architecture manufacturing systems can be realized by adhering to the following three principles (Wright 1995): 1. "Object-oriented, high-level languages that are parsable to plans and subsequently to machinery instructions are the necessary requirements 16 for the transfer of knowledge from one level of the factory to the next. This principle includes standardized data structures that must pass unambiguously down through the factory hierarchy." 2. "Common operating systems for each level of the factory facilitate communications, programming efforts, and the protection of standardized data structures." 3. "Open-architecture computer platforms are needed at all levels of the factory, with the key emphasis today being on improvements of factory floor machinery such as machine tools, robots, and other common manufacturing devices." This basis led to the hypothesis that the selection of a de-facto standard programming language, operating system and hardware platform for manufacturing controls would result in the open architecture systems required by manufacturers to reach their constraints of Cost, Flexibility, Delivery and Quality (Wright 1995). These standard components were chosen in the construction of the group's first fully functional MOSAIC controller at New York University in 1988, and preserved in the implementation of the second MOSAIC-PM system at UC Berkeley (Schofield and Wright 1998). The combination of the C programming language, Real Time Unix operating system and V M E bus hardware platform was used in the construction of both systems. The transfer of manufacturing knowledge between subsystems in the MOSAIC-PM approach was demonstrated via integration into the IMADE C A D / C A M system, which incorporates a Destructive Solid Geometry (DSG) feature-based CAD 17 system, and an automated process planning system (Schofield and Wright 1998). Also, integration of sensor technologies into the system was demonstrated via the use of Renishaw touch-trigger probes in fixturing and on-machine inspection algorithms (Wright 1995). While the MOSAIC and MOSAIC-PM systems have been successful in achieving the research goals of the group, the dependence on a specific hardware platform, operating system and programming language can be seen as somewhat of a liability due to the nature of these system elements (particularly hardware platforms and operating systems) to become obsolete at a rapid pace. In addition, the use of the UNIX OS system puts the system at an admitted disadvantage among industrial users, due to their clear preference for the P C platform (Wright 1995). 2.2.2 HOAM-CNC/ORTS (University of British Columbia) The Manufacturing Automation Laboratory at the University of British Columbia, under the leadership of Dr. Altintas, has developed an open control architecture based on the combination of P C and Digital Signal Processing (DSP) technologies. The architecture was introduced as a Hierarchical Open Architecture Multi-Processor C N C (HOAM-CNC) system (Altintas and Munasinghe 1994). The HOAM-CNC system is modular, with an Intel AT486-based System Master co-ordinating the actions of other processing modules over an industrial ISA bus. A Spectrum TMS320C30 DSP-based C N C Master runs a custom-developed micro-kernel that handles the co-ordinated control of multiple machine axes over a secondary bus, with Intel 80c196 based boards interfaced to the servo control loops. 18 Process monitoring and control boards can be integrated into the system, with the System Master handling communications and routing information to the C N C master via the ISA bus. In order to demonstrate the capabilities of the HOAM-CNC architecture, several advanced process monitoring and control applications were implemented. These include adaptive force control, tool breakage detection and chatter detection (Altintas and Munasinghe 1994). Further advancements were later made to the system in the form of the Open Real Time Operating System (ORTS), which is intended to enhance the system's openness, reconfigurability and modularity (Erol, Altintas and Ito, 1996). The O R T S is comprised of an advanced pre-emptive multitasking operating system running on one or more DSPs, and an Open Host software tool running on one or more P C s (with the Windows NT OS). Asynchronous buffered communication links allow tasks on multiple P C s and DSPs to be connected, resulting in a scalable distributed system. The O R T S is configured for a given machine tool or robotics application using a scripting language to set up interpolation parameters, motion control parameters, filtering networks, communication links etc. The scripting language draws on algorithms stored in a system library, which can be extended by the end user. 19 2.2.3 Machining Systems Laboratory (MSL) at McMaster University The Machining Systems Laboratory at McMaster University, under the leadership of Professor Elbestawi, has stressed the importance of hardware independence in open architecture machine tool control systems, and suggested that the benefits to end-users of using open architecture machine tool control systems are derived from i. the economies of scale gained from using standardized hardware, ii. the ability to integrate system functionality in a hardware independent manner (Teltz and Elbestawi 1997). Teltz and Elbestawi pointed out that, while many open architecture control systems realize the first of these benefits, the resulting advantages are diminished by a failure to meet the second. The group has aimed to overcome this perceived failure by striving for hardware independence and system openness via a software structure incorporating the Generalised Device Interface, Virtual Hardware Topology and Peer-to-Peer Message Based concepts found in POSIX operating system applications. In this approach, motion control and I/O functionality is achieved via the implementation of a 'Machine Server' (Teltz and Elbestawi 1997). The Machine Server provides services to other system modules in response to requests made via TCP/IP messages (these modules may reside on a single processor, across a backplane or across a network). The inherent compatibility and flexibility of this approach is compromised by the non-deterministic nature of the TCP/IP protocol. Additional system functionality is then integrated by writing client applications that call on the services of the Machine Server (these services are grouped into machine, program, data, override and system classes). For example, process 20 monitoring and control applications have been written via use of the data reporting and override services. 2.2.4 IMT/KTH Adaptive Controller (IMT/KTH Stockholm) Th. Lundholm at the Department of Production Engineering, Royal Institute of Technology (IMT/KTH) is among a small number of researchers in the field of Open Architecture controls who explicitly focus on the real-time optimization of the machining process via an Adaptive Control Optimization (ACO) strategy. As discussed in the UBC Open Architecture Controller section which follows, the challenge resulting from the A C O approach lies in the fact that, in order to optimize a machining process in real time, the process must be adaptively controlled in response to multiple, potentially active constraints. The IMT/KTH Adaptive Control System for Turning was designed to allow researchers at IMT/KTH to investigate and pursue A C O control of turning operations (Lundholm 1991). The system is a modular, networked system built around the Intel BITBUS specification. An Intel Master Node computer running the RMX I Real-Time Operating System is responsible for the co-ordination and monitoring of five Slave Node subsystems. The subsystems are a mixture of microprocessor, microcontroller and DSP based units that provide the following functionality. • C N C Servo and Spindle Control • Chatter Detection and Avoidance • Force Constraint Avoidance • Collision Detection 21 • Tool Breakage Detection • Tool Wear • Missing Tool Detection • Vision-based Position Control and Flank Wear Measurements The Master Node processor receives messages from the Slave Nodes over the BITBUS network. Catastrophic failures such as collisions and tool breakage detection result in system halt, while tool wear measurement, force constraint and chatter avoidance are used in an adaptive control strategy. The adaptive control strategy is based on suggested feed rate override values, which are sent to the Master Node from the Slave Node subsystems. The Master Node is responsible for examining the suggested feed rate override values received from each slave, constructing a resulting optimal feed rate override, and transmitting this value to the C N C control subsystem. The construction of an optimal override value in the face of conflicting suggestions (e.g. a suggested decrease to avoid a force constraint, coupled with a suggested increase to avoid predicted chatter) is a difficult and reportedly unsolved problem for the research group at IMT/KTH (Lindholm 1991). The IMT/KTH controller is open to the extent that it is modular and reconfigurable. Various subsets of the slave node subsystems can be implemented with relatively little software modification. 22 2.2.5 Tomizuka Research Group (UC Berkeley) Dr. M. Tomizuka and E.D. Tung at UC Berkeley retrofitted a Matsuura machining centre with a custom developed PC-based feed drive controller as part of their work on feedforward tracking control (Tung and Tomizuka 1993). The overall goal of the research was to design "perfect" tracking controllers, which minimize the contouring error (perpendicular error to the desired path resulting from the non-equivalent phase errors of all axes) by eliminating following error at the individual axis level. Probably the most advanced of these controllers is the Zero Phase-Error Tracking Controller (ZPETC), a feedforward controller designed to cancel the plant poles and cancellable zeros (those lying within the Z-plane unit circle and not on the negative real axis), and eliminate the phase error introduced by non-cancellable plant zeroes (Tung and Tomizuka 1993). In this work, an 80386 PC-AT based position controller was combined with the original Y A S N A C Servo Pack Proportional plus Integral (PI) velocity-loop controller to produce an open controller. This P C -based system allowed Professor Tomizuka's group to implement the advanced feedforward control laws necessary for the research. 2.2.6 Koren Research Group (University of Michigan) The manufacturing research group lead by Professor Koren has also placed a strong focus on the minimization of contour error in high-speed machining operations. In contrast with the work of Professor Tomizuka (described in section 2.2.5), the approach at the University of Michigan has been to allow a finite following 23 error on an individual axis level, while attempting to minimize the resultant contour error. This achieved through the use of a so-called Cross-Coupled Control (CCC) algorithm (Koren 1997), (Koren and Lo 1992). The C C C algorithm relies on the construction, in real-time, of the resultant contour error as derived from the individual axis errors. Based on the contour error, a compensating law is used to generate correction signals that are added to the reference outputs for each axis. The correction signals are intended to drive the axes to a uniform phase lag, thus minimizing the resultant contour error. The main issue with the C C C approach is the computation and communication bandwidth required to construct and react to the contour error in real-time when a large number of axes are involved (Koren and Lo 1992). As with Professor Tomizuka's work, the work done by Professor Koren falls in the domain of Open Architecture Control in the sense that the laboratory group has opened-up the interface to their experimental equipment in order to investigate the use of alternative control schemes such as the C C C algorithm. The primary aim has not been to design open systems. 2.2.7 OS AC A The Open System Architecture for Controls within Automation Systems (OSACA) project is a consortium-based effort initiated in Germany, involving control vendors, machine tool manufacturers and research institutes from several European countries. The main goal of the project is stated as: 24 ...the definition of a hardware-independent reference architecture for numerical machine tool equipment including the functionalities of numerical controls (NC), robot controls (RC), programmable logic controls (PLC) and cell controls (CC). ... The O S A C A reference model will form a common base for standard numerical and robot controls up to sophisticated cell controls including e.g. tool- [sic] and workpiece-handling systems. It will be open for the integration of new functionalities and for the use of new computing equipment. (Pritschow et al 1993) As indicated by the statement above, the O S A C A project partitions the functionality of a complete controller into logical modules, and rigorously defines software interface standards and behavioural requirements for the modules. Vendors and users are then free to embed unique knowledge into the system modules, provided that they satisfy the interface and behavioural specifications. Similarly to the work of Elbestawi and others at McMaster University, the O S A C A project is based on a peer-to-peer message-based structure. At the core of the architecture is the System Platform, which provides a set of well-defined services and a message transport mechanism to Architecture Objects within the system (Pritschow et al 1993), (Sperling and Lutz 1997), (Lutz and Sperling 1997). Rather than using an existing standard for the exchange of messages (like TCP/IP), however, the O S A C A group has defined a custom communications protocol based on the Open Systems Interconnect model. 25 The O S A C A System Platform is implemented "on top" of the particular Operating System, with all system modules interacting directly with the System Platform. In this way, dependence on the underlying operating system as well as the underlying hardware is removed. 2.2.8 OMAC The Open, Modular Architecture Controls (OMAC) project, driven to a great extent by the General Motors Powertrain Group (GMPTG), is aimed at reducing the total life-cycle cost of control systems in the automotive manufacturing industry. The intention is to achieve this by encouraging control system component vendors to supply fully interchangeable components, stimulating competition and improving performance in the process (GMPTG 1996), (Bailo and Yen 1996). Although G M P T G has taken a leading role in the O M A C project, it has also taken a purposeful stance that it will not develop or mandate any technical specifications. Rather, the company recommends that control vendors attempt to use de-facto standards for hardware platforms (e.g. the P C platform), operating systems (e.g. Microsoft Windows) and device interfaces (e.g. S E R C O S ) wherever possible and practical (GMPTG 1996). In addition, G P M T G is relying on the efforts of co-operating groups such as the National Institute of Standards and Technology (NIST) (Proctor, Shackleford and Yang 1995), (Michaloski 2000) and Lawrence Livermore National Laboratory (LLNL) (Weinert 2000) to develop a well-defined implementation framework and programming API for O M A C controllers. 26 Several pilot projects in both plant and laboratory settings are being done to validate the O M A C concept (GPMTG 1996). As an example, a 4-axis milling machine at G M P T G has been retrofitted with a NIST Enhanced Machine Controller (EMC) (Proctor, Shackleford and Yang 1995). 2.2.9 OSEC A s with the O S A C A project in Europe, the Open System Environment (OSE) consortium in Japan is chartered with the task of defining an Open System Environment for Controllers (OSEC) Architecture. The consortium first released the OSEC-I architecture in 1995, which was an abstract architecture intended to guide discussion of the merits and direction of open controllers. This was followed by the release of OSEC-II in 1996, which is intended as a practical architecture standard for use in system implementation (Sawada and Akira 1997). The perspective taken by the O S E C consortium is that the value added by the architecture (vs. a traditional closed controller) must be seen from four viewpoints, namely: machines, operators, CAD systems and production networks. Based on this, the Architecture definition is comprised of four types of components. These are: O S E C APIs, machine resource objects, a machining description language (OSEL) and a floor management protocol (OFMP) (Sawada and Akira 1997). The development of a machining description language is relatively unique, as few open architecture efforts deal explicitly with the well-known shortcomings of the traditional EIA Code ("G Code") interface that is common among machine tool controllers. The O S E L language is based on a three-level definition. The highest 27 descriptive level is OSEL-F (Feature OSEL) , which is a machine independent, feature-based language input. OSEL-F is translated into the Intermediate OSEL-I, which is expressed based on tool actions but remains machine independent. The final translation (done at the machine level) is into executable OSEL-X , which provides the machine-specific instructions necessary to manufacture a given part (Sawada and Akira 1997). 2.2.10 UBC Open Architecture Control System The driving force behind the development of the UBC Open Architecture Control System (developed by the Manufacturing Engineering Laboratory research group at the University of British Columbia under the leadership of Professor Yellowley) is the realization of the Adaptive Control Optimization (ACO) approach to the control of metal cutting processes (Yellowley and Adey 1992). The A C O approach attempts to minimize the cost of the machining process in real time, in contrast to the Adaptive Control Constraint (ACC) approach, which attempts to achieve good process conditions by maintaining a single major constraint (force, power, torque, etc). As discussed in (Yellowley and Adey 1992) and (Ardekani and Yellowley 1996), the A C O approach is distinguished from the A C C approach by the need in A C O to acquire accurate estimates of tool-wear rate, identify process parameters such as equivalent chip thickness in real time, and control the process based on multiple constraints. Early work in the area attempted to adaptively control feed rate in response to the identified equivalent chip thickness in turning operations, using 28 the feed rate override interface of a standard C N C (Yellowley and Adey 1992). This approach proved to be limited by the bandwidth of the interface (45 ms update time). In addition, this type of interface offers no standard way to adaptively control the process in response to multiple constraints. As a result of these limitations, a novel Open Architecture Controller was developed with the specific goal of integrating process and motion control (Yellowley and Pottier 1989, Yellowley and Pottier 1994). The control architecture is based on a unique Stateline Architecture reference model, as shown in Figure 2.2-1. X-Axis Slave (e.g. 80c196, 80x86, DSP) Servo Amp Encoder Y-Axis Slave (e.g. 80c196, 80x86, DSP) Z-Axis Slave (e.g. 80c196, 80x86, DSP) Servo Amp Encoder Servo Amp Encoder 3 © PLC Slave (e.g. 80c196, 80x86, DSP) Spindle Amp E-Stop Process Monitor Slave (e.g. 80c196, 80x86, DSP) Force Sensors Figure 2.2-1. UBC Open Architecture Controller Block Diagram As shown, the reference model consists of several processing entities and communications channels. The C N C master is a general-purpose processor with 29 several responsibilities. These include user-interface tasks and the calculation of coarse first-stage increments in a two-stage interpolation scheme (Yellowley and Pottier 1989). The first stage increments are passed over the backplane communications channel to slave axis controllers. The axis slaves perform a second stage interpolation, generating reference position increments at the loop closing frequency of the servo system. This two-stage algorithm greatly reduces the computational load associated with interpolation at the master, allowing the addition of several axes to the system without drastically reducing the computational bandwidth available for user-interface and other tasks. All axis control slaves, as well as PLC and process monitoring modules are interconnected via a frontplane communications channel, which consists of a synchronization line as well as one or more open collector statelines. One of the axis slaves is designated as the real-time co-ordinator, and is responsible for the generation of a timing pulse on the synchronization line at the loop closing frequency. The remaining axis slaves are receivers of the co-ordinating synchronization signal, and begin their interpolation activity on the rising edge of the pulse. The open collector statelines facilitate the implementation of a dynamic interpolation algorithm, in which the increment added to the position error buffer on each axis controller is dependent on the current value of the stateline bus signal. Implementation of the statelines as open collector lines permits simultaneous writing to the bus by all system slaves. That is, on any given stateline, if all system slaves write a logic high value (+5V), the value of the line is high. If any system slave writes 30 a low logic value (OV), the value of the line is low. The open collector line therefore represents an ANDing of the values written by all system slaves. In its simplest form, the stateline bus is a single open collector line. If the value of the line is high at the start of an interpolation interval, the next value generated by the second stage interpolator on each axis controller is added to the position error buffer. If the value of the stateline is low, no increment is added to the error buffer. The position control loop is, however, still closed in the normal fashion. In this way, the effective feed rate can be halved by pulling the stateline low 50% of the time (i.e. a 50% duty cycle). A more advanced version of the stateline bus has also been implemented, in which the bus carries a multi-bit value (Yellowley et al 1996). The value present on the bus can cause the axis controllers to add more than one increment, as well as removing increments from the buffer (in addition to the activities in the single stateline version). By using this multiple stateline algorithm, the feed rate can be increased in response to lower-than-expected force levels, the position error can be instantaneously reduced to zero (by removing error increments), or the axis direction can be physically reversed (allowing a tool to be backed out of a complex trajectory). It is through the stateline bus that adaptive control of the process in response to multiple constraints is possible. For example, a process monitoring slave may be collecting force data from individual machine axes via a dynamometer and identifying process parameters in real time (Yellowley and Adey 1992), (Ardekani and Yellowley 1996), (Seethaler 1997). By interfacing this device to the stateline bus in a straightforward manner, the device can influence the process by writing the 31 appropriate value to the bus in response to an impending constraint violation. It should be noted that integration of the device into the system backplane is not required, and a virtually unlimited number of process conditions can be monitored, with the most serious constraint controlling the process feed rate via the ANDing effect of the open collector statelines. The stateline bus has also been used to limit path error in high-speed contouring operations (Seethaler and Yellowley 1996). In this application, each axis attempts to maintain a constant phase error by writing to the stateline bus whenever an unacceptable deviation from the desired phase error is encountered. In this way, the system axes are driven towards a uniform phase error resulting in a minimized overall contouring path error. The net effect is similar to that of the Cross-Coupled Controller developed by Dr. Koren's group at the University of Michigan (described above), though the computation and communications bandwidth requirements are much less severe in the UBC Open Architecture system due to the use of the stateline approach. The UBC Open Architecture Controller was originally implemented using an 80x86 master communicating with 80c196 axis slaves over an STD 8-bit backplane (Yellowley and Pottier 1994). The system has since been ported to P C and STD32 platforms (Yellowley et al 1996), using a variety of microprocessor, microcontroller and D S P hardware platforms. As described in chapter four of this thesis, the most recent development effort is a P C / F P G A based implementation. In addition to being implemented on several different hardware platforms, the U B C Open Architecture Controller has been implemented in multiple Operating 32 System (OS) environments (Yellowley et al. 1991). Originally, the master level system software was implemented in DOS (32 bit protected mode), which still proves to be a robust and dependable platform. In addition, the software has been implemented successfully in OS/2. The work done in this thesis includes a preliminary implementation of low-level software functionality in a Windows 98 environment. Thus, in contrast with several of the systems and standards described in the previous sections, the UBC Open Architecture Control System is designed to be implemented on a variety of hardware and OS platforms. The remaining component in the specification of an open architecture system, the programming language, is the common thread among all implementations of the system. In all implementations of the UBC Open Architecture Control System, the master level system software is written in the Forth programming language. Forth is an interpretive, stack based, postfix language most often used in embedded controls applications due to its tendency to produce very efficient, compact code in resource constrained environments (Woehr 1992). Despite the prevalence of its use in embedded applications, the language is also suited to high level software development. While the stack based, postfix nature of Forth tends to present a hurdle to the newly initiated programmer (particularly for those trained in more mainstream languages such as C), the effort required to overcome the hurdle is small when compared to the flexibility gained once the power of the interpretive interface is harnessed. In Forth programs, no distinction is made between the application and the programming language. In fact, beyond a core set of native words, the Forth 33 programming language is written in itself. The result is programs that, to the end-user, resemble languages more than 'sealed' applications. As described in detail in the following section, Forth Programs can be extended by the user at any time. This dynamic extensibility allows the user to add knowledge and functionality to the system, derived from their own expertise and experience, in a relatively straightforward manner. To date, the UBC Open Architecture Control System has been implemented in UR/Forth, supplied by Laboratory Microsystems Incorporated (LMI) and based on the Forth-83 standard. UR/Forth is particularly well suited to the application due to its Native Code Compiler (NCC), which selectively translates Forth code into in-line optimized machine code (Laboratory Microsystems, Inc. 1992). The drawback associated with UR/Forth is the fact that Forth-83 is not a rigorous standard, i.e. implementations by different vendors for different operating systems do not necessarily support the same set of words (Woehr 1992). In response to this, a revised standard for the Forth programming language, commonly referred to as A N S Forth has been drafted (Woehr 1992), (Technical Committee X3J14 1994). Compliance with the A N S Forth standard guarantees that a Forth application will be completely (i.e. hardware and OS) platform independent. Since the release of the A N S Forth standard, several commercial A N S Forth environments have been developed and released. One popular example is SwiftForth, developed by FORTH Inc. (FORTH Inc. 1998). In addition, the object-oriented extension described in the following sections and used in this thesis work is 34 A N S Forth compatible. It certainly seems apparent that the future direction in Forth programming will stress A N S Forth compliance. 2.3 Object-Oriented Software Systems and the FORTH Programming Language The degree to which the systems described in the previous sections rely on Object-Oriented software concepts varies considerably. The O S A C A , O S E C and O M A C projects incorporate Object-oriented principles into the lowest level reference model definitions, while the MOSAIC and MOSAIC-PM systems are written completely in the procedural C programming language. It is indisputable, however, that Object-Oriented programming techniques have acquired a secure footing in the domain of software system design and implementation, both in embedded and general computing systems. The paragraphs below give a brief overview of the concepts involved in Object-Oriented design, and the advantages yielded through its use. Following this is a discussion of an Object-Oriented extension to the Forth programming language that is emerging as a de-facto standard within the Forth programming community. This Object-Oriented Forth extension provides the platform for the high-level software component of this thesis work. 2.3.1 Object Orientation Object orientation is essentially a complexity management tool used in the design and implementation of software systems, manifested in the forms of design 35 methodologies and programming languages. Although the origin of object-oriented techniques dates back to the late 1960's, it was not until the mid 1980's that the potential of object orientation as a design methodology in addition to an implementation technique was realized (Awad, Kuusela and Ziegler 1996). Since then, object-oriented system design and implementation has gained increasing momentum. The central concept in Object Orientation is that of Abstraction, as captured in the following statement. Abstraction has ... proved to be invaluable as an aid in solving problems. The general approach is to decompose complex problems into a number of subsidiary areas and then focus on the individual areas. These areas can then be analyzed further until manageable entities have been identified (Blair et al. 1991). While this approach to the solution of complex problems is not unique to object-oriented systems, the mechanisms by which it is employed are. These mechanisms are based on the combined application of modularization and information hiding (often referred to as encapsulation). Modularization refers to the subdivision of a system into modules that contain all of the data structures and algorithms required to implement that part of the system, while information hiding refers to the requirement that a user may only access a module via a well-defined, protected interface (Blair et al. 1991). 36 In object-oriented systems, the type of abstraction described above is achieved via the implementation of objects. An object can be formally defined as: A machine which has a number of defined operational states and a defined means to access and change these states (Cooling 1991). A practical understanding of the approach is likely best gleaned through a comparison to the traditional procedural approach to systems design and programming. Figure 2.3-1 shows the conceptual elements in a procedural application. In this type of system, a collection of data represents the current System State. Separate functions are implemented (often in functional modules), which act on the data to manipulate the system state. Generally, these functions have equal access to the data, and are 'unaware' of manipulations made on the data by other functions in the system. The main application, then, is essentially a series of function calls, whose sequence is controlled by logical branching structures. 37 Main Application function call 1 function call n Data (System State) data function 1 function n Figure 2.3-1. Schematic representation of a procedural application. In contrast, an object-oriented system is shown conceptually in Figure 2.3-2. As shown, the system state data is distributed among several objects in the system. Each object contains both the state data subset, and all methods used to manipulate the subset. Access to the methods and data is achieved only through a controlled interface, via the passing of messages to the object. In this way, the object has explicit control over the means by which the data subset can be manipulated, and full 'awareness' of manipulations that are made. The main application in this type of system is a series of messages rather than function calls. 38 Main Application message 1 message n messages Object 1 Method 1 Method n Data (Object State) Object 1 Method 1 Method n Data (Object State) Figure 2.3-2. Schematic representation of an object-oriented application. While an object-oriented system is thus made up of a set of objects, these objects are normally not coded individually or directly. Rather, they are instantiated from an object class definition. A class is an abstract description of an object, containing definitions for the instance variables (data subset) and methods contained within the object. Multiple objects can then be instantiated from a single class definition, greatly reducing the amount of code and complexity involved in system implementation. A key concept in the definition of classes is that of inheritence. Within an object-oriented system, class definitions are arranged in a hierarchy, with parent and child nodes as shown in Figure 2.3-3. Child nodes, or subclasses, inherit the instance variables and methods of parent nodes, or superclasses. The Graphics Object class in Figure 2.3-3 serves as a superclass to the Polygon and Circle 39 subclasses, i.e. the Polygon and Circle classes will inherit the instance variables and methods of the Graphics Object class. The Polygon class in turn serves as a superclass to the Triangle, Square and Pentagon classes. Class: Graphics Object (Superclass) Instance Variables Methods Class: Polygon (Subclass/Superclass) Instance Variables Methods Class: Circle (Subclass/Superclass) Instance Variables Methods Class: Triangle (Subclass) Instance Variables Methods Class: Square (Subclass) Instance Variables Methods Class: Pentagon (Subclass) Instance Variables Methods Figure 2.3-3. Sample class hierarchy. The use of classes and objects in this abstracted approach to system design is greatly enhanced by the system property of polymorphism (or overloading). This property allows the methods of distinct classes to have identical names. For example, in a procedural system there might be four independent functions called: d r a w _ t r i a n g l e ( x l , y l , x 2 , y 2 , x 3 , y 3 ) , draw_square(xl,yl,x2,y2,x3, y3, x4 , y4), draw_pentagon(Xl,yl,x2,y2,x3,y3,x4,y4,x5,y5) and d r a w _ c i r c l e ( x l , y l , R ) . When calling these functions, the main application would have to be aware of the differences between them and manage the number and type of parameters passed. The property of polymorphism in an object-oriented system allows each of the triangle, square, pentagon and circle classes to have a method called draw ( ) . In this case the differences between the implementation of the draw () method are transparent to the main application, as the relevant parameters are stored internally to the object. Invoking the method for any one of the graphics objects is then achieved by simply sending the message draw () to the appropriate object. 2.3.2 Advantages in Distributed Real-Time Embedded Systems The use of object-oriented techniques in system design and implementation yields several advantages in both the general case, and the specific case of distributed real-time embedded systems (such as the machine tool control systems described in this thesis). As was previously mentioned, object-oriented system design and implementation results in a dramatic reduction in system complexity. This is due to the encapsulation of the overall system into manageable and understandable modules, and the overall reduction in source code by as much as a factor of ten resulting from the mechanisms of instantiation and inheritance (Blair et al 1991). The modularity afforded by object orientation is particularly useful in multi-person implementation projects, in which it is not practical for any single person to understand the implementation details of the entire system. This is particularly true in well-designed systems with high levels of cohesion, i.e. narrow interfaces and low 41 levels of interdependence between modules (Sommerville 1995, ch. 12). In addition, the challenge of maintaining system structure in maintenance projects, as well as the overall efficiency of these projects, is greatly aided by the encapsulation of a properly designed object-oriented system (Sommerville 1995, ch. 32). High cohesion contributes to another popular characteristic of object-oriented systems, that of code transportability. By collecting both the data and methods associated with a system module into a single well-defined structure (a class), system modules can be re-used amongst diverse applications with a minimal level of code modification (Sommerville 1995, ch. 20). While the benefits described above apply to general software system design, there are several characteristics of object-oriented systems that provide particular benefit to the design and implementation of distributed real-time systems. First, real-time systems are frequently embedded systems, i.e. systems that interface with physical real-world entities (such as sensors and actuators). In fact, it is the interaction with physical entities that prescribes the real-time requirements in these systems. It has been shown that such real-world entities tend to map very conveniently into software objects, which aids in the process of system design (Cooling 1991). Second, the phenomena associated with physical entities tend to occur concurrently, in contrast with the sequential nature of computing processes. The object-oriented approach to system design tends to support models of concurrent events more effectively that procedural system approach (Cooling 1991), (Awad Kuusela and Ziegler 1996). 42 Finally, distributed systems are by definition made up of multiple, interconnected computing modules. In various implementations of the same system, a different set of computing modules (i.e. specific hardware) might be employed. By encapsulating each system entity, hardware changes can be made without affecting the rest of the system. This has obvious and important benefits In the specific case of Open Architecture Systems. 2.3.3 Object-Oriented Forth Extensions Since the introduction of object orientation, many object-oriented programming languages have emerged. Examples include the seminal language Smalltalk, Ada, C++ and, more recently, Java. While some languages are designed from the ground up as object-oriented languages, others are implemented as extensions of existing procedural languages (for example, C++ is a superset of the procedural C programming language). In the Forth programming community, several individuals and groups have brought forward object-oriented projects. These have also included both ground-up object-oriented languages such as NEON and M O P S , as well as extensions to existing Forth systems. One survey enumerated 17 object-oriented versions of the Forth programming language (Rodriguez and Poehlman 1996). Differences between the various object-oriented versions of Forth are both syntactical and functional. Some versions, such as that put forward by Pountain (Pountain 1986) are extremely lightweight, but offer only a basic subset of the functionality expected from a modern object-oriented language. Other versions, such as that designed by McKewan (McKewan 1997) offer relatively complete and 43 robust functionality at the expense of increased complexity in the implementation of the extension. The McKewan extension follows the syntax of the NEON/Yerk/Mops languages, which, after several years, has emerged as somewhat of a de-facto standard among object-oriented Forths. This extension provides a basis for much of the work presented in Chapter Three, and is therefore discussed in more detail in the following section. 2.3.4 The McKewan Object-oriented Forth Extension As mentioned above, the McKewan extension is an A N S Forth compliant, object-oriented extension to the Forth programming language. In this section a brief overview of the implementation details and use of the McKewan extension is presented. Before discussing the extension, however, it is useful to review the high-level details of the Forth programming language. FORTH Dictionary Data Stack Return Stack i 2 Code Space Data Space Locate Link Cntrl Bits Name Code Field Parameter Field Figure 2.3-4. Forth programming language system model. 44 As shown in Figure 2.3-4, the Forth language is based on a relatively simple system model. Entities within the model include the dictionary, data and return stacks, and code and data spaces. An interpretive interface manages the system entities, controlling incremental program compilation and execution. The analogue to a function, procedure, subroutine, etc. within the Forth programming language is a word. Word definitions are stored as a linked list in the dictionary as shown in Figure 2.3-4, and executed by the Forth interpreter. At system start-up, a core set of words is provided for the user. This set of words can be extended by the user, through the process of creating new words in the dictionary. This is the means by which Forth programs are implemented, and remain extensible. Variables and constants in the forth language are simply specific types of dictionary words. The data stack is a last-in-first-out (LIFO) buffer, used to pass parameters between Forth words (Woehr 1992). When defining a new Forth word, the programmer must specify the data required on the stack at the time of execution, as well as the data left on the stack once execution is complete. The return stack holds the return addresses that allow nested word calls to be made within the Forth system (Woehr 1992). The stack is used by the interpreter to temporarily store word addresses, allowing execution to proceed once a nested call is complete. Under very specific circumstances, the return stack can also be used to temporarily store data during program execution. Code space, or address space, is the space for which a given Forth language processor provides addresses (Woehr 1992). For example, a newly created variable 45 will be assigned an address within Code space. This address is accessible through the interpretive interface. Data space is the range of addresses whose contents are only accessible in a transportable way by core system words (Woehr 1992). In the McKewan object-oriented Forth extension, classes, objects, instance variables and methods are implemented as words with extended structures in code (address) space. For example, the structure of a class is shown in Table 2.3-1. Table 2.3-1. Class structure in the McKewan object-oriented Forth extension (McKewan 1997). Offset Size Name Description (Cells) (Cells) 0 8 MFA Method dictionary (eight-way hashed list) 8 1 I FA Linked-list of instance variables 9 1 DFA Data length of named instance variables 10 1 X F A Width of indexed instance variables 11 1 S F A Superclass pointer 12 1 T A G Class tag field 13 1 USR User-defined field Syntactically, a class is built as shown in the following listing. The example of a single two-dimensional point is used. The class definition is opened with the : C l a s s declaration, and closed with ; c l a s s . Immediately following the class name, P o i n t , is the inheritance relationship <Super Object, indicating that the 46 class P o i n t inherits from the root class Object. Two instance variables, x and y are declared to store the locations of the point (these instance variables are, in turn, defined by the class definition for Var, which includes the methods G e t : and Put:). Following this are the definitions for methods to retrieve, store and print the point location values (note that the methods Get: and Put: defined in the class P o i n t demonstrate the property of polymorphism). Each method definition is opened with :M and closed with ;M. It should also be noted that all method names (called selectors) must end with a colon as shown. The self-reference feature of the language is shown in the P r i n t : method, in which the Get: method defined within the class is called through the statement Get: s e l f . Finally, the c l a s s i n i t : method gets called automatically whenever an object is created. The method shown here overrides a "do-nothing" default method defined within the O b j e c t class definition. :Class Point <Super Object \ ================================ \ Instance V a r i a b l e D e c l a r a t i o n \ ================================ Var x Var y \ ================================ \ Object Method D e f i n i t i o n s \ ================================ :M Get: ( — x y ) Get: x Get: y ;M :M Put: ( x y — ) 47 Put: y Put: x ;M ;M P r i n t : ( — ) Get: s e l f SWAP ." x = " . ." y = " . ;M :M C l a s s l n i t : ( — ) 1 Put: x 2 Put: y ;M ;Class Once a class definition is complete, multiple instances can be created as objects through statements such as the following. \ ============================================= \ I n s t a n t i a t e object P l , defined by c l a s s Point \ ============================================== Point P l 2.4 Open Architecture Firmware Systems As discussed in the previous section, Object-Oriented Design and, more generally, the analytical process of abstraction allow for the encapsulation of physical hardware devices into abstracted software entities. The rigorous specification of interfaces for the abstracted definitions allows for the replacement of 48 system modules with minimal impact on the rest of the system. However, instantiation of the appropriate modules in a given system requires "awareness" of the physical hardware that is present. The awareness required to assemble the system correctly may come from a human systems integrator, who can assimilate the required hardware information from specifications and use the information to instantiate the proper modules when building the software system. While this human intervention approach is effective, there are clear and significant advantages to a more automated process. The desire to automate this hardware recognition and system building process has led to the deployment of several "Plug-and-Play" initiatives. These initiatives bring forward the need to bridge the gap between hardware and software with an open firmware standard. Probably the most well known standard is Plug and Play or PnP, originally developed by Intel and available on late model Microsoft Operating Systems. PnP is formalized in IEEE 1394. PnP compatible devices contain an ID number at a specific location in device ROM (firmware), which uniquely identifies a given device. During start-up, the PnP compatible Operating System probes the device, and uses the ID number to determine the device make, model and version. Based on this, the OS can either load one of the device drivers it has available, or prompt the user to supply a driver on diskette (Hart 1999). Perhaps somewhat less well known is the Open Firmware standard developed by Sun and used on their workstations, as well as Macintosh Power PC 's (Bradley et al. 1994). Open Firmware compatible devices have a region of Firmware 49 containing FCode, a tokenized version of the Forth programming language. Open Firmware itself is an interpretive environment, running on the Host at start-up. During the boot process, the device FCode is interpreted, resulting in the creation of a device tree, through which the Operating System can drive the underlying device hardware. The use of open architecture firmware standards in the automated configuration of systems has not been limited to the general computing industry. The Essential Services Node project (Caffrey, Shaw and Wagner 1997) represents an attempt to develop plug-and-play satellite systems. Involved in this project are NASA's Goddard Space Flight Centre, and FORTH Inc. The Essential Services Node envelopes the core satellite system functionality, with peripheral devices (such as communications and data collection hardware) registering themselves via a utility modeled on Open Firmware. In the domain of small-scale embedded devices, Brad Eckert has developed Tiny Open Firmware (Eckert 1999). In Tiny Open Firmware compatible devices, an interpreter is embedded in the device firmware, with full access to device functionality and programming. A PC-based tool called Firmware Factory allows the developer to enter the interpreter through a "backdoor", and modify the firmware functionality at run-time. As is the case in both the E S N and Tiny Open Firmware projects, the conceptual design of the Open Firmware standard, as well as many of its technical details and specifications, provide the basis for the Open Configuration System developed in this work and described fully in Chapter 3. There are, however, key 50 differences between the two. Most notably, the FCode embedded in Open Firmware compatible devices provides what is, for the most part, a description of the device present. That is, the host operating system is required to have some knowledge of the means by which the device operates and should be interacted with. In contrast, the Tokenized Configuration Stream described in Chapter 3 fully defines and instantiates the abstracted software methods used to drive a particular device. 2.5 Field Programmable Gate Array Hardware Architectures Having discussed the software and firmware technologies involved in the work presented in this thesis, the final technological topic to outline is hardware. As indicated in the overview of open architecture control systems in the manufacturing domain, the predominant hardware architectures used in real-time controls are based on microprocessors, microcontrollers and DSP's . A relatively new development in the arena of programmable devices is the Field Programmable Gate Array (FPGA). F P G A ' s offer flexibility approaching that of general-purpose processors and the custom application efficiency of Application Specific Integrated Circuits (ASIC's), also called Metallization Programmable Gate Arrays (MPGA's). While application development time for an F P G A solution is slightly longer than that for a general-purpose processor due to time spent developing the F P G A configuration, it is dramatically shorter than the ASIC development cycle. The reduction in Nonrecurring Engineering (NRE) efforts versus ASIC's, and reduction in non-51 required functionality versus general-purpose processors results in extremely cost-effective architectures (Sharma 1998). F P G A ' s can be included in the general category of Field Programmable Logic Devices (FPLD's), which also includes Programmable Logic Devices (PLD's) and Complex Programmable Logic Devices (CPLD's). While all of these devices are used to implement discrete logic solutions in a field programmable manner, the architecture of the F P G A is quite distinct from that of the PLD and the C P L D 1 . The simplest and earliest of these devices, PLDs, are typically designed around a monolithic sum-of-products gate-field architecture. In this type of architecture, input signals are routed first through an array of AND gates, followed by an array of OR gates. By establishing connections via re-settable fuses, combinational boolean (sum-of-products) expressions can be evaluated. The combinational circuits are then registered, allowing the implementation of sequential circuit implementation (e.g. state machines). C P L D s were developed to improve on the capabilities of the PLD architecture by increasing flexibility. In these more recent devices, several sum-of-product logic blocks are placed on the chip, with various interconnect schemes between the blocks allowing a wide variety of possible circuits to be efficiently implemented within the architecture. 1 This refers to traditional PLD and CPLD designs. In order to attain increased performance levels, recent CPLD designs have incorporated hybrid structures resembling FPGAs while retaining the CPLD designation (Sharma 1998). 52 As a further increase in flexibility, F P G A s were introduced. The design and physical implementation of F P G A architectures varies widely between models and vendors, with very little standardization between them. As with CPLDs , multiple logic blocks are implemented and interconnected on an FPGA. However, the resolution, or grain, of these logic blocks can vary from single transistors up to RAM based Look-up Tables (LUTs). For example, the device used to implement the servo controller described in Chapter 4 of this thesis is based on an architecture that combines 4-input and 3-input RAM based LUTs into a hybrid structure. Standardization between F P G A s comes in the form of the programming languages used to design applications for the chips. While several standard languages exist (e.g. Verilog, HDL), the predominant language at the current time is Very-large-scale-integrated Hardware Description Language, or VHDL. Before coding an F P G A implementation in VHDL, however, the typical design flow begins with a design specification at the behavioural level (Sharma 1998), (Van den Bout 1999). From this point, the typical design flow proceeds as follows: 1. Behavioural Specification 2. Register Transfer Level (RTL) Specification 3. VHDL Coding 4. Synthesis 5. Simulation 6. Design Debugging (loop) 7. Implementation 8. Device Programming and Testing 53 9. Design Debugging (loop) This approach was used to develop each component in the F P G A based servo controller described in Chapter 4. The design flow outlined above is expanded along with implementation specific details in section 4.3.1. 2.6 Summary In both the academic and industrial communities, Open Control Architectures are viewed as the means to increase the level of functionality of machine tool controllers, while reducing the cost of purchase, operation and upgrades. The interest in these types of controls has spawned many projects in both communities, several of which have been reviewed in this chapter. While most participants agree on the advantages that open architecture control should yield, there are many differing opinions on the importance and relative priority of each advantage that is to be gained. As a result, the goals, strategies and tactics used by each group to reach their own definition of what an Open Architecture Controller should be vary widely. Presumably, the end users of the controls will vary in their needs just as widely. Should this be the case, then the broad spectrum in open architecture efforts is certainly a healthy one. Once such project is the UBC Open Architecture Control System, which has been undertaken in the Manufacturing Engineering Laboratory at the University of British Columbia. The work presented in this thesis is a continuation of the UBC 54 Open Architecture project, aimed at improving the functionality of the control by introducing a system and protocol for dynamic system re-configuration. Several key technologies are incorporated in the work; one such technological approach is object-oriented system design and implementation. Specifically, an object-oriented extension to the Forth programming language is employed to leverage the many advantages of the object-oriented approach, as outlined in this chapter. A second technological approach utilized in the work is the concept of an open architecture firmware system. The approach used is founded in the Open Firmware standard, and makes use of an embedded stream of code stored in device firmware, supplying information to the host system for configuration. A third technology is used in the validation of the open configuration system. Namely, Field Programmable Gate Array (FPGA) hardware has been used in the implementation of a servo controller as opposed to the normal approach using microprocessors, microcontrollers, or digital signal processors (DSP's). A brief overview of F P G A technology has also been given in the chapter. 55 3 Novel Open Configuration Architecture and Protocol 3.1 Introduction The proposed Open Configuration Architecture and Protocol described in this chapter is intended to facilitate hardware independence (vendor neutrality), automated system configuration, dynamic reconfiguration, and system extensibility. Hardware independence 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. This will have the effect of both reducing the initial cost to both the system integrator and the end-user, as well as allowing for modular upgrades to the system without the necessity of a re-design by the original builder or integrator. Automated system configuration allows these components to be assembled in a "plug and play" manner, with the ultimate goal of complete system configuration on the first power-up with zero intervention from the integrator. Again, through reduced complexity seen by the integrator this will result in an overall reduction in cost. In addition, the end-user will be able to install new hardware in the system without the requirement of extensive technical support. Dynamic system reconfiguration (i.e. reconfiguration at run-time) allows for the re-distribution of tasks based on the current machining operation, as well as allowing a variety of hardware and software strategies to be tested, evaluated and modified without requiring a system re-start. This has benefits at all stages of 56 machine tool production and use. The ability to test and debug "on the fly" will compress the development cycle time for component vendors, as well as simplify troubleshooting for integrators. Advanced end-users (those with the ability to manipulate the system at relatively low levels) will be able to incorporate flexible process monitoring and control strategies in the manufacture of a variety of products. This will allow them to incorporate their own processing expertise in the system and thus strengthen their position in the market. System extensibility refers to the ability to add new hardware and/or software capabilities to the system after it has been delivered to the end-user (in contrast to modularity, which allows the replacement of existing components with components defined by the same interface). This capability provides similar advantages as dynamic reconfigurability. Namely, both system integrators and end-users can utilize the extensibility of the system to embed their own expertise, creating a competitive advantage in the marketplace. 3.2 Open Configuration Overview The paragraphs below give an overview of the technologies and techniques that are used to provide the capabilities discussed above. In the sections that follow, a detailed description of the design and implementation of the system is given. At the high level, the Open Configuration System relies on a Virtual Machine (VM) abstraction of the underlying machine tool to provide hardware independence. This includes abstracted machine tool axes, sequential logic processing entities (i.e. PLCs) and advanced process monitoring and control modules (e.g. tool breakage detection, chatter detection, force constraint control, etc.). This abstracted V M is 57 coded in the Object-Oriented FORTH Programming Language Extension described in Chapter 2, with each of the abstracted entities defined by a class and instantiated as an object. These objects are represented in Figure 3.2-1 by the "Hardware Independent Object" blocks. As shown, higher-level software (e.g. interpolation algorithms, machine tool co-ordination, part programming and process planning tools) interact with the virtual representation of the underlying machine tool, removing any dependency on the details of the underlying hardware. CNC Master High-Level System Software Hardware Independent Objects Virtual X-Axis Virtual Y-Axis Virtual N—H Virtual Process Monitor Binding Table H—H <*—H T Hardware Dependent Methods Open Config Utility Figure 3.2-1. Schematic representation of Open Configuration System components 58 The V M objects in turn rely on a set of low-level methods to communicate with the physical hardware such that the desired actions are triggered and the desired information is properly collected. However, instead of building these hardware dependent methods into the class definitions of the abstracted objects (which would require system class definition for each hardware configuration), the low-level methods are vectored into an entity called the Binding Table. The binding table is built at start-up, and acts as a reconfigurable software routing switch, directing method calls from the V M objects to the appropriate hardware dependent low-level methods as shown in Figure 3.2-1. Although the binding table is built and the method bindings are established at system start-up, both can be changed at run-time. This results in the property of dynamic reconfigurability. For the Binding Table to operate then the code required to action a particular physical entity must be provided. The approach taken with the Open Configuration System is to use a tokenized configuration protocol, as indicated in Figure 3.2-1. Each hardware device in the system has a series of bytes stored in firmware, which represent a tokenized Forth program. That is, Forth code (again written using the object-oriented extension to the Forth language) has been passed through a "Tokenizer" program that translates the code into a compact series of binary bytes (an example is given in Appendix IV). The format for translation from textual FORTH code to this tokenized form is based on the IEEE Open Firmware Standard (Bradley et al 1994). At start-up, the Tokenized Configuration Stream is retrieved from device firmware, translated and interpreted by the Open Configuration Utility. When interpreted, the configuration stream establishes the low-level methods required to 59 communicate with the device and binds these methods into the binding table. The abstracted V M object method calls are then bound to the low-level methods via the binding table. This results in the ability to automatically configure the system. The properties of hardware independence, automatic configuration and dynamic reconfiguration have been addressed. This leaves the property of system extensibility to be covered. Extensibility in this system is derived from the interpretive nature of the FORTH language. This interpretive nature allows the addition of V M objects (along with a corresponding expansion of the binding table), as well as higher-level software modules to take place at any time. This ability may be contrasted to the use of scripting languages, which do not have the capacity to create new code at low levels of the system. Instead, the programmer is limited to the resolution (granularity) provided at the scripting interface. 3.3 Virtual Machine Representation of a Machine Tool Axis All abstracted models in the Open Configuration System are based on the UBC Open Architecture Control System reference architecture described in chapter 2. At this stage, the most fully developed V M class is the Machine Tool Axis class. For this reason, it will be used here as an example of the definition, implementation and instantiation of a V M abstraction. The UBC Open Architecture provides a behavioural model for an axis controller in the system. As shown in Figure 3.3-1, the model has the following characteristics: 60 1. A 1 s t-stage Interpolation Buffer is used to store interpolated increments (typically calculated at 1/16 t h or 1/32 n d of the loop-closing frequency), which are passed from the system master. 2. The 1 s t-stage increments are further interpolated by a second-stage interpolator, resulting in incremental reference position values calculated at the loop-closing frequency. 3. An interface is provided for the stateline bus. As discussed in chapter 2, this interface is used by the controller to implement a dynamic interpolation strategy. 4. A quadrature encoder interface decodes incremental quadrature signals into absolute position. 5. A digital filter and servo amplifier reference output are available to translate current position error to amplifier input. The filter parameters may be adjusted to attain the required closed-loop characteristics (servo loops in a multi-axis system must be tuned to have near-equivalent time domain specifications in order to avoid tracking errors in contouring operations). The output may be a P W M signal, an analog voltage, or a series of logic outputs to drive a digital amplifier. 6. An axis controller core co-ordinates the actions of the blocks mentioned above, and implements the axis control law. 61 Is' Stage Interpolation Buffer Command Register Dynamic 2 n d Stage Interpolator Stateline Interface Axis Controller Core Digital Output Filter PWM/Ana log Servo Amp Reference Output Figure 3.3-1. UBC Open Architecture Axis Controller Behavioural Model While it is not necessary that the physical device have this exact structure, the logical elements of the reference model are used to define the low-level communication methods used by the virtual object to communicate with the physical axis control hardware. A listing of these low-level methods is given in Table 3.3-1 with corresponding stack diagrams (detailed description of the methods are given in Appendix I). The stack diagram is intended to show the state of the stack before and after execution of the word. Stack values are written in the same order that they would be entered, i.e. the right-most value in the stack diagram represents the value that would next be popped from the LIFO stack. 62 Table 3.3-1. Low level device methods in the VM axis controller model. Method Name Stack Diagram D e s c r i b e : (-) send header: (num_stg2 seq_num - fig) send i n c r e m e n t : (n-flg) r e a d p o s i t i o n : (-nflg\flg) r e a d v e l o c i t y : (~nflg\flg) r e a d a c c e l : (-nflg\flg) r e a d e r r o r : (~nflg\flg) f l u s h b u f f e r : (-fig) r e s e t : (--fig) h a l t : (-fig) e n a b l e : (-fig) s e t f i l t e r : ( Tv Kenc &>cfes %des ~ fig ) get b u f f e r s t a t : (~nflg\flg) get l c f r e q : (~nflg\flg) get m s r a t i o : (~nflg\flg) get seq num: (~nflg\flg) 3.4 The Binding Table The binding table is the key enabler in the overall Open Configuration System. This entity has its roots in Brad Eckert's Tiny Open Firmware system (Eckert 1999), which uses a binding table concept to provide run-time access to the 63 firmware programming in embedded devices. As described in Chapter 2, the Tiny Open Firmware system places a binding table in the firmware of each embedded device, allowing reconfiguration of firmware programming via the re-vectoring of calls to the binding table. In the Open Configuration System presented, the Binding Table resides on the master side of the backplane communication channel. The Binding Table, shown conceptually in Figure 3.4-1, acts as a dynamically programmable "switch", vectoring method calls from V M objects to the low-level communications methods corresponding to the devices in the current system configuration. The mechanism for this is based on the FORTH programming technique of vectored execution. As described in chapter 2, the FORTH programming language is made up of a dictionary of words (subroutines). Each of these words has a characteristic value called a Code Field Address (CFA), which represents the location in memory at which the "executable" portion of the word begins (Woehr 1992). These CFA 's are also referred to as execution tokens, or XT's. This refers to the fact that the C F A for a given word can be extracted from the word, and passed as a stack value (variable), or token. VM Object VM Method Status Device Device Method x a x i s enable: bound servo c o n t r o l card enable x x axi s h a l t : bound servo c o n t r o l card h a l t x x axi s reset: bound servo c o n t r o l card reset x x axi s send increment: bound servo c o n t r o l card send x increment x a x i s read p o s i t i o n : NOT bound [empty] [empty] x a x i s read v e l o c i t y : NOT bound [empty] [empty] x a x i s read e r r o r : NOT bound [empty] [empty] Figure 3.4-1. Conceptual representation of a Binding Table in the Open Configuration System. 64 The Binding Table is implemented as an object (instantiated from a class in the object-oriented Forth extension), with the purpose of maintaining a linked list (i.e. creating, adding and finding nodes). The linked list contains a node for each V M method and corresponding low-level method in the system. Each node contains textual descriptions of the V M and low-level method, as shown in Figure 3.4-2. Also contained in each node is a single memory cell dedicated to the storage of an execution token. 2 Node# Link Device Device Method Status XT Object Object Method Figure 3.4-2. Linked-list implementation of the Binding Table. When a V M object method is registered in the table, the location of the newly created node's XT cell is passed back to the object. The object then stores the location in an internal variable, and executes the XT stored at that address whenever the method is called. When a low-level device method is bound to a V M object method, the XT of the low-level device method is passed to the Binding Table. This XT is stored in the appropriate node's XT cell, resulting in execution of the low-level device method whenever the V M object method is called. 65 Also shown in Figure 3.4-2 is a Status cell within the Binding Table node. Once a low-level device method has been bound to the V M object method, a flag is placed in this cell indicating that the methods have been bound. When all methods for a V M object have been bound to device methods, the object can be utilized by higher level software. Once all V M object methods have been bound in this way, the system can be said to be configured. Now, once a V M object method has been registered in the binding table (and an associated node created), calling the method will have the fixed result of executing the XT stored in the node's XT cell. However, at any time the XT stored within the Binding Table node can be replaced. It is via this mechanism that the system is dynamically reconfigurable. Interacting with the binding table to register V M object methods and bind low-level device methods is straightforward. Registration of a V M object method is typically done automatically as part of the object's c l a s s l n i t : method (called at instantiation), and binding of low-level device methods is done automatically during the evaluation of the device's tokenized configuration stream. Both activities can also, however, be done manually through the FORTH interpretive interface. This facilitates incremental testing and debugging, allowing the developer to visually inspect the binding table, add nodes, bind methods, etc. The methods used to interact with the Binding Table are listed in Table 3.4-1, and described in detail in Appendix II. 66 Table 3.4-1. Binding Table methods and stack diagrams. Method Name Stack Diagram D e s c r i b e : (--) Show t a b l e : (--) Add node: ( Avm_obj_str Avm_meth_str - xt_addr) F i n d node: ( Avm_object Avm_method - n) B i n d node: ( Adev_str Amethod xt n -) 3.5 Tokenized Configuration Stream At system start-up, definition of the hardware dependent methods corresponding to a particular device in the system (e.g. an axis controller) and binding of these methods to the V M Object methods in the Binding Table is done via the interpretation of the Tokenized Configuration Stream stored in the device's firmware. The format of this configuration stream is based on that outlined in IEEE 1275 (Bradley et al 1994), which was described in detail in chapter 2. The Open Configuration architecture and protocol described here uses the term "Tokenized Configuration Stream" where IEEE Open Firmware uses the analogous term "fcode program". While there are some syntactical differences, the two are conceptually similar. The overall structure for the series of bytes stored in device firmware is shown in Table 3.5-1. As shown, the first seven bytes constitute a header for the remaining body of the configuration stream. 67 Table 3.5-1. Tokenized Configuration Stream structure (as stored in device firmware) Byte Name Description 1 format The value 0x07 should be stored in this byte to indicate that the byte-coded stream is not compliant with the Open Firmware standard, but rather with this Open Configuration architecture and protocol. 2 checksum-high The most significant byte of a 16-bit checksum value, constructed by summing the bytes in the tokenized configuration stream body (bytes 8 through N), calculated using two's complement addition and ignoring overflow. 3 checksum-low Least significant byte of the 16-bit checksum. 4 length-high The most significant byte of a 32-bit number representing the number of bytes in the complete tokenized configuration stream (bytes 1 through N). 5 length-high-middle High middle byte of the tokenized configuration stream length. 6 length-low-middle Low middle byte of the tokenized configuration stream length. 68 Byte Name Descript ion 7 length-low Least significant byte of the tokenized configuration stream length. 8 through N tokenized configuration stream body Tokenized representation of an Object-Oriented Forth program that defines the low-level methods for the device, and results in binding of the device methods into the Binding Table. The steps involved in acquiring and evaluating the tokenized configuration stream for a given device are as follows: 1. Detection: For each available communication channel, test for the presence of Open Configuration compatible device. 2. Retrieval: If a device is detected on a channel, retrieve the series of bytes that constitute the configuration stream, storing them in a temporary file. 3. De-tokenizing: Once the tokenized stream has been retrieved, run it through a de-tokenizing translator, expanding the bytes out into the appropriate Forth code. 4. Evaluation: Pass the de-tokenized code through the Forth interpretive interface. The first two steps (detection and retrieval) are communication channel-dependent, while the latter two (de-tokenizing and evaluation) are not. For each available 69 communication channel, there must therefore be an appropriate standard governing the protocol for device detection and tokenized stream retrieval. Compatibility with the protocol for a given channel, as well as the tokenized code format constitutes Open Configuration compliance. 3.6 Communication Channel Bindings The specific protocol for a given communication channel is referred to in IEEE 1275 as a "Bus Binding" (Bradley et al 1994). In this system, it is most likely that a variety of communication channels will be accommodated in the assembly of an overall control system (e.g. EISA, PCI, STD, V M E busses, parallel port, serial port, Ethernet, CANbus, etc). For this reason, the protocol corresponding to a given channel will be referred to as a "Communication Channel Binding". A communication channel binding has two significant components. The first defines the way in which a sequence of physical signals on the communication channel is meant to be interpreted by both the device and the system master. The second defines the set of Forth words (methods) that can be used to manipulate and inspect the signals on the channel from the interpretive environment running on the system master. These methods are available to the tokenized configuration stream methods in the Open Configuration environment, and constitute the means by which the devices instantiate themselves within the system. Implementation of the communication channel binding words is the only component of the Open Configuration extension to the Object-Oriented (ANS) Forth programming language that is Operating System dependent. For example, the work 70 presented in this thesis is implemented in the SwiftForth ANS-compatible Forth environment (FORTH Inc. 1998), running under Windows 98. The communication channel binding methods have therefore been developed to run under Windows 98 in this particular system. Once the relatively small number of methods that represent the communication channel bindings have been implemented in a given Operating System environment, the rest of the Open Configuration system can be built on top of these in a platform independent way. This platform independence then carries over to any third-party extensions to the system. The axis control hardware developed for this thesis (covered in Chaper 4) is built around a Standard Parallel Port (SPP) communication channel. The S P P channel binding is therefore presented below. Table 3.6-1 gives a listing of the S P P channel methods along with stack diagrams and the byte-values that represent the methods in a device configuration stream (detailed descriptions of the methods are given in Appendix III). Note that in this case, the token represents both the method and the channel object to which the method request is being sent. For example, in a system with multiple parallel ports each of the following may be valid: OpenPort: l p t l OpenPort: l p t 2 and OpenPort: l p t 3 . When the token for the OpenPort: method is encountered in a configuration stream, the assumption made is that the channel through which the configuration stream is being retrieved is the channel to which the method request should be sent. 71 Table 3.6-1. Standard Parallel Port (SPP) Methods Method Name Token Stack Diagram Describe: n/a (--) OpenPort: 0x601 (--) ClosePort: 0x602 (--) ReadStatus: 0x603 (-n) Write Data: 0x604 (n~) WriteControl: 0x605 (n~) Detect: n/a (-fig) GetTCS: n/a (fileid-flg) 3.7 Summary This chapter has presented an Open Configuration System and Protocol intended to facilitate hardware independence, automated system configuration, dynamic reconfiguration, and system extensibility. The system is based on an abstracted Virtual Machine representation of a machine tool, with hardware-dependent methods linked to physical devices through a binding table. The binding table acts as a dynamically reprogrammable switch, vectoring method calls from the Virtual Machine to the appropriate low-level 'device driver' routines. Registration of the appropriate methods in the binding table is done through the interpretation of a Tokenized Configuration Stream, which is retrieved from device firmware using the appropriate communication channel binding. 72 As discussed in the chapter, the following milestones have been reached in the development of the Open Configuration Architecture and Protocol at this time. • Specification of the Open Configuration Architecture and Protocol framework. • Modelling of a machine tool (or robotic) axis controller within the specified framework. • Design and implementation of the Binding Table • Definition of Configuration Stream tokenization, retrieval, de-tokenization and evaluation. • Specification and implementation of the S P P communication channel binding. 73 4 Field-Programmable Gate Array (FPGA) Based Servo Controller 4.1 Introduction This chapter describes the design, implementation and testing of a Field-Programmable Gate Array (FPGA) Based Axis Controller. The Controller is based on F P G A technology, as described in section 2.5, and is compatible with the Open Configuration Architecture and Protocol described in Chapter 3. 4.2 XESS Prototyping Board The hardware platform used for the development of the FPGA-based axis controller is an X E S S prototyping board, built around a Xilinx XS40 20k gate F P G A . This board is shown in Figure 4.2-1, mounted on a standard breadboard with some external pwm-to-analog conversion circuitry (described in section 4.3.7). Also incorporated on the board is a 32kB S R A M chip, an Intel 8031 microprocessor and a programmable 100 MHz oscillator. 74 Figure 4.2-1. Prototype FPGA Based Axis Controller (Photograph) In the work described here, the 100 MHz oscillator is programmed with a divisor value of 8; i.e. the oscillator emits rising clock edge at a frequency of 12.5 MHz. The 8031 microprocessor is not used in the axis controller design, so this chip is simply held in reset (tri-stating its i/o ports). 4.3 Controller Design Overview A schematic diagram of the overall design and implementation of the F P G A -based servo controller is shown in Figure 4.3-1. This controller is designed to control a single machine tool (or robotic) axis, and can be synthesized to fit within the XC40-10XL Xilinx 20,000 gate FPGA. It is important to note that only the gate count and general purpose I/O available limit the controller to a single axis. With a 75 higher gate count and enough I/O channels, the same design can be used to implement multiple axis controllers within a single F P G A . External RAM (1st Stage Increment Buffer) Figure 4.3-1. FPGA Based Axis Controller Block Diagram As shown (Figure 4.3-1), the design is divided into nine logical partitions or 'blocks'. The nine blocks are implemented synchronously (driven by a common clock signal), and each block is dedicated to a specific sub-task critical to the overall operation of the axis controller. In effect, each block is an independent processing entity, with all blocks processing in parallel within a single F P G A chip. There are several interfaces between the F P G A and the overall control system into which it is integrated. The backplane interface provides communication between the F P G A and the system master. During start-up, the controller's tokenized configuration stream is stored in 32k of on-board R A M . This configuration stream is sent to the System Master via the backplane, where it is de-tokenized and 76 interpreted by the Open Config utility. At the present time, the de-tokenization process is not automated (doing so simply requires the writing of a module to translate numeric tokens into ASCII text, following the Open Firmware standard with the addition of Open Config token definitions). However, methods to detect the device ( d e t e c t : ) and retrieve the tokenized stream (getTCS:) have been developed and tested. Also, the (manually translated) configuration code has been used to instantiate the controller in the Open Configuration System and bind the following subset of methods into the binding table, allowing the axis to be controlled through the Virtual Machine Tool interface. r e a d _ p o s i t i o n : x _ a x i s r e a d _ e r r o r : x _ a x i s s end_increment: x _ a x i s r e s e t : x _ a x i s e n a b l e : x _ a x i s h a l t : x _ a x i s s e t _ f i l t e r : x _ a x i s These methods were introduced in Chapter 3, and are described in detail in Appendix I. Once the start-up sequence is complete the board transitions to axis-control mode. First stage interpolation increments and commands such as enable, halt, reset, etc. are then passed downwards (from the master to the FPGA) over the backplane, while low-level control information (current axis position, current following error, etc.) and status information are passed upwards. 77 As outlined in section 4.3, the on-board RAM interface (handled by the Arbitrator block) is used to store first stage increments passed by the system master. This interface is also used for retrieval of these increments for second-stage interpolation. The Servo Amplifier Output and Quadrature Decoder provide the interface to the physical axis under control. An analog command signal ranging from +10 V to -10 V is sent to the servo amplifier, resulting in axis motion. A quadrature incremental position signal is received from the axis encoder, allowing the axis controller to determine the current following error and calculate the appropriate next control action. The Synch Line interface is used to guarantee synchronous operation of all axis controllers in the overall co-ordinated control of several axes. One axis controller is designated as a pulse-generating controller (as shown in Figure 4.3-1), while all other axes in the system are pulse-receivers. Pulses are generated at the loop closing frequency of the system (typically 4 kHz), triggering the updating of the digital control action. The frontplane interface provides a further mechanism for co-ordination between axis controllers, as described in the UBC Open Control Architecture outline in Chapter 2. This interface allows each axis to write to and read from the open-collector stateline(s), facilitating the dynamic interpolation mechanism. The overall role of the FPGA-based axis controller then, is to interface in real-time with the external system components described above. This is accomplished via the nine logical controller blocks, which are described in the following sections. 78 4.3.1 Pulse Generator The pulse generator is used by the pulse-generating axis controller to synchronize the digital control action of all axes in the system (typically the loop closing frequency is 4 kHz). The pulse generator is the first logical F P G A block described in this work because its simplicity allows for a complete description of its design and implementation. While it is not feasible to include such complete descriptions for the remaining components in the system due to the space required, an analogous design and implementation process can be assumed by the reader. The top-level schematic diagram for the pulse generator is shown in Figure 4.3-2. As shown, the block has two inputs (elk, p u l s e _ a c k ) and one output (pulse). The behavioural description for the pulse generator is as follows: • The incoming 12.5 MHz clock signal, e l k , is divided by a factor of 3125 to generate a 4 kHz signal. • On the rising edge of the 4 kHz signal, a logic high value is placed on the p u l s e output. • The value of the p u l s e output remains high until a logic high value is present on the p u l s e _ a c k input (indicating recognition of the pulse by the axis controller core), at which point the p u l s e output is pulled low. 7 9 [> pulse N pu lse_ack TD: C o n t r o l l e r Core CLK Figure 4.3-2. Pulse Generator top-level schematic. Based on the top-level schematic and behavioural description above, a register transfer level (RTL) schematic diagram can be constructed, as shown in Figure 4.3-3. In this diagram, the 12-bit register R e g l and multiplexer Muxl are used to implement the clock signal divider. The value stored in R e g l is incremented by +1 on the rising edge of the e l k signal, until a value of 3214 is reached. At that point the divider "rolls over", returning to a count of zero. The value stored in Regl is tested by the "=0" logic block, which emits a logic high value when the count is equal to zero. As shown, this logic signal is "OR'ed" with the current value of the pulse signal and fed into Mux2, effectively keeping the p u l s e output (stored in the single bit register Reg2) at a logic high value until the ack (i.e. p u l s e _ a c k input) signal is pulled high. 80 Figure 4.3-3. Pulse Generator register transfer level schematic. After producing an RTL diagram such as the one shown in Figure 4.3-3, the components can be coded in VHDL. The overall (top-level) block is described by the following VHDL statement. e n t i t y pulse_generator i s port ( el k : i n s t d _ l o g i c ; pulse: out s t d _ l o g i c ; pulse_ack: i n s t d _ l o g i c ) ; end pulse_generator; The internal architecture and signals of the block are then declared as follows: a r c h i t e c t u r e p u l s e _ g e n e r a t o r _ r t l of pulse_generator i s s i g n a l count, next_count: unsigned (11 downto 0) ; s i g n a l p u l s e _ s t a t e , n e x t _ p u l s e _ s t a t e : s t d _ l o g i c ; begin + -- hardware d e s c r i p t i o n statements (see below) + end p u l s e _ g e n e r a t o r _ r t l ; The multiplexer (Muxl) and comparator (<>3125) used in the clock-dividing portion of the block are described in VHDL as follows. next_count <= conv_unsigned (0,12) when count = conv_unsigned (3124, 12) e l s e count + conv_unsigned (1,12) ; 81 The output from the multiplexer (next_count) is then used to update the count value stored in R e g l on the rising edge of the e l k signal. Latching the value on the rising edge of the clock signal is achieved by the following process statement. proces s ( e lk ) beg in i f e l k ' e v e n t and e l k = ' 1 ' then count <= next__count ; end i f ; end process ; Similarly, the multiplexer Mux2, register Reg2, OR gate and NOT gate used in the pulse generating portion of the block are defined as follows: next_pulse_s ta te <= ' l 1 when count = conv_unsigned ( 0 ,12 ) e l s e ' 1 ' when pu l se_s ta t e = ' 1 ' and pulse_ack = 1 0 ' e l s e • 0 ' ; p r o c e s s ( e l k ) beg in i f e l k ' e v e n t and e l k = ' 1 ' then pu l se_s ta te <= next_pulse_s ta te ; end i f ; end process ; Finally, the value stored in Reg2 is assigned to the pulse output via the following statement. pu l se <= pu l se_s ta t e ; After generating the appropriate VHDL code, the block is synthesized (synthesis is analogous to compilation in computer programming terms) into a file called a netlist, which serves as the input for both simulation and final implementation. In the simulation phase, the correct logical operation of the block is tested by injecting an exhaustive set of test signals into the port and inspecting the output. Once correct operation of all blocks in the system has been verified, the 82 blocks are brought together into a single top-level entity, again described in VHDL. This top-level VHDL file is synthesized and tested to verify correct operation of the overall system. The final stage in the development process is implementation. In this phase, the netlist describing the top level entity (along with all of the system sub-components) is implemented into a bitstream configuration file. The exact format of the bitstream file is dependent on the FPGA, and implementation of a netlist into a bitstream file requires development tools supplied by the F P G A vendor. Once the bitstream file has been created, it is used to program the FPGA. At this point the physical hardware can be tested and, if necessary, subsequent iterations through the development cycle can be used to correct any bugs in the operation of the device. 4.3.2 Backplane (Parallel Port) Interface Communication with the System Master is achieved via the use of a P C Parallel Port, configured in Standard Parallel Port (SPP) Configuration. In this configuration the P C has access to three software registers, namely the Data Port (output), Status Port (input) and Control Port (output), with a total of 14 output lines and 6 input lines (Peacock 1999). The X E S S prototyping board provides a subset of these signals for interfacing with the F P G A (Van den Bout 1999, Echanove and Tombs 2000). The parallel port signals used in this design are shown on the left-hand side of Figure 4.3-4, with the signal mapping shown in Table 4.3-1. 83 TO PC P a r a l l e l P o r t P C _ d a t a _ b y - t e — P C ^ s t a t u s _ n y b b l e — BUSY -9 -DATA ADDR — B a c k p l a n e I n t e r f a c e —/•—&• s-tgl_do.-ta —f> p u s h _ r e q — p u s h _ a c k — h a l f _enp t . y_ f l ag —6* f l u s h _ r e q — f l u s h _ o c k t c s _ p u r g e _ r e q t c s _ p u r g e _ a c k 15 / t> t c s _ a d d r 8 t c s _ b y t e r s t r s t . a c k H> e n a b l e — e n a b l e _ a c k — p o s i t i o n — e r r o r -f> K p J M Kp_FM -r> K p A J M - V — B > KpA_FM 4 - V — & • K p A _ F B S -T*—r> B_FBS TD: Ran A r b i t r a t o r TQ: C o n t r o l l e r C o r e S igna l Tops TD; L e a d / L a g F i l t e r Figure 4.3-4. Backplane Interface top-level schematic diagram Table 4.3-1. PC Parallel Port Signal Mapping 4.3.2.1 Backplane Interface Signal PC Parallel Port Signal PC_data_byte [7:0] P C Data Port [7:0] (bits 1, 0 inverted) PC_status_nybble [3:0] P C Status Port [6:3] B U S Y P C Status Port [7] DATA* P C Control Port [3] (inverted) ADDR* P C Control Port [2] 84 During system start-up, the tokenized configuration stream is transferred from R A M across the parallel port interface using only the PC_data_byte and PC_status_nybble ports. This follows the Open Configuration Protocol outlined in chapter 3. Once the T C S has been transferred, the axis controller switches to its normal operating (axis control) mode. In this mode, the axis controller is presented to the system master as a series of byte-wide write-only registers (accessed via the PC_data_byte) and a single nybble-wide read-only register (accessed via the PC_status_nybble). The resulting "memory map" for the byte-wide write-only registers is defined as follows: Table 4.3-2. Byte-wide write-only register map Register Address Register Definition 0x00 output_select 0x01 through 0x07 undefined 0x08 stg_1_in_lo (LS byte of first stage increment) 0x09 stg_1_in_hi (MS byte of first stage increment) OxOA command OxOB Kpl (Lead/Lag filter parameter) OxOC KpF (Lead/Lag filter parameter) 85 Register Address Register Definition OxOD KpAl (Lead/Lag filter parameter) OxOE KpAF (Lead/Lag filter parameter) OxO F Bl (Lead/Lag filter parameter) 0x10 BF (Lead/Lag filter parameter) Writing to a byte-wide register is done in two stages. First, the address at which the byte will be written is placed on the PC_data_byte bus. The ADDR* line (normally high) is then strobed low, and the address byte is latched by the interface on the rising edge. Following this, the data byte is placed on the PC_data_byte bus. The DATA* line is then strobed low, and the data byte is latched into the register corresponding to the address value on the rising edge of the strobe. The value placed on the nybble-wide read-only (PC_status_nybble) register is determined by the value written to the output_select register (address 0x00). This correspondence is shown in the following table: 86 Table 4.3-3. PC_status_nybble values output_select value PC_status_nybble value 0x00 controller status [3]: undefined [2]: flush_ack [1]: reset_ack [0]: enable_ack 0x01 position [3:0] 0x02 position [7:4] 0x03 position [11:8] 0x04 position [15:12] 0x05 position [19:16] 0x06 error [3:0] 0x07 error [7:4] 0x08 error [9:8] Passing a first-stage interpolation increment (16-bit value) from the system master to the controller is done by writing the least significant byte of the increment to the stg1_in_lo register, followed by writing the most significant byte to the stg1_in_high register. Following a write to the stg1_in_hi register, the interface will push the 16-bit value into the 1st-stage increment buffer via the RAM Arbitrator (this is achieved via the push_req and push_ack handshaking signals shown in Figure 4.3-4). During this interaction with the RAM Arbitrator the BUSY signal is held high. 87 The system master must then wait for the BUSY signal to go low before sending another increment. The byte-wide command register is used to control the overall status of the controller. This register can be used to place the controller in a halt state with servo amplifiers disabled, to reset the controller (effectively defining the axis 'home' position by resetting the encoder counts) and to flush the first stage increment buffer. 4.3.3 RAM Access Arbitrator The XESS prototyping board includes 32 KB of RAM. At start-up, the tokenized configuration stream is stored in the RAM, waiting to be retrieved, de-tokenized and interpreted by the Open Config utility. After the start-up sequence the RAM is used to buffer first-stage interpolation increments received from the system master (PC). These first stage increments are subsequently retrieved by the second-stage interpolator, and used to generate motion increments at the loop closing frequency. As such, both the backplane interface and the second-stage interpolator require access to the contents of the RAM. The Access Arbitrator provides for this, by prioritizing access to the memory and interfacing with the Backplane Interface and the Second-stage Interpolator through a series of handshaking signals. The RAM Access Arbitrator is shown schematically in Figure 4.3-5. 88 TO: B a c k p l a n e I n t e r F a c e s t g l _ c f a t a -p u s h _ r e q -p u s h _ o c k < h a l f _ e n p t y _ f l a g - 6 -F l u s h _ r e q — F l u s h _ a c k <3— t c s _ p u r g e _ r e q — t c s _ p u r g e _ a c k <3— RAM A r b i t r a t o r -f> i n t e r n a l V E TQ: 32K RAM s t g l _ o u t — p o p _ r e q p o p _ r c l y TO: 2 n d S t a g e I n t e r p o l a t o r Figure 4.3-5. RAM Arbitrator top-level schematic. 4.3.4 2nd Stage Interpolator The second-stage interpolator is a "divide-by-16" linear interpolator, i.e. coarse first-stage increments (passed over the backplane) are broken down into sixteen fine second-stage motion increments. These motion increments are added to the reference position buffer at the loop-closing frequency, provided that the stateline bus value permits it. An 'accumulator' register is used to store and accumulate sub-BLU fractional remainders resulting from the divide-by-16 operation. When the accumulated value in this register reaches a full BLU, it is added to the reference position buffer along with the next second stage increment. This prevents the loss of sub-BLU remainders, which can result in an aggregate position error. Implementing the second stage interpolator in this way results in a chordal approximation to curved contours at the second stage level. Provided that the maximum distance from the chordal approximation to the exact curve does not exceed +/- BLU, the interpolated path will still be kinematically correct. This, 8 9 however, imposes a limit on the feed rate when interpolating a curved contour. For example, when interpolating a circular path the first stage interpolated increments represent "corner points" for the chordal approximation (each corner point lies on the circumference of the circle). The tangential feed rate is then given by: where R = radius of circular contour a = incremental angle between corner points T c = corner point calculation frequency. The limit imposed on the incremental angle by the chordal approximation is given by: (4.2) which results in the following upper limit for the feed velocity: A computationally efficient parabolic second stage interpolation scheme was developed by Yellowley and Pottier (Yellowley and Pottier 1989), which greatly improves the accuracy of circular contour tracking in the two-stage interpolation approach. This method has not been implemented in the F P G A Based Axis Controller for reasons of gate utilisation. It is, however, anticipated that future 90 versions of the controller (implemented on larger FPGA's) will include the parabolic scheme. A top level schematic of the current second-stage interpolator is shown in Figure 4 .3 -6 below. TO- R a n A r t a i t r a t o r 16 s t g l _ o u t -p o p _ r e q O p o p _ r d y N S e c o n d S t a g e I n t e r p o l a t o r 10 •f> s " t g £ _ d a t a h3 s t g £ _ p o p _ r e q -£* s t g 2 _ p o p _ r d y —f> n o _ i n c r _ a v a i l a b l e TD: C o n t r o U e r C o r e Figure 4.3-6. Second-Stage Interpolator top-level schematic 4.3.5 Axis Controller Core The Axis Controller Core, shown schematically in Figure 4 .3 -7 , acts to co-ordinate the actions of all blocks that are directly involved in the real-time control activity. This includes the 2ND stage interpolator, digital filter, amplifier output and quadrature decoder. In addition to interacting with these components, the controller core contains the current reference position, and constructs the position error signal by subtracting the encoder position from this reference. 91 s t a t e l i n e _ o u t TO' B a c k p l a n e I n t e r f a c e TO: S e c o n d S t a g e I n t e r p o l a t o r r s t _ a c k *3-e n a b l e e n a b l e _ a c k <}• s t g 2 _ d a t a s t g 2 _ p o p _ r e q O-s t g £ _ p o p _ r d y i _ i n c r _ a v a i i a b l e H £> f i l t e r _ o p c o d e f i l t e r _ a c k p w n _ o p c o d e p w n _ e n a b l e q d e c ^ p o s i t i o n q d e c _ r e s e t TO; D i g i t a l F i l t e r TO-. P V M O u t p u t TCf Q u a d r a t u r e D e c o d e r p u l s e p u l s e _ a c k Figure 4.3-7. Axis Controller Core top-level schematic. A s shown, the controller core monitors the pulse and stateline inputs, while interacting with other controller blocks through a series of handshaking and data signals. When a pulse is received, the controller core (implemented as a finite state machine) acknowledges the pulse and cycles through a series of branched states. If the stateline input is low, no increment is added to the reference position. The controller simply updates the position error, writes the updated value to the digital filter, and instructs the filter and P W M blocks to update their internal values and output signals (i.e. the digital axis control loop is closed normally). If the stateline is high, the controller requests the next position increment from the second stage interpolator, adds this value to the reference position, and closes the loop in the same manner. If, however, no increments are available from the second stage interpolator (i.e. the first-stage buffer is empty), the controller core writes a logic low value to the stateline interface and closes the control loop. This prevents other axis 92 controllers from adding any second stage increments to their respective reference positions. The controller core also interacts with the backplane interface, acting on and acknowledging halt, enable, and reset commands sent from the C N C master. 4.3.6 Digital Lead/Lag Filter The digital lead/lag filter is the most demanding component to implement within the F P G A architecture. While several axis controller system blocks implement signed binary arithmetic, the digital filter requires signed multiplication of numbers with integer and fractional components (i.e. fixed-point mathematics) to operate. As a result, a relatively complex many-state solution was required to reduce the footprint of the filter to the gate count required for implementation within the 20,000 gate F P G A . In order to understand the purpose of the lead/lag filter and the choice of its parameters, one may consider the high-performance current-controlled servo loop shown in Figure 4.3-8 (with non-linearities such as backlash hysteresis and amplifier saturation neglected). „(s) +^E(s ) / E(z) D(z) R(z)/R(s) GoKD Us) KT/J«,s P<sJ 1/s 9(s) Figure 4.3-8. Current-controlled servo loop block diagram 93 Here the sampled-time transfer function D(z) represents the lead/lag filter in the overall system. The definitions for each parameter and transfer function in the system are given in Table 4.3-4 below. Table 4.3-4. Current-controlled servo loop parameters Parameter Description eR(s) Axis reference position (BLU) E(s) Position error in the Laplace (continuous time) domain (BLU) E(z) Position error in the Z-transform (sampled time) domain (BLU) D(z) Digital Filter Z-transform domain transfer function (BLU) R(z) Digital Filter ouput signal in the Z-transform domain (BLU) R(s) Digital Filter output signal in the Laplace domain (BLU) GOKDA Zeroth-order hold and Digital to Analog (D/A) converter gain (V/BLU) U(s) Servo Amplifier reference voltage (V) K A Servo Amplifier voltage/current gain (A/V) lm DC Motor armature current (A) K T DC Motor torque constant (N*m/A) Je Effective polar moment of inertia, reflected to the motor shaft (Kg*m2) Q(s) Angular velocity of DC Motor shaft (rad/sec) 9(8) Angular position of DC Motor shaft (rad) 94 Ktach Tachometer feedback gain (V/(rad/s)) Kenc Encoder feedback gain (BLU/rad) Now, by replacing the Z-transform domain transfer function D(z) by its Laplace domain equivalent D(s) and reducing the servo amplifier / DC motor velocity feedback loop, the overall system can be replaced by the simplified block diagram shown in Figure 4.3-9. eR(s) + ^ E ( S ) — o — • Figure 4.3-9. Current-controlled servo loop reduced block diagram The velocity loop time constant, labelled x in Figure 4.3-9, can be expressed as: J„ KA-KT • Ktach (4.4) while the velocity loop gain, K, is theoretically equivalent to K D A - N O W , the continuous time transfer function for a lead/lag filter is given by: m = K • HSL. (4.5) s + b 95 As shown in Seethaler and Yellowley's work on the regulation of contouring error (Seethaler and Yellowley 1996), the numerator of the lead/lag transfer function can be used to cancel the first order lag velocity feedback loop by selecting: a = - = - A ' K T ' K , a c h J „ (4.6) This results in an overall closed-loop transfer function given by: 6_ ( Kp-K- Ke„c - K A - K T - K,ach ^ J. s +b-s + (Kp-K- Kenc • KA • KT • Klach J., (4.7) Kp-K-Kcnc s +b-s + K-K-K,, Where s2 + 1C,cons + con ^ = closed loop damping ratio COr closed loop natural frequency (rad/sec). So, by selecting K p and b such that: b = S (4.8) and K = ^ - , (4.9) p K-K.,„' 96 the closed-loop natural frequency and damping ratio can be specified for the system. In order to implement the lead/lag filter as designed, however, the transfer function must be mapped into the Z-transform domain. Using the simple approximation: . = ^ 1 , (4.10) s where T s is the sampling interval, or the inverse of the loop-closing frequency (Dutton, Thompson and Barraclough 1997), the resulting transfer function is: D(z) = K p . ^ (4.11) z — B Where A = \-a-Ts and B = \-b-Ts. Finally, this sampled-time transfer function can then be implemented within a digital device (such as an FPGA) via the following discrete time equation: r(Jfc) = Kp • e(k)-Kp -A • e(k-1) + B• r(k-1). (4.12) Where k = discrete time sample interval r(k) = digital filter output in the k t h time interval e(k) = position error in the k t h time interval This equation represents the fixed-point mathematical expression that must be evaluated within the F P G A lead/lag filter block. 97 While the values e(k), e(k-1) and r(k-1) are integer values (expressed in B L U ) , the values K p , A and B contain fractional parts. As mentioned above, multiplication of the filter equation terms within the F P G A controller therefore represents a computational challenge. In order to minimize the gate count of the digital filter, a multiple step mulitply-and-shift operation is used. Each of the filter parameter coefficients (K p, KpA and B ) are split into integer and fractional parts. The integer multipliers are labelled Kpi M , KpA| M and B | M , where "IM" is a mnemonic for "Integer Multiplier". The first step in evaluation of the filter output is multiplication of these integer coefficient components by the integer values of e(k), e(k-1) and r(k-1). This is achieved via a partial product look-up table (Andraka 1998). The fractional components of the filter parameter coefficients are approximated by an integer multiplication followed by an n-bit right shift (for example, a multiplication by 3 followed by a 2-bit right-shift implements an effective multiplication by 0.75). The fractional multipliers (integer values) are labelled Kp F M, KpApM and BFM, while the n-bit-shift values are labelled Kp FBs, KpA FBs and BFBS-Table 4.3-5 below gives sample values for the approximation of parameters in a filter implementation. Table 4.3-5. Sample filter parameter approximation terms. Term Filter Parameter Integer Multiplier Fractional Multiplier Fractional Bit-Shift Effective Multiplier Kp*e(k) K p = 69.565 Kp,M = 69 K p F M = 9 K P F B S = 4 K p e f f = 69.5625 Kp*A*e(k-1) K P * A = 69.078 KpAiM = 69 K p A F M = 5 K P A F B S = 6 Kpeff = 69.0781 B*r(k-1) B = 0.94 B I M = 0 B F M = 15 B F B S = 4 B e f f = 0.9375 98 As shown in Figure 1.1-1, the filter parameter approximation values are received from the backplane interface (allowing the tuning of control loops from the C N C master). The present position error e(k) is passed by the controller core, and the resulting filter output is passed to the amplifier reference output block. Handshaking signals are used by the controller core to initiate a filter update. TD: C o n t r o l l e r C o r e TQ: B a c k p l a n e I n t e r f a c e 10 e r r o r • f i l t e r _opcode f i l t e r _ a c k -3-Kp_IM — Kp_FM 7 ^ N 4 Kp_FBS —N KpA_IM * BH, 4 KpA_FM 7^-KpA_FBS —EH B_IM • B_FM ^ — N B_FBS • L e a d / L a g F i l t e r CLK-10 -y-—e> o u t p u t TO: PWM O u t p u t Figure 4.3-10. Lead/Lag Filter top-level schematic. 4.3.7 Amplifier Reference Output The Amplifier Reference block (top-level schematic shown in Figure 4.3-11) converts the digital output of the lead-lag filter into an analog signal between +10 a n d - 1 0 V D C . This is done in two stages. The first stage is internal to the F P G A . In 99 this stage the digital level is converted to a 3.3 V D C pulse-width modulated (PWM) signal, with 10-bits of resolution and a carrier frequency of f O S c/2 1 0 . TD: Digital Filter TQ; Controller Core level pwn_opcoc!e • pwn_enable 10 PWM •utput / \ (Vpwn) _ anpenable TD: PWM -> Analog Converter TD: Servo Amp CLK-Figure 4.3-11. PWM Output top-level schematic. The second stage is external to the FPGA. In this stage, an analog circuit is used to convert the P W M signal to an analog signal ranging from +10 to -10 VDC. As shown in Figure 4.3-12, the circuit consists of a high-impedance voltage follower, an inverting amplifier, a range-shifter and a second-order low-pass RC filter. +5V Figure 4.3-12. PWM to Analog Converter circuit diagram. The voltage follower is intended to provide a very high-impedance input port to the electronic network, so that the pulse-width modulated F P G A output signal will 100 not be significantly loaded. As shown, the inverting amplifier has a gain of unity (in this case R1 = 1.5 kQ - the value of R2 is set to 750 Q such that the impedance at each op-amp input terminal is balanced). As a result, the voltage following the range shifter (V) is given by: V'=—Vpwm-—(5V). (4.13) RA R3 Since the P W M signal from the F P G A ranges from 0 V to +3.3 V, and it is desired to have an analog amplifier reference voltage ranging from -10 V to +10 V, the resistance values are set to: R2 = 10 kQ R3 = 5 kQ R4 = 1.665 kQ R6 =1 .5kQ. This results in a (still pulse-width modulated) signal V ranging from -10 V +10 V being fed into the 2 n d order low-pass RC network. The low-pass filter section is designed to convert the P W M signal to a continuously ranging analog voltage by removing the PWM carrier frequency and preserving the lower-frequency position control component of the signal. At an oscillator frequency of 12 MHz and a 10-bit resolution, the P W M output has a carrier 101 frequency of 11.7 kHz. In order to preserve the bandwidth of the control signal (loop closing at 4 kHz), the filter resistance and capacitance values are chosen as: Rf = 1.8 kQ Cf = 15 nF, which results in a break frequency of 5.9 kHz for the 2 n d order filter. The attenuation of the filter at 11.7 kHz (the P W M carrier frequency) is thus approximately 14 dB, while the attenuation at 4 kHz (the loop-closing frequency) is approximately 3 dB. An improvement on the P W M carrier frequency attenuation results when the oscillator frequency is increased (for example, at an oscillator frequency of 20 MHz, the resulting 19.5 kHz P W M frequency attenuation is 21 dB). 4.3.8 Quadrature Decoder Shown schematically in Figure 4.3-13, the Quadrature Decoder block is responsible for decoding the incoming quadrature incremental position signal and converting it to an absolute position count. TQ; C o n t r o l l e r C o r e 20 p o s i t i o n O-r e s e t N Q u a d r a t u r e D e c o d e r TQ: E n c o d e r I n t e r f a c e Figure 4.3-13. Quadrature Decoder top-level schematic. 102 A similar system was implemented as a stand-alone F P G A application by Thomas Fung at the University of British Columbia (Fung 1997). Fung's quadrature decoder was implemented in HDL (Hardware Description Language) for an Altera NFX780_84 F P G A , and interfaced directly to the P C Parallel Port. Subsequently, the quadrature decoder was improved and implemented in VHDL (Very large scale integrated Hardware Description Language) for the Xillinx XC40-10XL F P G A (Oldknow 1999). In this thesis work, the VHDL version of the quadrature decoder has been adapted and integrated into the overall F P G A axis controller application. 4.3.9 Frontplane Interface i n t e r n a l _ s t a t e l i n e _ l i n t e r n a l _ s t a t e l i n e _ 2 i n t e r n a l _ s t a t e l i n e _ n e x t e r n a l s t a t e l i n e F r o n t p l a n e I n t e r f a c e CLK--f> s t a t e l i n e out Figure 4.3-14. Frontplane Interface top-level schematic. The frontplane interface, shown schematically in Figure 4.3-14, acts as both an interface to the physical stateline bus, and an internal stateline value resolver (modelling the open collector stateline as a wide-input AND gate). The current value of the physical stateline bus (external to the FPGA) is an input to the block, as are any stateline outputs from internal F P G A modules (e.g. axis controller core). All 103 input signals are combined through an AND operation, and the output is written back, both to the internal F P G A modules and to the physical stateline through the open collector port. 4.4 Test Stand Integration and Testing In order to verify correct operation of the F P G A based servo controller, a laboratory test stand was constructed. A block diagram representation of the test stand is shown in Figure 4.4-1, and a photograph is shown in Figure 4.4-2. DC Power Supply Tachometer F P G A Based A x i s Controller Servo Amplifier Coupled Shaft Quadrature Signal Posi t ion Encoder Figure 4.4-1. Servo test stand block diagram. 104 Figure 4.4-2. Photograph of servo test stand As shown, the P C Host (running the Open Configuration System) supplies position increments to the axis controller over the standard parallel port. Based on the lead/lag filter output (derived from position error), the axis controller supplies an analog reference voltage to the servo amplifier. The servo amplifier then drives a DC brushed servo motor in current-controlled mode, with a second DC motor supplying the necessary velocity feedback signal. Position feedback is acquired from an incremental quadrature encoder, which is integral with the driven motor. A specific listing of these components is given in Table 4.4-1 below. 105 Table 4.4-1. Description of servo test stand components. Test Stand Component Description P C AOpen/lntel Celeron 333 MHz P C running Windows 98 and Forth Inc. SwiftForth ANS-compatible Forth system. Axis Controller XS40-10XL F P G A prototyping board with external P W M to analog conversion circuitry. DC Power Supply Elenco Precision Deluxe Regulated DC Power Supply, model XP-650. Servo Amplifier Copley Controls Corp. model 513 servo amplifier. DC Brushed Motor and Encoder Pittman model 14204B352 30.3 V D C servo motor. Tachometer Electro-Craft Corp. model 138000 DC servo motor. Identification of the velocity loop time constant was done by injecting a +5VDC step at the servo amplifier reference input (i.e. by-passing the F P G A controller) and measuring the tachometer feedback signal time response with an oscilloscope. The tachometer signal is shown in Figure 4.4-3, along with a theoretical first-order lag represented by: Vlhmrelical=l2- \-e~ . (4.14) where T is the first-order lag time constant. 106 ro c cn CO E o .e o ro 50 150 200 250 T ime (ms) — Vtach (V) — Vtheoretical (V) Figure 4.4-3. Velocity loop tachometer signal (measured and theoretical, with time constant =10 ms). As shown, the system (neglecting high-order frequencies) is well-modelled by a time constant of 10ms. Based on the analysis in section 4.3.6, this allows the overall second-order closed-loop system to be specified by setting b = £ and co • T Kp~Tir In this case, the desired damping ratio and natural frequency are 0.707 and 25Hz respectively. Using a D/A converter gain of 0.019 V/BLU and an encoder gain of 318.3 BLU/rad, the resulting filter parameters are: 107 Kp = 40.84 A = 0.975 B = 0.944. Using approximated filter parameters (as described in section 4.3.6), the F P G A axis controller was tested in response to a 4000 BLU/second ramp input, as shown in Figure 4.4-4. As expected for a Type 1 system (Dutton, Thompson and Barraclough 1997), the steady-state error in response to the ramp is seen to approach a constant value of approximately 7 BLU. Ramp Response (4000 BLU/sec) 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 Time (s) - - Position Reference o Error Figure 4.4-4. Axis response to a 4000 BLU/second ramp input. 108 4.5 Summary In this chapter the design and implementation of an F P G A based servo controller has been presented. The controller is implemented on a prototyping board incorporating a Xilinx 20,000 gate F P G A , and is designed to control a single machine tool (or robotic) axis at a loop-closing frequency of 4kHz. The controller has been designed and implemented to be compatible with the Open Configuration System and Protocol described in Chapter 3. Methods to detect the device on a Standard Parallel Port and receive a Tokenized Configuration Stream from on-board firmware have been developed and tested. In addition, a core subset of the virtual axis methods has been implemented, allowing the device to be instantiated, bound into the Binding Table and controlled through the Virtual Machine Tool interface. Design and implementation of the controller is based on the synchronous operation of nine distinct processing entities within the FPGA. These are: • 4kHz Pulse Generator • Backplane Interface • R A M Access Arbitrator • Second Stage Interpolator • Axis Controller Core • Digital Lead/Lag Filter • Amplifier Reference Output • Quadrature Decoder • Frontplane Interface. 109 The controller accepts first-stage interpolated increments from the C N C master over the backplane communication channel (in this case, a Standard Parallel Port). The first stage increments are then stored in a circular buffer, located in a 32k x 8 R A M chip on the prototyping board. The first stage increments are later retrieved from R A M by a second stage interpolator, which applies a division by 16 into the final position increments to be added at the loop-closing frequency. The controller core closes the control loop at the prescribed rate of 4kHz, determining the appropriate position increment to add based on the value of the stateline bus, and constructing the position error based on the decoded quadrature position signal. The position error is then fed through the digital lead/lag filter, with the filter output emitted from the F P G A in the form of a P W M signal. The P W M signal is then converted to a continuous DC reference voltage for use in driving a current-controlled servo loop. Correct operation of the controller and conformance with the Open Configuration System has been tested via the integration of the controller into a servo test stand in the Manufacturing Engineering Laboratory. 110 5 Conclusions and Recommendations for Future Work 5.1 Conclusions In order to meet the rapidly changing demands of the manufactured goods marketplace, automatic machine tools require functionality, flexibility and cost effectiveness that cannot be provided by traditional "closed" control system architectures. As a result, both private industry and university researchers are developing Open Architecture control systems to meet the needs of manufacturers. Several projects have been initiated, each with a unique set of priorities and goals in the design and development of these systems. One such system, the UBC Open Architecture Control System, has been developed with a focus on minimizing the cost of machining through the Adaptive Control Optimization (ACO) approach. It has been recognized that the ability to reconfigure the 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 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 111 Model. The system improves the vendor neutrality of the system by implementing an object-oriented virtual machine tool that abstracts the behaviour of the distributed real-time 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 tokenized 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 F P G A based servo controller has been developed to validate 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 F P G A , and has been implemented on a prototyping board incorporating a Xilinx F P G A , external R A M chip and minimal analog circuitry. The controller has been integrated into a laboratory test stand, and tested for correct operation as well as conformance with the Open Configuration System and Protocol. 5.2 Recommendations for Future Work While the principle components of the virtual machine tool model have been identified (axes, P L C , process monitors), only the axis controller class has been fully specified and verified for correctness. The technical specifications of the V M therefore need to be extended to incorporate P L C and process monitor capabilities. 112 It is anticipated that the virtual machine concept will eventually be extended into a "virtual machinist", which will underpin the syntax of a feature-based integrated planning and control environment. While the feasibility of the Open Configuration System has been demonstrated in principle, its practical use requires a higher degree of automation in the configuration process. To this end, the writing of an automated Tokenizer/Simulator and De-Tokenizer, as well as the extension of the system to handle communication channels other than the Standard Parallel Port is required. The Standard Parallel Port interface was used as the backplane communication channel primarily out of convenience in this work (a hardwired S P P interface is a standard component of the F P G A prototyping board used). While the interface is effective, it may prove not to be the optimal approach. Alternative interfaces to the Standard Parallel Port should therefore be examined for implementation in the F P G A servo controller. 113 References Altintas, Y. and Munasinghe, W.K. 1994. A Hierarchichal Open-Architecture C N C System for Machine Tools. Annals of the CIRP 43:1:349-354. Andraka Consulting Group 1998. Multiplication in FPGAs . [resource on-line]; available from http://users.ids.net/~randraka/multipli.htm] internet, accessed 6 April 2000. Ardekani, R. and Yellowley, I. 1996. The Control of Multiple Constraints Within an Open Architecture Machine Tool Controller. Transactions of the ASME Journal of Manufacturing Science and Engineering 118:388-393 Awad, M., Kuusela, J . and Ziegler, J . 1996. Object-Oriented Technology for Real-Time Systems: a practical approach using OMT and Fusion. New Jersey: Prentice-Hall, Inc. Bailo, C P . and Yen, C .J . 1991. Open Modular Architecture Controls at G M Powertrain: Technology and Implementation. Proceedings of SPIE 2912:52-63. Blair, G. , Gallagher, J . , Hutchison, D. and Shepard, D. 1991. Object-Oriented Languages, Systems and Applications. London: Pitman Publishing. Bradley, W.M. , Kahn, D.M., Rible, J . and Williams, M. 1994. IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices -IEEE Std. 1275-1994. New York: Institute of Electrical and Electronics Engineers. Caffrey, R., Shaw, H. and Wagner, L. 1997. Developing plug-and-play spacecraft 114 systems: NASA Goddard Space Flight Center's (GSFC) Essential Services Node (ESN). AIAA-IEEE Digital Avionics Systems Conference Proceedings 1:2.1-28-2.1.35 Cooling, J .E . 1991. Software Design for Real-time Systems. Cornwall: Chapman and Hall. Dertouzos, M.L., Lester, R.K. and Solow, R.M. 1989. Made in America: Regaining the Productive Edge. Massachusetts: The MIT Press. Dutton, K., Thompson, S. and Barraclough, B. 1997. The Art of Control Engineering. Essex: Addison Wesley Longman Limited. Echanove, M.A.A. and Tombs, J .N. 2000. Design and Implementation of a R A M on the XS40 Board and the Bidirectional Interface with a P C . [resource on-line]; available from http://www.xess.com; internet, accessed 28 March 2000. Eckert, B. 1999. Firmware Factory User's Manual, [resource on-line]; available from http://www.geocities.com/Siliconyalley/Cable/34Z9/; internet, accessed 10 May 1999. Erol, N.A., Altintas, Y. and Ito, M. 1996. Modular Tools for Motion Control and Process Control System Design. Proceedings of SPIE 2912:13-23. Fisher, A.D. 1988. The Development of a Generative Computer-Aided Process Planning Package for the Peripheral Milling Process. M.Eng. Thesis, McMaster University. Forth, Inc. 1998. SwiftForth Development System for Windows, Second Edition. Manhattan Beach: Forth, Inc. Fung, T. 1997. Quadrature Encoder Interface using FPGA. [internal report]; 115 University of British Columbia; Department of Mechanical Engineering. G M Powertrain Group (GMPTG). 1996. Open, Modular Architecture Controls at GM Powertrain: Technology and Implementation, Version 1.0. G M Powertrain Group Manufacturing Engineering Controls Council. Hart, C. 1999. Plug and Play - where's the problem? [resource on-line]; available at http://home.ontherun.com.au/~chanVpnp.htm; internet, accessed 9 January 1999. Koren, Y. 1997. Control of Machine Tools. Journal of Manufacturing Science and Engineering 119:749-755. Koren, Y. and Lo, C.C. 1992. Advanced Controllers for Feed Drives. Annals of the CIRP 41:2:689-698. Laboratory Microsystems, Inc. 1992. UR/FORTH: version 1.1. Marina del Rey: Laboratory Microsystems, Inc. Lundholm, Th. 1991. A Flexible Real-Time Adaptive Control System for Turning. Annals of the CIRP 40:1:441 -444. Lutz, P. and Sperling, W. 1997. O S A C A - the Vendor Neutral Control Architecture. Proceedings of the European Conference on Integration in Manufacturing, Dresden, Germany. 10pp McKewan, A. 1997. Object-Oriented Programming in A N S Forth. Forth Dimensions March/April 1997:14-29. Michaloski, J . 2000. Analysis of Module Interaction in an O M A C Controller. Proceedings of the 7th International Symposia on Manufacturing with Applications (ISOMA), World Automation Congress 2000, Wailea, Hawaii. 116 8pp. Oldknow, K. 1999. FPGA Quadrature Decoder with Signal Conditioning and Velocity-Based Error Checking, [internal report]; University of British Columbia; Department of Mechanical Engineering. Peacock, C. 1999. Interfacing the Standard Parallel Port - 3 r d April 1999. [resource on-line]; available from http://www.geocities.com/SiliconValley/Bay/8302/ parallel.htm; internet, accessed 25 June 1999. Pountain, D. 1986. Object-Oriented Forth. Byte Magazine August 1986:227-233. Pritschow, G., Daniel, CH. , Junghans, G. and Sperling, W. 1993. Open System Controllers - A Challenge for the Future of the Machine Tool Industry. Annals of the CIRP 42:1:449-452. Proctor, F., Shackleford, W. and Yang, C. 1995. Simulation and Implementation of an Open Architecture Controller. Proceedings of SPIE 2596:196-204. Rodriguez, B. and Poehlman, W. 1996. A Survey of Object-Oriented Forths. ACM SIGPLAN Notices 31:4:8pp. Sawada, C. and Akira, O. 1997. Open Control Architecture OSEC-II: Architecture Overview and Prototype Systems. IEEE Symposium on Emerging Technologies and Factory Automation, ETFA '97. Los Angeles:543-550 Schofield, S. and Wright, P. 1998. Open Architecture Controllers for Machine Tools, Part 1: Design Principles. ASME Journal of Manufacturing Science and Engineering 120:417-424. Seethaler, R. 1997. Integrated Planning, Monitoring and Control of Milling Operations. Ph.D. Thesis, The University of British Columbia. 117 Seethaler, R. and Yellowley, I. 1996. The Regulation of Position Error in Contouring Systems. International Journal of Machine Tools Manufacture 36:6:713-728. Sharma, A.K. 1998. Programmable Logic Handbook - PLDs, CPLDs & FPGAs. McGraw-Hill. Sommerville, I. 1995. Software Engineering, Fifth Edition. Essex: Addison Wesley Longman Limited. Sperling, W. and Lutz, P. 1997. Designing Applications for an O S A C A Control. Proceedings of the ASME International Mechanical Engineering Congress and Exposition Dallas: 5pp. Technical Committee X3J14. 1994. American National Standard for Information Systems: Programming Languages: Forth. X2.215-1994. American National Standards Institute, Inc. Teltz, R.W. and Elbestawi, M.A. 1997. Design Basis and Implementation of an Open Architecture Machine Tool Controller. Transactions of NAMRI/SME XXV:229-304. Tung, E.D. and Tomizuka, M. 1993. Feedforward Tracking Controller Design Based on the Identification of Low Frequency Dynamics. Transactions of the ASME Journal of Dynamic Systems, Measurement and Control 115:348-356. Van den Bout, D. 1999. The Practical Xilinx Designer Lab Book. New Jersey: Prentice Hall. Weinert, G. 2000. Java Based Open Architecture Controller. Proceedings of the 7th International Symposia on Manufacturing with Applications (ISOMA), World Automation Congress 2000, Wailea, Hawaii. 6pp. 118 Woehr, J . 1992. Forth: The New Model. San Mateo: M&T Books. Wright, P.K. 1995. Principles of Open-Architecture Manufacturing. Journal of Manufacturing Systems 14:3:187-202. Yellowley, I. and Adey, D. 1992. A New Approach to the Real-Time Optimization of Turning Operations. International Journal of Machine Tools & Manufacture 32:3:453-466. Yellowley, I. and Gunn, E. A. 1989. The optimal subdivision of cut in multi-pass machining operations. International Journal of Production Research 27:9:1573-1588. Yellowley, I. and Pottier, P. 1989. 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:287-292. Yellowley, I. and Pottier, P.R. 1994. The Integration of Process and Geometry within an Open Architecture Machine Tool Controller. International Journal of Machine Tools & Manufacture 34:2:277-293. Yellowley, I., Ardekani, R., Yang, L. and Seethaler, R. 1996. Development of Robust Extensible Architectures for Machine Tool Control. Proceedings of S P / E 2912:72-81. 119 Appendix I: Detailed Description of Low Level Device Methods in VM Axis Controller Model Method Name Stack Diagram and Descript ion D e s c r i b e : (") All classes defined within the Open Configuration System should have a Describe: method. This method is intended for interpretive use by a developer, whether that developer is a vendor or end-user. The Describe: method should result in a textual output via the interpretive interface, containing a description of the class including all methods and stack diagrams. This is intended to increase the practical usefulness of the open software structure. send h e a d e r : (num_stg2 seq_num - fig) The send_header method is used to construct a header that is sent to the axis controller ahead of each series of 1 s t stage interpolation increments. Two values are placed on the stack prior to calling the method. These are num s tg2 , the total number of 2 n d stage increments in the move (double precision number), and seq_num, a single-precision "time-stamp" used to keep track of the current move being executed at the axis controller level. The 120 Method Name Stack Diagram and Descript ion method leaves a flag value on the stack after execution. If the method executed properly, the flag value is zero. If it did not execute properly (this includes execution of the V M object method when no low-level device method has been bound to it), the flag value is non-zero. send i n c r e m e n t : (n-flg) This method is used to send a 1 s t stage-interpolated increment across the communication channel for storage in the logical buffer of the axis controller. Calling of the method results in a single precision number (n in the stack diagram above) being popped from the stack and sent to the axis controller. After the method is finished, a flag is left on top of the stack to indicate normal or abnormal execution. A flag value of zero indicates normal execution. A non-zero flag value indicates erroneous execution (this includes execution of the V M object method when no low-level device method has been bound to it). r e a d p o s i t i o n : (~nflg\flg) This method is used to obtain the current absolute axis position, expressed in base length units (BLU's). It is the responsibility of the calling word to translate the BLU-based expression into a dimensional value through application of 121 Method Name Stack Diagram and Descript ion the appropriate metric (e.g. mm/BLU, in/BLU, etc.). No values are digested from the stack when the method is called, however there are two possible stack conditions after the method is called. If the method executes properly, the absolute position (single precision number) is left on the stack, followed by a flag value of zero. If the method does not execute properly (e.g. it is called before a low-level device method has been bound), then a non-zero flag value (but no position value) is left on the stack. r e a d v e l o c i t y : (~nflg\flg) This method is used to obtain the current axis velocity, expressed in base length units per second (BLU/sec). It is the responsibility of the calling word to translate the BLU-based expression into a dimensional value through application of the appropriate metric (e.g. rad/BLU, mm/BLU, in/BLU, etc.). No values are digested from the stack when the method is called, however there are two possible stack conditions after the method is called. If the method executes properly, the velocity (single precision number) is left on the stack, followed by a flag value of zero. If the method does not execute properly (e.g. it is called before a low-level device method has been bound), 122 Method Name Stack Diagram and Descript ion then a non-zero flag value, but no velocity value, is left on the stack. r e a d a c c e l : (~nflg\flg) This method is used to obtain the current axis acceleration, expressed in base length units per second-squared (BLU/sec 2). It is the responsibility of the calling word to translate the BLU-based expression into a dimensional value through application of the appropriate metric (e.g. rad/BLU, mm/BLU, in/BLU, etc.). No values are digested from the stack when the method is called, however there are two possible stack conditions after the method is called. If the method executes properly, the acceleration (single precision number) is left on the stack, followed by a flag value of zero. If the method does not execute properly (e.g. it is called before a low-level device method has been bound), then a non-zero flag value (but no acceleration value) is left on the stack. r e a d e r r o r : (~nflg\flg) This method is used to obtain the current axis following error, expressed in base length units (BLU's). No values are digested from the stack when the method is called, however there are two possible stack conditions after the 123 Method Name Stack Diagram and Descript ion method is called. If the method executes properly, the following error (single precision number) is left on the stack, followed by a flag value of zero. If the method does not execute properly (e.g. it is called before a low-level device method has been bound), then a non-zero flag value (but no error value) is left on the stack. f l u s h b u f f e r : (-fig) The flush_buffer: method is used to flush the contents of the 1 s t stage increment buffer in the axis controller, resetting all pointers and leaving the buffer empty. Any pending motion increments in the buffer are thus discarded. The method leaves a flag value on the stack after execution. If the method executed properly, the flag value is zero. If it did not execute properly, the flag value is non-zero. r e s e t : (-fig) This method is used as part of the "homing" sequence used to orient the axis at start-up, or in moving the system to its zero position. When called successfully, the absolute position value stored in the axis controller is reset to zero and a flag value of zero is left on the stack. In the case of erroneous execution, a non-zero flag value is left on the 124 Method Name Stack Diagram and Descript ion stack. h a l t : (-fig) The halt: method immediately terminates axis motion by disabling the servo amplifier. The controller then enters a halt state, in which no further motion increments are added. The method leaves a flag value on the stack after execution. If the method executed properly, the flag value is zero. If it did not execute properly, the flag value is non-zero. e n a b l e : (-fig) The enable: method is used at start-up (post-configuration) and to recover from a halted state. When this method is executed, axis motion is resumed by enabling the servo amplifier. The controller resumes normal operation, with motion increments added at the loop-closing frequency. The method leaves a flag value on the stack after execution. If the method executed properly, the flag value is zero. If it did not execute properly, the flag value is non-zero. s e t f i l t e r : ( Tv Kenc 0>des %des ~ fig ) This method is used to set the parameters in the axis controller's digital filter. Four floating-point values are 125 Method Name Stack Diagram and Descript ion placed on the stack prior to calling the word. These are xv the velocity loop time constant (in ms - the servo loop is assumed to be a current-controlled loop with tachometer feedback), Kenc the encoder gain (expressed in BLU/rad), codes the desired natural frequency of the closed-loop system (in Hz) and £des the desired damping ratio of the closed-loop system. Based on this, the set_filter: method determines appropriate values for the digital filter parameters (it may be a PD, PID, Lead/Lag, etc.) and sends them to the controller. As with the other methods, a flag value of zero indicates successful execution. get b u f f e r s t a t : (~nflg\flg) The get_buffer_stat: method is used to determine the current available space in the 1 s t stage increment buffer. The buffer is typically implemented as a circular buffer, i.e. over-filling will result in overwriting motion increments that have not yet been added to the reference position. If successful, the method returns the number of increments that can safely be added to the buffer, followed by a flag value of zero. If unsuccessful, only a non-zero flag value is left on the stack. get l c f r e q : (~nflg\flg) 126 Method Name Stack Diagram and Descript ion This method is used in conjunction with the getjnsratio: method by higher level interpolating tools to determine the appropriate interpolation increments for a given velocity. When successfully executed, the controller's loop-closing frequency (in Hz) is returned as a single precision number, followed by a flag value of zero. If unsuccessful, only a non-zero flag value is left on the stack. get m s r a t i o : (~nflg\flg) This method is used in conjunction with the getjcfreq: method to determine appropriate 1 s t stage interpolation increments for a given velocity. When successfully executed, the ratio of 2 n d stage increments to 1 s t stage increments implemented in the axis controller's 2 n d stage interpolator is returned as a single precision number (e.g. 16, 32), followed by a flag value of zero. If unsuccessful, only a non-zero flag value is left on the stack. get seq num: (~nflg\flg) This method is used to determine the current move being executed at the axis controller level. When successfully executed, the sequence number value (described in the send_header: method) is returned as a single precision number, followed by a flag value of zero. If unsuccessful, 127 Method Name Stack Diagram and Descript ion only a non-zero flag value is left on the stack. 128 Appendix II: Detailed Descriptions of Binding Table Methods Method Name Stack Diagram and Descript ion D e s c r i b e : (-) As mentioned in the Axis V M model method descriptions, all classes defined within the Open Configuration System should have a Describe: method. The Describe: method should result in a textual output via the interpretive interface, containing a description of the class including all methods and stack diagrams. Show t a b l e : (-) This method is used to visually inspect the current state of the Binding Table. The result is a listing of all V M Object methods currently registered in the table, as well as their status (bound/not bound) and, if the status is bound, the device and device method to which a given Object method is bound. Add node: (Avm_obj_str Avm_meth_str - xt_addr) The Add_node: method is used to register a V M Object method in the Binding Table, creating a new Binding Table node in the process. The single cell values Avm_obj_str and Avm_meth_str are the memory addresses of counted strings containing the V M Object name and method name respectively. After execution, the address of the new node's XT cell is left on the stack. The object 129 Method Name Stack Diagram and Descript ion that called the Add_node: method should immediately store this value in an internal variable, and the XT contained at the address should be executed whenever the method is called. Note that when a new node is created, the binding table automatically places a default XT in the XT cell, which has no effect other that returning a -1 flag. F i n d node: (Avm_object Avm_method - n) This method is typically embedded in the configuration stream of a given device. The Find_node: method expects the addresses of two counted strings to be on the stack when it is called, namely the V M Object name and method name. The result is a search of the binding table, returning the node number corresponding to the string values given, or a zero if no match is found or the table is empty. Following this, the B ind j iode: method can be used to bind a device method to a V M Object method. B i n d node: ( Adev_str Amethod xt n -) This method is used to bind a low level device method to a high level V M Object method. Before calling the method, four single-cell (i.e. single precision) values are placed on the stack. The first two are counted string addresses corresponding to the device name and device method name respectively. The third is the XT of the device method. The fourth is the node number to 130 Method Name Stack Diagram and Descript ion which the device method should be bound. Upon execution, the method stores the device method description and XT in the appropriate node within the linked list, and marks the status cell as 'bound'. 131 Appendix III: Detailed Descriptions of SPP Channel Binding Methods Method Name Token Stack Diagram and Descript ion Describe: n/a (-) As mentioned in the Axis V M model method descriptions, all classes defined within the Open Configuration System should have a Describe: method. The Describe: method should result in a textual output via the interpretive interface, containing a description of the class including all methods and stack diagrams. OpenPort: 0x601 (-) Before reading from or writing to any of the parallel port registers, the OpenPort: method must be called (similarly, the ClosePort: method should be called once the port is no longer in use. The method is intended for Open Configuration systems implemented within advanced multi-tasking operating systems (e.g. Windows NT, Windows 98, UNIX, Linux), in which I/O calls must be made through the host operating system. In other operating systems (e.g. DOS, Windows 3.x), 132 Method Name Token Stack Diagram and Descript ion direct writes and reads to and from the parallel port registers are permitted, i.e. the OpenPort: and ClosePort: methods will typically not have any real effect. ClosePort: 0x602 (--) This method should be called once interaction with the Parallel Port has ceased. The method is intended for advance operating system environments as described in the OpenPort: method. ReadStatus: 0x603 (~n) The ReadStatus: method returns a single precision (typically 32-bit) number, of which the least-significant 8 bits represent the current contents of the S P P status register. A comprehensive definition of the status register contents can be found in Peacock 1999. Note that the OpenPort: method must have been called for the ReadStatus: method to execute properly. WriteData: 0x604 (n~) The WriteData: method takes a single precision number from the top of the stack and writes the 133 Method Name Token Stack Diagram and Descript ion least significant 8 bits to the S P P data register. (Again, see Peacock 1999 for a comprehensive definition of the data register). As with the other read/write methods, OpenPort: must have been called in order for this method to execute correctly. WriteControl: 0x605 (n~) Similar to the WriteData: method, the WriteControl: method takes a single precision number from the top of the stack and writes the least significant 8 bits to the S P P control register. (Again, see Peacock 1999 for a comprehensive definition of the control register). As with the other read/write methods, OpenPort: must have been called in order for this method to execute correctly. Detect: n/a (-fig) This method is used to detect the presence of an Open Configuration compatible device connected to the Parallel Port. It must be called before any other operations are done on the parallel port, as the device will only remain in detect mode until its tokenized configuration stream has been retrieved. If no device is detected on the port, a flag value of 134 Method Name Token Stack Diagram and Descript ion zero is left on the stack. If a device is detected, a non-zero value is left on the stack. GetTCS: n/a (fileid-flg) GetTCS: is used to retrieve the tokenized configuration stream from a device that has been detected on the parallel port. The stream is stored in the temporary file identified by fileid (single cell value), ready for de-tokenizing and evaluation. A flag value is left on the stack after execution, with a zero value indicating successful execution and a non-zero value indicating unsuccessful execution. 135 Appendix IV: Tokenized Code Example The following segment of code, written in the object-oriented Forth extension described in Chapter 2, is used to send a first stage interpolated increment to the F P G A Servo Controller over the Standard Parallel Port. This represents the hardware-dependent code accessed via the Binding Table when the s e n d _ i n c r e m e n t : method is called from the Virtual Machine Tool. In this example, the LPT1 parallel port is being used. OpenPort: l p t l \ p u l l RD* and WR* (Control Port [2:3]) high 12 W r i t e C o n t r o l : l p t l \ wait f o r BUSY (Status Port [7]) to go low begin ReadStatus: l p t l 128 and not u n t i l \ l a t c h low-byte address i n t o FPGA 8 WriteData: l p t l 0 W r i t e C o n t r o l : l p t l 12 Wr i t e C o n t r o l : l p t l \ w r i t e low-byte of increment to FPGA dup 255 and WriteData: l p t l 4 W r i t e C o n t r o l : l p t l 12 W r i t e C o n t r o l : l p t l \ l a t c h high-byte address i n t o FPGA 9 WriteData: l p t l 0 W r i t e C o n t r o l : l p t l 12 Wr i t e C o n t r o l : l p t l \ w r i t e high-byte of increment to FPGA 65280 and 8 r s h i f t WriteData: l p t l 4 W r i t e C o n t r o l : l p t l 12 Wr i t e C o n t r o l : l p t l \ wait f o r BUSY (Status Port [7]) to go low begin ReadStatus: l p t l 128 and not u n t i l C losePort: l p t l 0 \ leave "0" f l a g on stack, i n d i c a t i n g s u c c e s s f u l execution Assuming the use of single-byte ASCII representation, and neglecting comments, the code segment above requires 408 Bytes of storage. 136 The equivalent tokenized code stream segment is given by the following series of byte coded values: 0x601 (OpenPort: l p t l ) 0x10, OxOC, 0x00, 0x00, 0x00 (12) 0x605 (WriteControl: l p t l ) OxBl (begin) 0x603 (ReadStatus: l p t l ) 0x10, 0x80, 0x00, 0x00, 0x00 (128) 0x23 (and) 0x34 (not) 0x14 ( u n t i l ) 0x10, 0x08, 0x00, 0x00, 0x00 (8) 0x604 (WriteData: l p t l ) 0xA5 (0) 0x605 (WriteControl: l p t l ) 0x10, OxOC, 0x00, 0x00, 0x00 (12) 0x605 (WriteControl: l p t l ) 0x47 (dup) 0x10, OxFF, 0x00, 0x00, 0x00 (255) 0x23 (and) 0x604 (WriteData: l p t l ) 0x10, 0x04, 0x00, 0x00, 0x00 (4) 0x605 (WriteControl: l p t l ) 0x10, OxOC, 0x00, 0x00, 0x00 (12) 0x605 (WriteControl: l p t l ) 0x10, OxOA, 0x00, 0x00, 0x00 (9) 0x604 (WriteData: l p t l ) 0xA5 (0) 0x605 (WriteControl: l p t l ) 0x10, OxOC, 0x00, 0x00, 0x00 (12) 0x605 (WriteControl: l p t l ) 0x10, 0x00, OxFF, 0x00, 0x00 (65280) 0x23 (and) 0x10, 0x08, 0x00, 0x00, 0x00 (8) 0x28 ( r s h i f t ) 0x604 (WriteData: l p t l ) 0x10, 0x04, 0x00, 0x00, 0x00 (4) 0x605 (WriteControl: l p t l ) 0x10, OxOC, 0x00, 0x00, 0x00 (12) 0x605 (WriteControl: l p t l ) OxBl (begin) 0x603 (ReadStatus: l p t l ) 0x10, 0x80, 0x00, 0x00, 0x00 (128) 0x23 (and) 0x34 (not) 0x14 ( u n t i l ) 0x602 (ClosePort: l p t l ) 0xA5 (0) Represented in this form, the code requires 119 Bytes of storage in device firmware, resulting in a 71 % reduction in footprint through the process of tokenization. 137 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.831.1-0080972/manifest

Comment

Related Items