Revision And Translation Of Existing Programs As A Tool To Teaching Computer Data Acquisition And Control Systems Design And Implementation

Keeping data acquisition and control systems (DACS) used in a graduate and undergraduate laboratory current in a rapidly evolving technological environment is an expensive and time-consuming task. Computer architecture and software have evolved more rapidly than the curriculum repeats, and the interfaces commonly used for DACS now vary widely, including parallel, serial, and Ethernet based protocols. Experimental programming is thus under near-constant revision and adaptation. Since the aerospace industry is widely varied, entry-level engineers may end up working with legacy systems from long-established laboratories, or find themselves in a startup research lab associated with modern computational facilities. It is essential that students learn the basics of designing experimental DACS, as well as the adaptation and evolution of existing programs. Using the well-documented and complete programs of the past allows a complete illustration and understanding of the principles of DACS, and provides a familiarization with legacy programming limitations. The revision of DACS programs written in various forms of BASIC and Testpoint into a more commonly used environment such as LabVIEW insures that the undergraduate laboratory experience interests, prepares and enthuses the experimentalists of tomorrow. This paper discusses and documents the processes used to familiarize upper division aerospace engineering students with the black arts of DACS. Details concerning the programming tasks, legacy hardware and software issues, and the motivation for keeping laboratory studies current are discussed. Also detailed are measures of student success and outcomes assessment concerning laboratory studies. Motivation for Continuing Laboratory Education Every engineering discipline has struggled to keep classrooms and laboratories abreast of the waves of technology sweeping them into the future. In aerospace engineering in particular, the rapidly evolving computer hardware and software have enabled great strides in computational field simulations. This evolution has benefited every major discipline and thrust area of this field, including analysis, simulation or optimization of structures, aerodynamics, propulsion, and control systems. The tools used in the educational laboratory have had to evolve to keep pace with this technological revolution, and in an economic climate of declining tax revenues, public-funded institutions in particular have struggled to remain abreast. Laboratory managers and educators have P ge 9.070.1 “Proceedings of the 2004 American Society for Engineering Education Annual Conference & Exposition Copyright 2004, American Society for Engineering Education” been in a constant revisionist mode just to keep up with the steady flow of ever faster and more capable computers and related data acquisition and control systems. A quick look at the revenues invested in such hardware from one of the prominent suppliers, National Instruments, revealed a tremendous growth in the use of new technology, with NI net corporate incomes increasing by an order of magnitude in the late 80’s, and a similar increase through the 90’s, to a level four times greater than that of Keithley, one of the most prominent suppliers of traditional equipment for decades, while Keithley also experienced moderate growth. Especially in the last few years, clones of the data acquisition boards of both these companies are also in plentiful supply. As computer systems evolved, hardware peripherals such as data acquisition, signal conditioning, and controller modules evolved likewise. A host of different hardware buss architectures and port communication protocols came into being, with some of them vanishing entirely within a generation. Although the cost of individual computers continued to decline during the last decade, the requirement for recurrent upgrades or replacements to software and hardware accelerated, with a great increase in the cost of this new technology. Since the introduction of new technology into industry was proceeding at the same accelerated pace, it was essential to insure that the students studying to be the fuel for this ongoing overhaul remain abreast of the current technologies, yet also be cognizant of the capabilities of the old. Many small companies cropped up to provide equipment and programming for data acquisition and control, but those engineers working with larger government and industrial laboratory facilities have generally been expected to adapt and extend their own facilities into a new age. As a result of this continued path of evolution, aerospace engineering laboratories and classrooms have had to insure that the general computer and programming skills that were being taught were also under near-constant revision and adaptation. The use of computer data acquisition and control systems depended on programming in languages such as Pascal and various versions of BASIC, and those were evolving very rapidly. Suppliers of data acquisition cards for PCs offered sample programs and drivers first for the most common versions of Pascal, and interpreted BASIC, and pre-compiled binary drivers to be loaded into memory for use by more simple control programs. Borland’s Turbo-Basic was adapted to common use for making the compilation process simple. At the same time graphical and object-oriented programming environments were being developed. These were soon emphasized as the way of the future in a windowed environment, and soon made an individually programmed solution a thing of the not-sodistant past. Since the aerospace industry is widely varied, entry-level engineers may end up working with legacy systems from long-established laboratories, or find themselves in a startup research lab associated with modern computational facilities. It is highly unusual for even a well-established laboratory to have a static programming environment. Experimental research facilities such as wind tunnels, constructed decades ago, are still operable today, though little similarities exist between the hardware packed racks of yesteryear and the compact computer measurement and control equipment that are likely to be installed to control those facilities today. In some instances, however, those old control systems are just now being replaced, often by entry-level engineers who come to P ge 9.070.2 “Proceedings of the 2004 American Society for Engineering Education Annual Conference & Exposition Copyright 2004, American Society for Engineering Education” the workplace with some understanding of and experience in the new programming environments such as Testpoint and LabVIEW. On the other hand, there are new and smaller facilities for specialized research that are being put in place by individual engineers and smaller companies, that can ill afford to duplicate the research equipment used before. These new companies often rely on the relatively new-skilled recent graduates who are still accustomed to learning hardware and software, and provided that their education was up-to-date with current technology, are likely to be familiar with state-of-the-art computers and data acquisition and control hardware. As examples of these trends several recent graduates in aerospace engineering at Mississippi State University have secured jobs working with long-established companies precisely because of their knowledge of DACS programming. These included various groups from Boeing, Lockheed Martin, and contractors to NASA, where students were hired because of their exposure to ASYST, Testpoint, or LabVIEW. Furthermore, continuing surveys of graduates and employers have indicated their educational experiences with DACS programming were both necessary, and appropriate. Also, in recent class-related visits to such facilities as the propulsion labs at NASA Marshall, students have seen first hand how practicing engineers use the same sort of equipment and LabVIEW programming in their work as they use in their classes. Reinforcing this, some of the engineers specifically discussed how their student interns and new hires were most useful in updating the programs used for these experiments. It is essential that students learn the basics of designing experimental DACS, as well as the adaptation and evolution of existing programs. While not every student will eventually work in a laboratory setting, it is likely that the results of their computational or design work will end up being tested in such a facility. Their understanding of the processes and limitations of experimental endeavors is essential if there is to be a successful feedback from the lab to the designer and manufacturer to complete the design process. If every student participates in the process of experiment design, programming for data acquisition and control, and conduct of laboratory tests, they will at least gain the necessary appreciation and knowledge of how that process relates to their computational analyses of the topics at hand. Since not every experiment is developed from scratch, and multiple and varied software solutions often exist for laboratory DACS tasks, a familiarization with those generations of solutions can be effective in giving the student a better perspective on the benefits of the latest software solutions. At the same time, using earlier programs as models for the development of the next generation solutions prepares the students to do precisely the same thing if they do end up working in an experimental laboratory. Using the well-documented and complete programs of the past allows a detailed illustration and explanation of the principles of DACS, and provides a familiarization with legacy programming limitations. A key to effectively providing this education relies upon presenting appropriate coded solutions, and proper advice and counsel that allows a student to make modifications to existing programs, or to realize when it is more cost or time effective to build a new and pe