Fermentation Vessel Automation Final Report

Team: Dec06-07

Client: Stephanie Loveland

ISU Department of Chemical and Biological Engineering

Faculty Advisor: Dr. Degang Chen

Team Members: Andrew Arndt Adam Daters

Bradley DeSerano Austin Striegel

Report Disclaimer Notice

DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

December 13, 2006

Table of Contents List of Figures............................................................................................................................... iv List of Tables ................................................................................................................................. v List of Symbols ............................................................................................................................. vi List of Definitions........................................................................................................................ vii 1. Introduction Materials ............................................................................................................ 1

1.1 Executive Summary ............................................................................................................ 1 1.2 Acknowledgement .............................................................................................................. 3 1.3 Problem Statement .............................................................................................................. 3

1.3.1 Problem Statement .................................................................................................. 3 1.3.2 Problem Solution .................................................................................................... 3

1.4 Operating Environment....................................................................................................... 5 1.5 Intended User(s) and Intended Use(s)................................................................................. 5

1.5.1 Intended User(s)...................................................................................................... 5 1.5.2 Intended Use(s) ....................................................................................................... 5

1.6 Assumptions and Limitations ............................................................................................. 6 1.6.1 Assumptions............................................................................................................ 6 1.6.2 Limitations .............................................................................................................. 6

1.7 Expected End Product and other Deliverables.................................................................... 7 2. Approach and Results ...................................................................................................... 7

2.1 Functional Requirements .................................................................................................... 7 2.2 Design Constraints .............................................................................................................. 8 2.3 Technology Considerations and Results............................................................................. 8

2.3.1 Data Acquisition Board........................................................................................... 9 2.3.2 Signal Conditioning ................................................................................................ 9 2.3.3 Oxygen Concentration Meter................................................................................ 10

2.4 Detailed Design................................................................................................................. 11 2.4.1 Oxygen Concentration Meter................................................................................ 12 2.4.2 Mass Gas Flow Meter ........................................................................................... 13 2.4.3 Signal Conditioning Carrier.................................................................................. 14 2.4.4 Stirrer Motor Control ............................................................................................ 15 2.4.5 Data Acquisition Board......................................................................................... 16 2.4.6 Software Interfacing.............................................................................................. 17

2.5 Implementation Process .................................................................................................... 18 2.5.1 Hardware Implementation .................................................................................... 18 2.5.2 Software Implementation...................................................................................... 18

2.6 End-Product Testing ......................................................................................................... 20 2.6.1 First Phase: Testing the Individual Equipment..................................................... 20 2.6.2 Second Phase: Testing the Overall System........................................................... 20 2.6.3 Third Phase: Beta Testing..................................................................................... 20

2.7 Project End Results ........................................................................................................... 21 3. Resources .......................................................................................................................... 21

3.1 Task Definitions................................................................................................................ 21 3.1.1 Task 1 – Problem Definition................................................................................. 21 3.1.2 Task 2 – Technology Considerations and Selection ............................................. 21

i

3.1.3 Task 3 – End-Product Design ............................................................................... 22 3.1.4 Task 4 – End-Product Prototype Implementation................................................. 22 3.1.5 Task 5 – End-Product Testing............................................................................... 22 3.1.6 Task 6 – End-Product Documentation.................................................................. 22 3.1.7 Task 7 – End-Product Demonstration................................................................... 22 3.1.8 Task 8 – Project Reporting ................................................................................... 22

3.2 Personnel Effort ................................................................................................................ 23 3.2.1 Original Personnel Effort...................................................................................... 23 3.2.2 Revised Personnel Effort ...................................................................................... 23 3.2.3 Final Personnel Effort ........................................................................................... 24

3.3 Other Resource Requirements .......................................................................................... 24 3.3.1 Original Other Resource Requirements ................................................................ 24 3.3.2 Revised Other Resource Requirements ................................................................ 25 3.3.3 Final Other Resource Requirements ..................................................................... 25

3.4 Financial Requirements .................................................................................................... 26 3.4.1 Original Financial Requirements .......................................................................... 26 3.4.2 Revised Financial Requirements........................................................................... 26 3.4.3 Final Financial Requirements ............................................................................... 27

3.5 Scheduling......................................................................................................................... 28 4. Closure Materials............................................................................................................ 27

4.1 Project Evaluation............................................................................................................. 27 4.2 Commercialization............................................................................................................ 28 4.3 Additional Work ............................................................................................................... 28 4.4 Lessons Learned................................................................................................................ 28

4.4.1 What Went Well ................................................................................................... 29 4.4.2 What Did Not Go Well ......................................................................................... 29 4.4.3 What Technical Knowledge Was Gained............................................................. 29 4.4.4 What Non-Technical Knowledge Was Gained..................................................... 30 4.4.5 What Team Would Do Differently ....................................................................... 30

4.5 Risk and Risk Management .............................................................................................. 30 4.5.1 Anticipated Potential Risks................................................................................... 30 4.5.2 Anticipated Risks Encountered and Management ................................................ 31 4.5.3 Unanticipated Risks Encountered and Management ............................................ 31 4.5.4 Resultant Changes in Risk Management Due to Unanticipated Risks ................. 31

4.6 Project Team Information ................................................................................................. 31 4.6.1 Client Information................................................................................................. 31 4.6.2 Faculty Advisor Information................................................................................. 32 4.6.3 Team Members ..................................................................................................... 32

4.7 Closing Summary.............................................................................................................. 33 4.8 References......................................................................................................................... 33

4.8.1 Hardware References ............................................................................................ 33 4.8.2 Software References ............................................................................................. 33 4.8.3 Other References................................................................................................... 33

Appendix...................................................................................................................................... 34 Appendix A – User’s Manual ................................................................................................... 34 Appendix B – Programmers’ Guide ......................................................................................... 35

ii

Appendix C – Testing Forms.................................................................................................... 36 Appendix D – LabVIEW Code Block Diagram ....................................................................... 38 Appendix E – Software Documentation and Code CD ............................................................ 39

iii

List of Figures Item PageFigure 1: Old Mock Fermentation Vessel Apparatus ..................................................................... 1 Figure 2: Control flow of System Interaction................................................................................. 2 Figure 3: GUI Implemented............................................................................................................ 4 Figure 4: Laboratory Apparatus...................................................................................................... 5 Figure 5: Process Model of Functional Requirements.................................................................... 8 Figure 6: The basic flow diagram of the system........................................................................... 11 Figure 11: SCC carrier SC-2345................................................................................................... 14 Figure 15: NI SCC-AI Series Isolated Analog Input Module Wiring Block Diagram................. 16 Figure 17: Final Graphical User Interface .................................................................................... 17 Figure 18: Software Block Diagram............................................................................................. 19 Figure 19: Original Project Schedule............................................................................................ 24 Figure 20: Revised Project Schedule ............................................................................................ 25 Figure 21: Final Project Schedule................................................................................................. 26 Figure 22: Deliverable Schedule................................................................................................... 27 Figure 23: Team Standard Test Documentation ........................................................................... 36 Figure 24: Intended User Survey .................................................................................................. 37

iv

List of Tables Item PageTable 1: Original Personal Effort.................................................................................................. 23 Table 2: Revised Personal Effort .................................................................................................. 23 Table 3: Final Personal Effort....................................................................................................... 24 Table 4: Original Other Resources Required................................................................................ 24 Table 5: Revised Other Resources Required ................................................................................ 25 Table 6: Final Other Resources Required..................................................................................... 25 Table 7: Original Financial Requirements.................................................................................... 26 Table 8: Revised Financial Requirements .................................................................................... 27 Table 9: Final Financial Requirements ......................................................................................... 28 Table 10: Project Evaluation......................................................................................................... 28

v

List of Symbols None

vi

List of Definitions COM – Serial communications port DAQ – Data acquisition Flash – Animated graphics technology and format from Macromedia, which can be viewed with a web browser plug-in GUI – Graphical user interface I/O – Input/output LabVIEW – Laboratory Virtual Instrument Engineering Workbench PCI – Peripheral component interconnect PPM – Parts per million PXI – PCI extensions for instrumentation RPM – Rotations per minute RS232 – Standard for serial cable interface SCC – Signal conditioning system offered by National Instruments SLM – Standard liters per minute USB – Universal serial bus VI (virtual instruments) – Sub-unit program in LabVIEW that represents the appearance and function of a physical implement

vii

1. Introduction Materials

This section introduces the project, including the executive summary, acknowledgements, problem statement and solution, operating environment, intended users and uses, limitations and assumptions, expected end-product and other deliverables.

1.1 Executive Summary

A mock fermentation vessel is available for use by senior chemical engineering students to conduct experiments in their final laboratory course. This vessel experiment used obsolete methods to collect data from the equipment. Students were recording the data by hand every ten to fifteen seconds using stopwatches for timing, and then transferring this hand-written data to electronic format for further analysis and graphing. Figure 1 shows the old configuration of the mock fermentation vessel and its equipment.

Figure 1: Old Mock Fermentation Vessel Apparatus

The objective of this project was to design an automated system to collect the necessary data for the user. This system involved the use of data acquisition cards to interface with the lab equipment, and LabVIEW software which was used to collect the data. Figure 2 illustrates the flow of the system components in project.

1

Figure 2: Control flow of System Interaction

To implement this system the project team purchased a data acquisition card and signal conditioning modules from National Instruments. The signal conditioning was needed to provide isolation for the stirrer motor control unit. Also the signal conditioning allowed easy connection to the data acquisition board and further upgradeability for the system. Another purchase made by the team was a new oxygen concentration meter to update the old equipment, and allow data collection over an RS-232 connection. A user interface was created for this system for the intended users to operate. This interface displayed data in a real-time display, and allows automatic data collection every five seconds. This automatically collected data was stored in an electronic format for easy analysis and graphing. Also delivered with this system were an extensive user’s manual, programmer’s guide, and a flash tutorial detailing the use of the system. Testing was performed by both the team and the project’s client and intended users. The team tested each software module gathering data, as well as the entire user interface for complete functionality. The client and intended users provided feedback allowing the project team to implement all the desired changes. Overall the final project was completed successfully, fully meeting or exceeding all of the guidelines set forth by the client at the beginning of the project. This project was completed by utilizing 788.5 total man-hours, and approximately $2800 of new equipment. The project team recommends that the project be terminated at the end of the semester, as the project requirements set forth by the client were fully met or exceeded. Only if further automation was specified by client would there be a need for additional work on this project.

2

1.2 Acknowledgement

For his aid in this project with technical and practical advice, the team would like to acknowledge the effort of Dr. Degang Chen of Iowa State University. This group would also like to recognize Stephanie Loveland of the Iowa State University Department of Chemical and Biological Engineering. She provided finances, design specifications, and requirements for this project.

1.3 Problem Statement

The problem statement is broken up into two separate sections; one that defines the general problem area and another that describes the proposed approach to the solution.

1.3.1 Problem Statement

A mock fermentation vessel is available for use by senior chemical engineering students to conduct experiments in their final laboratory course. This vessel used obsolete methods to collect the data from the equipment. Students were recording the data by hand every ten to fifteen seconds using stopwatches for timing, and then transferring this hand-written data to electronic format for further analysis and graphing. The objective of this project was to design, update, and install new equipment and software for the mock fermentation vessel equipment data to be collected automatically. A new oxygen concentration meter was needed for the apparatus, specifically one that was able to communicate with the LabVIEW software. The remaining equipment, stirrer motor control and mass gas flow meter, must be adapted so that they could communicate with the LabVIEW software. Software must also be developed to gather data from the equipment and allow for smooth, efficient operation by the user. The software must be designed to take readings from the equipment and display this data in real-time for analysis by the user. The user interface needed to be developed so that data would be saved automatically for users to be able to analyze and graph later. A manual or tutorial would be developed alongside the user interface to provide the user some aide in using the software as well.

1.3.2 Problem Solution

With the need of a new oxygen concentration meter for the project’s apparatus, the team worked with the client to determine the best meter to purchase. This involved checking for easy connection and support by LabVIEW, as well as ensuring long-term support for the product. Throughout this research process the team worked with the client in meeting all the needs specified. To communicate with the existing laboratory equipment the team researched the equipment and determined the form of data output. This research allowed the

3

team to determine the necessary data acquisition cards and signal conditioning units to collect accurate data from the equipment. The data acquisition information collected from the equipment was then interpreted by software developed using LabVIEW. A GUI was developed that displayed real-time information to the user on screen. This GUI also allowed the user to save this collected data every five seconds for later analysis and graphing. Figure 3 below shows the final implementation of this GUI. Also extensive documentation was developed alongside the software to provide the user aide in using the software. A further learning material created by the team was a flash tutorial which guided the user through the GUI, and provided an interactive way for the intended users to learn the software.

Figure 3: GUI Implemented

4

1.4 Operating Environment All equipment is housed in the teaching laboratory of Sweeney 2059. Figure 4 below shows the laboratory setup in Sweeney 2059. This room is subject to a temperature controlled environment of 60-80 degrees Fahrenheit. High levels of moisture would cause hardware failures, which would render the data collection or software inoperable. Also the connections were to be checked and cleansed from time to time due to normal dust accumulation, and regular use.

Figure 4: Laboratory Apparatus

1.5 Intended User(s) and Intended Use(s)

This section is divided into two parts, one to cover the intended user(s), and the second is to cover the intended use(s).

1.5.1 Intended User(s)

The mock fermentation vessel is a setup used by senior level students in the Department of Chemical and Biological Engineering as well as faculty within the department. The users would have knowledge of safety procedures and requirements while conducting experiments within the lab. Students would need to have been exposed to the concepts that the lab is designed to simulate.

1.5.2 Intended Use(s)

The intended use of this project was to automate the collection of data from the mock fermentation vessel apparatus. This automation process yielded data in a real-time display as well as saved file format for further data analysis by the users.

5

The end system was not intended to be used on any other equipment that was not supported.

1.6 Assumptions and Limitations

Certain aspects of this project needed to be constrained to more specific terms. In the individual assumptions and limitations sections, more specific details are developed to better outline the project.

1.6.1 Assumptions To adequately develop this product certain assumptions about the project were developed. These assumptions are stated as follows: • The end-user of this project would be someone who was familiar with the

fermentation process • Only one experiment would be conducted at a time • Environmental stability of 2059 Sweeney would be maintained • All new components and cables would be paid for by the client • The end-user understood basic computer terminology (double-click, scroll,

etc) • All laboratory components would operate within their given rated power

values • A computer would be supplied by the client with LabVIEW and Excel already

installed • An extra PCI slot would be available on the computer for a data acquisition

card • The data acquisition card would supply its own clock

1.6.2 Limitations

A number of limitations were imposed upon the project; including the following: • File format type would be in Excel format • Software would be written using LabVIEW • One sample every five seconds must be recorded from each specified device • Maximum flow rate for the air/nitrogen must be less than 6 SLM • Motor speed must be kept less than 800 RPM • Safety glasses must be worn at all times when working in 2059 Sweeney • No more than 4 significant digits stored upon measurement • The voltage signals from the stirrer motor control must be electrically isolated • The oxygen concentration meter must read from 0 to 9.5 PPM dissolved

oxygen • The oxygen concentration meter must be a benchtop unit

6

1.7 Expected End Product and other Deliverables The expected end product of this project was an automated collection system for the mock fermentation vessel apparatus. The system including all the necessary hardware for collection and data acquisition has been delivered to the client. Along with the physical system, a GUI was developed that displays real-time information to the user and saves this data into an Excel file format. This software was reviewed by the client, and subsequent changes were made and delivered to the client after final review. A number of documentation and learning material accompanied the software and were provided to the client upon the completion of the project. These materials included a printed copy of the fully commented program code, a user manual, and a programmer’s guide. Also as a learning tool for the intended users, a flash tutorial walked the users through the use of the system. A soft copy of all these materials can be found on a CD attached in the appendix of this report. Also a hard copy of these documents can be viewed in the appendix of this report.

2. Approach and Results

This section outlines the approach formulated by the team to ensure that the system was correct.

2.1 Functional Requirements

The following functions were implemented into this project and were required to complete this project successfully. These requirements were specified by the client as well as the faculty advisor, and were modeled in the process model in Figure 5. Data acquisition: The system must be able obtain measurements of speed, torque, air/nitrogen gas flow, and oxygen concentration from the appropriate measurement devices. The system would apply proper filtering on the equipment output, to obtain accurate measurements.

Data collection: The measurements obtained must be recorded every five seconds. This information is stored in an Excel file format and available for user download.

Software interaction: A GUI must display real-time information and must be developed in LabVIEW. It shall be easy to use and has a user manual detailing operation.

7

Figure 5: Process Model of Functional Requirements

2.2 Design Constraints The entire project was designed and constructed to perform under the following conditions and constraints. Software environment: The software developed for this project was developed in LabVIEW. This included creating a GUI for user interaction. Measurement collection timing: The measurements from the lab equipment were recorded at one sample every five seconds.

Max air/nitrogen gas flow rate: The maximum air/nitrogen gas flow rate would be less than 6 SLM.

Max motor speed: The maximum motor speed would not exceed 800 RPM.

Electrical isolation on stirrer motor control: The voltage signals from the stirrer motor control must be electrically isolated.

Oxygen Concentration Meter: The oxygen concentration meter must be able to measure between 0 and 9.5 PPM of dissolved oxygen, and must be able to interface with LabVIEW.

2.3 Technology Considerations and Results

For this project, there are four main areas for technology considerations. These areas include the data acquisition board for collecting data, signal conditioning use, and oxygen concentration meters.

8

2.3.1 Data Acquisition Board

Technology considered: A means for collecting the information from the equipment was designed using a data acquisition board, but there were a large variety of boards available. There were several types of boards considered along with their unique attributes. A USB DAQ unit would give the system easy connection to the computer that would be used for the experiments and be relatively inexpensive to implement. A drawback to this unit was there was no way to apply any signal conditioning with this type of unit. The second type of DAQ considered for this project was a PXI DAQ system. The PXI system allowed for signal conditioning at a very high resolution signal and very high sampling rate, but these great features were translated into the high cost of the this system. The final DAQ consideration was the PCI board, this board allowed for signal conditioning and sampling at lower cost. The PCI DAQ board does not provide extremely high resolution or sampling rate.

Technology selected: After careful consideration of the equipment and requirements the PCI DAQ board was selected. The PCI DAQ board allowed for a sampling rate that is well within the constraints outlined by the client and provided the advantage of signal conditioning capability. Another benefit was the moderate cost of the PCI DAQ board, while cost was not a constraint, having an overly excessive sampling rate was not worth the extra cost.

2.3.2 Signal Conditioning

Technology considered: Signal conditioning plays a huge role in obtaining reliable analog output from lab equipment. Therefore in the design the team needed to explore equipment transients, and other noise within the lab environment. Results from contacting equipment manufacturers inquiring upon signal integrity of the output yielded an effective approach to signal conditioning.

For the stirrer motor control unit two scaled voltage signals required electrical isolation up to 143Vrms due to a floating ground. This floating ground would provide fast transients which would need to be filtered out. To get accurate signal conditioning National Instruments was contacted for a recommendation for equipment. Following their recommendation and an online advisory tool, many signal conditioning modules were found having varying input with voltage ranges from ±50mV to ±42V.

For the mass gas flow meter unit the output signal took the form of a voltage ranging from 0 to 5V. This output would require an additional signal conditioning module for purchasing for signal conditioning, or a direct

9

connection to the DAQ board. The voltage signal would not require a great deal of signal conditioning, but an additional module would provide easy connection to the DAQ board. However direct connection to the DAQ would limit costs, but would require a DAQ board to have direct inputs.

An additional consideration for signal conditioning is the extra purchase of a signal conditioning carrier which would house potential signal conditioning modules. This signal conditioning carrier offered a low cost signal conditioning solution for a wide range of analog or digital input and output signals. Without purchasing this SCC carrier, the overall cost would be decreased, but the signal conditioning modules would be unable to be used.

Technology Selected: The signal conditioning carrier was selected as the proper means for facilitating signal conditioning. It allowed the use of the signal conditioning modules, and its additional cost was outweighed by simplification of the design and the future upgradeability of the system.

For the stirrer motor control as all the analog voltage input modules from National Instruments have a working isolation up to 300V this covered the issue with the floating ground. Also since transients may be present, utilizing the differential capability of these modules shielded against this extra danger. In evaluating each of the modules for a necessary voltage range needed, the 0 to 5V input range two-channel analog input voltage module from National Instruments was selected.

For the mass gas flow meter, an additional module with the 0 to 5V input range two-channel analog input voltage from National Instruments was selected. This selection was dictated by ease of connection with the DAQ board, and allowing further upgradeability to the system.

2.3.3 Oxygen Concentration Meter

Technology considered: The current oxygen concentration meter that was used in the mock fermentation vessel was out of date, and did not provide an interface with a PC, a replacement must be identified. There were a wide variety of oxygen concentration meters available on the market, but as the client specified that it must be a benchtop meter this narrowed the field. Two oxygen concentration meters were identified that met the required specifications, but had a few differences. Omega Engineering carried a benchtop oxygen concentration meter which had an RS232 link for computer connection, and provided 100 data point logging. This unit offered little support for future supplies and was to be no longer carried by the manufacturer. The other unit identified was the Orion 3-Star benchtop oxygen concentration meter from Thermo Electron. This unit offered an RS232 link for computer connection, and provided 200 data point

10

logging. This unit also offered a 3-year replacement warranty and up to five years of guaranteed manufacturer supply support.

Technology selected: The Orion 3-Star oxygen concentration meter was selected from Thermo Electron. This unit offered all the functionality that was desired by the client, while also offering attractive features and support for an extended period of time.

2.4 Detailed Design

This section covers all the specific details of the team’s design. It includes all hardware, wiring diagrams, part numbers, estimated part costs, and part sources/sellers that are required for each component. The automated collection system consists of three main pieces of equipment in which data was collected from, each being acquired with LabVIEW for the final product. This section is divided into the five main components of this project. These five main components are listed below. The system flow diagram further relates these components as shown in Figure 6.

• Oxygen concentration meter • Mass gas flow meter • Signal conditioning carrier • Stirrer motor control • DAQ board • Software interfacing – GUI

Figure 6: The basic flow diagram of the system

11

2.4.1 Oxygen Concentration Meter

The selected oxygen concentration meter was the Thermo Electron Orion 3-Star benchtop dissolved oxygen meter. This meter offered many features including measuring the full scale of dissolved oxygen (0-9.5 PPM), a 200-point data logger for storing measurement information, and a RS232 bidirectional link for connection to a PC or printer. This model is shown in Figure 7 to the right. This meter was purchased in a kit that provided the meter, probe, probe stand, and calibration materials for an approximate cost of $1335. This unit was purchased from VWR Scientific.

Figure 7: Orion 3-Star Meter

In order to utilize the RS232 bidirectional link for data logging, an additional conversion cable must be purchased to interface with the PC. The connections diagram is shown below in Figure 8. The conversion cable converted the 3.5mm stereo jack connector into a COM port, which was connected to the serial port of the PC used. This conversion cable had an approximate cost of $30, and was purchased from VWR Scientific with the oxygen concentration meter.

Figure 8: Rear connections of Orion 3-Star Meter

To interface with LabVIEW, the team used the onboard serial port for data acquisition from the oxygen concentration meter. The meter was configured to transfer data every five seconds to the PC. This information was in a comma delimited output, which was then filtered using LabVIEW to grab the appropriate information for data storage and display.

12

2.4.2 Mass Gas Flow Meter

The current mass gas flow meter of the mock fermentation vessel is the Omega FMA-5610, shown in Figure 9. This meter offers an output signal in the form of a 0 to 5V analog signal. This signal represents the mass gas flow in standard liters per minute, and represents a scale of 0 to 10 SLM. Therefore the scaling follows that 0V corresponds to 0.0 SLM, and 5V corresponds 10.0 SLM, and follows a linear scale between each of these points. This output signal is obtained from the 9-pin D connector on side of the enclosure. The connector outputs the voltage on pins 2 and 3. These pins are wired using standard copper wire to the voltage module selected from National Instruments for signal conditioning. This module is the NI SCC-AI04. This input module offered two channels of isolated analog input, with isolation up to 300V, and differential input. This module is further discussed in Section 2.4.4, as it was also used for the stirrer motor control unit. Error! Reference source not found. below shows the pin configuration for the D-connector on the Omega FMA-5610 (on the left), and shows the wiring block diagram used for connecting the SCC-AI04 module (on the right). This SCC-AI04 module was plugged into the signal conditioning carrier for interaction with the PC and LabVIEW. The signal conditioning carrier is further discussed in the next section (Section 2.4.3).

Figure 9: Omega FMA-5000 Series

Figure 10: Omega FMA-5610 Connector Diagram (left), NI SCC-AI04 Voltage Input

Module Wiring Block Diagram (right)

The NI SCC-AI04 isolated analog input module will be purchased from National Instruments at an approximate cost of $265.50.

13

2.4.3 Signal Conditioning Carrier

In order to use the signal conditioning modules for the design, an SCC carrier must be purchased to house these modules. The SCC carrier selected was the SC-2345, which would allow direct cabling to the M-Series DAQ board selected (Section 2.4.5). The SCC carrier selected is shown in Figure 11. The SCC carrier comes at a price of $220.50 and was purchased from National Instruments.

Figure 11: SCC carrier SC-2345

This unit provided a low-cost, low-profile housing for each of the SCC modules purchased. The SCC carrier was powered by the DAQ board with a 5V signal. The modules were connected in a configuration as shown in Figure 12. Figure 12 also shows the connector block diagram of the SCC carrier unit. As can be seen the SCC carrier unit can hold up to 20 SCC modules, which can be either analog or digital signals. This allowed for future upgradeability for the mock fermentation vessel collection system.

Figure 12: Analog Input SCC Configuration (left), Diagram of Module Layout in SC-2345 Connector Block

14

The SCC carrier connected with the DAQ board through the use of a 68 pin shielded connector cable. This cable was the NI SHC68-68 that was specifically used for connection to M-Series DAQ boards (Section 2.4.5). The cable is shown in Figure 13. The cable comes in many lengths from 0.5 to 10 meters in length, but a length of 2 meters was chosen to allow for easy spacing of PC away from the mock fermentation vessel. The cable comes at a cost of approximately $99 and was purchased from National Instruments.

Figure 13: NI SHC68-68 Connection Cable

2.4.4 Stirrer Motor Control

Figure 14: GKH Stir Tester

The current stirrer motor control of the mock fermentation vessel is a component of the Glas-Col GKH-Stir Tester 099D HST20N, shown in Figure 14. This control unit offers two output signals that represent torque (oz-in) and speed (RPM) in the form of analog voltage signals. The voltage signals are scaled signals which for every 1mV measured they are approximately 1 oz-in of torque or 1 RPM of speed respectively. There a few design issues that need to be taken into account when trying to measure these signals for data acquisition. The unit operates with a floating ground that typically operates at 70 to 90V. Also 60V fast transient spikes could appear on the output lines due to the switching DC motor that is driven by the motor control. In order to measure the torque and speed accurately, signal conditioning must be applied to ensure signal integrity. To achieve proper conditioning an isolated analog input module was used from National Instruments. The SCC AI Series modules from National Instruments offer varying input voltage ranges from ±50mV to ±42V. As discussed earlier the team selected an input voltage module with an input range of 0 to 5V. This module was the NI SCC-AI04, which offers two channels of isolated analog input, with isolation up to 300V, and differential input. In order to connect the stirrer motor control to the module, a cable purchased from Glas-Col for a cost of $30 was used to connect differentially to each channel of the module. This protected against the fast voltage transients, and offered better noise rejection. Figure 15 below shows the wiring block diagram for connecting the SCC-AI04. This SCC-AI04 module will be plugged in the signal conditioning carrier for interaction with the PC and LabVIEW. Additional information on the signal conditioning carrier can be read in Section 2.4.3.

15

Figure 15: NI SCC-AI Series Isolated Analog Input Module Wiring Block Diagram

The NI SCC-AI04 isolated analog input module will be purchased from National Instruments at an approximate cost of $265.50.

2.4.5 Data Acquisition Board

Figure 16: NI PCI-6221 DAQ Board

The selected data acquisition board was the National Instruments NI PCI-6221 M-Series data acquisition board. This DAQ board offered many features including 16 analog inputs, 2 analog outputs, 24 digital I/O lines, and two counters/timers. This DAQ board is shown at the right in Figure 16. This unit offered 16 bit resolution which correlates to an accuracy of 70μV. The sampling rate of the board was 250 kilo-samples/sec which provided an adequate signal sampling for the analog input signals. This board was purchased from National Instruments at an approximate cost of $427.50.

In order to gather information from the SCC carrier and the signal conditioning modules the DAQ board connects to the SCC carrier via the NI SHC68-68 shielded cable discussed in Section 2.4.3. This cable transfers the various analog input channels to the DAQ card for sampling. By using the internal clock supplied on-board the DAQ board each channel of input can be sampled and have data acquired.

The configuration of the DAQ board uses 6 of its 16 analog input channels used for sampling and data acquisition. These 6 six channels represent the 3 differential pairs of signals for mass gas flow, torque, and speed. The additional input and output channels could be used for future expanding or controlling of external devices.

To interface with LabVIEW, the team took advantage of the available express VI’s that were available to define the operation of the card. With these express

16

VI’s scaling was applied to account for the various signals that were inputted. Also these express VI’s aided the team in not having to create new LabVIEW code to define the operation of the DAQ board.

2.4.6 Software Interfacing

A graphical user interface (GUI) will help students navigate the integrated data acquisition system for the mock fermentation vessel. The final design of the GUI consisted of a main screen displaying all of the data and allowed for user input on when to begin recording samples out to a file. Figure 17 shows the final design of this page.

Figure 17: Final Graphical User Interface

Upon starting the mock fermentation vessel experiment, a user accesses the program via an icon on the desktop of the computer located in the laboratory. When opened the program first prompts for a filename entry. This filename is used to store the experiment data upon starting a log. After the file is specified the user is presented with a full screen display of all the data being collected. Each piece of laboratory equipment has a corresponding gauge to indicate the current level being measured. Also scrollable, timed graphs were made available to chart the data for the user. As the client specified that oxygen concentration over time was the most relevant over time, this was given its own graph. The other pieces of equipment were also given their own graph, but to save space and not clutter the screen, the team placed these graphs into a tabbed dialog box for easy looks at each graph.

17

Each displayed is updated in real-time for the user to view. However, the refresh of the different meters is not the same. The mass gas flow, motor speed, and motor torque are updated at much faster rate as this data is sampled every 10000 Hz. The oxygen concentration is updated every five seconds as this is the fastest the meter outputs to the PC. To begin an experiment the user simply presses the “Start Log” button in the bottom left of the GUI. This begins a timer which records the data every five seconds to the output file specified upon startup. To stop the experiment the user simply presses the “Stop Log” button, which is actually the same button as “Start Log” only it is changed to “Stop Log” while the recording is in progress. To begin a new experiment without closing the program the user simply needs to type in a new filename, and follow the same procedure outlined above. To close the program there is a master stop button in the bottom right, or the user can simply exit out of the program. In order to graph the data recorded, a user can open up the file which was recorded in comma separated format. This format is natively opened in Excel, and provides easy access for the user to graph or analyze the data.

2.5 Implementation Process This section will detail the implementation of this project with both the hardware and software. 2.5.1 Hardware Implementation

As already detailed earlier the hardware was implemented following the block diagram in Figure 6 and outlined in the detailed design. However through the implementation process the team encountered one problem. Initially the team found that the mass gas flow meter provided a 4-20mA output current signal, along with an output signal of 0-5V. The current module was decided upon by the team and the client because it cheaper in overall cost. Upon arrival of the purchased current module, the team discovered that the particular mass gas flow meter available did not output a current signal. Therefore the team had to purchase a secondary voltage module to enable collection of the mass gas flow meter.

2.5.2 Software Implementation The program was implemented using LabVIEW as was outlined by the client. To first begin the software implementation process, the team created a block

18

diagram to define the flow of the program. Figure 18 below was used as a basis to begin the software implementation.

Figure 18: Software Block Diagram

After the block diagram was defined, the team set out to create the program following the method determined. This was done by focusing on the two main branches of the block diagram. These branches were data collected from the data acquisition board and the data collected from the oxygen concentration meter. This was done since each of the data collection branches runs on a different timing since the oxygen concentration meter can output at most every five seconds. Therefore separate timing loops were developed, and the information from the oxygen concentration meter was passed to the data acquisition loop, which housed the main GUI and file output capability.

19

For further documentation of the exact software implementation refer to the programmer’s guide in the appendix, and also view the LabVIEW code block diagram attached in the appendix as well.

2.6 End-Product Testing

The methods for testing and the criteria for acceptance are discussed here. Testing is important to the project and should not be overlooked, and was thoroughly carried out over the project. This project was tested in three phases, which are detailed below. 2.6.1 First Phase: Testing the Individual Equipment

This phase involved testing the functionality of all of the devices and integrating them with LabVIEW. The separate VI developed for each piece of equipment was tested by the team to ensure the information was reported accurately and the software was performing correctly. The team member performing the test filled out a standard form for each test they ran. This form can be found in the appendix. This form included their name, the date, and time performed. Also the form noted the test performed and its results. If a problem occurred it was noted, along with the problem description and a solution field for noting the fix to the problem. This standard form for testing ensured proper testing by a team member, as well as provided good documentation for later use in the project. A couple of forms that were filled out are attached in the appendix. In order to move on to the next phase of testing, all device measurements must be reported accurately and any additional software functions were performing correctly. The team reviewed this testing data from this phase with the faculty advisor and decided to move onto the second phase of testing as all specifications were met.

2.6.2 Second Phase: Testing the Overall System

The second phase of testing for this project involved testing the real-time data transfer from all devices at once. Also it involved testing the data collection and file storage capabilities of the LabVIEW program. Overall the GUI was tested for errors, and for proper displaying of all information. This phase of testing was carried out again by the team using the standard form found in appendix, and used in the first phase. To move on to the last phase of testing, the team evaluated the system by running through a mock experiment and verifying results of output to those expected. The team then reviewed the testing data from this phase with the client and made the decision to move onto the final phase of testing.

2.6.3 Third Phase: Beta Testing

This phase involved having the client and potential users test the software and report problems to the team. For testing the system, four groups were asked to

20

use the software and fill out a survey after trying out the system. This survey can be found in appendix. The survey consisted of opinions on: ease of use, functionality, presentation, and usability of the data exported. These were rated on a 1 to 5 scale, and a section for comments followed each section. Also a section for suggestions appeared at the end for additional comments. The client will also be asked to use the software and fill out the survey. After the team received comments from the client and student testers, the appropriate changes were made to the software. Another group of students was asked to use the software and fill out the survey. This ensured that any changes made did not affect the overall system. The team evaluated the final surveys, and upon final consultation with the client decided the final phase of testing was complete.

2.7 Project End Results

The results of this project have already been discussed many times throughout this report, so this section will highlight some of the major results. To start, the team learned how to program the software necessary in LabVIEW. Before the project, no one on the team had any significant experience with LabVIEW. The most important result of the project is that it successfully collects data every five seconds for the user in an electronic file, and it displays all the data in a real-time interface for the user. Another result was that the project team learned how to work for and interact with a client.

3. Resources

This section details the financial, personnel, and other resources that were required in order to complete the project. 3.1 Task Definitions

This section details the task definitions for each task performed throughout the project. 3.1.1 Task 1 – Problem Definition

Understand the functionality of the product. Define the operation of the product and identify constraints. Consult with advisor about the feasibility of the project.

3.1.2 Task 2 – Technology Considerations and Selection

List the choices of technologies that can be used in the product design. Contact manufacturers for product specifications and information, and select the best and most feasible approach.

21

3.1.3 Task 3 – End-Product Design

Construct a series of VI’s that define the functionality of the technology selected.

3.1.4 Task 4 – End-Product Prototype Implementation

Integrate the VI’s developed in the design process into a main GUI system.

3.1.5 Task 5 – End-Product Testing

Test the product to check that it meets all operational and user-defined requirements.

3.1.6 Task 6 – End-Product Documentation

Document all the details of the product design, and develop an end-user manual and maintenance documentation.

3.1.7 Task 7 – End-Product Demonstration

Demonstrate the functionality of the product to the client, advisor, and industrial review panel.

3.1.8 Task 8 – Project Reporting

Document the details of the whole project in a series of reports, including a project plan, design report, and final report.

22

3.2 Personnel Effort The tables below show the original and revised allocations of hours for personnel effort. Each table shows the number of hours for each team member broken up by the tasks defined in the previous section. These tasks include: Task 1 – Problem Definition Task 2 – Technology Considerations and Selection Task 3 – End-Product Design Task 4 – End-Product Prototype Implementation Task 5 – End-Product Testing Task 6 – End-Product Documentation Task 7 – End-Product Demonstration Task 8 – Task Reporting 3.2.1 Original Personnel Effort

Table 1 shows the original estimated personnel effort requirements for the project. These estimates were based upon on trends from prior project teams’ experiences.

Table 1: Original Personal Effort

3.2.2 Revised Personnel Effort Table 2 shows the revised personnel effort requirements for the project. These estimates were based upon the project team’s status at the time of the design report submission. The changes made in the overall distribution of hours reflected a greater insight into the commitment required for each task. Overall the total number of hours was reduced after further research into LabVIEW revealed that less time would be needed to design and implement the end-product.

Table 2: Revised Personal Effort

23

3.2.3 Final Personnel Effort Table 3 shows the final personnel effort requirements needed for the project. The final changes made in the hours reflected further insight into the final two tasks, tasks 7 and 8. These tasks did not require as much time as was estimated, and therefore the total number of hours was reduced. Overall the total hours for the entire project from original estimate were reduced by approximately 45 hours, or about 6% less than the original estimated hours.

Table 3: Final Personal Effort

3.3 Other Resource Requirements Other resource requirements entail all those resources that are not associated with personnel effort or financial resources. These resources may include parts, materials, and services required throughout the project as well as support for test and measurement equipment. This section details the original, revised, and final other resources required for this project. 3.3.1 Original Other Resource Requirements

Other resource requirements used in this project included an oxygen concentration meter, a DAQ board, a signal conditioning unit, and cables which were to be purchased by the client. The only other costs that were associated were the printing of materials for the project poster. Table 4 below itemizes these resources and their estimated cost.

Table 4: Original Other Resources Required

24

3.3.2 Revised Other Resource Requirements Table 5 below shows revised other resources required for the project. The revisions made reflected an overestimation of the estimated cost of the hardware. The original prices did not figure in the academic discount given by National Instruments nor shipping. Also the cost of oxygen concentration meter was also decreased due to an academic discount.

Table 5: Revised Other Resources Required

3.3.3 Final Other Resource Requirements The final other resource requirements are shown below in Table 6. The final cost took into account the purchase of an additional signal conditioning module, not originally estimated. Also the final shipping charges and prices were revised. Overall the final cost of the project increased from original estimates. This increase was due to the purchase of another module that was unanticipated.

Table 6: Final Other Resources Required

25

3.4 Financial Requirements The financial requirements are the consolidation of the monetary costs of all resources: personnel, parts, service, etc. that are needed to complete the project. This includes not only the costs relating directly to the final product itself, but also any and all costs incurred during the planning and implementation of the project. The tables below show this information with and without the calculated cost of labor. The cost of labor used was an hourly rate of $10.50. 3.4.1 Original Financial Requirements

The original estimated total financial requirements are itemized below in Table 7.

Table 7: Original Financial Requirements

3.4.2 Revised Financial Requirements Table 8 shows the revised costs for materials along with revised labor cost estimates. Combining the savings from labor and discounted equipment the reduced the financial cost by approximately $400 as compared with the original.

26

Table 8: Revised Financial Requirements

3.4.3 Final Financial Requirements

Table 9 shows the final financial resources required for this project. The final financial requirements included the purchase of another signal conditioning module, which added another $265.50 to the parts and materials subtotal. Also the final shipping costs for each of the various components were also adjusted in the financial requirements. The final total however was still lower than the original estimate of approximately $300.

27

3.5 Scheduling

28

Table 9: Final Financial Requirements

The project schedule went through some slight modifications since the initial planning of the project. These resulted from new insight into the appropriate time frame for each task. Also this evolved from team member insight and understanding of LabVIEW as well as adjusting dates for tasks which delivered a better project. The major differences that can be noted in the overall schedule are that testing and demonstration were completed earlier than initially estimated. Also the overall testing time was extended in the final schedule to meet the earlier completion date. The changes can be seen in stand-alone versions of the original, revised, and final schedules which appear in Figure 19, Figure 20, and Figure 21 respectively. The project deliverable schedule, which did not change, is located below in Figure 22.

Figure 19: Original Project Schedule

24

Figure 20: Revised Project Schedule

25

Figure 21: Final Project Schedule

26

27

Figure 22: Deliverable Schedule

4. Closure Materials This section provides information concerning the success of the project, any possibilities for commercialization, recommendations for additional work, lessons learned, risks the group encountered and how the risks were managed, project team information, and a short summary detailing the project. 4.1 Project Evaluation

Milestones for the project were evaluated as follows: • Greatly Exceeded – Minimum expectations were met with the addition of several

extra features. • Exceeded – Minimum expectations were met with the addition of one or more extra

features. • Fully Met – Minimum expectation were met. • Partially Met – Some of the minimum expectations were met. • Not Met – None of the minimum expectations were met • Not Attempted – The minimum expectations were not attempted So that a numerical project success score could be attained each evaluation was given a per unit point value. The per unit point values are as follows: • Greatly Exceeded – 1.1 • Exceeded – 1.0 • Fully Met – 0.9 • Partially Met – 0.5 • Not Met – 0.0 • Not Attempted – 0.0 The project was evaluated by the following rubric, as shown in Table 10. • Each milestone was assigned a relative importance that corresponded to the

percentage of time the milestone required. • After each milestone was evaluated, the relative importance was multiplied by the

per unit point value for each evaluation. This value was called the evaluation score. • The overall status for the project was determined by summing the priority statuses

multiplied by the per unit point evaluation values status for each milestone. • A perfect project, in which all tasks’ expectations were exceeded, would receive a

perfect 100%. It was decided that a passing score (a successful project) would be 90%. This number was decided because if any one of the major tasks’ goals, were not fully met it would result in an unsuccessful project; the score for any one of these tasks only evaluated as partially met would be slightly lower than 90.

27

Table 10: Project Evaluation

The overall evaluation score for the project was 95.5%, which reflects that all the milestones were at least fully met and many of them were exceeded. Due to the project team’s accelerated timeline for beta testing; the project team was able to deliver the project to the client well before the actual deliverable date (the end of the semester). This allowed the client and intended users adequate time to use the product and give the project team feedback. With this feedback, a number of changes were applied to the project and a 100% complete mutually successful product was created that met and exceeded the guidelines laid forth by the client.

4.2 Commercialization

This project was not designed to be commercialized. It was made solely to work with the only research laboratory equipment available to student with the equipment outlined in previous sections. However, the hardware and software integrated by the team was written to be extendable, following some programming changes, to allow for newer equipment, or collect data from similar equipment.

4.3 Additional Work

Due to the features integrated by the project team, this project could be extended to provide further control and automation to the mock fermentation vessel apparatus. The DAQ board and SCC carrier box purchased by the team would allow for control of various controls such as a voltage controlled solenoid, or a motor to set the stirrer motor control. This would allow the intended users to automate the process even more and even allow for remote control experiments over the internet. However, as the intention of the laboratory setup was to allow intended users to gain knowledge in the fermentation process, total automation would have to be decided by the client.

4.4 Lessons Learned This section describes the lessons the project team learned, including what went well, what did not go well, what technical knowledge was gained, what non-technical knowledge was gained, and what the project team would do differently if the project was done again.

28

4.4.1 What Went Well

There were several aspects of the project that went particularly well. Throughout the project the client provided a helpful understanding of the fermentation process, and very flexible when new equipment and components needed to be ordered. Also during the project the team strived to get the project ahead of schedule. This allowed the team to get to beta testing earlier than expected and allowed for more groups of intended users to test the software. This extensive beta testing allowed the team to provide the client with a fully developed program that met and exceeded their expectations. Also throughout the project the advisor, was helpful in questioning the team about the design and always looked for ways to improve the project.

4.4.2 What Did Not Go Well

Some aspects of the project proved to be very challenging. There was a steep learning curve associated with learning LabVIEW. The project team spent many hours working with and trying different implementations of code as the programming language became better understood. Also since there was only one computer available to work on the equipment with, dividing up the work proved difficult to distribute among the team. Another difficult experience for the group was determining the pin-out of the stirrer motor control and the voltages to read to get the proper signals. This was due to the fact there was no documentation for the motor, and the motor manufacturer was unsure of the exact pin-out and the corresponding voltages. However this only increased time spent by individual team members and did not affect the overall outcome of the project.

4.4.3 What Technical Knowledge Was Gained

One of the main areas of technical knowledge learned by the team was programming in LabVIEW. This knowledge was invaluable in helping create an efficient, easy to understand, easy to use program. Also by gaining this knowledge the team was able to debug problems seen while testing, and also make changes as were dictated from beta testing. Also the team learned a great deal about data acquisition, and data acquisition systems available, particularly those from National Instruments. This research into data acquisition proved valuable in understanding the need for signal conditioning, as well as how to choose sampling rate and sampling frequency. Overall the team learned a great deal about systems engineering and systems integration. As the team developed not only the hardware, but the software for the project as well, the team was able to learn how to manage, design, and debug an entire system.

29

4.4.4 What Non-Technical Knowledge Was Gained

The largest piece of non-technical knowledge learned by the team was how to troubleshoot problems. The issues encountered by team were rarely obvious, and required the team to be able to look through the entire system and find the problem. Also the team learned how to work on a shortened deadline. As our beta testing was moved up by the client, the team learned how to adapt to a changing schedule, and to prioritize tasks in order to complete on a shortened time frame. Overall this project also helped improve the teamwork and communication skills of all the team members.

4.4.5 What Team Would Do Differently If the project were to be redone, the team would have researched each of the pieces of equipment more thoroughly. This would have allowed the team to spend less time on debugging, as well as saved the project and client money overall. Also it would have been nice for the team to have a better LabVIEW programming reference, or someone who was very familiar with LabVIEW. This would have decreased the development time of the software, and would have allowed for longer beta testing with the client and intended users.

4.5 Risk and Risk Management

The following section summarizes the risks the team anticipated and encountered and how they were dealt with.

4.5.1 Anticipated Potential Risks

There were four risks associated with this project: equipment damage, human injury, loss of a team member, and an unworkable design. In order to prevent the delay due to equipment damage the team reviewed all procedures before testing the equipment. Also any user manual for the equipment was reviewed to minimize any chance of damage. To protect against human injury, the team paid special attention to the safety procedures of the lab, and took every precaution prior to working with the system. In order to prevent the negative effects of losing a team member, each of the team member’s documented tasks they performed and the team met once a week to review progress and to update fellow members of the team. In order to prevent an unworkable design, the team reviewed the design with the advisor and client prior to any purchasing. Also alternate methods were researched so if the design proved unworkable the team would not let the project schedule slip.

30

4.5.2 Anticipated Risks Encountered and Management

Of the anticipated risks the team encountered only one of them. The team broke the fermentation glass vessel while removing the old oxygen concentration probe. However this did not delay the project, as the team was able to continue work on other aspects of the project while this unit was being fixed. Also as this happened at the end of the first semester, the module was fixed during the summer break.

4.5.3 Unanticipated Risks Encountered and Management An unanticipated risk encountered by the team was the output of the mass gas flow meter being a 0-5V signal. Originally the team was under the understanding that the meter output the data is a current from 4-20mA. However, after purchasing the current module, the team discovered after speaking with the manufacturer that the current output was only available on certain units. In order to remedy a secondary voltage module was ordered. Since a voltage module was already purchased for the stirrer motor control unit, the team was able to work on the mass gas flow recording in the program while the module was being shipped.

4.5.4 Resultant Changes in Risk Management Due to Unanticipated

Risks After the team encountered the unanticipated risk of a secondary voltage module purchase, the team re-evaluated data collection system to ensure no more unintended purchases. As this was the only unanticipated problem encountered, the rest of the risk management plan was used as before.

4.6 Project Team Information The following section will detail the contact information for every person that is involved in this project.

4.6.1 Client Information Stephanie Loveland ISU Department of Chemical and Biological Engineering Office: 2033 Sweeney Hall Office Phone: 515-294-3024 Email: prairie@iastate.edu

31

4.6.2 Faculty Advisor Information Dr. Degang Chen Office: 329 Durham Office Phone: 515-294-6277 Email: djchen@iastate.edu

4.6.3 Team Members

Andrew Arndt Major: Electrical Engineering Address: 4800 Mortenson Ave. #214, Ames IA 50010 Phone: (515)-450-8650 Email: abarndt@iastate.edu

Adam Daters Major: Electrical Engineering Address: 4800 Mortenson Ave. #214, Ames IA 50010 Phone: (641)-485-5286 Email: adaters@iastate.edu

Bradley DeSerano Major: Electrical Engineering Address: 138 Gray Ave., Ames IA 50014 Phone: (319)-610-3901 Email: bdez@iastate.edu

Austin Striegel Major: Electrical Engineering Address: 125 Campus Ave #4, Ames IA 50014 Phone: (712)-660-0913 Email: astrieg@iastate.edu

32

4.7 Closing Summary A mock fermentation vessel was available for use by senior chemical engineering students to conduct experiments in their final laboratory course. The students recorded data every ten to fifteen seconds by hand and used stopwatches for timing. After the recording concluded, the data needed to be transferred into an electronic format for convenient analysis and graphing. The objective of this project was to design an automated system to collect the necessary data for the user. This system used a data acquisition card and signal conditioning modules to interface with the lab equipment. LabVIEW software was developed to collect the data and display it to the user in real-time. Also the software recorded the data into an electronic format for easy analysis and graphing by the user. Overall this project allowed end users complete access to data collected from all the laboratory equipment. This ensured a deeper more complete understanding of the fermentation process, and provided a better environment for learning.

4.8 References 4.8.1 Hardware References

1. Mass Gas Flow Meter. Omega FMA-5610 by Omega Engineering.

<http://www.omega.com/>. 1-800-327-4333. 2. Oxygen Concentration Meter. Thermo Electron Orion 3-Star by Thermo

Electron Corporation. <http://www.thermo.com/>. 1-866-984-3766 3. Stirrer Motor Control. Glas-Col GKH-Stir Tester 099D HST20N by Glas-

Col. <www.glascol.com>. a. Contact name: Lee Clark. 812-235-6167 (ext. 235).

4.8.2 Software References

1. National Instruments. “LabVIEW”. 2004. <http://www.ni.com/labview>. 2. National Instruments Discussion Forum. <http://forums.ni.com/>.

4.8.3 Other References

1. Loveland, Stephanie. “Power Requirements and oxygen mass transfer in an aerated agitated solution”.

2. EE/CprE 491 Senior Design Course Notes. By Dr. John Lamont. 3. EE/CprE 491 Senior Design Coursepack Supplement. By Dr. John Lamont.

33

Appendix The following appendices are supplements to the content found in final report.

Appendix A – User’s Manual

MMoocckk FFeerrmmeennttaattiioonn VVeesssseell AAuuttoommaattiioonn

SSooffttwwaarree UUsseerrss’’ MMaannuuaall

CClliieenntt:: DDeeppaarrttmmeenntt ooff CChheemmiiccaall aanndd BBiioollooggiiccaall EEnnggiinneeeerriinngg

SStteepphhaanniiee LLoovveellaanndd

IISSUU SSeenniioorr DDeessiiggnn TTeeaamm:: DDeecc0066--0077

AAnnddrreeww AArrnnddtt AAddaamm DDaatteerrss

BBrraadd DDeeSSeerraannoo AAuussttiinn SSttrriieeggeell

34

Appendix B – Programmers’ Guide

MMoocckk FFeerrmmeennttaattiioonn VVeesssseell AAuuttoommaattiioonn

PPrrooggrraammmmeerrss’’ GGuuiiddee

CClliieenntt:: DDeeppaarrttmmeenntt ooff CChheemmiiccaall aanndd BBiioollooggiiccaall EEnnggiinneeeerriinngg

SStteepphhaanniiee LLoovveellaanndd

IISSUU SSeenniioorr DDeessiiggnn TTeeaamm:: DDeecc0066--0077

AAnnddrreeww AArrnnddtt AAddaamm DDaatteerrss

BBrraadd DDeeSSeerraannoo AAuussttiinn SSttrriieeggeell

35

Appendix C – Testing Forms

Results

Solution

Problems Yes / No

Problem Description

Test Performed

Name:

Time:Date:

Figure 23: Team Standard Test Documentation

36

1 2 3 4 5Poor

1 2 3 4 5Poor

1 2 3 4 5Poor

1 2 3 4 5Poor

Excellent

Comments

Comments

Ease of UseExcellent

ExcellentComments

Suggestions

Name:Date:

PresentationExcellent

Comments

Data Usability

Functionality

Figure 24: Intended User Survey

37

Appendix D – LabVIEW Code Block Diagram

38

Appendix E – Software Documentation and Code CD

39