u MSU LIBRARIES __ RETURNING MATERIALS: Place in book drop to remove this checkout from your record. FINES will be charged if book is returned after the date stamped below. DEVELOPMENTS IN TRIPLE OUADRUPDLE MASS SPECTROMETRY I. A Distributed Processing Control System II. Screening Applications for Fuel Analysis by Carl Alan Myerholtz A DISSERTATION Submitted to Michigan State University in partial fulfillment of the requirments {or the degree of DOCTOR OF PHILOSOPHY Department of Chemistry 1983 © 1983 CARL ALAN MYERHOLTZ ALL RIGHTS RESERVED ii JSTRHCT DEVELOPMENTS IN TRIPLE puobRURpLE mess SPECTROMETRY I. Q Distributed Processing Control System II. Screening Rpplications for Fuel Analysis Carl filan Myerholtz A dat: acouisition and control system for a triple quadrupole mass spec ctr ometer has been developed using several microproc esws:rs in a d’stribute d pr ocesszino system. This system includes four processors, one actino as the sM/stem mae5ter controlling three slave processors. In such a distribui; ed nroresrinu svstem each p"ocessor" is arsi 13H ned a specific task. Critical to this application is the allocation of the task of data acquisition, ion path control. and peak finding to separate slave processors. This modular approach leads to a system where each major section of the instrument has it’s own dedicated intelligence. This parallel processing system allows operations that are often implemented in hardware (for speed considerations) to be performed in software. For an instrument operating in the research environment, the flexibility of a primarily great benefit. In this [1! software based system is implementation both the hardware and the software become more modular, making it easier to implement and test Carl elan Nyerholt: different data acquisition. peak finding, and scanning algorithms. The use of triple quadrupole mass spectrometry, an MS/HS technique. to detect selected species in middl: 5L: distillate fuels has been examined. Nonparaffinic components, which are mainly aromatic and heteroaromatics containing nitrogen or sulfur. contribute to the formation of undesirable deposits during the storage and combustion are rf particular interest where aviation fuels are concerned. Collision*actiyated dissociation (CGD) spectra were obtained for reference compouncs from several heteroatom~containing compound classes. These included the thiophenec. thiols, nitrobenzenes. pyridines and anilines. The alkylbenzenes were examined in addition to heteroatom-containing species. The CAD results were used to select screening reactions for each compound class. The effectiveness of these screening reactions was demonstrated by identifying the presence of various species in samples of Jet A aviation fuel, a shale oil derived fuel and No. 2 diesel fuel. Triple quadrupole mass spectrometry can be used to rapidly identify a number of different components in middle distillate fuels. This information can be an aid to studies of fuel composition and stability. ACKNOWLEGHENTS I would like to thank Dr. Chris Enke under whose guidance this work was performed, for providing an environment of wreedom and challenge. I thank the fellow members of the research group and the department for making Michigan State a unique place to work. I would like to recognise Dan Sheffield for is contribution to the duality o f man o f t h e f i g u r e s p r e en t ed h e r e . Ffiwieu1c1.al ELHDDCM”t -ftn“ anyesel.f meis tn”cr¢itk3d by» grfiarn:s from the National aeronautics and Space noministrstion (NASA) and Extranuclear inc. Financial support ror the TQHE instrumentation project was provided by the Office of Naval Research (DNR). Finally I would like to express my appreciation to my many friends and my parents for their support during my stay in Michigan. I would especially like to thank Uncle Bruce, Tom Atkinson, George Lucas, the makers of Pepsi~Cola, and a the people at Bangaway Engineering for helping me preserve my sanity and survive this experience. iii TABLE OF CONTENTS QCII::NONLEGV'ENTSIIIUIIIIUIII'lllIIIIIIIOIIIIII-IIIIDIII List Of TabIESIIIIIIIII.IO.IOIIIIIIIII-.IIIIIIIIIIIII List 0+: FingrESIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII Part I. A Distributed Processing Control 8ystem...... Chapter 1. Introduction.............................. URBQNIZHTIBN..... ................................. .. INTRODUCTION TO THE RESEARCH ..... l .................. Chapter 2. Distribution and Coordination of Tasks.... INTRDDUCTIDN ....................................... DISTRIBUTED SYSTEM8................................ SCHEMES OF PARTITIBNINB........ .................... RELATIONSHIPS QMDNG TQSHS....... ............. . ..... GDVRNTQSES OF MDDULQRITY ........ . .................. INTERPRDCESSDR CDMNUNICQTIDN REGUIREMENTS.......... SOFTWARE CDNSIDERATIDNS ........... ......... ........ SYSTEM DESIGN CDNSIDERGTIDNS ...... . ................ REFERENCES ......... . ...... . ......................... iv iii vii M CHAPTER 3. REFERENCE Chapter 4. SDFTwnRE SELECTION QDAPTINB DIRECTINB HGSTER PR Interprocessor Hardware Overview. c.‘ ‘DIIIIIIIIIIIIIINIIIIIIIIIIIIIIInII An Integrated Software System.... SELECTIDN CDNBIDERQTIUNS.... ..... EM: "TFHE irilfifrti LTflhHfiLJflflBEi ESVFBTTZFI.. .. |l FORTH TO 9 DISTHIEUTED ENVIRONMENT........ S L. {31 ".‘III E: {:3 F. {:1 C; E: ET}, :3...) {I} l:;‘ is u I I I I I M I I I I II I I I IIIIIIIII I OCESSOR FORTH EXTENSIOFS......... llllll RESULTS GNU CONCLUSIONS ........... . ................. REFERENCSS... ....... . ....................... . .......... Chapter 5. DESIRABLE DISTRIBUT PARTITIQM MICRDPRDC INTERPROC A Distributed Processing Control System... CCWJTRCK- STTYTEvlirEFVOJHEES..... .... II M 5 II {ED FDRFHXEEKSIFMB SHTBTEHWS. . ....... a ......... ... -. :[l\l[3 ilF: T":TTESiAiES.. . . ................ . ....... . ...... . ESSOR SYSTEM HQHDNQRE ............. . ..... .. E S S D F‘: *I 3:! {:': D lfAJ Ft} [it E II I I 4 I I I I I I I) I ‘-I IIIIIIIIIIIIIII SOFTWARE.... ....................................... CONTROL S IMPLEMENT YSTEN DESIGN CONSIDERQTIONS ............... QTION OF TONS CONTROL FUNCTIONS ........... USER INTERFACE.. .......... .............. ........... USER FROG SUNNQRY.. REFEREN“E' ‘DIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IQAFIAE{ILITYI I II I I I I I I I I I I I I I I I I I I It I II I I I II I I I I I I I I I I I II I I I I I I I I I I I I I I I I I I I I I I I ’-l I I I I .4.‘ I I I I I I; arr-3 -..I..'.. Part II. Screening Applications {or Chapter 6. Screening Aviation Fuels ABSTRACT.........................u EXPERIMENTAL SECTION.............. HEEJL 5 AND D BCUSSION............ CDNCLLSIONB....................... AERiNEHULEfl)GPHENIT3.. ... ... ... ... ... .. HEPERENCUD L.-\JIIIIIIIJIMIIHIIIIIBIIIIUII '1 Fuel Analysie.. for Chapter 7. Screening Fuel; for Selected [X {nil 3': 'I' [til l'\ 1"" "r' n""-..'a_.'|!-.I"I.~'IunIanunnnnn-nnnuulaluuunn. ERPERINENTAL......................L. RESULTS AND DISCUSSION.............. CONCLUSIONS....................... ACHNONLEDBNENTB........JJ......... REFERENCmS........................ Chapter 8. Comments and Suggestions. Appendix A. TQMS Operator's Manual.. vi Thiophenee. 13 H U; fl 4 .41."? J. '_.' 'LJ . ....l 1 If: 'T 4;. UI a I H U! "1 . J— L I ST OF TABLES Titie Advantages of Uietrihuted Proceeeing I n t :r p r" o L: E “-5.; -23 or" If; t". m m u n i .1: a t i on N o d :25; 35 53:-..11111.5it”"./ ril't I:‘CP‘E§ i. c: r“. 138.;1 2. 5. 53 L15 o r d —: U: L‘ Ir:_en*or‘ocxeeseur‘ thamtm’Ff re lJ-saer" er: t 911-31: 1 or. 3.; t o F'O P: T H 3:". d 3:5“. e ..:"-'_::. r‘ .:c3rnr)1 I EH” ~$i3r‘ 1”tii? :n53g31193r' :zr‘CUCtaeéaairir' rh:u1r‘eolse ..ttri..HL»n. r!d & [Lamiw oi Bwefimvm Advantages of Distributed Proceeeimg fiyeteme Modes and Pathe oi Interproceeeor Communication TOMS devices and their mnemonic namee Selected control system commande Daughtere of reference compoumde Matrix of characterietice Thiophenee, recctione. retention timee vi 1 Page l"\ . .4 .lo- .._. m, Ir- . ..,' .__1 U k...»— 1 42 Daughtere a? re¥erence cempdunde 17w rI {-3 5...: m m .55 r” c: ‘F E. c e e n i n g r“ £735.12: t i a n 3: J. ., ‘v‘iii Fioure P; fe-L M H LIST OF FIGURES {itie S15tem with Looselv and Tidhtiz/ihwnvied Tasks .~- ... - p— . .. .. .u. N .. .. ... -_ .. .... .... _.. .... "' -.. ,-. . .l. ' n- .. l. .-. ,0. ”I ... .u .I 1' .._ -. ., V ' .-_ _ .. W. 1.:.t.::: :5: LJ1-:9::X:LJ( [thulfllLllll‘~.miL.l'mM . 2- 5.-.. .4...JL-:. 1/].-121' can: Sample Multiprocessor prodrem Distributed Intelligence Multiprocessor Tooolooies Modular Hardware System Distributed Processing Modules Sample FORTH Program TOMS Control System Block Diagram ~ade C:\ a.) U 1:7 : .7 b.4- Lil DJ CD 1.21:: ~u Fs .‘ 1". ‘ _' n 4'— : "V7 a ‘l u .__u .l m I" .-' I ' M ”T (‘3. l a '.J Parallel Processing Timing Diagram Parameter Editor Display Softhnohs Functional Diuordm ..s55s $3oc5oi:rrMfiefl;rgx f3rc3or7ein to fibfltlitfifi '. a.. .- .. ‘ _.. .. -.. . __ c ‘11! l 3. ’::-H":.“.\ h:- H 1“ I __i [T X l L! 1 "+ I... 7-1 ~1 -3 I L] --.-I..» :"-$e:.-it:~‘ 7-7.... .-..-.1 a; 5'5 2' rrtim J; _ ."--‘. end 721-. .5. ii. .775 :7.i .5. Ftiw Shie.x; 5 a)? {net .5 ufhl Stu5le £311 {itil‘ti.cil.e fi1955CTt:it3ri iifiirii'tcnr'i:iaj C1157c3ni£.tcntnr.anis TENS i n :51: r L...".”.-5:'+:7'. 1.: 3:. il. ...‘.:.;: in: d i .-... of r 3 m "TYEFHE unuuiars Lvsiaci iii iii x'tiirwe 5u755l .551 a Rm... "153 o'r' J .5 t H 9 53h 55.1 e Di 1 :-.:.:".d [Iii eat-e1 {5 us. Parents of €7+ Tor Jet A, Shale Fil, fiiesel Parentg 0+ 91+ tOF Jet H, Shale Uii, LiWTEl Ltnusunf 54 irtwn.3et A, Eduale Dill.l EDiesel L: m U! Lw ‘ oF 46 from Jet A, Diesel Loss of 27 and 17 irom Shale Dil Compound Classes for Future Study lfi? : T _. RA. i‘“ ll] 1' x J ...‘ I’ .' .' e I .... .- 17"? mo .4 PART I. A DISTRIBUTED PROCESSING CONTROL SYSTEM CHAPTER 1 INTRODUCTION M I'_.-,l ORBANI ZATI ON The research covered in this dissertation spans two different areas and the dissertation is divided accordingly. Part I is a description of several instrumentation developments and Part II is a description of the application of triple quadrupole mass spectrometry (TOMS) to hydrocarbon fuel analysis. Part I is mode up oi Chapters 2 through 5. instrumentation developments and applications. Chapters 2 thru 4 deal with the development of the hardware and software oi a distributed processing system for real~time instrument control. The development of a control system tor a triple quadrupole mass spectrometer using this distributed 1‘1 ystem is discussed in Chapter 5. Chapters c.4 7o 9 ID I.“ m ,. '.'l .21 u: and u are presented in manuscript form. Applications of triple quadrupole mass spectrometry to the screening of hydrocarbon fuels for selected species are described in Chapters 6 and 7, which form Part II of this dissertation. These chapters are also presented in manuscript form. Chapter 8 contains comments and suggestions of area for further investigation. The user’s manual for the triple quadrupole mass spectrometer control system is included in Appendix A. This document provides a more complete description of the capabilities of the control system than could have been CLVEFEd in the manuscript format of Chapter 5. INTRODUCTION TO THE RESEARCH The overall objective of the author's resuarch was the development and advancement of laboratorv instrumenta Ff H I: 3 K I related goal was to demonstrate the application of TOMS to the detection of select;d sp ci II! ill s in complex mixtures. Instrument Control Bvstem Development The main focus of the instrumentation work was the development of a distributed processing svstem for real—time instrument control. This work was a collaborative project with Mr. Bruce Newcome. The results and application of this work is described in Chapters 2 thru 5. The duration. complexity, and sophistication of this project make the separate identification of the author’s work and that of Mr. Newcome very difficult. On the first level. it is very simple; all of the software was written by the author. while all of the hardware was developed by Mr. Newcome. However in the synergism generated by many a late night discussion, many of the author’s suggestions were incorporated in the final hardware designs and many of Mr. Newcome's suggestions Ul were incorporated into the software system. In other words, it was a real team effort in the best sense of that phrase. Nevertheless, consistent with our primary responsibilities, the system descriptions contained in this dissertation concentrate on the software aspects of the instrumentation developments. r1 Chapter ; is an introduction to distributed processing and some of the special needs of real-time instrument control systems. Chapter 3 is a brief overview of the hardware system developed as part of the the distributed processing project. In Chapter 4, the development of an integrated software package for program development and operations in distributed processing environment are a: discussed. Software for laboratory instrumentation is an area often overlooked by scientists in the field. Many people fail to look at software and programming languages as tools. This is somewhat due to the fact the software is so flexible it can be bent into just about any shape needed. The suitability of a tool for a job often determines whether or not it is practical to under take a given task. Laboratory instrumentation has made a great step forward by moving from the strip chart recorder to the microcomputer for data acquisition. However the microcomputer acts as only a glorified strip chart recorder if data acquisition is it's only function. The next real _/ (I! breakthrough in laboratory instrumentation needs to be and will be in the software field. It is important when developing new tools for laboratory automation that software capabilities be developed along with improved hardware capabilites. Fuel analysis applications Chapters 6 and 7 describe the application of triple quadrupole mass spectrometry to screening hydrocarbon fuels of selected species. These species are illustrated in Figure 1.1. Heteroatom containing species are present in low-levels in most hydrocarbon based fuels. It has been demonstrated that some of these species are detremental to the storage and thermal stabilities of the fuel. The ability to rapidly identify which spec1es are present in a fuel sample would be a substantial aid to fuel stability studies. The separatory power of TOMS can be used to selectively detect the presence of many, if not all heteroatom-containing species in complex hydrocarbon mixtures. The paper presented in chapter 6 is a detailed study of the determination and confirmation of a screening procedure for thiophenes in jet aircraft fuels. Chapter 7 is intended as an introduction to the application of TOMS for fuels screening and describes the selection' and implementation of screening procedures for several classes of compounds. Figure 1.1 Compou d classes studied in part II. NH3 N02 <1,» CHs-CHz ' ° ° ‘ CHz-SH THIOPHENE PYRIDINE ANILINE NITROBENZENE INDOLE (BENZOPYRROLE) ALKYLTHIOLS CHAPTER 2. DISTRIBUTION AND COORDINATION OF TASKS A Distributed Processing System for Real-Time Instrument Control ‘1. Distribution and Coordination of Tasks Carl A. Myerholtz Bruce H. Newcome Christie 6. Enke Department of Chemistry Michigan State University East Lansing, MI 48824 10 11 INTRODUCTION In recent years advances in computer technology have greatly increased the power and sophistication of mini— and microcomputer systems, while at the same time their cost has been dramatically reduced. As a result, the use of small computer systems in the laboratory for instrument control applications has expanded greatly. Laboratory computer systems were initially used principally to perform data acquisition and preliminary data reduction functions, often acting as little more than intelligent strip chart recorders. As the performance/cost ratio increased. small computers were incorporated directly into laboratory instruments and took on increasing responsibilty for control operations such as temperature programming and scan generation. In addition, the data acquisition and reduction functions increased in sophistication. The results of this evolution are recent-generation instruments which incorporate real—time control and data acquisition systems and which work interactively with the operator to optimize the data resulting from an experiment. Ideally these systems control as many instrument parameters as practical and automatically record these parameters along with the acquired data to create a complete experimental record. However, as powerful as these small processors are, the 12 demands of high speed data acquisition and instrument control can exceed the processing capabilities of a single processor. It is important for instrument control systems to advance beyond these limitation so that they can be applied to larger and more complex instruments where the need for increasingly intelligent instrument control is extremely great. DISTRIBUTED SYSTEMS There are several approaches that can be taken to implement advanced control systems with higher performance than is commonly seen today. One solution to this problem is the development of specialized hardware to solve a specific problem. This approach has several drawbacks among which are the time needed to develop and test the hardware and the difficulty in adapting specially tailored hardware to new experimental demands. A second approach is to employ bigger and faster computer systems that are capable of executing control functions and processing information more rapidly than their predecessors. A problem with this approach is that the increase in computing power becomes more expensive as the level of performance increases. An alternate solution is the use of more than one processor in a system to expand the amount of computing power available to the process.r This results in a distributed processing environment where each processor is a assigned a specific task or set of tasks to perform. Systems utilizing more than one processor typically fall into one of two classes. distributed processing systems and multiprocessing systems. In a distributed processing system, the work load is spread over several processors by assigning a set of tasks to each processor. The processors are not necessarily identical; each may incorporate enhancements such as special interfaces or numeric coprocessors to enable them to per+orm their allotted tasks. In a multiprocessing system the work load is spread over several ”equal” processors by assigning tasks to any unoccupied processor. a number of the advantages of distributed processing systems are listed in Table 2.1(1). SCHEMES OF PART I T I ON I NB Partitioning tasks into separate processors takes a variety forms depending on the functions being implemented and the criteria used to separate tasks. Three of the major forms of task partitioning are: horizontal partitioning, vertical partitioning, and partitioning based on data 'Tab Fa 14 1e 2.1 Advantages of Distributed Processing Systems ster Execution D D O IN Parallel execution Less time spent in ”overhead” * addition of hardware controllers and :DFE Simpler proces depewuhmwt Tsedili<._m _ w><._m MW MW fl mam m:...<._.m I and any slave. Tiis is accomplished with bus switching hardware that puts any 5 ave processor involved in a transfer on hold and connects its local data and address bus to the interprocessor communications bus. When the transfer is comoleted. the slave processor’s bus is released. and program execution in the slave is resumed. U: a vecond interprocessor module supports a method of communication called the command transfer mode. The hardware on this module 'onsists of first-in—first~out (FIFO) buffers {‘1 fi for each slave processor. Each FIFD is 24 bits wide and 3; elements deep and is referred to as a command buffer. The master processor can write data into any slave s FIFO which then can be read out and interpreted by the slave. The low order 2% bits written by the master are stored in the FIFO as data. The four high order nits are hardware contro signals that can be used to immediately reset. hold or interrupt the slave processor. The third interprocessor module provides a communication mode called status transfer. The hardware on this module involves 16 bytes of dual—port memory. Each processor in the system (maximum of eight) is assigned two bytes of status information: one hardware status byte and one software status byte. These are maintained up to date in each computer’s dual—port memory. The hardware status byte for each processor includes such information on the processor as command buffer full or empty, and processor halted. The software status byte is used to synchronize tasks between different processors by using program-driven flags or codes to indicate program status. This hardware and software information on each processor is updated every 4 usec in eich processor s interface through a special status bus, which is part of the interprocessor communications bus. REFERENCES (é)B.H. Newcome, C.G. Enke, Rev. Sci. Inst. Submitted for publication l?84. (7)8.H. Newcome. C.B. Enke. Rev. Sci. Inst. Submitted for publication 1984. CHAPTER 4. AN INTEGRATED SOFTWARE SYSTEM 4(2) A Distributed Processing System for Real-Time Instrument Control 3. An Integrated Software System Carl A. Myerholtz Christie 8. Enke Department of Chemistry Michigan State University East Lansing, MI 48824 41 4.2 The hardware for a distributed processing system for laboratory instrument control has been described earlier(8). This hardware allows control systems to be assembled easily and provides communication and control pathways among several processors in a tightly-coupled distributed processing system. In order to utilize these capabilities effectively, a software environment had to be created which could effectively develop real-time research instrument control applications. SOFTWARE SELECTION CONSIDERATIONS The software developed to operate with this hardware needed to be as well suited for operation in a single processor environment as in a distributed processing environment. Since the hardware provides an easy path for upgrading to a distributed processing system, the software selected also needed to be able to make the transition easily. This constrained our software development to systems that can operate effectively in a small single processor environment as well as a larger multiple processor distributed environment. It is also important that programming language features and structure should be such that transferring a task to a separate processor would not require extensive recoding of existing programs. In addition to it’s suitability for operation in a distributed processing system, the software system should be adaptable to instrument control applications. Real-time instrument control often involves the need to control many specialized interfaces very rapidly. The ability to interact directly with these specialized interfaces and the speed of execution of programs are important considerations. In a research laboratory, experiment design is constantly evolving so that it is important that the control software for an instrument be able to be reconfigured easily to meet new experimental demands. Another goal for our software system was that it provide the user with the ability to develop and test programs destined for the slave processors, load programs into the slaves, and provide methods of accessing the slave processors for debugging purposes. The software environments of the master and slave processors should be as similar as possible, so that programs may be tested on the master processor, where the user can readily interact with the program, prior to being loaded into a slave processor. In a few cases, groups have endeavored to develop from scratch, languages and operating systems designed specifically for distributed processing applications(9),(10). This approach was viewed as too 44 costly and time consuming an undertaking for a scientific laboratory. Instead, only currently available languages and operating systems were considered and evaluated for their suitability and adaptability to the distributed processing environment. What was needed was a language that would operate effectively on small single processor systems, but could easily be enhanced to operate in a distributed ~processing system. SELECTION OF THE FORTH LANGUAGE SYSTEM The high—level programming language FORTH was chosen as the basis for this system(ll)(12),(13). Although FORTH is not a widely used language, it’s popularity has increased steadily since it’s inception. Originally developed in 1968 to control a radio telescope at the National Radio Astronomy Observatory, FORTH is one of the few languages developed for small computer systems with control applications in mind(l4). Implementations of FORTH are now available for nearly all popular microprocessor and minicomputer systems. Some of the implementations include such advanced features as multi-tasking(15) and floating point processor support(16). A FORTH program, or “word", consists of a series of previously defined words. These ”words” are stored with their definitions in a ”dictionary"; definitions for new words are merely lists of previously defined words. when executed, each word (program) performs a function that can be as simple as addition or as complex as plotting an entire graph of acquired data. Even a novice user can write programs (new words) by merely concatenating existing high—level words. All previously defined words, from assembly language to the highest level can be used in any given program. when executed directly, each word acts like a separate program. when used as a command in another program, it it is like a subroutine. A typical FORTH system has several hundred words in the ”vocabulary” of the core system. The modularity of FORTH words is similar to that of distributed processing systems. Simple modules (or words) can be readily combined into complex modules that can be combined into even more complex modules. An unusual feature of FORTH is the use of a push-down stack to pass parameters between words when they are acting as subroutines in a larger program. A push—down stack acts as a Last-In-First—Out (LIFO) buffer; items placed on the stack are removed in reverse order. FORTH uses this parameter stack to pass values between both high level and assembly language routines. Thus the interface to an assembly language routine is no different from that to a high level FORTH routine. 4.5 It’s extensibility, the ability to add new commands to the language, is one of the most powerful features of FORTH. It is generally recognized that high—level languages aid in program development. But, in order to be of significant aid to a programmer, a language must contain those high-level functions that are n_eded for the given application. FORTRAN is an example of a high-level language well suited for numeric processing. FORTRAN, which stands for formula translation, was designed to make computational programming easier. Most control applications do not need a great deal of computation. Instead, they need many spec1alized input/output (I/O) functions and the ability to respond rapidly to real-time events. when FORTRAN is used to program control applications, the special I/O functions often end up being coded as assembly language subroutines. The result is that most of the actual control software is not written in a high—level language. When developing control application software, as in all projects, it is important for the tool to fit the job. Most of the major programming languages available today were originally designed to run on large computer systems and solve numeric processing or data management problems. These more traditional programming tools can be applied to control systems, but this is like trying to use a pickaxe to drive a nail, neither the scale nor the function are quite right for the job. FORTH can be the basis for the development of 47 high-level languages which are specific for each application. In FORTH programming, words build on each other, each new word becoming a higher and higher level of operation. The end result is a high-level language that is specific to the application at hand. As programs for a given level of operation are achieved, these become the "high-level" words for the next level of program capability. This makes programming that application on any level very efficient. Figure 4.1 is a listing of a short FORTH program that illustrates how this comes about. The application to be controlled is a stepper motor that advances 9.25 degrees each time memory location 18 is accessed. Line O is just a comment line to indicate these routines are for the stepper motor. Line 2 defines a new word STEP that fetches (Q) the value from location 10 and then discards (DROP) it. This causes the stepper motor to advance 8.25 degrees. The word STEPS, defined on line 4, pulses the motor n times, where n is the number on top-of—the-stack (TOS). This is done by using the new word STEP and the standard FORTH words DO and LOOP which create a loop that goes from O to n, thus repeating STEP n times. The final word, DEGREES, advances the stepper motor a given number of degrees. It takes the number on TOS as the number of degrees to move and multiplies this by four leaving the result on TOS. This provides the number of 0.25 degree steps desired which the word STEPS then uses to advance the stepper motor. This new 48 O ( STcPPER MOTOR ROUTINES ) 1 2 . STEP 1@ E DROP : 4 . STEPS a DO STEP LOOP : a . DEGREES 4 * STEPS ; 7 8 : DEMO 358 O DO ACOUIRE CR . 18 DEGREES 19 +LOOP ; Figure 4.1. FORTH programming examples illustrating how words build into more and more powerful commands. 49 word DEGREES can be used to create a simple data acquisition experiment that acquires and displays a data point for every IO degrees of stepper motor rotation. Line 8 in Figure 4.1 defines the word DEMO that performs this experiment. A loop is created with the DO and +LOOP words that will go from O to 3&0 by steps of IS. The user written word ACOUIRE acquires one data point and returns it on top of the stack. This value is displayed on a new line with the "CR” and ".” commands. FORTH is a very compact and powerful language system. A basic FORTH system which contains the FORTH compiler, an editor, an assembler, disk accessing functions and terminal I/O routines typically occupies only 8 Hbytes (H=1024) of processor memory. For applications not requiring all of the above features, the FORTH kernel can be reduced to under 1 Hbyte. The small memory requirement of this language system makes it ideal for small microcomputer systems such as dedicated slave processors. In a standard configuration, the FORTH language system incorporates a high-level language, editor, assembler, and operating system functions in an integrated package. It can be a stand—alone system that does not require the use of other software packages or an additional operating system to function. All functions of the editor, assembler, operating system and high-level language are available to the user at all times; there is no need to invoke a separate editor to edit text. An edit command can be issued at any time by the user from a terminal or by a program while it is running; FORTH makes no distinction between the two operations. The major functions of high~level language, editor, and assembler all follow the same rules of form and syntax which makes the system internally consistent and easier to use than non—integrated systems. FORTH allows the user to access memory and input/output (I/O) ports on peripheral devices directly. There is no operating system standing guard (or interfering), between the user and the system hardware. Many I/O tasks can be taken care of in high—level FORTH. In addition, memory and I/O ports can be accessed readily from a terminal, greatly simplifying the testing and debugging of hardware interfaces. Typically programs written in FORTH execute EO-SOZ as fast as their assembly language counterparts. This is much faster than conventional interpretive languages such as BASIC that execute programs hundreds of times slower than assembly language. The speed of FORTH, it’s ability to interact directly with the processor and it’s peripheral devices allow much more efficient use of machine resources than many compiler language systems such as FORTRAN and PASCAL. Availability of source code for the language was also an important consideration since some modification would be necessary to adapt the language to support interprocessor and intertask communication. Source code for FORTH is readily available for most popular microprocessors from a number of vendors. Two of the sources are the Forth Interest Group (FIG) and FORTH Inc. of Hermosa Beach, CA. The Forth Interest Group offers source code for FORTH implementations on a variety of processors for a nominal cost. However, the source code available from FIG has a number of drawbacks for this application. The principal drawback of the FIG implementations is that the basic FORTH system is written in conventional assembly language and requires a separate assembler to generate a FORTH system. Unlike the FIG implementation, the source code for the polyFORTH system from FORTH Inc. was written in FORTH and includes a target compiler that allows one FORTH system to generate a new FORTH system. An additional feature of the polyFORTH system that make it attractive is support of multitasking. Although the polyFORTH system is quite a bit more expensive than the FIG implementations, the performance, target compiler, training support, and other advanced features make it well worth the expense in this application. ADAPTINS FORTH TO A DISTRIBUTED ENVIRONMENT The basic FORTH system which normally operates in a single processor environment had to be expanded to handle the interprocessor tasks of block data transfer, parameter passing, and task assignment. This involved additions to the FORTH system running on the master processor and development of modified FORTH system that would operate within the slave processors. It was also necessary to develop a method of compiling the modified FORTH system and loading it into the slave processors. Compilation of Slave Processor Software The first step in adapting FORTH to a distributed processor environment involved modifications to the polyFORTH target compiler that is executed on the master processor. Several interprocessor memory access words were developed that utilize the direct memory transfer (DMT) hardware to transfer data between the memory of different processors in the system. These words, which are described in Table 4.1, form the basis for the transfer of large blocks of information between processors. Their use follows the sequence: select a slave processor with the #SLAVE command, then transfer data between the master’s parameter stack and the selected slave's memory. Two slave processor Table 4.1. Interprocessor Memory Access Words #SLAVE w select the slave whose number is on top of the stack (TOS) for access by the interprocessor memory operations. I@ - Fetches a 16—bit value from the address specified by the master’s TOS in the slave selected by #SLAVE to the master s stack. I! - Stores the second value on the master's stack at the address on top of the stack in the slave previously selected with #SLAVE. This operation transfers a 16—bit value. ICS - Fetches an S~bit value from the address specified by the master’s TOS in the slave selected by #SLAVE to the master’s stack. I! — Stores the low-order byte of second value on the master’s stack at the address on top of the stack in the slave previously selected with #SLAVE. PSLAVE - Selects the source and destination processors for the IMOVE function. The TOS value is the destination processor number and the second stack value is the source processor number. IMOVE - Transfers n bytes from a source address in the source processor to a destination address in the destination processor selected by the }SLAVE command. Usage: source add, dest add, number bytes IMOVE. control words, RESET and HLD, were developed. These words utilize the control signals provided by the command transfer hardware to reset a selected processor or put a processor into a HOLD state, preventing any program execution. These interprocessor control and access words were used to create a modified version of the target compiler that directly downloads the code into the desired slave processor instead of writing the compiled code to the disk. There are several advantages to having a compiler that directly downloads code into the target processor. One advantage is that the compiler can initialize variables and tables in the slave processor during the compilation process. This eliminates the need for special slave initialization routines which take up memory and are only used once. The devices interfaced to the slaves are all memory—mapped; thus the compiler can also be used to initialize all of them appropriately. Since the compiler interprets code from the disk, the entire specialized initialization procedure may reside on the disk rather than occupy any system memory. For the master processor to instruct a slave processor to execute a selected routine, the master processor should have some knowledge of what routines are available in a given slave. To accomplish this, a word was added to the compiler which records information about selected slave U1 U1 commands into a Slave Command Access Table (SCAT). This new word is called COMMAND and is a FORTH "immediate” word. This type of word is executed at compilation time instead of being compiled and is thus useful in adding new functions to the compiler. When it is executed, COMMAND records into the slave’s SCAT the first three characters of the name, the length of the name, and the code field address of the last word compiled into the slave. This information is later used to direct the execution of a task in a slave processor. DIRECTINB SLAVE PROCESSORS The source code of the basic FORTH system to be used in a slave processor had to be modified so that the slave processor can receive instructions from the command FIFOs. The code that normally interprets commands and data from a terminal was replaced with new code which performs the same function using the command FIFOs. The result is a slave interpreter that operates in the following manner: using the command buffer hardware, the slave monitors the condition of its command FIFO. When the FIFO becomes not empty, the high 8 bits of the 24 bit value in the FIFO are read. A value of one indicates that an immediate control operation using the high four bits was executed. In this case the lower 16 bits are discarded. If the value is two, this indicates that the lower 15 bits contain the code field address of a FORTH word to execute. Control is then transferred to the routine at this address. when execution is completed, control will return to the command FIFO interpreter. A value of three in the high byte of the command FIFO signals that the lower 16 bits are data. This value is then transferred to the slave s parameter stack. This method of moving numeric data to the stack and initiating the execution of a word appears to the rest of the FORTH system to be identical to interpreting text from a terminal. This new command interpreter was installed in such a manner as to preserve the multitasking capabilities of the polyFORTH system. Thus a slave can be running a background task such as an oscilloscope display and still be able to act on new commands sent to it through the command buffers. The slave processors do not possess terminals or disk drives; thus the support code for these devices is not normally down-loaded into a slave. This reduces the basic FORTH slave system to approximately 2 Kbytes. However, for debugging purposes, terminal support software can be loaded into a slave processor to allow a programmer to interact with it directly. Normally the user can directly interact with only the master processor. Since the slave interpreter operation mimics normal operation from a terminal, a programmer may test a routine on the master and then, when it is down-loaded into a slave, he or she can be confident it will behave in the same manner. MASTER PROCESSOR FORTH EXTENSIONS To allow programs running on the master to pass data and commands to the various slave processors, several new words were defined for the master processor FORTH system. The first of these follows the form nPUSH, which pushes the value at the top of the master processor’s stack to the top of the nth slave processor’s parameter stack. This becomes the primary method of parameter passing from the master to the slave processors. The second type of word developed was designed to ease access of variables and arrays in a slave processor from the master processor. It follows the form nLABEL and is used to define a new word on the master processor that when executed selects the appropriate slave with the #SLAVE command and leaves the address of a variable in the slave on the master's stack. The execution of words defined by this command prepares the master processor for use of one of the interprocessor memory access words described in Table 4.1. The third major type of word added follows the form SLn, and allows commands to be passed to a slave in the form of addresses of FORTH words to execute. When executed, a word of this form looks up the code field address for the word that follows it in the Slave Command Access Table for slave n. If the lookvup is successful, the address is transmitted to slave n’s FIFO as a command to be executed. The SLn and nPUSH commands use the status hardware to determine if a slaves FIFO is full or not. If the FIFO is full the command passes control to the next task in the multitasking loop. When control is returned to the command it checks the FIFO status again. this process is repeated until data can be transferred to the slave’s FIFO. A brief example of how some of these commands are used is presented in Figure 4.2. In the code for slave one the word SQUARE is defined. It squares the number on top of its stack. After the definition of SQUARE the word COMMAND appears that causes the compiler to make an entry for SQUARE in the SCAT for slave one. Similarly the code for slave two contains the definition of the word CUBE. On the master processor the word POWERS is defined and it behaves as follows: first it duplicates the number on the top of the stack, then it transfers that number to the stack of slave one and to the stack of slave two with the IPUSH and 2PUSH commands. Then the SL1 command is used to direct slave one to execute the SQUARE function while the SL2 command directs slave two to execute the CUBE function. L'l ~13 SLAVE l: : SOUARE DUP % ; COMMAND SLAVE 2: : CUBE DUP DUP * t : COMMAND MASTER: : POWERS DUP IRUSH EPUSH SL1 SQUARE SL2 CUBE ; Figure 4.2. Sample Multiprocessor Program 60 RESULTS AND CONCLUSIONS Three of the major interprocessor tasks, block data transfer, parameter passing, and task assignment, can easily be accomplished by the use of the new words added to the master processor’s FORTH vocabulary. Tables 4.1 and 4.2 summarize the new FORTH commands that a user needs to learn to develop programs to run in a distributed environment. Block data transfers can be readily programmed utilizing the LABEL commands and the interprocessor memory access words described in Table 4.1. The passing of parameters from the master to the slaves is accomplished by the use of the PUSH commands. Assignment of tasks to the slave processors is made simple by the use of the SL commands and the ability to refer to the slave tasks by name. The use of this type of software system is not limited to the dedicated hardware developed in our laboratory. This software approach could be implemented on any multiprocessor system with shared memory. It would require the development of additional software to emulate the various communications modes implemented in hardware. The specialized communications hardware developed as part of this project offloads some of the burden from the software and offers some time savings, which, when trying to accomplish a great 61 Table 4.2. User Extensions to FORTH and the Target compiler for the master processor. COMMAND - A directive to the target compiler to record information of the last word compiled into the slave command access table. 1PUSH,2PUSH,3PUSH — Transfer the TOS value from the master’s parameter stack to the specified slave's parameter stack. SL1,SL2,SL3 - Direct the specified slave to execute the word whose name follows the SLn command. Example: SL1 + would cause slave one to perform an addition. 1LABEL,2LABEL,3LABEL — Usage: 1LABEL slave-name master-name. Creates a word in the master’s dictionary (master-name) that when executed selects the appropriate slave number for interprocessor memory access and leaves the address of the parameter field of slave-name on the master’s stack. HLD ~ Causes the slave processor whose number is on TOS to be put in a hold state, preventing program execution. RESET - Performs a hardware reset of the slave processor whose number is on TOS. 0‘ M deal of real time instrument control, can be vital. The primary goal of this effort was to develop a programming environment for a distributed processing system that was simple and easy to use. The use of FORTH for program development on both the master and the slave processors makes the system internally consistent and easy to use once the fundamentals of FORTH are mastered. Although a moderate amount of sophisticated systems level programming was needed to develop this system, it is simple and straight forward to use. This system has been used to implement a four—processor system to control a triple quadrupole mass spectrometer. Use of this system demonstrates: the speed of programming, use by novices to design automated experiments, speed of execution and gains of parallel processing, completely modular software that is non-interactive with parallel tasks except where it should be. REFERENCES (8)B.H. Newcome, C.G. Enke, Rev. Sci. Inst. (9)R. Taylor, P. Wilson, Electronics 55, No. 24, 89, (1982) (1@)S.H. Fuller, J.K. Ousterhout, et. a1. Proceedings of the IEEE 66, No. 2, 216 (11)C.H. Moore, Astrom. Astrophys. Suppl. 15, 497, (1974) (12)J.S. James, Byte 5, No. 8, 10B (1980) (13)S.M. Hicks, Electronics, March 15, 1979, p. 114 (14) C. Moore, Byte 5, No. 8, 76 (1980) (15)R.E. Dessy, M.H. Starling, American Laboratory, 21, Feb. 1988 (16)Forth Inc, Hermosa Beach, Ca. CHAPTER 5. A DISTRIBUTED PROCESSING CONTROL SYSTEM 64 New Directions in Computer Control of Chemical Instrumentation: An Application to Triple Quadrupole Mass Spectrometry Carl A. Myerholtz Bruce H. Newcome Christie G. Enke Department of Chemistry Michigan State University East Lansing, MI 48824 66 Advances in modern computing technology have had a dramatic impact on the analytical research laboratory in recent years (17), (18), (19). The introduction of minicomputer systems made it possible to bring computing facilities into the laboratory where the scientist could utilize them directly. Many of the early computer systems performed mainly data acquisition and data reduction functions. As the cost of laboratory computer facilities decreased while their capabilities increased, laboratory computer systems were given more responsibilities. Computers systems were interfaced more intimately to instruments in order to perform control operations such as scan generation and temperature programming in addition to data acquisition and data reduction. Advances in storage technology have allowed greater amounts of data as well as reference libraries to be stored in laboratory computer systems. These systems began to be known as "data systems", and as they were paired up with instruments we began to see terms such as MS/DS appearing referring to the combination of a mass spectrometer and a data system." When the functions of a conventional data system are examined, it can be seen that they can be classified into two general groups: first the real time functions which are involved in instrument control and data acquisition and secondly, the non-real time functions such as data analysis, reference library searching, archival data storage, and 67 tabulation and presentation of results. These two groups have very different requirements in both CPU response time and types of resources needed. The control group requires a fast response time and dedicated interfaces to the instrument while the data analysis group requires large mass storage devices ( e.g. disk and tape drives), graphics display devices, and facilities for hard copy generation (e.g. printers and plotters) and can tolerate a moderate CPU response time. Examining these different requirements suggests that the needs of a data system might be best met by two computers operating in a hierarchical manner(28),(21). The real time functions can be performed by an intelligent instrument control system which can be dedicated to the particular instrument and which will handle all of the instrument control and data acquisition functions. The data analysis functions can be performed by a second system which is configured to handle these tasks in an efficient manner. This scheme allows the data analysis computer to be operated as a multi-user system which can analyze the data from more than one instrument. The cost and capabilities of expensive peripherals can then be shared by more than instrument or function. This distribution of data system functions also allows analysis of stored data and acquisition of new data simultaneously thus maximizing the use of an expensive instrument. In our laboratory we have 68 implemented such an hierarchical system using microcomputers for the intelligent control svstems and a minicomputer for the data analysis system. Modern microprocessors are ideally suited for dedicated control systems since they offer high performance at a low cost. A further advantage of these microprocessors is that they are supported by a large variety of inexpensive LSI (large scale integration) peripherals suc as serial ports, parallel ports, counter/timers, and microprocessor~compatible signal converters. The availability of these low cost interface devices is important since it allows a much larger number of instrument parameters to be controlled at a reasonable cost. The programmable nature of many of these devices is also an advantage since it allow a custom interface to the instrument to be easily implemented from standard devices. Data analysis systems need to be able to support large amounts of storage for both data and reference libraries. Support for languages such as FORTRAN and PASCAL for data manipulation and number crunching applications must be provided as well as multiuser, multitasking operating systems. Graphics capabilities are often added to these systems to aid in data display and interactive data analysis. Relatively xpensive features such as large storage devices, floating point processors, and graphic 69 displays can be most effectively utilized in a multiuser environment, where several users can take advantage of these capabilities at one time. Commercial minicomputer systems such as the PDP-ll series from Digital Equipment Corp.(22) with the RSX-llM operating system are well suited for such applications. Figure 5.1 illustrates the hierarchical system of computing facilities in use in our laboratory. Microprocessor based systems are used to control instruments and acquire data. The data is then passed up to a PDP—ll computer system for data reduction, display and archival storage<23). This computer is also part of a departmentnwide distributed network which allows access to even a greater variety of resources if they are needed. This separation of instrument control and data analysis tasks frees each of the computer systems to provide enhanced capability. Once freed of real—time processing constraints, the data analysis system can be expanded to provide more sophisticated data reduction and retrieval functions. Expert systems utilizing artificial intelligence concepts can be developed. The control system can also grow in sophistication and take on even more aspects of instrument control. Ideally these systems would control as many instrument parameters as possible and record these parameters along with the acquired data to create a complete experimental record. This paper will focus on the control system part of the data system and show how substantial Figure 5.1 - Hierarchial computing facilities illustrating how several instrument control svstems are conn TI =cted to a generalupurpose mini~computer system. The mini—computer (. ill yst:m is equipped with extensive peripherals that stored and display the data from several different instruments. %@ 71 TAPE DRIVE OTHER COMPUTER SYSTEMS GRAPHICS TERMINALS DISPLAY I: DD ID g-E E E , PRINTER -UDDDCI D o a MINI- COMPUTER J DISK DRIVE SYSTEM 000:0 I PLOTTER ~ 3 J ' " ‘Lu—anfgfq FLOPPY DISK [:1 INSTRUMENT INSTRUMENT INSTRUMENT CONTROL CONTROL CONTROL MICRO MICRO MICRO INSTRUMENT INSTRUMENT INSTRUMENT 72 advances in control capability and operator assistance can be achieved. DESIRABLE CONTROL SYSTEM FEATURES As control system tasks evolve from simple data acquisition to full instrument control, an expanded number of capabilities and features are needed to ensure that the Operator and an instrument can effectively interact to produce the best possible results from the experiment. A number of these features are listed in Table 5.1. An example of the desirability of software control of the instrument over simple computer starting or monitoring of existing control hardware is seen in the generation of a scan control signal. In the case of computer-triggered scan generator, the computer can only control the start of a scan whereas software generation of the complete scan signal allows simple linear scans and also logrithmic, square-law, step, recursive, or any other function. Efficiency might be improved by scanning at a fast rate until a signal peak appears then backing up and scanning slowly over the peak. Total generation of a scan control signal by the control system allows any scanning algorithm to be implemented in the future without any modifications to the hardware. \ I Table 5.1. Desireable Attributes for a Control System * Maximum flexibility through programmed software control of the instrument * Appropriate and friendly user interface * Aids in optimization of instrument parameters * Adaptable to changing experimental needs * User programmable for experimental procedures 74 The existence of an appropriate and friendly user interface to the control system is very important since an awkward or difficult user interface discourages operator interaction with the system and leads to higher error rates and increased frustration. A control system may employ a number of devices to interface with the operator such as keypads, terminals, or touchpanels. The choice of device depends greatly of the use of the particular system. Other factors which contribute to a friendly user interface are the use of simple, yet descriptive commands and the provision for more than one method of modifying an instrument parameter. For example, the system might provide a simple command, a video editor, and a menu, any of which could change the parameter of interest. This would allow different operators with a wide range of expertise to effectively operate the instrument. Another feature that helps operator confidence is checking for inappropriate commands and issuing descriptive warning and error messages. An important function of the control system is assistance in or the automation of the optimization of the instrument parameters. The control system can perform this function on a number of levels depending of the needs of the experiment and the ability of the Operator. The existence of tuning aids which allow the operator to interactively optimize the instrument are very helpful when the instrument is performing non-routine experiments and/or when the optimum tuning criteria are not clearly definable. When the optimum or standard performance can be clearly defined by the operator the control system could perform an automatic tuning operation. Another possible feature of an advanced control system is the dynamic optimization of the instrument during data collection using a predefined set of goals specified by the operator. A system which allows for changing experimental needs is useful since this allows the system to expand if new ancillary equipment is added to the instrument or if the instrument itself is modified. By allowing such modifications to the control system, the frustration of using an instrument which is only partially under computer control is avoided. If the hardware of the computer system is modular, new interfaces can be easily added to the system. Equally important is that the software for the system should be open to modification so new interfaces can be integrated into the system. A useful feature for a control system is the ability to define new experimental procedures so that routine analyses can be performed easily and with few errors. It is desirable if the new experiments can be defined by using the normal commands for the instrument instead of a separate command language since this helps minimize the amount of information that must be learned. As instruments become 76 more complex and their control systems become more sophisticated the amount of computing power that is needed increases rapidly. As developed in the next section, one possible way to achieve this increase in computing power is to use several smaller computers connected together as a distributed processing system instead of one bigger or faster computer. DISTRIBUTED PROCESSING SYSTEMS Distributed processing systems offer several advantages over single processor systems(24),(25). Some of these advantages are listed in table 5.2 and can be grouped in three classes: faster execution, independent task execution, and modularity of hardware and software(26). Systems utilizing more than one processor typically fall into one of two classes, distributed processing systems and multiprocessing systems. In a distributed processing system the work load is spread over several processors by assigning a fixed set of tasks to each processor. The processors are not necessarily identical; each may incorporate enhancements to enable them to perform their allotted tasks. These enhancements may include special interfaces, additional memory or numeric coprocessors. This is called static load Table 5.2. Advantages of Distributed Processing Systems Faster Execution * Parallel execution * Less time spent in “overhead” % Simpler addition of hardware controllers and pF'DCt-ESFSCJF‘FS Independent Task Execution * Non—interference of tasks * Elimination of task interleaving programs * Elimination of priority assignment programs * Simpler task program modification Modularity of Hardware and Software * Consolidation of related tasks * Simpler extension of instrument capability * Simpler debugging and troubleshooting \I 0] sharing, where assignment of a task to an individual processor occurs during the design phase. In a multiprocessing system the work load is spread over several "equal" processors by assigning tasks to any unoccupied processors. This is called dynamic load sharing, where assignment of a task to a processor occurs during program xecution. Systems utilizing more than one processor can be loosely or tightly coupled(27). These terms refer to the method of communication the processors use to pass information. Loosely coupled systems use shared peripherials to pass messages, while tightly-coupled systems use shared memory to pass messages<28). Multiple processors systems can be interconnected in a variety of ways(29),(3@),(31). Several of these interaction schemes are shown in Figure 5.x. In our laboratory we chose to implement a distributed processing system utilizing a global bus structure as the principal means of interprocessor connection(32). The bus structure developed can support one master processor and up to seven slave processors. The master processor is equipped with interfaces to interact with the user and to direct the operations of the slave processors. The slave processors possess the interfaces to the instrument, but cannot interact with the user directly. .5er I." "'I Figure a.z - Some of the more common multiprocessor topologies BIZI PROCESSING ELEMENT COMMUNICATIONS ~—~ . SWITCH RING STAR \‘K 7/ INTERPROCESSOR BUS I MEMORY] MASTER SLAVE SLAVE SLAVE SHARED GLOBAL MEMORY BUS 81 PARTITIONINS OF TASKS The partitioning of tasks into separate processors takes on a variety forms depending on the function being implemented and the criteria used to separate tasks. Three of the major forms of task partitioning are horizontal partitioning, vertical partitioning and partitioning based on data access<33). Two tasks can be horizontally partitioned if they can be executed without regard to order or can be executed concurrently. Vertical partitioning involves the separation of tasks that have predecessor-successor relationships. These relationships may arise from data dependency or control flow considerations. Partitioning based on data access separates tasks by what data they operate on. Temporal order, control and direction of data flow are not considered. Since most tasks involved in real—time instrument control have some form of predecessor-successor relationship, efforts were directed toward developing a distributed processing system utilizing vertical task partitioning. This required the development of efficient communication links between the processors. Vertical partitions in real-time systems can be classified into three major types according to transform concepts proposed by Yourdon and Constantine(34): afferent, central, and efferent. In afferent data flow an input stream is prepared for internal processing. This involves such actions as acquiring data points, signal processing (averaging), formating and conversions necessary to transform the data into a usable form. Efferent data flow involves the preparation of internally computed data for output transmission. Efferent transforms perform the conversions, scaling, and formating necessary to present data to the output interface (display, DAC, printer, etc.) in the required form. Central transforms are those between the afferent and efferent data types. These central transforms are where the main data processing, such as peak finding, of the system take place. The afferent/central/efferent partitions may indicate classes of tasks that can be separated into different processors. MICROPROOESSOR SYSTEM HARDWARE A system of modular microcomputer components was developed to aid the construction of laboratory control systems(35). In this system each function (CPU, memory, ADC, parallel interface, etc.) is implemented as a separate module. These modules are interconnected by mounting them on a "motherboard". Several motherboards can be connected t-gether by plugging them into a backplane module. The structural relationships of these system elements is shown in Figure 5.3. To date, more than 28 function modules have been developed for this system, including two CPU modules (Intel 8885, SBSS(36)), three types of DACs, parallel and serial interfaces, an analog multiplexer, a programmable gain amplifier, and a 12—bit ADC. Figure 5.3 contains all the essential modules for a small control system. Several advantages arise from the use of such a system to implement the necessary computer hardware for a control application. One is that a system can be implemented with only the needed functions. There are no multifunction boards that require the space and price of the functions when only one of the functions is needed. A second advantage of a flexible modular system is the ease of expansion and upgrading. Experimental demands in the research environment are constantly changing. The ability to incorporate additional modules to extend areas of the instrument operation that are under computer control is important. The capabilities of an existing control system can be expanded by the addition of modules which add more memory, graphics display capabilities, or an advanced numeric processor. Common functions such as "chip-select" logic can be implemented on one module for use by all the other modules on each motherboard. This reduces the board size and the complexity of other modules. By minimizing the complexity Figure 5.3 ~ A small control system modular microprocessor hardware system hardware hierarchy of mounting function motherboards and plugging the motherboards into to complete a system. illus using the trating the modules on a backplane K{PBACKPLANE NCTION MODULES FU J/” is MOTH E RBOARDS of these modules custom interfaces for special applications may easily be developed. This hardware system has been utilized to implement an number of small control systems in our laboratory<37),(38), (39). INTERPROOESSOR HARDWARE Additional modules were developed for this system to allow pr‘cessors to be linked together to form a distributed processing system (Figure 5.4). These modules implement three paths of communication which are used to support the interprocessor communication modes outlined in Table 5.3. The first interprocessor module (Figure 5.4A) supports a direct memory transfer communications path. This hardware allows transfers between the master processor and memory on any slave. This is accomplished using bus switching hardware which places any slave processor involved in a transfer into a hold state and then connects the slave processor's address and data bus to an interprocessor communications bus. When a transfer is completed, the slave processor’s bus is released, and program execution in the slave is resumed. This hardware is used to implement the block transfer of data between processors and to load software into the slave processors at system startup. \J 0'] riqure 5.4 — Block diagrams of the interprocessor communication modules. A) the bus switch module used to implement the direct memory transfer path. 8) The 2 command FIFO buffers. C) The status hardware which maintains ui ;tatus information on all processors in each processors IIIEeI'I’IIiL'Ir"‘7’ . 88 SLAVE MEMORY MASTER INTERPROCESSOR / SLAVE PROCESSOR BUS CPU BUS SWITCH (A) (r LU LI. u. D m C u. IL INTERPROCESSOR BUS MASTER (B) STATUS MASTER SLAVE I SLAVE 2 INFORMATION HARDWARE MASTER SOFTWARE 93 93 93 HARDWARE HALTED HALTED HALTED SLAVE I SOFTWARE 7 HARDWARE FIFO FULL FIFO FULL FIFO FULL SLAVE 2 SOFTWARE 47 47 47 l fl [_ A STATUS BUS (C) Table :39 -_r 5.a. Modes and Paths of Interprocess-r Modes of lnterorocessor Communication it Al's . Block data transfer .aed: assituwnent Parameter transfer .ask coordination C. ommunica Hardware Paths for Interprocessor Communication .‘g'a Direct nmwmmny trans" .,'r er 1:) om m a n d t r a n s f e r Statcs transfer If. 1 till I’I 90 The second interprocessor communications path supported in hardware is called the command transfer path (Figure 5.48). This path is implemented as a set of first—in-firstfout (FIFO) buffers for each slave processor in the system. Each FIFO buffer is 32 elements deep and is referred to as a command buffer. The master can write data into any slave's FIFO buffer, which can then be read out and interpreted by the slave. In addition to the command FIFO buffer this module provides control lines that allow the master processor to reset, hold or interrupt a slave processor. The task assignment and parameter passing functions needed for interprocessor communication are implemented utilizing this hardware module. The third interprocessor module provides a communications path called the status transfer (Figure 5.4C). Each processor in the system (maximum of eight) has one of these modules which contains 16 bytes of dual—port memory. Two bytes are assigned to each processor: one for hardware status and one for user definable software status. Each processor's hardware status byte includes such information as command buffer full or empty, and processor halted. The value of the software status byte can be written by application routines to indicate what function is under execution or when a task has been completed. These values are updated every 4 usec through a portion of the interprocessor communications bus called the status bus, so that any change of status information in the system is known by all processors within 4 usec. This module provides the principal means of interprocessor task coordination. SOFTWARE Once this efficient modular hardware system was developed, it was necessary to develop a software operating environment that complements the capabilities of the hardware. The attributes of a good laboratory language have been discussed in some detail in references (40) and (41). In our laboratory we have chosen to use the high—level programming language FORTH (42),(43),(44) to develop instrument control applications. FORTH implements many of the attributes of a good laboratory language. Among FORTH’s more important features are its small size, its ability to directly access machine resources, and its extensibility. 9 standard FORTH system containing the FORTH compiler, an editor, an assembler, disk access functions and terminal I/O routines typically occupies only 8 Kbytes (K=1@24) of processor memory. For applications that do not require all of the above functions, the FORTH kernel can be reduced to under 1 Hbyte. This small size makes FORTH well suited for small control system where FORTH can be programmed into read~only memory (ROM) so that it is available upon system powerup. The standard FORTH system implements all of the functions necessary for program development. Thus each FORTH based instrument can be programmed without the use of additional software packages such as cross compilers, and without the need for a separate development system. FORTH allows the user to access memory and input/output (I/O) ports on peripheral devices directly. There is no ope-ating system standing guard, or interfering, between the user and Fi‘ h IU U1 U! y tem hardware. This is important in instrument control applications where much of the work is interfacing to and operating non-standard peripherals. Many I/O tasks can be taken care of in high—level FORTH. In addition, memory and I/O ports can be directly accessed from a terminal, greatly simplifying the testing and debugging of hardware interfaces. FORTH is an extensible programming language, one to which new commands and structures can readily be added. A FORTH program, or ”word”, consists of a series of previously defined words. Each word performs a function such as multiplication, fetching data from memory, acquisition of a data point or plotting a set of acquired data. When executed directly, each word acts like a separate program or function of the system. When used in defining a new "word" or program, existing words act like subroutines in languages such as FORTRAN. A typical FORTH system has several hundred words already defined in it’s ”vocabulary”. Programs are III [1| . sily written, even by novice users, by merely concatenating existing words: and in the process, a new, higher—level word is added to the vocabulary. An unusual feature of FORTH is the use of a push-down stack to pass parameters between words. A push-down stack acts as a Last—In—First-Out (LIFO) buffer; items placed on the ‘tack are removed in reverse order. FORTH uses this parameter stack to pass values between both high level and assembly language routines. Thus the interface to an assembly language routine is no different than to a high level FORTH routine. whenever a number is entered on a command line it is pushed onto the top of the stack. In FORTH programming, words build on each other, each new word becomes a higher and higher level of operation. The end result is a high—level language that is specific to an application, which makes programming that application more efficient. Figure 5.5 is a listing of a short FORTH program that illustrates how this comes about. The application to be controlled is a stepper motor that advances 6.25 degrees each time memory location 10 is accessed. Line O is just a comment line to indicate these routines are for the stepper motor. The definition of a word is begun with a ":” followed by the name of the new word. The definition of a word is terminated by a ";”. Line 2 defines a new word STEP that 94 B ( STEPPER MOTOR ROUTINES ) 2 : rTEP 19 a page ; DEGREES 4 * STEPS , Figure 5.5. FORTH programming examples fetches (O) the value from location IO and then discards it (DROP). This causes the stepper motor to advance 9.25 degrees. The word STEPS, defined on line 4, pulses the motor n times, where n is the number on top—of—the-stack (TOS). This is done by using the new word STEP and the standard FORTH words DO and LOOP which create a loop that goes from O to n, thus repeating STEP n times. The final word, DEGREES, advances the stepper motor a given number of degrees. It takes the number on TOS as the number of degrees to move and multiplies this by four leaving the result on TOS. This Drovides the number of O.25 degree steps desired which the I _ . word STEPS then uses to advance the stepper motor. This modularity of software complements the modularity of the hardware, where small simple components can be readily combined together to perform a complex function. For operation in the distributed processing environment, a modified version of FORTH was developed for operation on the slave processors. First the editor, assembler, and disk access functions were removed since they would not be needed on the slave processors. This reduced the size of the basic system to less than 4 Hbytes. The standard command interpreter was then modified to accept commands and parameters from the command buffer FIFOs. Extensions were made to the FORTH system running on the master processor to allow the master to download code into the slave processors, perform interprocessor memory 96 transfers and direct the execution of tasks in the various slave processors. This yielded an integrated system where all processors are prog‘ammed in a common language with little deviation from single processor implementations of FORTH(4S). CONTROL SYSTEM DESIGN CONSIDERATIONS One of the first considerations in designing a control system is the determination of the useful dynamic range of data that the instrument can produce. In many cases the dynamic range of the instrument is not limited by noise from the detector or the electronics but is limited instead by "chemical noise" in the system. This noise results from the chemical background in the sample being analyzed. One method of increasing the dynamic range of the instrument is to add more than one dimension of selectivity. An example of this is the use of chromatography to separate the sample in time before it is analyzed by the instrument. In the triple quadrupole mass spectrometer there are two stages of selection which results in a usable dynamic range on the order of 10°. That is, it is possible to have a noise level that is eight orders of magnitude below the level of maximum usable signal. When a gas chromatograph is used with the triple quadrupole mass spectrometer, a mass scanning ‘ate of lOOO amu/sec or greater is desirable to give adequate resolution of the BC profiles. At these scanning speeds analog current measurement techniques are used with a resulting dynamic range of from it?):5 to 1E6. This range is limited by ion statistics at the low end and detector saturation at the high end. Other sample introduction techniques that provide a 1 ss transient sample allow slower scan rates. At slower [Ii scan rates, pulse counting techniques can be used to extend the dynamic range to its full value of 163. This wide dynamic range must be reflected in the number repr-sentations and peak finding algorithms so that significant data is not lost. The triple quadrupole mass spectrometer also provides a challenge to the designer of the control system because of the large number of parameters that need to be controlled. These devices are listed in Table 5.4 along with the simple mnemonic names that have been assigned to them. The TOMS instrument is capable of operating in three different ionization modes: electron impact ionization, positive chemical ionization, and negative chemical ionization. It can rapidly change between these different modes under computer control. This provides an added level of complexity since the Optimum value of all of the devices may be different for each of the different ionization modes and Table CIV E x T 13-1. f .. "DEF-'15 deviccu IL! 1,1 .... r...‘ I .., r. Electron energy Repeller El ion volume CI iCMW'volume Extractor lens l Ion source IUMi-source lens 2 ~....... ICNI EOLHIJ: IthBFCflJad Interquad Ouad 1 DC rod offset 43 LT and their mneumonic N {3| H E M H v H 1 H3 H3 ONE R83 names OTVICE Quad Ouad Multi i‘." 9 '.... ~- ...\ \. .... EL! Ouad Ouad Mass Mass Ouad Quad 3 DC rod offset plier high voltage selected by quad 1 I’d selected by quad selected by quad ; 3 delta mass 3 resolution thus the control system must be capable of storing the desired device settings for each the mode. To achieve optimum performance the value of some of the devices should be changed as the mass command is scanned. This tracking of 1 d1 E‘VEFc ij‘l ii I U vices with mass increases the demands put on the control system since it increases the number of calculations that must as performed in real time as the data is acquired. Other capabilities that are needed in the control system are the ability to view the raw ion signal in real time and the need to display the data that the control system has acquired. The display of the raw ion signal is very important for proper tuning of the instrument. The control system needs to offer a number of aids to the operator so that the TOMS instrument can be interactively tuned using the judgment of the user to optimize the instrument for the experiment. The ability to display the acquired data allows the operator to adjust the acquisition parameters so that the data is collected properly and also permits the course of an experiment to be monitored. Utilities for managing the data that the system acquires are also important features of the control system. 10% IMPLEMENTATION OF TOMB CONTROL FUNCTIONS An examination of the tasks involved in controlling a TOMS instrument led to the identification of three major groups of functions; ionpath control, signal acquisition or detection, and signal processing (peak finding)(46). These functions correspond to the efferent, afferent, and central types of vertical partitions discussed earlier. The initial decisions of how to partition functions among processors in a distributed system are the most critical in determining overall system performance and capabilities. A distributed processing system utilizing four Intel BOSS processors was implemented to support these partitioning decisions. In this system one processor acts as the system master and the other three are operated as dedicated slave processors. Figure 5.6 illustrates the interconnection of the master to the slave processors and the connections of the slave processors to the instrument. The horizontal arrows between the slave processors represent the status communication hardware which is used to synchronize the slave processors during scanning operations. The double-ended arrows connecting the master to the various slaves indicates the path of data transfer through which the master can directly access the memory in each slave. Finally, commands and parameters are transferred from the master to each slave through the command buffers Figure 5.5 ~ Diagram of the distributed processing control system for a triple quadrupole mass spectrometer consisting of one master processor and three slave processors. The various arrows illustrate communication paths discussed in the text. 102 .._1mOI mmFZEQ mxma 1__mw._. mommmoomd mmkmflz mDm ZO_H_mo mommmocmmmmfiz N A. 111 . 1. a. 2...... a 1111 11 ...... 1 m 1%! vi... o..:u m ON_ 248ml momhmxxmw 238 M 0. E11 mmmxh m 1.6.911, com a 49v L. w 14 v MAN .11-me.vl1 L v m m><1.m _ m><1.m Zofiumemo 825 oz_oz_11_ vaun. 925 15$ 20_ 1 - -. .- 1 - - .1 - 1 H 1111111 film--. 1 1.1H..1.1M.1,,11..w1-~ 1 .1 1 1 1 1a 1111111 1.11Hfi - 1 1 1 ._ 183 depicted as a series of small boxes between the master processor and each slave processor in Figure 5.6. All of the communication between the instrument and the outside world is provided by the master processor. The master processor supports a number of devices in order to carry out its role. A CRT terminal and keyboard are provided as the primary means of interaction between the operator and the instrument. The master processor accepts commands from the operator and directs the operation of the slave processors to carry out these commands. A printer is provided so that the operator can obtain a permanent record of results and system parameters to consult during the course of an experiment. An 8 Mbyte winchester disk is utilized to store data acquired during an experimental session. 9 link to a “host” minicomputer allows data to be directly transfer to the ”host" upon completion of an experiment. An 8—inch floppy disk is provided to allow different operators to maintain their own sets of instrument parameter settings and pre-defined experimental procedures. The master is the most complex processor in the system and as a result contains the largest amount of memory, a total of 48 Kbytes. A basic FORTH system programmed into EPROM (eraseable programable read only memory) occupies 8K bytes of this memory space, leaving 40K available for control software and data space. 1E4 The ionpath processor performs all of the efferent functions of the control system. It contains interfaces to provide all of the output signals needed to control the instrument. These interfaces consist mainly of digital—to—analog converters to provide control voltages and a few bytes of parallel output to control the mode selection of the ionizer and quadrupole controllers. All of the DACs have 12~bits of resolution and provide a +/- 10 volt output range with the exception of the DAC’s controlling the mass selection of quadrupoles one and three. The mass control DACs have 16-bits of resolution and an output range of 0-10 volts. In addition to many interfaces, this processor is provided with 32 Hbytes of RAM (random access memory) for programs and calibration tables. The software to run the ion path slave is loaded into its memory by the master DFDCESSDI’" - One of the main functions of the ionpath slave processor is to perform the transformation of information from a value in a given set of units to a number to send to a DAC to generate the desired value in the instrument. The ion path slave accepts values in experimental units (mass, volts, etc.) from the master, performs the necessary transformations and outputs the result to the instrument. The master is never directly involved in setting instrument parameters and never needs to deal with the values in any other terms than volts or mass. The second function of the ion path slave is the generation and control of the scanning functions. This is a logical task for this processor since it has local control over the entire instrument. The ion path slave accepts information from the master processor such as: type of scan, range to be canned and mass step increment to use, and U! scanning rate. The slave processor then sets up the specified instrument conditions and generates the desired scanning function. During the course of the scan the ion path slave coordinates the advancement of the scan with the operation of the other slave processors. The ionpath slave also signals the completion of the scan to all other processors. The detection slave processor performs the afferent functions of data acquisition and formating. This processor controls the interfaces that convert the analog output of the instrument into a digital form. The principal function of this processor is to a acquire a data point. It performs this function by sampling the ion current from the instrument, possibly averaging the result to improve the signal to noise ratio, and then converting the result to a standard numeric format recognized by the other processing elements in the system. Currently only analog data conversion is supported, however this processor provides the system with the processing power need to handle pulse counting hardware when it is installed. The detector slave 1E6 is provided with 16 Hbytes of HRH. However with the limited range of function currently demanded of this processor less than 8H bytes are utilized. The peak-finding slave processor is the main signal processing element in the system. This processor combines positional output from the ion path slave with intensity information from the detection slave. Various criteria are used to determine the presence and position of a peak in the mass spectrum. When a peak is detected this processor records the position and intensity of the peak. This information is transferred to the master processor when a scan is completed. The peak finding slave has no direct connections to the instrument. This processor is supplied with 24 Kbytes of memory, of which 8 Hbytes are allocated to storage of information detected during a scan. In addition to illustrating the interconnections in the control system, Figure 5.6 illustrates the sequence of commands each processor might receive in order to acquire a daughter scan of a parent ion at mass 100. The detection slave is passed the parameter 10 along with the AVGS command to set the number of times to average the ion-current value to 10. The detection slave is then instructed to prepare for a daughter scan. The peak finding slave is passed the parameter 300 along with the command THRES. This sets the threshold for peak detection to 36% counts. This processor 167 is also instructed to prepare for a daughter scan. When told to prepare for a daughter scan the peak finding and detection slaves look to the ion path slave for synchronization during the scan. Finally the ion path slave is passed the pa*ameter 188 along with the M81 command, which selects the parent mass of 106 for the daughter scan. The parameters for the start (mass 18), end (mass 126), and increment of the scan (6.1 amu) are passed to the slave processor prior to issuing the daughter scan command DSCAN. Figure 5.7 illustrates the synchronization and overlap of tasks in the distributed processing system. This figure also illustrates the increased throughput that can be achieved by the use of several processors in place of a single processor. The data acquisition cycle has been divided into five principal tasks; calculation of ionpath values, setting the ionpath values, acquisition of a data point, format conversions of an acquired data point, and peak finding Operations. In a single processor system these functions must be performed in series. The distributed processing system allows these tasks to be overlapped to some extent increasing the system throughput. 168 r: - Figure o./ - Timing diagram comparing the data acquisition cycle on a single processor system with the data acquisition cycle in the distributed control system. 113‘? ._.z . on. (.53 3:2 mason: <53 Ez zo «:6 5.12 20 fil 5332:. @252... so: :mommma 9252.... an... 3.85.. 11 3.52.... x3... _ . _ . 125.. 3.3 5.5.. 33 5.9. «:3 «8302... $2 225... E2 meson: z p.12 25.8 :88me u u 83.; 321:3 Es. zo. $33, 83,; .EE zo. commuoomm 372 be 5:2 34.533 E2 5m Ez 53:33 5E 20. 2mkm>m mommwoomaomog moor—.155. < 1.23 ZO_._._m_DOU< 4.55 mw34<> 7..—kn. zo— ze.+z wh<4304 54.. 29 £2 Em $2 558.26 2wkm>m mommmoomaomozz w1_02_m 4 It; ZO_._._m_DOU< <._.<4w mommwooma mmkmdz zotbmma mmomhw mo A H 84+" 2-ALKYL—THIOPHENES R (3 (\CH2 H E CH2 H )1 j -R- k \F H H H 97+ H H 97* H 4‘ CH2 HA 8 Cflz ///8\ CH2 \\ __, c/j __,. H +,. H H H 53+ 14:: Table 6.2. Summary of characteristic ions PARENT MASS NEUTRAL DAUGHTER LOSS ION B4 98 112 86 100 114 45 97 5 THIOPHENE 1 K 1 X 1 X 2—HETHYL- 1 1 1 THIOPHENE 1 X 1 X 1 X X 2—ETHYLw 1 1 1 TH I OFT-{ENE 1 X 1 X 1 X X DINETHYL~ 1 1 1 TjleFffiflfiE 1 X 1 X 1 X X IwHEXENE 1 X 1 1 CYCLO* 1 1 1 HEXANE 1 X 1 1 2~HEPTENE 1 > 1 1 NETHYL- 1 1 1 CYCLOHEXANE1 X 1 1 2~OCTENE 1 X 1 1 n-HEXANE 1 X 1 X 1 n—HEPTANE 1 X 1 X 1 noOCTANE 1 X 1 X 1 143. collision. In order to obtain a scan of all ions that generate a given daughter ion, such as 97+, the parent scan mode is used. The parent scan involves selecting the desired daughter ion with quadrupole 3 while quadrupole 1 is scanned over the desired mass range. An ion must be transmitted by quadrupole 1, undergo CAD in quadrupole 2, and generate the particular fragment ion selected by quadrupole 3 to be detected. As suggested by the study of the fragmentation of pure thiophenes and potentially interfering compounds, the loss of 45 was used as a primary screening characteristic and the formation of a 97+ daughter ion was used as a secondary characteristic to confirm the presence of thiophenes in the sample. In Figure 6.2, the results of scanning samples of Jet A and a shale oil derived fuel for a neutral loss of 45 are presented. Low ionization potentials (20 eV) were used in an attempt to minimize fragmentation of the samples in the source(58). The peaks at 84, 98, 112, 126, 140, 154, and 168 amu indicate the presence and distribution of thiophenes with 0—6 carbons in side chains. Figure 6.3 shows a portion of the raw mass spectra for Jet A and the shale oil fuel covering the same mass range as the neutral loss scans presented in Figure 6.2. Comparisons of the spectra in Figures 6.2 and 6.3 illustrate dramatically how readily a TQMS instrument can detect components in complex mixtures. Figure 6.4 illustrates the results of scans of the Figure 6.2 — Spectra of the neutral loss of 45 from Jet H 1'1' and a Shale oil derived fuel to detec the presence of thiophenes in the sample. 145 a4 1001 - Jet A 50— 112 140 3‘ _ 154 168 ._ 95 26 1 1 I 1 1 1| 0) L L11 L 1 PAL JJA 1 1 ‘0 ‘I‘T‘ITITFTT‘I‘I‘ITT 0 .. so 90 100 no 120 130 140 150 160 170 180 C o 100 - > . '3 . Shale Oil 0 _ 112 Q) 0: 50-1 54 98 126 140 0 L L 11 L LLLL L 'I'I‘ITT'I'I'I‘I‘I‘I 80 90 100 no 120 130 140 150 160 170 180 Moss .l .- Figure é.n ~ Raw mass illustrated the complexi 1" '\ I —.v 146 spectra for Jet of the samples. Intensity Relative 100 O 109 50 147 Jet A l I 11111“ I 111 ll llllll llllll lll .111 1 l ‘ l ' l ' l ‘ l 1 l ' 1 ' l 1 l 37 I 1 l 80 90 100 110 120 130 140 150 160 170 180 190 Shale Oil 80 90 100 110 120 130 140 150 150 170 180 190 Mass Fioure 5.4 indicating and a shale tfie oil 1. l oectra presence chmcived of of 148 the parent masses 0 substituted thiophenes fuel. +2 Intensity Relative M9 168 _ Jet A 50 -( _ 182 9 I1 I 1 0 1 L 1 i L, L l 1 7 ' l 1 l l 1 l ' 1 l I I l T I 1 1 90 100 110 120 130 140 150 160 170 180 190 126 100 — _ % Shale OH 112 140 50 -' 154 ‘ l h 1% 1m 0 1 l . JJL 1.1 I I I l l I I T T l VT I l r I l T 1 90 100 110 120 130 140 150 160 170 180 190 Mass two fuel samples for parents of the +97 daughter ion used to confirm the presence of substituted thiophenes. The peaks at 9B, 112, 126, 14%, 154, and 168 are readily apparent and support the results presented in Figure 6.2. To confirm the identification of the thiophenes detected in Jet I) by the rapid screening technique, additional experiments were performed with the aid of a gas chromatograph interfaced to the triple quadrupole mass spectrometer. These experiments involved the use o¥ a technique known as multiple reaction monitoring (HRH). MRM is the GEHMS/MS analog of multiple ion monitoring (HIM) routinely performed with conventional GC/MS instruments. Instead of selecting a series of fixed mass settings at which to repetitively monitor the ion current, a series of parentedaughter mass pairs are selected to monitor the ion currents arising from selected CAD reactions in the collision cell. For example, to monitor for the 45 neutral loss from thiophene, quadrupole one would be set to transmit ions of mass 84, quadrupole two would be pressurized with collision gas, and quadrupole 3 would be set to transmit ions of mass 39. Similarly, several other parent-daughter reaction pairs can be monitored sequentially and repetitively in an NRM experiment. To determine the retention times of the thiophenes, a standard mixture of four thiophenes was prepared in a dodecane solvent. The resulting MRM chromatograms are presented in Figure 6.5 and were used to obtained the retention times of the reference thiophenes. This experiment was repeated with a 1.@ ul sample of Jet A. Table 6.3 lists the thiophenes present in the mixture, the reactions used to monitor each thiophene, and the reference retention times and the retention times observed from Jet A. The retention times of the components of Jet A monitored by the reactions attributed to the thiophenes match the observed retention times for the reference thiophene mixture. These results confirm the ability of the selected screening reactions to detect the presence of thiophenes in complex mixtures such as Jet aviation fuels. CONCLUSIONS This work illustrates a method for the development of a rapid screening procedure for a particular compound class using triple quadrupole mass spectrometer. The separatory power of a TQMS instrument allows detection of preselected trace components in complex matrices without the need for prior sample work up or additional chromatographic techniques. The capability of TQMS to analyze fuel samples directly can reduce sample handling and analysis time to Figure 6.5 * Multiple reaction monitoring chromatograms of a reference thiophene mixture. . mm .80 .ms 89» T Shm 68. p — p _ — _ _ _ _ s Nwmmsn .nN fSm .mh sew Tau: Gs. _ — p — _ h _ _ h 8 am. am. am. em. as. am so 2. _ ,nm . so é? _ p _ — p _ _ — p s \(_ <<_ T we ado Tl sdm SNMNSS. as. _ _ p P — n _ p — b _ _ _ s . 0N Tam . ms 8.0m TI sf mhmcm. as. 8338. E186. $58.0, 3.6m 2:83 2s). 8.15m» .. x 93m. Table 6.3. Multiple reaction monitoring results Retetion Time (sec.) Comoound Monitoring Reaction Std. Jet A Thiophene 84 —} I? 48.0 51.0 2~Methvlthiophene 98 —} 53 85.8 87.9 E—Ethvlthiophene 112 -} 67. 87 -} 53 154.9 155.2 2,4 Dimethvlthiophene 112 —} 67. 87 -} 53 161.1 163.@ about 5 minutes. The ability of a triple quadrupole mass spectrometer to detect a minor component in such a complex hydrocarbon mixture can make it a valuable tool in fuel stability studie_. ACKNOWLEDGMENTS The authors would like to thank the National Aeronautics and Space Administration for financial support of this project, and the people at Extranuclear Inc. for their assistance and use of their equipment. REFERENCES (49)Dahlin. H.E.; Daniel, S.R.; Norstell, J.H. Fuel 1981, 6Q, 477~48B (5@)Tutubalina,V.P.; Gabdrakhmanov, F.8.; Korotkova, E.G. Deposited Doc. 1988, SPSTL 46Dth-D88 (51)Hazlett, R.N.; Hall, J.M. Prepr. - Am. Chem. Soc., Div. Pet. Chem. 1981, 26(2), 613-619 (52)worstell, J.H.; Daniel, 8.8. Fuel 1981, 66, 481—484 (53) Bol’shakov,G.F., Izv. Vvssh. Uchebn. Zaved., Heft Ba: 1976 19(5), 51—3 (54) Chertkov, Y.B., Chem. Technol. Fuels Dils, (1976),154 (55)Heneman, F.C. Gov. Rep. Announce. Index 1981, 81(26), .56)R.A. Yost, C.G. Enke, Anal. Chem. 58, 125 A (1979) (57)R.A. Yost,C.G. Enke,D.C. McGilvery,J.D. Morrision, Int. J. of Mass Spectrom. and Ion Physics, 30, 127 (1979) (58)Aczel, T., Rev. Anal. Chem., 1, 226 (1972) CHAPTER 7. SCREENING FUELS FDR SELECTED SPECIES Screening_fiiddle Distillate Fuels for Selected Species by Triple Quadrupole Mass Spectrometry Carl A. Myerholtz Christie 8. Enke Department of Chemistry Michigan State University East Lansing, MI 48824 ABSTRACT The use Vof triple quadrupole mass spectrometry, an MS/MS technique, to detect selected species in middle distillate fuels has been examined. Collision-activated dissociation (CAD) spectra were obtained for reference compounds from several heteroatom-containing compound classes. These included the thiophenes, thiols, nitrobenzenes, pyridines and anilines. The alxylbenzenes were examined in addition to heteroatom-containing species. The CAD results were used to select screening reactions for each compound class. The effectiveness of these screening reactions was demonstrated by identifying the presence of various species in samples of Jet A aviation fuel, a shale oil derived fuel and No. 2 diesel fuel. Triple quadrupole mass spectrometry can be used to rapidly identify a number of different components in middle distillate fuels. This information can be an aid to studies of fuel composition and stability. 166 In recent years, a number of studies have shown that the thermal and storage stabilities of middle distillate fuels are affected by low level concentrations of heteroatom containing species(59),(68),(61),(62) Thermal stability is the resistance of a fuel to deposit formation when stressed at temperatures encountered in an operating engine. Storage stability is the resistance of a fuel to the formation of gums under storage conditions that are less strenuous, but of longer duration than the thermal stresses encountered in an engine. Studies of thermal and storage stabilities of fuels would be aided by knowledge of the presence and distribution of various heteroatom—containing species and how they change under thermal stress. This information becomes even more important when the suitability of alternate sources of feedstocks such as shale oil are considered. Triple quadrupole mass spectrometry (TDMS) is a tandem mass spectrometry or "MS/MS" technique. An MS/MS instrument consists of two mass analyzers separated by an ion-molecule collision region. Ions of a selected mass are allowed to pass through the first mass analyzer and into the collision region. There the ions undergo collision-activated dissociation (CAD). The second mass analyzer is then used to select particular masses of fragment ions for detection. A TQMS instrument utilizes two quadrupole mass filters as mass analyzers. The collision cell is also a quadrupole, but one 161 that is operated in the ”RF only" mode. This mode provides a minimum of mass discrimination and acts rather as an “ion pipe" to contain the reactant ions and all the ionic products of the ion-molecule reaction. Without the quadrupole collision chamber, losses due to scattering would be excessive. A block diagram of a TQMS instrument is shown in Figure 7.1. The three quadrupoles are identified by number, beginning at the source. Ions undergo CAD in the center quadrupole (number 2) at much lower energies (5—30 eV) than other MS/MS techniques which use magnetic and electric sectors and operate at collision energies in the 3—10 keV range(63). A TQMS instrument can be operated in a variety of modes to perform different types of experiments. Figure 7.2 illustrates the operation of a triple quadrupole mass spectrometer for three types of experiments useful in mixture analysis. In addition to mixture analysis applications, TOMS can be a useful tool in the elucidation of the structure of pure compounds(64). In MS/MS the term ”parent" is used to describe an ion selected from the ion source by the first mass analyzer. The term "daughter” is used to describe an ion that is a result of fragmentation of a "parent ion". In TOMS, the daughter ions are produced by CAD in the the collision region. The Operation of a TDMS instrument to perform the three types of Block diagram 162 of :1 triple quadrupole mass ZOEUmHmD ZOCUwumm ZOFqum so} 20_ 20_ HUDQOKQ ZO_._.<._.ZmEO