The follow is a list of a few applications written to address specific problems. Each sample includes most of the following:
Problem: An explanation of the original problem
Samples included are:
Problems: Customer had an older LabVIEW 5 application that need more automation flexibility, higher channel count of temperatures and pressures and faster acquisition speed. Simple sequences of gases was not sufficient, since one experiment could be completed in several minutes. They needed a way to automatically run an entire list of sequences and modify the list based on the results of the earlier tests. Safety conditions were also too restrictive. Control of the pulsed gas required a separate computer since the code was CPU intensive. This had to be manually enabled during the test.
Solution: Application upgraded to LabVIEW 7. The chemist could now collect 125 channels of data and control several gases at different flow rates. The pulsing was re-written to take advantage of the MIO hardware. Sequences were defined off-line using an Excel template. Sequences were called by a high-level programming flow using drop-down commands and ordered execution with conditional branching. Multiple timers and counters were included to provide several parallel conditions. Flexible safety conditions were also added to allow an unlimited number of thresholds that could trigger one of five shut-down modes. Critical inputs could be calibrated against a known standard inside the application.
Benefits: The chemist had much greater flexibility to configure experiments that would run for hours unattended. More data was now available including all data channels, all control channels and timing. Safety alarms were recorded in detail on the front panel with date and time stamps. To prevent the result files from exceeding a size that could be loaded into Excel, an intelligent log file incrementer would add an index to the log filename. A recent history of the date, time and filename were shown to provide status of this function.
Shortcuts: Persistent front panel values including all sequences restored the last state. Sequences could be run individually and be edited on the panel if required. Program editor would flag simple code errors real-time as they were made. Multiple programs could be loaded and saved easily.
Problems: Customer was only able to collect 2 samples of data for comparison at one time. This required the second sample to be re-analyzed before it could be compared to a third sample. Data was saved in ASCII format and required all analysis to be done manually when off-line.
Solution: Application written in LabVIEW 6i. The scientist could now collect unlimited data samples and compare any 2. Both calibration and curve fitting were included in the program and all results were writting directly into Excel. Later, an XML database was used to record the assay breakdown and the sample data. Finally the XML was uploaded to SQL Server.
Benefits: The scientist had much greater flexibility to analyze the data as samples were taken. Data validation could be performed before an experiment was completed. Breakdown data allowed comparison of similar experiments.
Shortcuts: Intelligent data entry by using defaults selectable from previous, 2 previous or 3 previous. Function keys used for the common functions. Included was an automatic timed collection with a delayed start. Complete sequence editor provided buttons to duplicate, delete or rearrange steps.Screen View
Problems: Analysis performed during data collection took too long and wasted valuable equipment time in the lab. Scientists had faster computers on their desk than were being used in the lab.
Solution: Application written in LabVIEW 6i to perform analysis on a batch of Excel files. A file directory was specified by browsing the disk. Files could be processed all together or individually. Files could be updated automatically, or left open in Excel if the scientist wanted to verify the results before overwriting the previous results.
Benefits: Less time spent in the lab collection data. Shorter experiments improved data consistency. Changes could be made to the analysis algorythms and then re-run on an entire set of experiments.
Shortcuts: Default directory set to the Data folder. Easy selection of all files. Auto-save would save and close all Excel documents. Program required no user interaction to process 200+ files. Results were visible on the screen before they were committed to the file.
Problems: Scientist needed to collect data from an SR850 lock-in amplifier and compare results back at his office.
Solution: Application written in LabVIEW 6i. Collected data from the SR850 and wrote an ASCII file. Added header information and instrument settings. Control mode was added to simplify the instrument setup.
Benefits: Quick setup of the instrument. User can select which parameters should be modified. Easy collection of results. Simple to open the file into Excel and compare experiments.
Shortcuts: Default values for the instrument settings and data file location. Display of data before saving allowed operator to filter out bad data.
Problems: A standalone unit was designed to monitor 20 temperatures and control 4 heaters to regulate the air temperature of a chamber. The unit required tuning of 4 PID's to optimize the temperature stability. Once the parameters were set, they needed to be saved to non-volatile memory. Long term testing to verify the stability was the last step with the data logged to a file for documentation. A serial port was available for communicating with the unit.
Solution: Application written in LabVIEW 6i to communicate the the controller unit and monitor all temperatures. PID tuning values were displayed and could be edited in the same table. All data was recorded to a log file along with a date and time stamp.
Benefits: Quick setup of the PID parameters was enhanced by a table of current settings. Any change in the table was automatically written to the unit. Graphing the temperature channels was improved by enabling individual channels. The Exit State control allowed the changes to be saved to non-volatile memory automatically.
Shortcuts: PID setting were initialized with the unit's current settings. Write and Response window allowed any of the unit's commands to be sent to the unit at any time during the process. This allowed any setting to be changed or queried.
Problems: Customer had dozens of Head/Media testers (ie. Guzik) collecting data for different disk drive products(ie. Fireball), each with many pre-production builds. A cryptic filenaming scheme was used to uniquely name each file according to the date, component vendor and build. All files were saved on a dedicated file server in a complex directory structure. To find a file, the engineer would have to browse to the drive, select the data folder, the product folder, the tester, the revision, and then the type of test performed. Then they would have to decipher the file names to locate the file they wanted. There was no easy way to compare the results of two tests, much less two builds.
Solution: Application written in Excel VBA. When the Gather tool was lauched, a dialog box would prompt for selection of tester, test type and product. These values were syncronized with a central set of values on the server that would allow them to be updated easily. Multiple checkboxes could be selected for builds and vendors. The last selection allowed for all dates or just a range of dates. When Ok was pressed, the program would search all levels of the file heirarchy and decode the filenames to produce a list of files that met all criteria. From this list, the engineer could choose to see all data files, or just a quick summary of of the Min, Max and St. Dev. of all critical parameters.
Benefits: Several minutes of frustration to locate a particular data file was reduced to just a few seconds. A dozen files scattered on the server could all be opened simultaneously. Complex statistics could be produced for any combination of parameters in just seconds. Engineer productivity was dramatically increased. Better products were brougt to market sooner. The company saved a lot of money and their stock went up.
Shortcuts: All program options were accessible by a custom pull-down menu. When the application was updated to reflect new products, the program would alert the operator. The list of matching files could be saved as a spreadsheet and kept for reference.
Problems: Data was manually being entered into a database, and then retyped into another program to create a bar code label. Errors were made in the re-typing that made the labels inaccurate. Each operator produced a different looking label. Some information needed to be retyped two or four times for similar parts. Bar code numbers could accidentally be skipped. There was no way to tell the status of the parts.
Solution: Application written in Excel VBA. The bar code number is automatically generated and the user is prompted to enter each piece of information. After the last entry the data is formatted and sent to the label program and printed automatically. A Remote Status Update program was used to relay part locations back to the master database.
Benefits: The user is prompted for each field. The data from the previous entry is automatically inserted as the default for each new entry. Current date is inserted in the Date Entered field. All entries are converted to uppercase to provide consistency. An equipment table was added to located parts anywhere in the lab. A history of equipment where the parts were used is also available.
Shortcuts: Reprint Button for duplicating bar code labels. Default value is accepted by pressing Enter. Duplicate values need only be typed once.
Problems: Engineers could not tell how their parts were progressing in the lab. The main database showed the date the parts were started, but no other information was available.
Solution: Application written in Excel VBA. A bar code wand is used to read the tracking number directly on the lab test equipment. The number is sent along with the equipment ID back to the database server. The database is updated with the status and location of the parts.
Benefits: An engineer anywhere on the WAN could access the master database and see the test equipment where their parts are located and if they are in still in process or finished. A history of equipment where the parts were tested is also available.
Shortcuts: The .XLS program file is available on the main Start menu (Win 95) providing one click access to the Update program while the tester application is still running.
Problems: A data collection and reporting station had limited functions for reporting and no analysis. The report generator was configurable by a custom macro language, but description information had to be entered manually into either the macro or the report program. Each of 4 elements on each of up to 20 reports had to be manually edited. This process took up to 3 hours including the time for printing.
Solution: Application written in Visual Basic. One screen displays all of the settings for most of the reports. The operator enters only a few items and the rest of the information is determined by analyzing the data files. When all of the entries are completed, a set of new macro files are written to a network server. The report generator then reads in the macro files and prints the report with no additional editing.
Benefits: Up to 3 hours of data entry is reduced to as little as 5 minutes of operator time. The last parameters are restored as the defaults for all settings. Date field is automatically set to the current date. Data analysis, previously unavailable, was added to the program with the results inserted into the macro and printed directly on the report. Additional analysis can be added to the program as needs change. Four different stations are support by the same executable by using a system selection box.
Shortcuts: One data entry is automatically applied to up to 16 areas. With no data changes, full program operation possible in only two keystrokes. All 20 reports can be printed automatically with a single check box.
Problems: Using a standard timing unit to control a power supply, 6 disk drives were being switched on and off for preset intervals for testing. Programming the timer units was very cryptic. All tracing of which products were tested was on paper. No intermediate information was available from the test, only a final pass or fail could be determined by a separate test.
Solution: Application written in C running under DOS. A computer was setup to control relays to switch the power supplies. The drives are wired back to the computer so as to indicate a successful start. One computer controls 30 disk drives using a multi-tasking approach. A bar code wand reads the serial number from each drive during setup.
Benefits: Pass or fail is determined on every cycle. Serial number allow the computer to track the progress of every drive tested. Comment fields allow for test information to be entered. Start, stop, number of cycles and many other parameters are easily programmed with the keyboard. A printed report recaps all information from the date and time the test started to the exact cycle of every failure. Built-in fault-tolerance allowed the system to recover from a loss of power during the test. Later additions to the system allowed a data pattern to be written to the drive which was read and verified at preset intervals.
Shortcuts: Using a specially printed bar code page, complete system operation is possible using only the bar code wand. Special mode provided to erase current data and reset all drives with re-scanning the serial numbers. A single keystroke prints all the reports for a set of drives.Screen View
Last updated on: July 25th, 2014