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 U B C 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 R A M 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  M a n u f a c t u r i n g F u n d a m e n t a l s a n d the N e e d for O p e n A r c h i t e c t u r e s  1.1.1  The Metal Removal Process  17.2  Machining Cost  2  2 4  1.2  T h e s i s Objective  13  1.3  T h e s i s Outline  13  2  Open Architecture Control Systems and Technologies  15  2.1  Introduction  15  2.2  O p e n A r c h i t e c t u r e C o n t r o l s in the M a c h i n e T o o l S e c t o r  15  2.2.1  MOSAIC (UC Berkeley)  76  2.2.2  HOAM-CNC/ORTS  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)  23  2.2.7  OSACA  24  2.2.8  OMAC  26  (University of British Columbia)  iii  2.2.9  OSEC  2.2.10  UBC Open Architecture  2.3  27 Control  System  28  O b j e c t - O r i e n t e d S o f t w a r e S y s t e m s a n d the F O R T H P r o g r a m m i n g L a n g u a g e  2.3.1  Object Orientation  2.3.2  Advantages  2.3.3  Object-Oriented  2.3.4  The McKewan  35 35  in Distributed  Real- Time Embedded  Systems  Forth Extensions Object-oriented  41 43  Forth Extension  44  2.4  O p e n Architecture Firmware S y s t e m s  48  2.5  Field Programmable G a t e Array Hardware Architectures  51  2.6  Summary  54  3  Novel Open Configuration Architecture and Protocol  56  3.1  Introduction  3.2  O p e n Configuration Overview  57  3.3  V i r t u a l M a c h i n e R e p r e s e n t a t i o n of a M a c h i n e T o o l A x i s  60  3.4  T h e Binding Table  63  3.5  T o k e n i z e d Configuration Stream  67  3.6  Communication C h a n n e l Bindings  70  3.7  Summary  72  4  5  Field-Programmable Gate Array (FPGA) Based Servo Controller  6  74  4.1  Introduction  74  4.2  X E S S Prototyping Board  74  4.3  Controller Design Overview  75  4.3.1  Pulse  4.3.2  Backplane  4.3.3  RAM Access  4.3.4  2  4.3.5  Axis Controller  4.3.6  Digital Lead/Lag  nd  Generator  Stage  7  (Parallel  Port) Interface  9  83  Arbitrator  S3  Interpolator  89  Core  91  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 t a n d Integration a n d T e s t i n g  104  4.5  Summary  109  5  Conclusions and Recommendations for Future Work  111  5.1  Conclusions  111  5.2  R e c o m m e n d a t i o n s for F u t u r e 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:  132  Detailed Descriptions of SPP Channel Binding Methods  Appendix IV: Tokenized Code Example  v  136  List of Tables  T a b l e 2 . 3 - 1 . C l a s s structure in the M c K e w a n object-oriented Forth e x t e n s i o n ( M c K e w a n 1997)  46  T a b l e 3 . 3 - 1 . L o w l e v e l d e v i c e m e t h o d s in the V M a x i s controller m o d e l  63  Table 3.4-1. Binding Table methods and stack diagrams  67  T a b l e 3 . 5 - 1 . T o k e n i z e d C o n f i g u r a t i o n S t r e a m structure (as s t o r e d in d e v i c e f i r m w a r e )  68  T a b l e 3.6-1. Standard Parallel Port ( S P P ) Methods  72  T a b l e 4 . 3 - 1 . P C P a r a l l e l Port S i g n a l M a p p i n g  84  T a b l e 4 . 3 - 2 . B y t e - w i d e write-only register m a p  85  Table 4.3-3. PC_status_nybble values  87  T a b l e 4 . 3 - 4 . C u r r e n t - c o n t r o l l e d s e r v o loop p a r a m e t e r s  94  T a b l e 4 . 3 - 5 . S a m p l e filter p a r a m e t e r a p p r o x i m a t i o n t e r m s  98  T a b l e 4 . 4 - 1 . D e s c r i p t i o n of s e r v o test s t a n d c o m p o n e n t s  vi  106  List of Figures  F i g u r e 1.1-1. D i a g r a m of the T u r n i n g P r o c e s s , s h o w i n g d e p t h of cut (a), f e e d per revolution (S) a n d a p p r o a c h a n g l e (v|/)  3  F i g u r e 1.1-2. D i a g r a m of the e n d milling p r o c e s s , s h o w i n g d e p t h of cut (a), width of cut (d), f e e d per revolution (S), s w e p t a n g l e of cut (<t>), tool length (L) a n d tool r a d i u s (R) s  4  Figure 2.2-1. U B C O p e n Architecture Controller Block Diagram  29  F i g u r e 2 . 3 - 1 . S c h e m a t i c r e p r e s e n t a t i o n of a p r o c e d u r a l a p p l i c a t i o n  38  F i g u r e 2 . 3 - 2 . S c h e m a t i c r e p r e s e n t a t i o n of a n object-oriented a p p l i c a t i o n  39  Figure 2.3-3. S a m p l e c l a s s hierarchy  40  Figure 2.3-4.  44  Forth p r o g r a m m i n g l a n g u a g e s y s t e m m o d e l  F i g u r e 3 . 2 - 1 . S c h e m a t i c r e p r e s e n t a t i o n of O p e n C o n f i g u r a t i o n S y s t e m c o m p o n e n t s  58  Figure 3.3-1. U B C O p e n Architecture A x i s Controller Behavioural Model  62  F i g u r e 3 . 4 - 1 . C o n c e p t u a l r e p r e s e n t a t i o n of a B i n d i n g T a b l e in the O p e n C o n f i g u r a t i o n S y s t e m  64  F i g u r e 3.4-2. Linked-list i m p l e m e n t a t i o n of the B i n d i n g T a b l e  65  Figure 4.2-1. Prototype F P G A B a s e d A x i s Controller (Photograph)  75  Figure 4.3-1. F P G A B a s e d A x i s Controller Block Diagram  76  F i g u r e 4 . 3 - 2 . P u l s e G e n e r a t o r top-level s c h e m a t i c  80  F i g u r e 4 . 3 - 3 . P u l s e G e n e r a t o r register transfer level s c h e m a t i c  81  F i g u r e 4 . 3 - 4 . B a c k p l a n e Interface top-level s c h e m a t i c d i a g r a m  84  F i g u r e 4 . 3 - 5 . R A M Arbitrator top-level s c h e m a t i c .  89  F i g u r e 4 . 3 - 6 . S e c o n d - S t a g e Interpolator t o p - l e v e l s c h e m a t i c  91  Figure 4.3-7. A x i s Controller C o r e top-level schematic  92  F i g u r e 4 . 3 - 8 . C u r r e n t - c o n t r o l l e d s e r v o loop b l o c k d i a g r a m  93  F i g u r e 4 . 3 - 9 . C u r r e n t - c o n t r o l l e d s e r v o loop r e d u c e d block d i a g r a m  95  F i g u r e 4 . 3 - 1 0 . L e a d / L a g Filter top-level s c h e m a t i c  99  F i g u r e 4 . 3 - 1 1 . P W M O u t p u t top-level s c h e m a t i c  100  vii  F i g u r e 4 . 3 - 1 2 . P W M to A n a l o g C o n v e r t e r circuit d i a g r a m  100  F i g u r e 4 . 3 - 1 3 . Q u a d r a t u r e D e c o d e r top-level s c h e m a t i c  102  F i g u r e 4 . 3 - 1 4 . F r o n t p l a n e Interface t o p - l e v e l s c h e m a t i c  103  F i g u r e 4 . 4 - 1 . S e r v o test s t a n d block d i a g r a m  104  F i g u r e 4 . 4 - 2 . P h o t o g r a p h of s e r v o test s t a n d  105  F i g u r e 4 . 4 - 3 . V e l o c i t y loop t a c h o m e t e r s i g n a l ( m e a s u r e d a n d t h e o r e t i c a l , with t i m e c o n s t a n t = 10 m s ) . 107 F i g u r e 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 r a m p input  viii  108  List of Symbols  v|/  A p p r o a c h a n g l e (deg)  v  F e e d velocity ( m m / m i n )  a  T a y l o r tool life e q u a t i o n e x p o n e n t , I n c r e m e n t a l a n g l e in c i r c u l a r interpolation (deg)  (3  T a y l o r tool life e q u a t i o n e x p o n e n t  o-  M a x i m u m s t r e s s a p p l i e d to tool s h a n k ( N / m ) 2  max  x  V e l o c i t y l o o p time c o n s t a n t (s)  ^  C l o s e d loop d a m p i n g ratio  Q(s)  A n g u l a r velocity of D C M o t o r shaft ( r a d / s e c )  9(s)  A n g u l a r position of D C M o t o r shaft (rad)  co  C l o s e d loop natural f r e q u e n c y ( r a d / s e c )  0 (s)  A x i s r e f e r e n c e position ( B L U )  <p  S w e p t a n g l e of cut in milling (deg)  n  R  s  a  D e p t h of cut in turning a n d milling o p e r a t i o n s (mm), C o n t i n u o u s - t i m e l e a d / l a g filter parameter  A  D i s c r e t e - t i m e l e a d / l a g filter p a r a m e t e r  b  C o n t i n u o u s - t i m e l e a d / l a g filter p a r a m e t e r  B  D i s c r e t e - t i m e l e a d / l a g filter p a r a m e t e r  BLU  B a s e L e n g t h Unit: s m a l l e s t r e s o l v a b l e position c h a n g e in a C N C s y s t e m  Ci  T a y l o r tool life e q u a t i o n c o n s t a n t  Cf  P W M to a n a l o g c o n v e r t e r circuit c a p a c i t o r v a l u e . (nF)  C,  T o o l c o s t ($)  C  V a r i a b l e m a c h i n i n g c o s t p e r unit length ($/m)  v  d  W i d t h of cut in milling (mm)  D(z)  Digital Filter Z - t r a n s f o r m d o m a i n transfer function  ix  e(k)  P o s i t i o n error in the k  E(s)  P o s i t i o n error in the L a p l a c e ( c o n t i n u o u s time) d o m a i n ( B L U )  E(z)  P o s i t i o n error in the Z - t r a n s f o r m ( s a m p l e d time) d o m a i n ( B L U )  f c  F P G A oscillator frequency ( M H z )  F  x  A p p l i e d f o r c e in the x-direction (N)  F  y  A p p l i e d f o r c e in the y-direction (N)  0S  time interval ( B L U )  G (s)  Z e r o t h - o r d e r hold  h  Equivalent chip thickness (mm)  0  e  l  m  J  e  D C M o t o r a r m a t u r e current (A) E f f e c t i v e polar m o m e n t of inertia reflected to the m o t o r shaft ( K g * m ) 2  k  D i s c r e t e time s a m p l e interval, s p e c i f i c cutting p r e s s u r e ( N / m ) 2  K  A  S e r v o Amplifier voltage/current gain (AA/)  K  D A  Digital to A n a l o g ( D / A ) c o n v e r t e r g a i n ( V / B L U )  Kenc  E n c o d e r feedback gain (BLU/rad)  Kp  L e a d / l a g filter g a i n  K  D C Motor torque constant (N*m/A)  T  Ktach  T a c h o m e t e r f e e d b a c k g a i n (V/(rad/s))  l  E n g a g e d cutting e d g e length ( m m )  e  L  T o o l length ( m m )  M  B e n d i n g m o m e n t a p p l i e d to tool s h a n k ( N m )  N  Spindle speed ( R P M )  R  W o r k p i e c e r a d i u s in turning (mm), tool r a d i u s in milling ( m m ) , r a d i u s of c i r c u l a r c o n t o u r in c i r c u l a r interpolation ( m m )  r  T o o l n o s e r a d i u s (mm)  r(k)  Digital filter output in the k  R(s)  Digital Filter output s i g n a l in the L a p l a c e d o m a i n ( B L U )  R(z)  Digital Filter o u p u t s i g n a l in the Z - t r a n s f o r m d o m a i n ( B L U )  R1  P W M to a n a l o g c o n v e r t e r circuit r e s i s t o r v a l u e . (Q)  th  time interval  x  R2  P W M to a n a l o g c o n v e r t e r circuit r e s i s t o r v a l u e . (Q)  R3  P W M to a n a l o g c o n v e r t e r circuit r e s i s t o r v a l u e . (Q)  R4  P W M to a n a l o g c o n v e r t e r circuit resistor v a l u e . (Q)  R5  P W M to a n a l o g c o n v e r t e r circuit resistor v a l u e . (Q)  R6  P W M to a n a l o g c o n v e r t e r circuit resistor v a l u e . (Q)  Rf  P W M to a n a l o g c o n v e r t e r circuit resistor v a l u e . (Q)  S  F e e d p e r revolution ( m m )  s  L a p l a c e Transform variable  T  T o o l life (min), T o r q u e ( N m )  T t  C o r n e r - p o i n t c a l c u l a t i o n f r e q u e n c y in c i r c u l a r interpolation ( k H z )  c  T o o l r e p l a c e m e n t time (min)  s  T  D i s c r e t e time s a m p l i n g interval (ms)  s  U(s)  S e r v o A m p l i f i e r r e f e r e n c e v o l t a g e (V)  V  P e r i p h e r a l cutting velocity ( m / s e c )  V  Intermediate P W M to a n a l o g c o n v e r t e r circuit v o l t a g e (V)  V  a n a  V V  i g 0  p w m  t  A n a l o g r e f e r e n c e v o l t a g e (V) P u l s e - w i d t h m o d u l a t e d r e f e r e n c e v o l t a g e (V) T a n g e n t i a l velocity in c i r c u l a r interpolation ( m m / s e c )  Vtheoreticai  T h e o r e t i c a l t a c h o m e t e r f e e d b a c k s i g n a l in velocity loop (V)  x  M a c h i n e c o s t rate ($/min)  X, Y, Z  Cartesian Co-ordinates  z  Z-Transform variable  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 manufacturing  industry stands at the heart of the nation's  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. A s 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  4  z  z Spindle Rotation  V  Workpiece  a  X  2T  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) ), tool length (L) and tool radius (R). s  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)  c  t  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 ( R P M 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 t (min) and Ct ($) respectively. s  Now, the variable machining cost per unit length, C ($/m) in both turning and v  milling operations can be represented by the following equation (Yellowley and Gunn 1989). c  = -+ v v x  v  l  x-t +C, s  (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-T -S =C a  (1.2)  p  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 T =  -I -I - V " -S .  (1.4)  a  Ca x  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 by the peripheral cutting velocity, V and v  setting the result equal to zero yields the following result.  c  2  ri-i)  (1.6)  7  Straightforward algebraic manipulation yields the optimum value of tool life, given by: T=  }__Nc.+x-t ^  r  [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  (Yellowley and Gunn 1989).  e  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, l is: e  .  a-r(l-shw)  h =  "  cosy  — +  ^  TC r  j  \2  S + —  (1.10)  In milling, the equivalent chip thickness is given by:  K=— (r0 Sin  n  2  t  h.=-i  0-11)  <t> > 2 n  n  s  t  where n is the number of cutter teeth. If the equivalent chip thickness in the cutting t  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  3  71 • K n  M + (M  2  (1.12)  +r )2 2  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: (1.13)  M = L—  Where F and F are the forces applied in the x and y directions, as shown in Figure x  y  1.1-2. The torque term, T in equation (1.12) can be written as: T =  k-a-v-R-d  (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. A s 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. A s 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. proposed  Open  Configuration  Architecture  and  Chapter three presents a Protocol  reconfiguration of distributed machine tool control systems.  for  the  dynamic  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  2.1  Open Architecture Control Systems and Technologies  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 ObjectOriented Software, Open Architecture Firmware and Field-Programmable Gate Array (FPGA) hardware.  2.2  Open Architecture Controls in the Machine Tool Sector  A s 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 U C 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 M O S A I C - P M system at U C 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  M O S A I C - P M approach was demonstrated via integration into the IMADE C A D / C A M system, which incorporates a Destructive Solid Geometry (DSG) feature-based C A D  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 M O S A I C - P M 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 O S 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  H O A M - C N C system is modular, with an Intel AT486-based System Master coordinating the actions of other processing modules over an industrial ISA bus.  A  Spectrum TMS320C30 DSP-based C N C Master runs a custom-developed microkernel 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 H O A M - C N C 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 D S P s , 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 D S P s 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). 20  For example, process  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 U B C 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 R M X 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 D S P 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 U C 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 nonequivalent 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 P C - A T 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). A s 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 OSAC 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)  A s 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 ( G M P T G 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 ( G M P T G 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 ( G P M T G 1996).  A s 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, C A D 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.  27  The highest  descriptive level is O S E L - F (Feature OSEL), which is a machine independent, feature-based language input. O S E L - 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 O S E L - 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 U B C 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). A s 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. A s 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  Y-Axis Slave (e.g. 80c196, 80x86, DSP)  Servo Amp  Z-Axis Slave (e.g. 80c196, 80x86, DSP)  Servo Amp  PLC Slave (e.g. 80c196, 80x86, DSP)  Spindle Amp  Process Monitor Slave (e.g. 80c196, 80x86, DSP)  Encoder  Encoder  Encoder  3©  E-Stop  Force Sensors  Figure 2.2-1. UBC Open Architecture Controller Block Diagram  A s 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 P L C 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 U B C Open Architecture system due to the use of the stateline approach. The U B C Open Architecture Controller was originally implemented using an 80x86 master communicating with 80c196 axis slaves over an S T D 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. A s 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 D O S (32 bit protected mode), which still proves to be a robust and dependable platform. In addition, the software has been implemented successfully in O S / 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 U B C Open Architecture Control System is designed to be implemented on a variety of hardware and O S 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 U B C 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 enduser, resemble languages more than 'sealed' applications. A s 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 U B C 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  necessarily support the same set of words (Woehr 1992).  systems do  not  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 F O R T H Inc. (FORTH Inc. 1998). In addition, the objectoriented 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 M O S A I C - P M 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  implementation technique was realized (Awad, Kuusela and Ziegler 1996).  to  an  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 objectoriented 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 comparison  to  the  of the approach is likely best gleaned through  traditional  procedural  approach to  systems  design  a  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 data function call 1  function 1  function call n  function n  Data (System State)  Figure 2.3-1. Schematic representation of a procedural application.  In contrast, an object-oriented system is shown conceptually in Figure 2.3-2. A s 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  Object 1 messages  Method 1 Method n  message 1  Data (Object State)  message n  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)  Class: Circle (Subclass/Superclass)  Instance Variables  Instance Variables  Methods  Methods  Class: Triangle (Subclass)  Class: Square (Subclass)  Class: Pentagon (Subclass)  Instance Variables  Instance Variables  Instance Variables  Methods  Methods  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: draw_triangle(xl,yl,x2,y2,x3,y3), d r a w _ s q u a r e ( x l , y l , x 2 , y 2 , x 3 , y3, x4 , y4), draw_pentagon(Xl,yl,x2,y2,x3,y3,x4,y4,x5,y5)  and  draw_circle(xl,yl,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 multiperson 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, realtime 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 Since  the  Forth Extensions  introduction  of  object  programming languages have emerged.  orientation,  many  object-oriented  Examples include the seminal language  Smalltalk, A d a , 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 N E O N 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 A s 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 highlevel details of the Forth programming language.  Data Stack  i  Return Stack  FORTH Dictionary  Code Space  Data Space  Locate  2  Link  Cntrl Bits  Name  Code Field  Parameter Field  Figure 2.3-4. Forth programming language system model.  44  A s 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. system start-up, a core set of words is provided for the user.  At  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  (Cells)  (Cells)  0  8  8 9 10 11 12 13  1  1  1  1  1  1  Name  Description  MFA  Method dictionary (eight-way hashed list)  I FA  Linked-list of instance variables  DFA  Data length of named instance variables  XFA  Width of indexed instance variables  SFA  Superclass pointer  TAG  Class tag field  USR  User-defined field  Syntactically, a class is built as shown in the following listing. single two-dimensional point is used.  The example of a  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 O b j e c t , indicating that the  46  class P o i n t inherits from the root class O b j e c t . 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 P u t : ) . Following this are the definitions for methods to retrieve, store and print the point location values (note that the methods G e t : and P u t : 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 G e t : method defined within the class is called through the statement G e t :  self.  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 definition.  : C l a s s P o i n t <Super Object \ ================================ \ Instance V a r i a b l e Declaration \ ================================ Var x Var y \ ================================ \ Object Method D e f i n i t i o n s \ ================================ :M Get:  (— xy )  Get: x Get: y ;M :M Put:  (xy— ) 47  class  Put: y Put: x ;M ;M P r i n t : Get:  (— ) self  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 o b j e c t P l , d e f i n e d by c l a s s P o i n t \ ==============================================  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 P n P , originally developed by Intel and available on late model Microsoft Operating Systems. P n P is formalized in IEEE 1394.  P n P compatible devices contain an ID number at a  specific location in device R O M (firmware), which uniquely identifies a given device. During start-up, the P n P compatible Operating System probes the device, and uses the ID number to determine the device make, model and version. Based on this, the O S 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 P C ' 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 N A S A ' s Goddard Space Flight Centre, and F O R T H 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. A s 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. A s 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 generalpurpose 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 costeffective 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 P L D 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 A N D gates, followed by an  array of O R 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 P L D 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  A s 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.  A s with C P L D s , multiple  logic blocks are implemented and interconnected on an F P G A .  However, the  resolution, or grain, of these logic blocks can vary from single transistors up to R A M 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 R A M based LUTs into a hybrid structure. Standardization between F P G A s comes in the form of the languages used to design applications for the chips.  programming  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 V H D L . Before coding an F P G A implementation in V H D L , 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. V H D L 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. A s 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 U B C 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 U B C  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). overview of F P G A technology has also been given in the chapter.  55  A brief  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. 56  This has benefits at all stages of  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). dynamic reconfigurability.  This capability provides similar advantages as  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.).  57  This abstracted V M is  coded in the Object-Oriented F O R T H 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.  A s 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  Virtual X-Axis High-Level System Software  Hardware Dependent Methods  Hardware Independent Objects  Virtual Y-Axis  N—H Binding Table  Virtual  H—H <*—H Virtual Process Monitor  T 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 runtime. 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 F O R T H 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 F O R T H 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  U B C 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 U B C Open Architecture provides a behavioural model for an axis controller in the system. A s shown in Figure 3.3-1, the model has the following characteristics:  60  1. A 1 -stage Interpolation Buffer is used to store interpolated increments (typically st  calculated at 1/16  th  or 1/32  nd  of the loop-closing frequency), which are passed  from the system master. 2. The 1 -stage increments are further interpolated by a second-stage interpolator, st  resulting in incremental reference position values calculated at the loop-closing frequency. 3. A n interface is provided for the stateline bus. A s 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. A n axis controller core co-ordinates the actions of the blocks mentioned above, and implements the axis control law.  61  I ' Stage Interpolation Buffer s  Dynamic 2 Stage Interpolator  n d  Stateline Interface  Axis Controller Core  Command Register  Digital Output Filter  PWM/Analog Servo A m p 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  Describe:  (-)  send header:  (num_stg2 seq_num - fig)  send increment:  (n-flg)  read  position:  (-nflg\flg)  read  velocity:  (~nflg\flg)  read  accel:  (-nflg\flg)  read  error:  (~nflg\flg)  flush  buffer:  reset:  (--fig)  halt:  (-fig)  enable:  (-fig)  set  ( Tv Kenc  filter:  get b u f f e r get  3.4  (-fig)  stat:  lcfreq:  &>cfes  )  (~nflg\flg) (~nflg\flg)  get m s r a t i o :  (~nflg\flg)  get  (~nflg\flg)  s e q num:  %des ~ fig  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. A s 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 F O R T H programming  technique of vectored execution.  A s described in chapter 2, the F O R T H  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). XT's.  These C F A ' s are also referred to as execution tokens, or  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 x x x x x x x  Object axis axis axis axis axis axis axis  VM Method enable: halt: reset: send increment: read p o s i t i o n : read v e l o c i t y : read e r r o r :  Status bound bound bound bound NOT bound NOT bound NOT bound  Device servo c o n t r o l servo c o n t r o l servo c o n t r o l servo c o n t r o l [empty] [empty] [empty]  card card card card  Device Method enable x halt x reset x send x increment [empty] [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.  Node#  2  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 X T cell is passed back to the object.  The object then stores the  location in an internal variable, and executes the X T stored at that address whenever the method is called. When a low-level device method is bound to a V M object method, the X T of the low-level device method is passed to the Binding Table. This X T is stored in the appropriate node's X T cell, resulting in execution of the lowlevel 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 X T cell. However, at any time the X T 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 lowlevel 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 F O R T H 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  Describe:  (--)  Show  (--)  table:  Add node:  ( vm_obj_str vm_meth_str  F i n d node:  ( vm_object vm_method - n)  B i n d node:  ( dev_str  3.5  A  A  A  A  - xt_addr)  A  method xt n -)  A  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". similar.  While there are some syntactical differences, the two are conceptually  The overall structure for the series of bytes stored in device firmware is  shown in Table 3.5-1. A s 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  the  tokenized  configuration stream length. 6  length-low-middle  Low  middle  byte  of  configuration stream length.  68  Byte  Name  Description  7  length-low  Least  significant  byte  of  the  tokenized  configuration stream length. 8 through N  tokenized  Tokenized  configuration  Oriented Forth program that defines the low-  stream body  level methods for the device, and results in binding  representation  of the  of  an  device methods  Object-  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.  69  For each available  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, S T D , 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:  lptl  OpenPort:  lpt2  and OpenPort:  lpt3.  When the token for the O p e n P o r t : 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  3.7  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)  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 hardwaredependent 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  A s 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  4.1  Field-Programmable Gate Array (FPGA) Based Servo Controller  Introduction  This chapter describes the design, implementation and testing of a FieldProgrammable 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 X S 4 0 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 F P G A .  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  A s 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. read_position: read_error:  x_axis  send_increment: reset:  x_axis  x_axis  enable: halt:  x_axis  x_axis  x_axis  set_filter:  x_axis  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 F P G A ) over the backplane, while low-level control information (current axis position, current following error, etc.) and status information are passed upwards.  77  A s outlined in section 4.3, the on-board R A M 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 U B C Open Control Architecture outline in Chapter 2. This interface allows each axis to write to and read from the opencollector stateline(s), facilitating the dynamic interpolation mechanism. The overall role of the FPGA-based axis controller then, is to interface in realtime 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.  A s shown, the block has two inputs ( e l k , p u l s e _ a c k ) and one output  ( p u l s e ) . 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.  •  O n 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.  79  [> p u l s e N  pulse_ack  TD:  Controller 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 M u x l 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 R e g l 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 a c k (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 V H D L statement. e n t i t y pulse_generator i s port ( elk: i n std_logic; p u l s e : out s t d _ l o g i c ; pulse_ack: i n s t d _ l o g i c ) ;  end p u l s e _ g e n e r a t o r ;  The internal architecture and signals of the block are then declared as follows: architecture pulse_generator_rtl of pulse_generator i s s i g n a l count, n e x t _ c o u n t : u n s i g n e d (11 downto 0) ; signal pulse_state, next_pulse_state: s t d _ l o g i c ; begin +  -- hardware  d e s c r i p t i o n statements + end p u l s e _ g e n e r a t o r _ r t l ;  (see below)  The multiplexer (Muxl) and comparator (<>3125) used in the clock-dividing portion of the block are described in V H D L as follows. n e x t _ c o u n t <= conv_unsigned (0,12) when count = conv_unsigned count + conv_unsigned (1,12) ;  81  (3124, 12) e l s e  The output from the multiplexer ( n e x t _ c o u n t ) is then used to update the c o u n t 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. process(elk) begin i f e l k ' e v e n t and e l k = ' 1 ' then count <= next__count ; end i f ; end p r o c e s s ;  Similarly, the multiplexer Mux2, register Reg2, OR gate and NOT gate used in the pulse generating portion of the block are defined as follows: n e x t _ p u l s e _ s t a t e <= 'l when count = conv_unsigned ( 0 , 1 2 ) e l s e ' 1 ' when p u l s e _ s t a t e = ' 1 ' and p u l s e _ a c k = 1  •0'  1  0 ' else  ;  process(elk) begin i f e l k ' e v e n t and e l k = ' 1 ' then p u l s e _ s t a t e <= n e x t _ p u l s e _ s t a t e ; end i f ; end p r o c e s s ;  Finally, the value stored in Reg2 is assigned to the pulse output via the following statement. p u l s e <= p u l s e _ s t a t e ;  After generating the appropriate V H D L 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 V H D L . This top-level V H D L 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 subcomponents) is implemented into a bitstream configuration file. The exact format of the bitstream file is dependent on the F P G A , 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 F P G A . 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 lefthand 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  PC_data_by-te  —  PC^status_nybble  —  Port  —/•—&• s-tgl_do.-ta —f> p u s h _ r e q  BUSY - 9 -  —  DATA  —  ADDR  — Backplane Interface  push_ack half _enpt.y_f lag  —6*  flush_req  —  flush_ock  TD: R a n A r b i t r a t o r  tcs_purge_req tcs_purge_ack 15 / 8  t> t c s _ a d d r tcs_byte rst rst.ack H> e n a b l e —  TQ: C o n t r o l l e r  Core  enable_ack  —  position  —  error  Signal  Tops  -f> K p J M Kp_FM  -r> K p A J M - V — B > KpA_FM 4 -V—&• KpA_FBS  TD; L e a d / L a g  Filter  -T*—r> B _ F B S  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  PC Parallel Port Signal  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]  BUSY  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 RAM  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  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  write-only  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 A D D R * 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 1 -stage increment buffer via the RAM Arbitrator (this st  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, detokenized 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  stgl_cfata push_req TO: B a c k p l a n e  Inter Face  push_ock < half_enpty_flag Flush_req  -6—  TQ: 3 2 K RAM RAM Arbitrator  -f>  internalVE  F l u s h _ a c k <3— tcs_purge_req  —  stgl_out  t c s _ p u r g e _ a c k <3—  —  pop_req  TO: 2 n d  Stage  Interpolator  pop_rcly  Figure 4.3-5. RAM Arbitrator top-level schematic.  4.3.4  2  nd  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 B L U , 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 +/- B L U , the interpolated path will still be kinematically correct.  89  This,  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 approach.  interpolation  This method has not been implemented in the F P G A Based Axis  Controller for reasons of gate utilisation. 90  It is, however, anticipated that future  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.  stgl_outTO-  Ran  Artaitrator  10  16  pop_req O pop_rdy  N  Second Stage Interpolator  •f> s " t g £ _ d a t a  h3  stg£_pop_req -£*  TD:  ControUer  Core  stg2_pop_rdy  —f> n o _ i n c r _ a v a i l a b l 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 coordinate the actions of all blocks that are directly involved in the real-time control activity.  This includes the 2  ND  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  stateline_out  TO'  Backplane Interface  rst_ack  £> f  *3-  Second Stage Interpolator  stg2_pop_req  TO-.  PVM  Filter  Output  pwn_enable qdec^position  O-  TCf qdec_reset  stg£_pop_rdy i_incr _a vaiiable  Digital  pwn_opcode  <}•  stg2_data TO:  TO;  f ilter_ack  enable enable_ack  ilter_opcode  Quadrature Decoder  H  pulse  pulse_ack  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. A s 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)  GoK  Us) D  K /J«,s T  P<sJ 1/s  Figure 4.3-8. Current-controlled servo loop block diagram 93  9(s)  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  e (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  R  (V/BLU) U(s)  Servo Amplifier reference voltage (V)  K  Servo Amplifier voltage/current gain (A/V)  A  DC Motor armature current (A)  lm  K  T  Je  DC Motor torque constant (N*m/A) Effective polar moment of inertia, reflected to the motor shaft (Kg*m ) 2  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.  e (s) R  —  +^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„ K -K A  T  (4.4)  • K  tach  while the velocity loop gain, K, is theoretically equivalent to K A - N O W , the D  continuous time transfer function for a lead/lag filter is given by:  m  =  K  • HSL. s+b  (4.5)  95  A s 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  ' J„  K T  (4.6)  K , a c h  This results in an overall closed-loop transfer function given by: ( p-K-  e„c  K  -  K  6_  A -  K  J. K -K- K  (  s +b-s +  p  enc  K  T -  ,ach ^  K  (4.7)  •K •K •K A  T  lach  J., K -K-K p  cnc  K-K-K,,  s +b-s +  s + 1C,co s + co 2  n  n  Where ^  = closed loop damping ratio closed loop natural frequency (rad/sec).  COr  So, by selecting K and b such that: p  b= S  (4.8)  K = ^ - , K-K.,„'  (4.9)  and  p  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 is the sampling interval, or the inverse of the loop-closing frequency s  (Dutton, Thompson and Barraclough 1997), the resulting transfer function is: D(z) = K  . ^  p  z  (4.11)  —B  Where A = \-a-T  s  and B=  \-b-T . s  Finally, this sampled-time transfer function can then be implemented within a digital device (such as an F P G A ) via the following discrete time equation: r(Jfc) = K • e(k)-K p  p  -A • e(k-1) + B• r(k-1).  (4.12)  Where k  = discrete time sample interval  r(k)  = digital filter output in the k time interval  e(k)  = position error in the k time interval  th  th  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 , A and B contain fractional parts. A s mentioned above, multiplication p  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 , KpA and B ) are split into integer and fractional parts. The integer p  multipliers are labelled K p i , K p A | and B | , where "IM" is a mnemonic for "Integer M  Multiplier".  M  M  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 M, F  KpApM and BFM, while the n-bit-shift values are labelled Kp Bs, KpA Bs and BFBSF  F  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. Filter  Integer  Fractional  Fractional  Effective  Parameter  Multiplier  Multiplier  Bit-Shift  Multiplier  Kp*e(k)  K = 69.565  Kp,M = 69  Kp  KPFBS = 4  Kp  Kp*A*e(k-1)  K * A = 69.078  KpAiM = 69  KpA  KPAFBS = 6  Kpeff = 69.0781  B*r(k-1)  B  BFBS = 4  B f = 0.9375  Term  p  P  = 0.94  BIM  =  0  F M  BFM  98  =9 F M  =5  = 15  ef  eff  = 69.5625  A s 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.  error • TD: C o n t r o l l e r Core  10 10  f i l t e r _opcode f i l t e r _ a c k -3-  TO:  PWM O u t p u t  Lead/Lag Filter  Kp_IM —  TQ: B a c k p l a n e Interface  output  -y-—e>  Kp_FM  7^ N 4  Kp_FBS KpA_IM KpA_FM  —N * BH, 4 7^-  KpA_FBS  —EH  B_IM • B_FM  ^—N  B_FBS • CLK-  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 c / 2 . 10  OS  TD: Digital Filter  level  TQ; Controller Core  10 PWM •utput  pwn_opcoc!e • pwn_enable  (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 F P G A . In this stage, an analog circuit is used to convert the P W M signal to an analog signal ranging from +10 to -10 V D C . A s 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 R C 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. A s 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). A s a result, the voltage following the range shifter (V) is given by:  (4.13)  V'=—Vpwm-—(5V). 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 R C network.  The low-pass filter section is designed to convert the P W M signal to a continuously ranging analog voltage by removing the P W M 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;  Controller Core  position Oreset  20 N  Quadrature Decoder  TQ:  Encoder Interface  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 V H D L (Very large scale integrated  Hardware Description Language) for the Xillinx XC40-10XL  FPGA  (Oldknow 1999). In this thesis work, the V H D L 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  internal_stateline_l internal_stateline_2  Frontplane Interface  -f> s t a t e l i n e  out  internal_stateline_n external  stateline CLK-  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 A N D 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).  103  All  input signals are combined through an A N D 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  FPGA Based Axis Controller  Tachometer  Servo Amplifier Coupled Shaft Quadrature Signal  Position Encoder  Figure 4.4-1. Servo test stand block diagram.  104  Figure 4.4-2. Photograph of s e r v o test s t a n d  A s 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  PC  AOpen/lntel Celeron 333 M H z P C running Windows 98 and Forth Inc. SwiftForth ANS-compatible Forth system. XS40-10XL F P G A prototyping board with external P W M  Axis Controller  to analog conversion circuitry. Elenco Precision Deluxe Regulated DC Power Supply,  DC Power Supply  model XP-650. Servo Amplifier  Copley Controls Corp. model 513 servo amplifier.  DC Brushed Motor and  Pittman model 14204B352 30.3 V D C servo motor.  Encoder Electro-Craft Corp. model 138000 DC servo motor.  Tachometer  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:  V  =l2-  lhmrelical  \-e~  .  (4.14)  where T is the first-order lag time constant.  106  ro c cn CO  E o .e o ro  150  50  200  250  T i m e (ms)  — Vtach (V) —  Vtheoretical (V)  Figure 4.4-3. Velocity loop tachometer signal (measured and theoretical, with time constant =10  ms).  A s 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  ~Tir  Kp  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 / B L U 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. A s 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 B L U . Ramp Response (4000 BLU/sec)  0.05  0.1  0.15  0.25  0.2  0.35  0.3  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 F P G A . 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  5.1  Conclusions and Recommendations for Future Work  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 architectures.  "closed" control system  A s 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 U B C 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-thefly" 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 U B C 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 U B C 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. interfaces to the  Standard Parallel Port should therefore  implementation in the F P G A servo controller.  113  Alternative  be examined for  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 F P G A s .  available from http://users.ids.net/~randraka/multipli.htm]  [resource  on-line];  internet, accessed  6 April 2000. Ardekani, R. and Yellowley, I. 1996. The Control of Multiple Constraints Within an Open Architecture Machine Tool Controller. Journal of Manufacturing  Transactions  Science and Engineering  ASME  118:388-393  Awad, M., Kuusela, J . and Ziegler, J . 1996. Object-Oriented Time Systems:  of the  Technology for Real-  a practical approach using OMT and Fusion.  New Jersey:  Prentice-Hall, Inc. Bailo, C P . and Y e n , 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. Languages,  Systems and Applications.  Object-Oriented  London: Pitman Publishing.  Bradley, W . M . , Kahn, D.M., Rible, J . and Williams, M. 1994. IEEE Standard for Boot (Initialization Configuration) Firmware: IEEE Std. 1275-1994.  New York:  Core Requirements  and Practices  -  Institute of Electrical and Electronics  Engineers. Caffrey, R., Shaw, H. and Wagner, L. 1997. Developing plug-and-play spacecraft 114  systems:  N A S A 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 X S 4 0 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.  115  [internal report];  University of British Columbia; Department of Mechanical Engineering. G M Powertrain Group (GMPTG). 1996. Open, Modular Architecture Powertrain:  Controls at GM  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 Engineering  Science and  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  Dresden, Germany.  Conference  on Integration in  Manufacturing,  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  Proceedings  of the  Applications  (ISOMA),  7  th  International  World Automation  116  Symposia Congress  on  Controller.  Manufacturing  2000, Wailea,  with Hawaii.  8pp. Oldknow, K. 1999.  FPGA  Velocity-Based  Error  Quadrature  Decoder  with Signal  Checking,  [internal  report];  Conditioning  University  of  and British  Columbia; Department of Mechanical Engineering. Peacock, C. 1999. Interfacing the Standard Parallel Port - 3 on-line];  available  parallel.htm;  from  rd  April 1999. [resource  http://www.geocities.com/SiliconValley/Bay/8302/  internet, accessed 25 June 1999.  Pountain, D. 1986. Object-Oriented Forth. Byte Magazine August 1986:227-233. Pritschow, G . , Daniel, C H . , 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. SIGPLAN  ACM  Notices 31:4:8pp.  Sawada, C. and Akira, O. 1997. Open Control Architecture OSEC-II: Overview  and  Prototype  Systems.  IEEE  Symposium  Architecture  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.  Engineering  ASME Journal of Manufacturing  Science  and  120:417-424.  Seethaler, R. 1997.  Integrated Planning, Monitoring  and Control of  Operations. Ph.D. Thesis, The University of British Columbia.  117  Milling  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. Proceedings  Designing Applications for an O S A C A Control.  of the ASME International Mechanical  Engineering  Congress  and Exposition Dallas: 5pp. Technical Committee X3J14. 1994. Systems:  Programming  American  Languages:  National Standard for Information 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 7  th  International Symposia on Manufacturing  with Applications  Automation Congress 2000, Wailea, Hawaii. 6pp.  118  (ISOMA),  World  Woehr, J . 1992. Forth: The New Model. San Mateo: M&T Books. Wright, P.K. 1995. Manufacturing  Principles of Open-Architecture Manufacturing.  Journal  of  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. machining  operations.  1989. The optimal subdivision of cut in multi-pass 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. Robust Extensible Architectures for Machine Tool Control. S P / E 2912:72-81.  119  Development of Proceedings  of  Appendix I: Detailed Description of Low Level Device Methods in VM Axis Controller Model  Method Name  Stack Diagram and Description  Describe:  (") 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  header:  (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  st  stage interpolation increments. Two values are placed on the  stack  prior  to  calling  the  num s t g 2 , the total number of 2  n d  method.  These  are  stage increments in the  move (double precision number), and seq_num, a singleprecision "time-stamp" used to keep track of the current move being executed at the axis controller level. The 120  Method Name  Stack Diagram and Description 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  increment:  (n-flg) This method is used to send a 1  st  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 lowlevel device method has been bound to it). read  position:  (~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 Description 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. read  velocity:  (~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 B L U based  expression  application  into  a dimensional  of the appropriate  mm/BLU, in/BLU, etc.).  metric  value  through  (e.g. rad/BLU,  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 Description then a non-zero flag value, but no velocity value, is left on the stack.  read  accel:  (~nflg\flg) This method is used to obtain the current axis acceleration, expressed (BLU/sec ). 2  in base  length  units  per second-squared  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. read  error:  (~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 Description 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. flush  buffer:  (-fig) The flush_buffer: method is used to flush the contents of the  1  st  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 nonzero. reset:  (-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 Description stack.  halt:  (-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 nonzero. enable:  (-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 nonzero. set  filter:  ( Tv Kenc 0>des %des ~ fig ) This method is used to set the parameters in the axis controller's digital filter.  125  Four floating-point  values are  Method Name  Stack Diagram a n d Description placed on the stack prior to calling the word. These are x 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 P D , PID, Lead/Lag, etc.) and sends them to the controller. A s with the other methods, a flag value of zero indicates successful execution. get  buffer  stat:  (~nflg\flg) The get_buffer_stat:  method is used to determine the  current available space in the 1  st  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  lcfreq:  (~nflg\flg)  126  v  Method Name  Stack Diagram a n d Description 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 nonzero flag value is left on the stack.  get  msratio:  (~nflg\flg) This method is used in conjunction with the getjcfreq: method to determine appropriate 1 increments  for a given  executed, the ratio of 2  velocity. n d  st  stage  interpolation  When successfully  stage increments to 1  increments implemented in the axis controller's 2  st  stage  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. g e t s e q 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 Description 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 Description  Describe:  (-) A s 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  table:  (-) 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.  A d d node:  ( vm_obj_str A  vm_meth_str  A  - 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 vm_obj_str and vm_meth_str A  A  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 X T cell is left on the stack. The object  129  Method Name  Stack Diagram and Description that called the Add_node: method should immediately store this value in an internal variable, and the X T 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 X T in the X T cell, which has no effect other that returning a -1 flag. Find  node:  ( vm_object A  vm_method - n)  A  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 i n d j i o d e : method can be used to  bind a device method to a V M Object method. Bind  node:  ( dev_str method xt n -) A  A  This method is used to bind a low level device method to a high level V M Object method. Before calling the method, four singlecell (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 X T of the device method. The fourth is the node number to  130  Method Name  Stack Diagram and Description which the device method should be bound. Upon execution, the method stores the device method description and X T 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 Description  Describe:  n/a  (-) A s 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. method  is  systems  implemented  tasking  intended  operating  for  Open  within  The  Configuration  advanced  multi-  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. D O S , Windows 3.x),  132  Method Name  Token  Stack Diagram and Description 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. intended  for  environments  advance as  The method is  operating  described  in  the  system 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 Description least significant 8 bits to the S P P data register. (Again, see Peacock 1999 for a comprehensive definition of the data register).  A s 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).  A s 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 Description 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. hardware-dependent send_increment:  code  accessed  via  the  Binding  This represents the Table  when  method is called from the Virtual Machine Tool.  the  In this  example, the LPT1 parallel port is being used. OpenPort:  lptl  \ p u l l RD* and WR* ( C o n t r o l P o r t [2:3]) h i g h 12 W r i t e C o n t r o l : l p t l \ w a i t f o r BUSY (Status P o r t [7]) t o go low b e g i n 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 W r i t e C o n t r o l :  lptl  \ w r i t e low-byte o f increment t o FPGA dup 255 and W r i t e D a t a : 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 h i g h - b y t e 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 W r i t e C o n t r o l :  lptl  \ w r i t e h i g h - b y t e o f increment t o FPGA 65280 and 8 r s h i f t W r i t e D a t a : 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 \ w a i t f o r BUSY (Status P o r t [7]) t o go low b e g i n ReadStatus: l p t l 128 and not u n t i l ClosePort:  lptl  0 \ l e a v e "0" f l a g on s t a c k , 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 0x10, 0x605 OxBl 0x603 0x10, 0x23 0x34 0x14 0x10, 0x604 0xA5 0x605 0x10, 0x605 0x47 0x10, 0x23 0x604 0x10, 0x605 0x10, 0x605 0x10, 0x604 0xA5 0x605 0x10, 0x605 0x10, 0x23 0x10, 0x28 0x604 0x10, 0x605 0x10, 0x605 OxBl 0x603 0x10, 0x23 0x34 0x14 0x602 0xA5  (OpenPort: l p t l ) (12) (WriteControl: l p t l ) (begin) (ReadStatus: l p t l ) (128) (and) (not) (until) (8) (WriteData: l p t l ) (0) (WriteControl: l p t l ) (12) (WriteControl: l p t l ) (dup) (255) (and) (WriteData: l p t l ) (4) (WriteControl: l p t l ) (12) (WriteControl: l p t l ) (9) (WriteData: l p t l ) (0) (WriteControl: l p t l ) (12) (WriteControl: l p t l ) (65280) (and) (8) (rshift) (WriteData: l p t l ) (4) (WriteControl: l p t l ) (12) (WriteControl: l p t l ) (begin) (ReadStatus: l p t l ) (128) (and) (not) (until) (ClosePort: l p t l ) (0)  OxOC, 0x00, 0x00, 0x00  0x80, 0x00, 0x00, 0x00  0x08, 0x00, 0x00, 0x00  OxOC, 0x00, 0x00, 0x00 OxFF, 0x00, 0x00, 0x00 0x04, 0x00, 0x00, 0x00 OxOC, 0x00, 0x00, 0x00 OxOA, 0x00, 0x00, 0x00  OxOC, 0x00, 0x00, 0x00 0x00, OxFF, 0x00, 0x00 0x08, 0x00, 0x00, 0x00 0x04, 0x00, 0x00, 0x00 OxOC, 0x00, 0x00, 0x00  0x80, 0x00, 0x00, 0x00  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:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0080972/manifest

Comment

Related Items