Fermentation Vessel Automation Final Report. Team: Dec Client: Stephanie Loveland ISU Department of Chemical and Biological Engineering

Transcription

1 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

2 Table of Contents List of Figures... iv List of Tables... v List of Symbols... vi List of Definitions... vii 1. Introduction Materials Executive Summary Acknowledgement Problem Statement Problem Statement Problem Solution Operating Environment Intended User(s) and Intended Use(s) Intended User(s) Intended Use(s) Assumptions and Limitations Assumptions Limitations Expected End Product and other Deliverables Approach and Results Functional Requirements Design Constraints Technology Considerations and Results Data Acquisition Board Signal Conditioning Oxygen Concentration Meter Detailed Design Oxygen Concentration Meter Mass Gas Flow Meter Signal Conditioning Carrier Stirrer Motor Control Data Acquisition Board Software Interfacing Implementation Process Hardware Implementation Software Implementation End-Product Testing First Phase: Testing the Individual Equipment Second Phase: Testing the Overall System Third Phase: Beta Testing Project End Results Resources Task Definitions Task 1 Problem Definition Task 2 Technology Considerations and Selection i

3 3.1.3 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 Project Reporting Personnel Effort Original Personnel Effort Revised Personnel Effort Final Personnel Effort Other Resource Requirements Original Other Resource Requirements Revised Other Resource Requirements Final Other Resource Requirements Financial Requirements Original Financial Requirements Revised Financial Requirements Final Financial Requirements Scheduling Closure Materials Project Evaluation Commercialization Additional Work Lessons Learned What Went Well What Did Not Go Well What Technical Knowledge Was Gained What Non-Technical Knowledge Was Gained What Team Would Do Differently Risk and Risk Management Anticipated Potential Risks Anticipated Risks Encountered and Management Unanticipated Risks Encountered and Management Resultant Changes in Risk Management Due to Unanticipated Risks Project Team Information Client Information Faculty Advisor Information Team Members Closing Summary References Hardware References Software References Other References Appendix Appendix A User s Manual Appendix B Programmers Guide ii

4 Appendix C Testing Forms Appendix D LabVIEW Code Block Diagram Appendix E Software Documentation and Code CD iii

5 List of Figures Item Page Figure 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 Figure 11: SCC carrier SC Figure 15: NI SCC-AI Series Isolated Analog Input Module Wiring Block Diagram Figure 17: Final Graphical User Interface Figure 18: Software Block Diagram Figure 19: Original Project Schedule Figure 20: Revised Project Schedule Figure 21: Final Project Schedule Figure 22: Deliverable Schedule Figure 23: Team Standard Test Documentation Figure 24: Intended User Survey iv

6 List of Tables Item Page Table 1: Original Personal Effort Table 2: Revised Personal Effort Table 3: Final Personal Effort Table 4: Original Other Resources Required Table 5: Revised Other Resources Required Table 6: Final Other Resources Required Table 7: Original Financial Requirements Table 8: Revised Financial Requirements Table 9: Final Financial Requirements Table 10: Project Evaluation v

7 List of Symbols None vi

8 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

9 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

10 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 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

11 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 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 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

12 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

13 1.4 Operating Environment All equipment is housed in the teaching laboratory of Sweeney Figure 4 below shows the laboratory setup in Sweeney This room is subject to a temperature controlled environment of 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) 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 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

14 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 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 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

15 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

16 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

17 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 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

18 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 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

19 2.4 Detailed Design 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. 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

20 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 Figure 7: Orion 3-Star Meter provided the meter, probe, probe stand, and calibration materials for an approximate cost of $1335. This unit was purchased from VWR Scientific. 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

21 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. Figure 9: Omega FMA Series 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 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 $

22 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 $ 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

23 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 Stirrer Motor Control 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 Figure 14: GKH Stir Tester 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

24 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 $ Data Acquisition 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 Figure 16: NI PCI-6221 DAQ Board an adequate signal sampling for the analog input signals. This board was purchased from National Instruments at an approximate cost of $ 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 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

25 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 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

26 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 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 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 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

27 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

28 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 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 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 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

29 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 3. Resources 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. 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 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 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

30 3.1.3 Task 3 End-Product Design Construct a series of VI s that define the functionality of the technology selected Task 4 End-Product Prototype Implementation Integrate the VI s developed in the design process into a main GUI system Task 5 End-Product Testing Test the product to check that it meets all operational and user-defined requirements Task 6 End-Product Documentation Document all the details of the product design, and develop an end-user manual and maintenance documentation Task 7 End-Product Demonstration Demonstrate the functionality of the product to the client, advisor, and industrial review panel 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

31 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 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 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 endproduct. Table 2: Revised Personal Effort 23

32 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 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

33 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 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

34 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 $ Original Financial Requirements The original estimated total financial requirements are itemized below in Table 7. Table 7: Original Financial Requirements 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

35 Table 8: Revised Financial Requirements 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 $ 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 $

36 Table 9: Final Financial Requirements 3.5 Scheduling 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

37 Figure 19: Original Project Schedule 24

38 Figure 20: Revised Project Schedule 25