Improving Test Throughput on a Monitored Run-In System for Medical Oxygen Concentrators

Transcription

1 Control and Simulation, Data Management, Inspection and Placement/ Industrial Controls/Devices/Systems LabVIEW for Windows LabVIEW SQL Toolkit NI-Serial PCI-485i/2 RS-485 interface Improving Test Throughput on a Monitored Run-In System for Medical Oxygen Concentrators by David J. Boyd, Senior Test Engineer, Respironics The Challenge: Developing a new software application for monitoring performance of multiple oxygen concentrators throughout factory run-in test, improving operator efficiency, test coverage, unit performance data archiving, and overall throughput, while preserving the hardware of an existing custom system. The Solution: Using LabVIEW to quickly develop our application and controlling diverse hardware components using custom serial protocols, with ActiveX integration for a novel, walkabout user interface. Introduction Medical oxygen concentrators are used to provide oxygen therapy for patients with chronic obstructive pulmonary disease (COPD) and other respiratory conditions as an economical alternative to compressed or liquefied O2 systems. Concentrators work on the principle of differential adsorption rates for nitrogen and oxygen when pressurized air is passed over a suitable zeolite or molecular sieve. The primary components of Respironics Millennium concentrator include an air compressor, a dual-chambered canister containing the sieve medium, an accumulating tank, check and solenoid valves, filtering and noise abating components, drive electronics, an outlet pressure regulator, and an integrated metering valve and flowmeter. Models are produced for domestic and international use, and optionally include an internal circuit for monitoring outlet oxygen purity. Project History As a part of the team readying the Millennium series of oxygen concentrators for production, the Test Engineering group worked with the Millennium s design group to develop a production test plan. Drawing from experience with prior concentrator designs, the plan specified a factory run-in test during which, at intervals of one hour or less: Oxygen output purity would be verified under conditions of maximum rated output flow Alarm circuitry would be verified to indicate no-flow conditions Output pressure under no-flow conditions would be checked On units equipped with an Oxygen Performance Indicator (OPI), the internally derived oxygen output purity measurement would correlate with the verified value This plan represented a departure from prior test methods, which had verified performance only at the end of an unmonitored run-in period, using a portable test cart pushed along a stationary row of concentrators that moved through run-in as a group. To accomplish testing during run-in, the Test Engineering group designed an automated system supporting 30 units under test (UUTs) via a cascaded arrangement of valves, a set of mass flow controllers and pressure transducers, and a Siemens OXYMAT 6 oxygen analyzer. The system included a distributed I/O subsystem to interface each UUT through a diagnostic connector incorporated in the Millennium design. An outside firm was contracted to supply a custom printed circuit design for a digital and analog I/O module that formed the basis of the distributed I/O as well as the control of the pneumatic components. The contractor also developed most of the original test application, in C. System Details

2 The contractor s custom I/O module was designed and programmed to be compatible with devices communicating via the Optomux serial protocol, a popular, relatively low-speed interface developed by the OPTO22 Corporation. It provides eight channels of analog input, two channels of analog output, eight bits of digital input, eight bits of digital output, and a few miscellaneous timer/counter inputs. The serial interface is two-wire RS-485 permanently coded for 19.2Kbaud, and each module maintains a serial device address in nonvolatile storage. Thirty modules, sharing one NI-485 port on the PC, are mounted in the overhead wiring and hose troughs and provide the diagnostic interface to the concentrators. Six modules, sharing the other NI-485 port, are mounted on the shelves within the test rack to control the valves, mass flow controllers, and pressure transducers. Each shelf contains a one-of-five valve manifold followed by an MKS mass flow controller. Additional valves on each shelf can occlude the selected UUT output into a pressure transducer, or route one shelf s output to the Siemens analyzer. When not selected for measurement, UUT outputs are vented to atmosphere. The module on the topmost shelf also converts the output of an ambient temperature/ humidity probe mounted outside the rack. A photo of one of the systems as it currently exists is shown in Figure 1. Figure 1 Millennium Automated Run-In Test System (MARTS) Limitations Two installations of the run-in test system were built in the time period, while the original software went through numerous revisions, both by the contractor and later by Test Engineering personnel. Most revisions attempted to improve scheduling of testing of multiple UUTs, which necessarily shared test resources at different levels. The critical O2 measurement cycle was only completed once per hour per UUT, and UUT status was only checked during the measurement window. The serial protocol between the PC and I/O modules was also the subject of many attempted fixes due to intermittent communication failures of unknown origin, requiring operators to re-test units manually. The test results were recorded on the PC s hard drive in a format not readily distributed. The system used an I/O module to obtain the Siemens analyzer reading via its analog chart recorder output, involving unnecessary reading conversions, instead of using the Siemens serial interface. The application was not well regarded by test operators

3 because it required them to return to the PC, navigate a series of onscreen dialogs, and type in in-process identifiers to add each UUT. The running status of the test system and of the UUTs was difficult to determine, and failures were only flagged at the end of the run-in period. Enhancements from LabVIEW In the spring of 2000, the author was assigned the task of developing a LabVIEW -based test application to replace the original software, to be ready in the fall when the Georgia plant relocated into a single, new building a few miles from the existing facilities. LabVIEW made it easy to implement a queued state machine software design to schedule the test resources, increasing test cycles to three per hour per UUT, and ensuring continuous monitoring of UUT status. Displays clearly reflect test progress and resource assignments, seen in Figure 2 and Figure 3. Using functions from the SQL Toolkit, all test data is logged to an Access database kept on a server, which may be queried in real time by Engineering, Quality Assurance, and Manufacturing personnel. LabVIEW helped uncover a longstanding bug in the I/O module s protocol code, and implement a workaround. The Siemens analyzer protocol was implemented in LabVIEW, increasing O2 measurement accuracy and permitting inclusion of analyzer status. Figure 2 Millennium Concentra tor Run-In Main Window, Showing Unit Status and Most Recent Test Results Figure 3 Millennium Concentrator Run-In Rack Status, Showing Test Resource Assignments and Recent O2 Readings A major enhancement to the user interface involved freeing the operator from returning to the PC to interact with the test system when adding, removing, or checking status on UUTs. To do this, Manufacturing began using barcode in-process IDs, and an Intermec wireless barcode scanner was added to the system. To provide response to the operator, the author used the ActiveX client capabilities in LabVIEW to call Microsoft Speech API text -to-speech methods, and fed the PC s soundcard output to a low-power assisted-listening transmitter added to the system. With the wireless barcode scanner and the

4 battery-operated belt receiver, the operator can now move anywhere along the test line, adding, removing, and checking on UUTs, as shown in Figure 4. This approach also allows the test system to actively direct the operator, by voice prompts, to remove UUTs when they complete run-in or fail a test cycle. When a passing UUT is removed, the application prepares a certificate with summary results and prints it at a final QC station where the UUT is serialized before packing. A reprint of this is shown in Figure 5. Failing UUTs generate a detailed test report at a repair station printer. Figure 4 Operator with Barcode Scanner and Receiver, Close-up of Cable and UUT Barcodes Conclusions LabVIEW was an excellent development tool for rapidly creating a test application meeting all performance goals, coordinating multiple test processes, providing high-quality data presentation and archiving, and supporting novel user interface techniques. The application runs round the clock with no reliability problems. Manufacturing now has a tool that supports high-volume production while ensuring consistent high quality.

5 Figure 5 Test Certificate Printed on Successful Completion, with Average Test Results