End-of-line Testing Equipment | EOL Test2022-11-09T10:07:35-05:00

Custom End-of-line Test Equipment

  • ~100 turnkey end-of-line test systems delivered

  • Software for over 800 end-of-line test systems

  • Platinum-level National Instruments Alliance Partner

A few clients that have trusted us to deliver an end-of-line test system:

gelogosmall MOOG xerox
mitsubishielectric harris greatbatch
SKF logo alstom carrier

How we can help: our capabilities & expertise

  • Design and development of complete systems, including, software, instrumentation, panels/enclosures, and part handling machinery.

  • Automated test report generation

  • FPGA-based development for measurement, control, and computation

  • Synchronized data acquisition – even for distributed systems (TSN & GPS)

  • Signal acquisition – e.g., pressure, vibration, load, temperature, force, distance, strain

  • Custom Adapter Module Development for MAC Panel’s SCOUT mass interconnect ATE interface
  • Damage protection for the product (UUT)

  • Personnel safety

  • Real-time control

  • ITAR Registered

  • PID control loop development

  • Signal conditioning circuit board design

  • Test executives (see StepWise)

  • Power conversion (AC/DC, DC/DC, AC/AC, DC/AC)

  • Custom AC motor control

  • Common mode and high-voltage isolation custom signal conditioning circuit board design

  • Power measurements

  • Precision control

  • Power electronics

Some parts we’ve tested

  • Motors

  • Pumps

  • Compressors

  • Generators

  • Bearings

  • Data Center Uninterruptable Power Supplies

  • Rail Controllers

  • Aircraft Actuators

  • Injectors

  • Switches

  • Relays

  • Air Conditioners

  • Gas Turbines for Power Generators

  • Gears

  • Driveshafts

  • Timing Chains

  • Valves

  • Implantable Medical Batteries

  • Automotive Drive Train Components

Yes, I need an end-of-line tester »

Want more proof points?  Check out these end-of-line test case studies:

Replacing Wire-wrap Boards with Software, FPGAs, and Custom Signal Conditioning

Replacing Wire-wrap Boards with Software, FPGAs, and Custom Signal Conditioning

Electronic components of fielded systems were aging out
Reverse engineering effort converted wire wrap boards to FPGA-based I/O

Client – Amentum – A supplier for Military Range System Support

Challenge

Amentum (www.amentum.com) supports a decades-old system deployed in the early 1980s. While the mechanical subsystems were still functioning, the wire-wrapped discrete logic and analog circuitry was having intermittent problems.

Systems designed and built decades ago can sometimes have wonderful documentation packets. Nevertheless, we’ve been burned too often when the docs don’t incorporate the latest redlines, last-minute changes, or other updates.

The replacement system needed to be a form-fit-function replacement to land in the same mounting locations as the original equipment with the same behavior and connections. Below is an image of the existing wire-wrap boards and their enclosure. We had to fit the new equipment in this same spot.

Figure 1 – Original wire-wrap boards

Finally, Amentum wanted to work with Viewpoint in a joint development approach. While our joint capabilities looked complementary, we didn’t know at the start how well we would mesh with our technical expertise and work culture – it turns out we worked extremely well together as a team and neither one alone could have easily delivered the solution.

Solution

Since the team treated the existing documentation package with suspicion, we adopted a “trust but verify” approach. We would use the documents to give overall direction, but we would need details from the signals to verify operation.

Leveraging Amentum’s experience with the fielded systems, the team decided early on to record actual signals to understand the real I/O behavior. We used the system’s “test verification” unit to run the system through some check out procedures normally run prior to system usage. This verification unit enabled us to use a logic analyzer for the I/O to and from the discrete logic digital signals and an oscilloscope and DMM for the analog signals. The available schematics were reviewed to assure that the signals made sense.

With a trustable understanding of system operation, Amentum created a requirements document. We jointly worked on the design of the new system. There were both an “inside” system (in a control shelter) and an “outside” system (in the unit’s pedestal).

Some overall tasks were:

  • Viewpoint recommended an architecture for the inside application running on PXIe LabVIEW RT and FPGA layers.
  • Amentum created the system control software on a Linux PC.
  • Viewpoint developed the more intricate parts of the inside application and mentored Amentum on other parts they developed. This work recreated the existing discrete logic and analog I/O using PXIe NI FPGA boards.
  • Viewpoint designed custom interposer boards to connect harnesses to the NI PXIe equipment, including a test point and backplane boards.
  • Amentum designed and developed the cRIO-based outside system application and Viewpoint created a set of custom interposer boards to connect harnesses to the cSeries modules.

The PXIe FPGA boards handled the required 60 MHz clock-derived signals with correct phases, polarity, and so on. Furthermore, the wire-wrap boards were register-based so the PXIe had to decode “bus signals” sent over a Thunderbolt bus to emulate the programming and readouts from the various wire-wrap boards.

Figure 2 – PXIe replacement to wire-wrap boards

Amentum wanted to be able to support the LabVIEW FPGA VIs used to replace the functionality of the discrete logic. So, Viewpoint acted as mentor and code reviewer with Amentum to ramp them up on using LabVIEW FPGA effectively. Neither one of us alone would have been successful coding the applications in the allotted time. Joint knowledge and experience from both Viewpoint and Amentum were required.

Signal conditioning and harnesses needed to be reworked or replaced as well, of course, since the landing points for the wires were different in the new system. Viewpoint suggested a technique, which we’ve used frequently in past obsolescence upgrade projects, to create PCB boards that accepted existing connectors.

For the cRIO, these interposer “connection” PCBs plugged directly into the cRIO cSeries module. For the PXIe, these interposer PCBs accepted the field wiring connectors and converted them to COTS cables that connected to the PXIe modules. These interposer PCBs could have signal conditioning incorporated as needed. This approach significantly reduced the need for custom harnesses. All told, about 200 signals were passed between the PXIe and various other subsystems, and about 100 for the cRIO. This approach saved significant wiring labor and cost.

Figure 3 – cRIO with interposer boards between cSeries and field harnesses

The work to design and build the signal conditioning custom electronics was split between Viewpoint and Amentum. Viewpoint did more design than build and handed over the schematics and Gerber files to Amentum so they could manage the builds while also being able to make modifications to the boards as needed.

Benefits

Amentum wanted an engineering firm that was willing to work along side them as a partner. Joint discussions about architecture and design led to a collaborative development effort where Amentum benefited from Viewpoint’s extensive expertise and guidance on LabVIEW architectural implementation and FPGA coding style.

The main outcomes were:

  • As a partner of the team, Viewpoint acted as staff augmentation by providing experienced engineers with technical capabilities that Amentum initially lacked.
  • This team approach delivered a stronger product to the end-customer more quickly than either of us could do alone.
  • The combination of Viewpoint’s and Amentum’s experience reduced the amount of reverse engineering needed due to the lack of firm requirements.
  • Reduction of electronics obsolescence by using software-centric FPGA-based functionality. Recompiled LabVIEW FPGA could target future boards models.
  • Increased software-based functionality simplifies future updates and modifications.
  • Decrease in number of parts leading to simpler maintenance.
  • Lower wattage consumed eliminated need for an anticipated HVAC upgrade.
  • Cybersecurity concerns were reduced by using Linux-based systems and FPGA coding.

System Overview

Using software to emulate the old hardware was a critical success factor. Since the requirements were not 100% solid at the start of the project, some field-testing was required for final verification and validation. The flexibility of the software approach eased modifications and tweaks as development progressed. A hardware-only solution would have necessitated difficult and costly changes. For example, some of the changes occurred very near the final deployment after the system was finally connected to an actual unit in the field.

SOFTWARE FUNCTIONS
Emulate original discrete logic functions via FPGAs
Emulate original analog signal I/O
Overall system control via Linux PC
Maintain the same user experience as existed before
Modern application architecture for simpler maintenance
HARDWARE USED
NI cRIO chassis with various cSeries modules
NI PXIe chassis with FPGA modules to handle all the analog and digital I/O via a combination of multifunction and digital-only cards
Custom PCBs for signal conditioning and connectivity

Pump Test Station – Increasing throughput

Pump Test Station – Increasing throughput

Standardizing on testing technique & reporting
Increasing test throughput with automation

Client – Industrial pump manufacturer

Challenge

Pump manufacturers typically test their product in the same facility in which the pumps are created. These tests are well defined and based on standards created by organizations such as API and ANSI to name a few. These tests are run to verify the performance of the pump as well as provide a report to the customer demonstrating that the pump they purchased will meet their needs. Sometimes these tests become factory witness tests where the customer sits in on the testing being performed on the pumps they had purchased.

This particular pump manufacturer had a test facility where many different sizes and types of pumps could be tested.  The software provided to them by another integrator to run the test stand had the desired user interface screens, but did not function as requested, and was missing certain desired features.

Our client came to us with the following requests:

  • Evaluate the software written by the previous integrator to assess whether any of the code could be reused in the new application.
  • Ensure that existing cDAQ hardware would be compatible with changes and improvements to the software.
  • Deploy the hardware/software solution on the test site to verify it performed as required.

Solution

The Pump Test Utility was used for end-of-line test and product validation.

It had the following features:

  1. A Pump Test application that can run one of the following tests at a time:
    • Performance Test.
    • Net Positive Suction Head (NPSH) Test.
    • Mechanical Test.
  2. All test configuration and data files generated by the software must be compatible with Microsoft Excel.
  3. Ability to show vibration data real time while the test is running.

Benefits

  • Standardization of testing technique –each pump will be tested with the same procedures and calculations/algorithms.
  • Automated generation of report content and presentation – automation of this step will save hours of manually recording data and entering that data into a spreadsheet to generate the same report.
  • Automation of the reporting and elimination of the need to manually record data will increase throughput of the testing facility.

System Overview

We developed the Pump Test Utility application to allow our client’s engineers and operators to:

  • Run one of three guided tests that visually provides pump performance feedback during the test.
  • Create a test configuration user interface that will be used to store configuration information that can be recalled when testing a similar pump.
  • Automate the collection of data during the test.
  • Automate the population of report templates with the configuration and data acquired during the test.
  • View and print out vibration graphs real time during the test.

The pump test software was developed in LabVIEW.

It interfaced with simple delimited text files and Excel workbook templates to save the configuration information necessary to set up and run the required tests.

The resulting data acquired during the test, both raw data acquired from the sensors and calculated data used to characterize the pump being tested, are saved to delimited text files.

Both high-speed (10 kS/s) and low-speed (10 S/s) data are acquired.  High-speed data are graphed real time in a separate UI that allows the user to set cursors on the graph for visualization and printing to a pdf report.

Low-speed data is written to a delimited text file for archival storage and retrieval if additional analysis is required.

The high-speed data are for vibration measurements. The low-speed data are for pressure, temperature, RPM and flowrate measurements.

Flow rate and vacuum pressure were automatically adjusted using a PID loop and 4-20 mA controlled valves.

The pump test configuration is performed within the application from a series of drop-down selections populated with sensors found in an Excel workbook. The Excel workbook is updated and maintained outside the application. Once the test sensors and conditions have been selected, those selections are written to an Excel workbook for use in the reports.

The Excel ActiveX interface was used to develop the reports the client provided to their customers for the slow data. The Excel workbook template contained the formatting necessary for the reports. As the software wrote the data into the workbook, the reports were built from the formulas and formatting already configured in the Excel template.
At the end of the test, the software printed the appropriate worksheets containing the elements of the report required.  The vibration (high-speed data) is written to a binary file and a pdf.

SOFTWARE FUNCTIONS
Data Acquisition
Test Sequencing
3 Standardized Test Types
Generate Standard Table-Based Reports
Generate Pump Performance Graphs
Generate Vibration Graphs
Sensor Management Tools
Test Configuration Management Tools
HARDWARE USED
NI cDAQ Signal Conditioning Chassis
Variety of NI cSeries Signal Conditioning Modules
Pressure Sensors
Level Sensors
Flowmeters
Vibration Sensors
Displacement Sensors
Temperature Sensors
Torque Sensors
Speed Sensors

Pump Test Station

Pump Test Station

Client – Industrial pump manufacturer

Standardizing on testing technique & reporting

Reducing the number of pumps in the production queue

Challenge

Pump manufacturers typically test their product in the same facility in which the pumps are created. These tests are well defined and based on standards created by organizations such as API and ANSI to name a few. These tests are run to verify the performance of the pump as well as provide a report to the customer demonstrating that the pump they purchased will meet their needs. Sometimes these tests become factory witness tests where the customer sits in on the testing being performed on the pumps they had purchased.

Most pump manufacturers have more than one testing site at a facility to accommodate different pump types and sizes. The ability to automate these tests and to present a common look to the testing process and reports make the customer experience more positive to those reading the reports and/or witness the testing.

Our client came to us with the following requests:

  • Evaluate the software written by the previous integrator to assess whether any of the code could be reused in the new application.
  • Specify a hardware and software solution to acquire the signals needed to compute the performance results for standard tests.
  • Deploy the hardware/software solution on the first test site to verify it performs as required and then deploy to the remaining test sites at their facility.

Solution

The Pump Test Utility had the following features:

  • A Pump Test application that can run one of two different tests; a performance test and a net positive suction head (NPSH) test.
  • An Access database was used to store the available sensors for that test site. The user selected the appropriate sensors while configuring the test.
  • The test data was stored in an Excel file where each pump received its own Excel file.
  • The LabVIEW Report Generation toolkit was used to populate the Excel file with data as well as create the report for the pump

Benefits

  • Standardization of testing technique – now each pump will be tested with the same procedures and calculations/algorithms used are standardized across all test sites within the facility.
  • Standardization of report content and presentation – now every customer that purchases a pump from our client will receive a report with identical information presented and that information will have been derived from the same calculations/algorithms.
  • Reduction of the number of pumps in the production queue (and hence inventory) by roughly as much as 1/2 due to faster data acquisition and especially the archiving of the test results and the generation of the final report and its associated calculations.

System Overview

We developed the Pump Test Utility application to allow our client’s engineers and operators to:

  • Run one of two guided tests that visually provides pump performance feedback during the test.
  • Create a test configuration file based on an Excel template that will be used to store test data as well as generate a report.

The pump test software was developed in LabVIEW and interfaced with an Access database and Excel workbook to acquire the configuration information necessary to set up and run the required tests. The resulting data acquired during the test, both raw data acquired from the sensors and calculated data used to characterize the pump being tested, are saved to the Excel workbook. Both high speed (10 kS/s) and low speed (10 S/s) data are acquired and stored into one data file for archival storage and retrieval if additional analysis is required. The high-speed data are for vibration and sound measurements and low speed data are for pressure, temperature, RPM and flowrate measurements.

The pump test configuration is performed within the application from a series of drop down selections populated with sensors found in an Access database. The database is updated and maintained by the client through a series of user interfaces within the application. Once the test sensors and conditions have been selected, those selections are written to the Excel workbook for use in the reports.

The LabVIEW Report Generation Toolkit software was used to develop the reports the client provided to their customers. The Excel workbook template contained the formatting necessary for the reports. As the software wrote the data into the workbook, the reports were built from the formulas and formatting already configured in the Excel template. At the end of the test, the software printed the appropriate worksheets containing the elements of the report required.

SOFTWARE FUNCTIONS
Data Acquisition
Test Sequencing
Metric or SAE Units
Multi-Level User Authentication
2 Standardized Test Types
Generate Standard Table-Based Reports
Generate Pump Performance Graphs
Generate Vibration Graphs
Sensor Management Tools
Test Configuration Management Tools
HARDWARE USED
NI cDAQ Signal Conditioning Chassis
Variety of NI cSeries Signal Conditioning Modules
Pressure Sensors
Flowmeters
Vibration Sensors
Displacement Sensors
Temperature Sensors
Torque Sensors
Speed Sensors

Pump Test Station Used Across Multiple Locations Worldwide

Pump Test Station Used Across Multiple Locations Worldwide

Client – ITT Goulds Pumps

Challenge

Pumps are used for everything from sump pumps for the consumer home market all the way to large pumps for industry capable of moving thousands of gallons per minute. Just as varied is the fluid being pumped: from water to slurries to hydrocarbon-based fluids.

Pump manufacturers typically build and test in plants across the world and each of those facilities is responsible for testing every pump manufactured at that site to ensure that the pump will perform as the customer expects. These tests are well defined and based on standards such as API, ANSI and other organizations. These standards provide test procedures but do not give details as to how to perform the tests. Each site typically tests their product without guidance as to how to satisfy the aforementioned standards. As a result, differing hardware and software solutions are usually put in place to test the individual site’s products.

Such varied testing systems make it exceedingly difficult to compare test results across testing sites, both within plants and between plants.

We were asked by our client to create a homogeneous test platform with which they could compare data across manufacturing plants and test sites within the plants as well as automate calculations of plant performance metrics and reporting.

This client engaged us to develop and implement a software and information storage solution that could run the prescribed tests on any testing site and make these data available to their engineers. These tests were to be semi-automated and guide the test operator through a test ensuring that the procedure and the resulting data were collected in the same manner on every test site, worldwide.

Solution

The Pump Test Globalization application consists of the following sub-applications:

  • A Pump Test application that can run 1 of five different tests simultaneously to reduce the amount of time the UUT is under test. A separate data file is generated for each test and those data files are stored in the database along with the test results.
  • A Test Configuration application that helps to manage the orders and the tests association with those orders.
  • A Report Generation application that creates a report for each test run on a pump. Additional performance graphs are generated along with options for graphs depicting vibration and orbital performance of the pump.

Benefits

  • Standardization of testing technique – now each pump will be tested with the same procedures and calculations/algorithms used are standardized across all manufacturing test sites.
  • Standardization of report content and presentation – now every customer that purchases a pump from our client, regardless of origin of manufacture, will receive a report with identical information presented and that information will have been derived from the same calculations/algorithms.
  • Ability to generate manufacturing performance data – metrics such as first pass yield may be calculated for all manufacturing sites. Data from all manufacturing sites may now be compared.
  • Abstraction of data acquisition hardware – measurement data can be acquired from a variety of sources including OPC servers and NI DAQ Hardware. With this abstraction, the client’s existing hardware was reused where it made sense and replaced with new hardware as needed.

System Overview

We developed Pump Test, Pump Test Configurator and Pump Test Report Generator applications to allow our client’s engineers and operators to:

  • Run one or a series of guided tests that visually provides pump performance feedback during the test.
  • Configure a test for a specific pump model number and serial number. This configuration is read in by the Pump Test software to set up the test according to the configuration.
  • Generate a report that would be sent with the pump to their customer showing how the pump performed and that it met the customer’s requirements.

The pump test software was developed in LabVIEW and interfaced with a SQL database to acquire the configuration information necessary to set up and run the required tests. The resulting data acquired during the test, both raw data acquired from the sensors and calculated data used to characterize the pump being tested, are saved to the database. Both high speed (10 kS/s) and low speed (10 S/s) data are acquired simultaneously and stored into one data file for archival storage and retrieval if additional analysis is required. The high-speed data are for vibration and orbital measurements and low speed data are for pressure, temperature, rpm and flowrate type measurements.

The pump test configuration software was also developed in LabVIEW and is a separate application that uses a SQL database on the back end. The database is located on a secure server and has been designed to retain the following information:

  • Lists of all the manufacturing and test facilities.
  • List for all the motors used for running the pumps.
  • List for all the available sensors and hardware for each test station for every manufacturing plant.
  • Ability to associate each sensor with a hardware channel for acquisition.
  • Create and edit orders that contain pump specific information such as model number and serial number.
  • Create and edit test configuration information for a given order.

The report generation software was also developed in LabVIEW and provides the user a means to create standard reports for each of the test types. Additional addendums to the standard report can be created to include graphs utilizing the high-speed data such as vibration and orbital information.

SOFTWARE FUNCTIONS
Data Acquisition
Test Sequencing
Test Configuration Verification
Language Localization
Metric or SAE Units
Multi-Level User Authentication
5 Standardized Test Types
Generate Standard Table-Based Reports
Generate Pump Performance Graphs
Generate Vibration and Orbital Graphs
Pump Order Management Tools
Sensor Management Tools
Test Configuration Management Tools
HARDWARE USED
NI cDAQ Signal Conditioning Chassis
Variety of NI cSeries Signal Conditioning Modules
Various OPC Servers for PLC Communications
Pressure Sensors
Flowmeters
Vibration Sensors
Displacement Sensors
Temperature Sensors
Torque Sensors
Speed Sensors

Custom Test System Using NI PXI for Electrical Test

Custom Test System Using NI PXI for Electrical Test

Updating an obsolete tester that maintains functionality

Client – Medical Device Manufacturer

Challenge

Our client already had a test system in place, but the tester (really two test systems testing two different product variants) was becoming obsolete.  The tester was old, hardware was failing, and it was getting harder and harder to keep it reliably running.  They wanted a new tester to improve reliability, but maintain the functionality of the existing tester to keep the FDA-mandated verification and validation time to a minimum.

Solution

The updated end-of-line manufacturing test system maintains the functionality of the old test systems, but with updated hardware and software.  The same software is utilized for both the manual test system update and the automated test system update.  Our client deployed 6 manual testers and 1 automated tester.

Benefits

  • Improved maintainability and reliability with updated hardware and software
  • Maintains existing test system functionality to keep certification time down

System Overview

There were two variants of the new test system.  One was for an older product line that utilized manual test, with an operator that connected/disconnected the UUT, and initiated the test.  The other was an automated tester, integrated into a manufacturing machine.  Both testers utilized custom fixtures (provided by the client), off-the-shelf NI measurement hardware (selected by Viewpoint), and custom test software (developed by Viewpoint).  The software is configurable for both the manual test system and the automated test system.

SOFTWARE FUNCTIONS
Read UUT limits from config file
Perform tester self-test
Measure impedance
Power UUT
Pressurize UUT
Measure UUT output
Perform leak down pressure test
PLC interface (for automated tester) for start, done, pass, fail
HARDWARE USED
Custom test fixture (provided by client)
NI PXI
PXI Multifunction I/O Module
PXI Digital I/O Module
PXI Relay Module
PXI Digital Multimeter Module
PXI Switch Matrix Module

*- images are conceptual, not actual

Manufacturing Inspection System Uses Machine Vision to verify assembly and labeling

Manufacturing Inspection System Uses Machine Vision to verify assembly and labeling

Reducing human error with automated inspection

Client – Automotive Component Manufacturer

Challenge

Our client already had an end-of-line tester in place.  However, preventing incorrect product shipments drove them to add machine vision capabilities to verify that the part being packed is of the correct physical configuration and that the part was labeled correctly.  They also wanted a more automated way to track which serial numbers were being shipped.

Solution

Viewpoint enhanced the existing end-of-line tester by adding machine vision capabilities to verify correct part assembly and part labeling.  This capability also allowed for automated tracking of which parts went into which shipping container.

Benefits

  • Automated part assembly verification to reduce human error from manual visual inspection
  • Automated label verification to reduce the chance of shipping the wrong product

System Overview

The enhanced system added machine vision-based capabilities to an existing end-of-line manufacturing test system.  New hardware (cameras, lighting, fixture) was selected and integrated by the client.  Viewpoint developed the image analysis routines using the Cognex In-Sight software.  These routines were then downloaded and controlled using LabVIEW software developed by Viewpoint.  In addition, the LabVIEW GUI contained the image acquired by the camera and the results of the image analysis.  The tester can inspect four different part types.

The software essentially performs the following functions:

  1. Look up the expected characteristics of the part being inspected.
  2. Populate the on-camera In-Sight “spreadsheet” with configuration information used in the image analysis/inspection.
  3. Trigger the image capture and read results from the on-camera spreadsheet.
  4. Use the on-camera image analysis to check a critical angle of the part as the part is set in the nest fixture.
  5. Check the information laser etched on the part and compare the results with what should be on the part (relative to the barcode read in for the lot and the 2D barcode on the part) using the OCR/OCV capabilities of the camera.
  6. Perform other physical part characterization image analyses to verify the part was correctly labeled & assembled.
SOFTWARE FUNCTIONS
Look up expected part characteristics
Trigger image capture
Read results of on-camera image analysis
Display image taken by camera and show if test passed or failed
Monitor contiguous part failures & initiate shutdown
Log vision test failures to database
HARDWARE USED
Existing end-of-line tester
Test Fixture
(qty 2) Cognex camera
Lighting for camera
INTERFACES / PROTOCOLS
TCP/IP
HAVE A SIMILAR CHALLENGE? GET A CONSULTATION »

Automated Manufacturing Test System for Electronic Medical Devices

Automated Manufacturing Test System for Electronic Medical Devices

Using PXI and LabVIEW for modular testing of over 1,000 different models

Client – a medical device manufacturer and repair depot

Challenge

Our client manufactures hospital patient pendants used to control bed frame, nurse calling, and TV functions. The company was also growing after adapting a business model of being a repair depot for older designs for their own and the pendants of other manufacturers. As such, their products are very high mix and medium volume.

The basic functions for all these pendant models are closely related, so the client wanted a means to build a single automated test system that could verify functionality for 1000s of models. And, since the products are medical devices, the testers needed to comply to 21 CFR Part 820 and Part 11.

Solution

The testers were designed to support the common measurements needed to test the circuitry of the devices as well as the complex signals required to drive TVs and entertainment systems. A test sequence editor was created which allowed the client to create as many test sequences as needed to test each specific pendant model by creating a list from pre-defined basic measurement steps configured for each specific measurement.

For example, each device had a power supply, the voltage of which needed to be tested. To test a specific model, a voltage measurement step was added to the model-specific sequence and configured with the upper and lower measurement limits for the power supply. The complete test sequence was created by adding and configuring other measurements test steps as needed. Each test step could also be configured with switch configurations to connect the measurement equipment, such as a DMM, to the proper pins on the device circuit board.

Using this configuration process, the client was able to support the testing of well over 1000 models without any programming. A separate application was developed to create these test sequences which were saved as XML and fed to the test system for selection and execution.

The test execution was managed by NI TestStand and the pre-defined common test steps were written in LabVIEW. The test sequences and test results were interfaced to the client SQL database which they used in their ERP system. This ERP system used the results produced by the test system to help manage the workflow of production, for example by assuring that all units had passed testing before being shipped. Part 11 compliance was handled through checksums used to check if results had been modified.

Benefits

  • Test sequence editor used to develop and maintain tests for 1000s of device models
  • Enabling our client to create test sequences without programming reduced overall development costs by about 50%.
  • Test sequences and test results were stored in the client’s ERP SQL-compliant database for integration with manufacturing workflow
  • Modular and common software developed for the test systems reduced the V&V effort during IQ & OQ by allowing testing of the test execution application separate from the individual test sequences.

System Overview

The automated test system was able to execute each test sequence in three different modes: engineering, service, and production. Each mode has been specifically designed for various departments throughout the manufacturing floor. Typically, the manufacturing engineer would verify the sequence by executing it in engineering mode. Once the test sequence parameters pass, it was then approved for production testing.

During actual product testing, an approved and digitally-signed test sequence is loaded and executed via the test sequencer, designed for automated production. During execution, test results are displayed to the operator and simultaneously pushed to a database. The automated test system produces a record for each tested device, indicating the disposition of each test step and the overall performance of the device. All result data are digitally signed and protected from tampering.

The architecture of the test system follows a typical client – server model.

All client stations communicate with a central ERP and SQL server and each computer is secured by applying operating system security. The SQL server contains all of the test definitions, device history records and results. Information from it can be queried at any time by quality engineers throughout the organization, assuming they have proper login access. This provides real time status about products ready for shipment. Also, other than the software running on the client stations, no other user has permission to write or modify any information in this database. The client is able to keep the server in a protected area separating it from the manufacturing environment while the client test stations are placed throughout the manufacturing area.

Surprisingly, there were only twelve test steps needed to uniquely configure and be combined to create sequences to test well over 2000 unique models. Test steps are capable of measuring basic resistance, current and voltage parameters as well as perform sound quality measurements and high speed digital waveform analysis. Several tests were designed to be subjective while others are fully automated and test to a specified acceptable tolerance. During configuration, each test step requires the manufacturing engineer to enter expected values and tolerance limits to define pass – fail status. Upon testing, the devices are attached to a generic interface connection box and the test system makes the appropriate connections and measurements.

SOFTWARE FUNCTIONS
NI TestStand
Low-level measurement drivers to interface to a DMM, signal generator, switches, and data acquisition cards.
Measurement-based test steps
Test sequence execution
Test sequence management
User access management
Test report creation and management
Verification of test sequence content and ability of user to execute
Verification of the content of the test results
HARDWARE USED
NI PXI chassis and controller
NI PXI acquisition cards for analog measurements
NI PXI acquisition cards for digital input and output
NI PXI DMM for precision voltage and resistance measurements
Audio amplifier for speaker tests
INTERFACES / PROTOCOLS
Ethernet

*- images are conceptual, not actual

Yes, I’d like to chat about my test system needs »

Automated Manufacturing Test Systems for Medical Diagnostic Equipment

Automated Manufacturing Test Systems for Medical Diagnostic Equipment

Using NI PXI and LabVIEW as a common architecture for multiple test systems testing several subassemblies

Client: a manufacturer of automated blood analysis machines

Challenge

Our client was embarking on a complete redesign of their flagship automated in-vitro Class 1 blood diagnostic machine. In order to meet schedule goals, the design and build of several automated test systems needed to occur in parallel with the overall machine. In a major design paradigm shift, many components of the machine were being manufactured as modular subassemblies, every one of which was an electro-mechanical device. Thus, multiple testers were required to test each of the specific subassemblies in the machine. And, since this was a medical device, the testers needed to comply to 21 CFR Part 820 and Part 11.

Solution

With a looming deadline, the testers needed a common architecture, so that all testers could leverage the development from the others. Since each subassembly could be tested independently of the overall machine prior to final assembly, the design of the testers was based on a common measurement and reporting architecture, written in LabVIEW, that interfaced to the customers Part 11 compliant database for testing procedures and measurement results. Furthermore, procedures and validation checks for calibration of the testers were part of the overall test architecture.

Benefits

  • Modularization of the test system architecture aided development and maintenance
  • Reduced overall development costs due to standardization of test sequence steps and reporting
  • Both test sequences and test results were stored in a managed database that satisfied 21 CFR Part 11 requirements
  • Modular and common software developed for the test systems reduced the V&V effort during IQ & OQ.

System Overview

Since multiple subassemblies were being tested, with one part-specific test system per part, the automated test systems used as much common hardware as possible to simplify the development effort through common hardware drivers and test steps. Measurements were made with PXI equipment. Test steps and the test executive that executed the test sequence(s) were developed using LabVIEW.

The types of test steps required to verify the proper operation of each subassembly were categorized into basic operations, such as voltage reading, pulse counting, temperature reading, and communications with on-board microcontrollers. The specifics of each measurement could be configured for each of these measurement types so that each test step accommodated the needs of the specifics of each subassembly. For example, one subassembly might have needed to run the pulse counting for 2 seconds to accumulate enough pulses for accurate RPM calculation while another subassembly might have only needed 0.5 seconds to accomplish that calculation.

The configuration of a test step algorithm was accomplished via an XML description. The accumulation of these XML descriptions of each test step defined the test sequence run on that specific subassembly.

Test results were associated with these test sequences by completing the entries initially left blank in the test sequence, so that all results were explicitly bound to the test sequence.

The operator user interface distinguished between released and unreleased test sequences. With unreleased test sequences, engineers could try the most recent subassembly designs without needing to wait for final validation. The released sequences were only available to test operators. This login-driven branching was managed using the Windows login, so that the client employees could use their company badge-driven login process. Once logged in, the user would be able to execute the test sequence in automated mode, where all steps happen automatically, or manual mode, where one step could be operated at a time.

Furthermore, the Windows environment was locked down using built-in user account group policies to designate the level at which a user could access Windows or be locked into accessing only the test application.

V&V Effort

During the V&V effort, each test sequence was verified for expected operation, against both known good and bad parts. Once verified, the sequence was validated against the requirements and, when assured to be as expected, a checksum was applied to the resulting XML test sequence file and all was saved in a Part 11 compliant database. Upon retrieval, when ready to run a test, the sequence was checked against this checksum to assure that a sequence had not been tampered.

Test results, saved as XML in the same file format as the test sequence, were also surrounded by a checksum to verify that no tampering had occurred.

The IQ/OQ efforts were handled in a traditional manner with the client developing the IQ/OQ documentation, with our assistance, and then executing these procedures, again with our assistance.

SOFTWARE FUNCTIONS
Low-level measurement drivers
Measurement-based test steps
Test sequence execution
Test sequence management
User access management
Test report creation and management
Verification of test sequence content and ability of user to execute
Verification of the content of the test results
HARDWARE USED
PXI chassis and controller
PXI acquisition cards for analog measurements
PXI acquisition cards for digital input and output
CAN card
INTERFACES / PROTOCOLS
Ethernet
CAN

*- images are conceptual, not actual

Yes, I’d like to chat about my test system needs »

Creating an N-Up Tester to handle increased production volume demands

Creating an N-Up Tester to handle increased production volume demands

Enhanced throughput offers ROI payback period of less than 1 year

Client

Automotive Components Supplier / Manufacturer

Challenge

The company makes automotive components in very large volume, several part models each at more than 1 million per year.

The client’s primary concern was conserving floor space. They were completely out of spare manufacturing space.

Solution

Viewpoint created an N-up NI PXI-based Manufacturing Test System. In this case, N=6 because analysis showed that a 6-up electronic part tester allowed the test operator to cover the test time with the load/unload time.

At the high volumes needed, the client needed to parallelize as much as possible. The cost of 6 sets of test equipment and device sockets was less important than speed. Using the equation:

ProfitPerUnit x NumberAdditionalPartsPerYearAfterParallelizing > CostOfTestEquipment,

being able to completely parallelize made the number of extra units per year large enough that the payback time for completely duplicating the measurement instrumentation for each UUT socket was less than about 1 year.

Benefits

  • Paid for itself in less than 1 year by the enhanced throughput.
  • This approach consumed about 20% the floor space that would have been used for duplicating the test system 5 more times (for a total of 6 testers)

System Overview

Viewpoint developed an NI TestStand application that ran 6 instances of the test sequence independently of each other utilizing the duplicated PXI-based test equipment. The common parts of the overall master sequence were:

  • Startup check for the entire test stand
  • Shutdown of the entire test stand
  • Archiving the test results into the database

Part handling was managed by a PLC and robot which delivered the parts from a tray into the UUT sockets. Digital bits were used for signaling the test sequence which parts were present in their sockets and ready to test.

SOFTWARE FUNCTIONS
Test System GUI
Test sequencer
Startup checker
Test Results Archiver
Yes, I need an N-up tester »

Increasing Test System Automation for Existing Tester to handle Production Volume Demand Increase

Increasing Test System Automation for Existing Tester to handle Production Volume Demand Increase

Reduced test time across several products by an average of ~25% and reduced time to create paperwork by ~3x

Client

Manufacturer of high-voltage power supplies

Challenge

The client already had an existing manufacturing test system in place. They wanted Viewpoint to enhance the tester due to an increase in production volume demand.  Viewpoint reviewed the existing test system and noted 3 areas for improvement:

  1. Automation available in the measurement instruments – most of the test equipment was automatable, via some combination of serial, GPIB, or Ethernet interfaces. Furthermore, some equipment, such as an oscilloscope, had the ability to store and recall setup configurations. The test operators already used these configurations to decrease setup time for the next test step. Most test equipment did not have automated setup.
  2. Operator time spent on each test step – the client had been through a Lean assessment and had already done a good job of timing operations. However, we specifically noted that the operator was manually connecting to the test points and manually transcribing to paper the measurement results from instrument displays.
  3. Automating the connections – many types of product models were being tested at this test system. Connecting the test equipment to all sorts of products would require either 1) many types of test harnesses and connectors or 2) a redesign of the products to make test connections simpler and quicker.

Solution

The enhanced automated test system included automation of instrumentation interfaces, a test executive to run the test sequences, automated test report generation, and automated test data archiving for the electronic UUT.

Benefits

  • Reduced total test time across several products by an average of ~25%.
  • Time to create paperwork was reduced by ~2/3 due to automated data collection.

System Overview

The enhanced test system included the following updates:

  • Test sequence automation
  • Automated test report generation
  • Automated test data archiving
  • Automation of instrumentation interfaces
  • Configurable automated test steps associated with each type of measurement instrument. The test operators would create a sequence of steps to setup each instrument and record the resulting measurement. The sequence of steps could be saved and recalled for each product to be tested, so the instruments could be used automatically.
  • New programmable meter – integrated the new DMM meter with a programmable interface to replace the one that was not automatable.
  • Foot switch integration – Since the connections to the test points were manual, a foot switch allowed the operator to take the measurement and advance to the next step.

The StepWise test executive platform managed the multiple test procedures created for the different products. StepWise also handled creation of HTML reports for every part tested.

SOFTWARE FUNCTIONS
Test GUI
Test Sequencer
Report Generator
Test Data Archiving
Instrument interfaces
Yes, I need to increase my level of automation »

Product Validation & Production Test System – For complex Mission-critical sub-system

Product Validation & Production Test System – For complex Mission-critical sub-system

Client

Ensign-Bickford Aerospace & Defense

Upgrade reduces per unit test time by ~40% and improves reliability of software

Challenge

The customer needed to upgrade their existing test system.  Their old test system was very manual:

  • It did not provide ability for unattended operation
  • The thermal control had to be set manually
  • They wanted to do less manual review of the data

The client develops mission-critical products, so there’s a desire to reduce manual operations because they have to explain any anomalies, and manual operations are typically more error-prone.  They needed repeatable results that they could trust.

Solution

Viewpoint developed a new test system that utilized new hardware and software, augmented by existing low level hardware and firmware.  The test system was developed to perform both functional test for production and environmental testing, and was designed to handle up to 4 DUTs at once. The test system utilizes the StepWise test executive software with custom test steps, which allowed the client to create their own highly configurable test sequences.  The system was developed in two phases, with the second phase adding support for a FPGA expansion backplane (NI CompactRIO chassis) in order to provide future capability for bringing some of the microcontroller sequence activity into the NI space. In addition, the previous version had a mix of serial, TTL, and USB instrumentation, which was not as robust as Ethernet based instrumentation. Phase II involved upgrading to all Ethernet based instrumentation, and did away with the original test system’s many manual toggle switches that could be used instead of the programmable mode through the SW.

Benefits

  • ~40% test time reduction per unit
  • ~25% reduction in anomalies that needed to be justified
  • ~500 manhours saved in test execution

System Overview

Software Functions
Test sequencing
Test report generation
Data recording/logging
Error handling
Test GUI
Oscilloscope interface
Thermal chamber interface
Power supply interface
External custom hardware interface
I need an automated test system »

Production Test of Large Uninterruptible Power Supplies

Production Test of Large Uninterruptible Power Supplies

Manufacturing Test of UPS Units Designed for Data Center Backup Power

Client: A major manufacturer of data-critical three-phase uninterruptable power supplies

Challenge

A major manufacturer of very large three-phase uninterruptible power supplies (UPSs) needed better measurement, analysis, and report generation capabilities. Their clients used these UPSs on mission critical equipment, such as data warehouse server farms, communications equipment, and so one. Existing testing procedures used equipment that did not allow for complete simultaneous coverage of all sections of a UPS unit, from input to output. Our client wanted a better understanding of the signals on each of the three phases at various locations within the UPS, especially when power sources were switched or faults were induced.

Also, in the prior test procedure, factory acceptance reports were manually assembled for our client’s end-customers, delaying the final sign-off. Finally, since the end-customer might want to run a specially configured test or run a series of tests in a different sequence than some other end-customer, our client wanted to be able to rerun certain types of tests or run tests in a customer-specific order. Thus, the test sequencing needed to be flexible and editable, possibly on the fly.

Finally, synchronization between the data collection on all signals was critical to assess functionality, since all 3-phases of the UPS output needed to be in the proper timing relationship.

Solution

At a high-level, the majority of testing a UPS relies on knowing the reaction of the UPS to changes on the input side (such as a grid power outage) and changes on the output side (such as an immediate heavy load). Thus, many of the tests performed on a UPS deal with power quality measurements, such as defined by IEEE 519 or IEC 61000 series standards, which cover both continuous and transient operation.  The StepWise test execution platform was utilized to allow the customer to develop arbitrary test sequences using the application specific test steps developed for the program.

Our solution used a cRIO to measure both current and voltage from each leg of the 3-phase power (and neutral) by using appropriate cSeries modules connected to various voltage and current test points within the UPS. The cRIO had enough slots to allow a single cRIO to measure a single UPS.

Assessment of continuous operation mainly reviewed the UPS output power quality. Here, it was important to know the amplitude and phase of each leg of the 3-phase power. Synchronous data acquisition between all voltages and current channels was needed for proper timing alignment of collected data points.

Assessment of transient operation was often a review of power ripple and recovery time. For example, in the event of grid power loss, a UPS would switch over to backup power, with the result being a small transient created on the output a UPS. Again, the voltages and currents needed to be collected synchronously to assure that event timing was aligned.

For increased power capacity, the UPSs could be connected in parallel. When ganged together, the continuous and transient behavior of each UPS needed to be compared to the others, in order to capture the behavior of the entire combined system. Consequently, each cRIO (one per UPS) had to share a clock to enable synchronous data collection across all cRIOs. A timing and synchronization module was placed into each cRIO chassis with one cRIO acting as the master clock source and the others being slaved to that clock.

The overall test system architecture has a master PC communicating with each cRIO. Each cRIO was placed in certain activity states by the master PC, such as “arm for measurement”, “transfer collected data”, and “respond with system health”. This arrangement enables the number of cRIO to shrink or grow depending on the number of UPSs being testing in parallel.

Results

The test system connected the timing module in each cRIO in a daisy-chained configuration, leading to data sampling synchronization error of less than 100 ns between all cRIOs, which translates to about +/-0.001 degree phase error for 60 Hz power signals. This timing synchronization was more than sufficient to analyze the collected waveform data for power quality and transient structure.

LabVIEW was used to create various configurable test steps that could be executed in random order as well as in an automated sequential manner. Our client was thus able to test a UPS in a predefined manner as well as react rapidly to queries from their customer when they were viewing a factory run-off test. For example, the customer might ask to re-run the same test several times in a row to validate consistent responses.

Each type of test included automated analysis routines that numerically calculated the relevant parameters against which the UPS was being checked. Not only was this automated calculation faster, but it reduced mistakes and improved reproducibility as compared to the previous post-testing partially manual calculations.

Data from all tests, even repeated ones, on a given UPS were archived for quality control purposes and made a part of the device history for that UPS.

Finally, the report generation capability built into this test system was far superior to the previous methodology by allowing our client to hand their customer a professional report package practically immediately the testing was complete. Customer satisfaction was improved substantially with this state-of-the-art test system.

Manufacturing Test – for mission-critical components

PXIe

Manufacturing Test – for mission-critical components

 

Using PXI & LabVIEW RT

Client: A major manufacturer of implantable cardiac and neural stimulators

Challenge

Our client needed several extremely reliable test systems to test the batteries that power their implantable medical devices. These new test systems were needed for two main reasons. First, the needed to upgrade existing obsolete test equipment, based on antiquated hardware and software. Second, new battery designs could not be tested on the old equipment.

A critical aspect of the new test system was the need to detect any excessive charge being extracted from the battery, thus rendering it unsuitable for surgical implantation. Thus, the test system needed to monitor the total energy withdrawn from a battery during testing to assure that it never exceeded a certain limit while also offering precise control of the type of pulses being drained from a battery.

All test results had to be stored in a database in order to maintain device history for each battery manufactured for archiving, quality control, and process improvements.

Solution

PXIe

The updated manufacturing test system is PXI-based along with a custom micro-controller-based circuit board for some low-level control. Each PXI controller communicated to the microcontroller (uC) on the custom PCB via CAN. The uC controlled the current drain from the battery while monitoring actual current and voltage from the battery at over 1000 samples per second using a precision 6.5 digit PXI DMM. Additionally, each PXI chassis was used to test many hundreds of batteries. Signal connections were handled by several switch multiplexers. Overall control of all the PXI testers was managed by a host PC connected to the PXI controller.

Benefits

  • Reduced test system cost vs complete COTS solution with combo LabVIEW RT on PXI and firmware on microcontroller-based custom circuit board
  • Enabled tight control of DUT operation on controller with microsecond level responsiveness while being supervised by higher-level PXI RT
  • Quick-reaction test abort capability
  • Test results stored to database for archiving, quality control, and process improvements

System Overview

In a simplified view, the testing proceeded by pulsing the battery with a series of different durations and varying amperages. The exact sequence of this pulsing is unique for each DUT model. Measurements were made using a PXI filled with various NI boards such as DMMs, for accuracy, and data acquisition cards, for general purpose use.

Additionally, the pulsing amperage levels needed to be tightly controlled in order to know that the tests have been performed properly. Thus, a real-time amperage control scheme had to be implemented to maintain the level requested for the pulse. We chose to accomplish this control via an analog control circuit developed using a custom Viewpoint-developed circuit board. This board was controlled via a Microchip PIC microprocessor. The LabVIEW RT application communicated with the microcontroller to setup the pulsing sequence and coordinate the start and stop of the pulsing and the NI acquisition hardware.

This custom circuitry also reduced the overall cost of the test system by about 40%.

The engineering time to design this custom circuitry was more than offset by the reduction in material costs because more than 10 test systems were deployed, allowing the non-recurring engineering effort to be shared between many systems.

When no critical issues were detected, the waveforms acquired by the PXI system were stored and then analyzed to determine the viability of the DUT. The pass/fail disposition, the waveforms, the total energy consumed, and other test results were then passed along to a master PC that managed all these results in a database for archiving, quality control, and process improvements, each set of results being tied to the unique unit serial number.
The test systems provided reliable operation for testing the large annual production volumes of the mission-critical DUTs.

SOFTWARE FUNCTIONS
LabVIEW RT – for managing the microcontroller functions and overall data collection and safety monitoring
Microcontroller application – to provide precision pulsing of the batteries
Communicate to the host PC – to both receive pulsing instructions and configurations and to return pulse waveforms for each battery tested.
MAIN HARDWARE COMPONENTS
PXI chassis & controller
PXI DMM
PXI analog input modules
SCXI multiplexing switches
INTERFACES / PROTOCOLS:
Ethernet TCP-IP
CAN
HAVE A SIMILAR CHALLENGE? GET A TEST SYSTEM CONSULTATION »

Gas Turbine Test System

GAS TURBINE TEST SYSTEM

 

A MEDIUM SCALE SCADA SYSTEM

 

Client: Dresser-Rand

Problem Scope

For this application, Dresser-Rand needed an extensible system capable of monitoring numerous signals interfaced to a large gas turbine. Well over a
thousand signals needed to be collected from an extremely varied set of data acquisition devices and instruments. The configuration of this system and
viewing of data needed to be available from any of a number of computers connected to the data acquisition network. Also, data needed to be available for additional processing on other connected networks.  Dresser-Rand required that all of the components that were necessary to run a test, such as the server, database, acquisition, configuration, and viewing, were able to be run on one computer or distributed over several computers.

Solution

This system utilizes Client-Server architecture to acquire signals from a variety of devices and logs the data to a central SQL Server database. The data is then processed and viewed on remote terminals. It is modularly designed to facilitate changes in acquisition hardware as well as viewing and processing software. There are three important components to this application: a SQL Server data management system, TCP/IP packet based messages for configuration and data, and a flexible, applicationindependent driver model.

National Instrument’s LabVIEW was used for the bulk of this project. C, Visual Basic, and Fortran were also used to develop analysis routines and interface with various pieces of hardware.

Technical Highlights

  • Client-Server technology
  • TCP/IP packet based messages for communication of data and commands
  • 100base-T local network with bridge to other company/worldwide networks
  • Remote configuration and viewing
  • SQL Server database
  • High channel count (1000+ signals)
  • Flexible data acquisition system
    • Diverse data acquisition devices: DAQ, GPIB, VXI, RS-232, PLC
    • Common driver model – drop in drivers, self-aware configuration
    • Common calculation model – drop in calculations, self-aware configuration
  • Flexible GUIs with drop in screens

Several software technologies used for various aspects of the project: LabVIEW, Microsoft SQL Server, Microsoft PowerStation Fortran, Microsoft Visual Basic, Microsoft C, Microsoft Access

System Overview

gas-turbine-test-system-overview-straight

 

Software Architecture

gas-turbine-test-system-software-architecture-straight

Automated End-Of-Line Tester Upgrade – Boiler

Automated End-Of-Line Tester Upgrade – Boiler

Automated End-Of-Line Tester upgrade makes operators and engineers happy

Client – ECR International: A manufacturer of heating and cooling systems.

Challenge

ECR has significant domain expertise in developing boiler systems.  Viewpoint has significant domain expertise in measurement and control systems.  To ensure quality control ECR International utilizes an end-of-line testing stand.  Each boiler is test fired and adjustments are made to optimize proper combustion.  Results of the testing are recorded along with the boiler’s unique serial number.

The team at ECR needed an upgrade to one of their end-of-line test systems to support an increase in production capacity without sacrificing the testing and quality assurances process.

ECR also wanted to eliminate the need to constantly adjust test limits based on temperature.  This manual adjustment process was time consuming.

They took this as an opportunity to update and clean up the code base for supportability.

ecr-look-inside

Solution

Viewpoint was asked to upgrade the existing test stand code and add a bit of functionality.  Since ECR already had the necessary hardware, Viewpoint worked with the existing hardware set, porting software and adding new features.

The updates improved usability, saved time, and increased accuracy.

The solution was delivered on time and under budget.

Benefits

  • Test time reduction and increased accuracy (automated temperature-based test parameter control)
  • Increased test flexibility (can test at multiple boiler capacities)
  • Improved operability with updated user interface
  • Improved development supportability with cleaned up code base
  • Improved IT supportability with updated code base
  • Increased stability (EEPROM test stand lock-up resolved)

System Overview

ecr-boiler-test-system-overview

I need a custom test system »

Manufacturing Test System for Electrical Components

Manufacturing Test System for Electrical Components

Replacing Obsolete Custom Electronics with cRIOs in High-Power Capacitor Testing

Modular Embedded cRIO Systems Shortens Development and Reduces Risk in Complex PC-based Test System

Client: A major manufacturer of electrical power generation and distribution equipment.

Problem Scope

This project involved retrofitting a test system used to verify operation of a high-power capacitor used in electrical power distribution. This system was originally built around 1990. Critical sections of the original test system relied on custom, wire-wrapped analog and digital circuitry to process, analyze, and isolate the high-voltage and high-current signals created by the capacitor. Analog filters, rectifiers, and comparators produced pass/fail status signals. A master PC, other measurement and control equipment, the analog circuits, and a six-position carousel were integrated to create the entire automated test and control system.

For each unit under test (UUT), test specifications are obtained from a Manufacturing Execution System (MES) and cached locally. The subsystems at each carousel position are designed to run independently. This parallel capability allows greater throughput and reduced test time per capacitor unit. In addition, as different capacitor models move through the carousel stations, the test parameters and conditions must be aware of the particular model being tested.

Test results for UUT are pushed back to the MES system for record retention and data mining. The existing MES interfaces were retained exactly for the retrofit.

Challenge

All capacitors require 100% testing prior to shipment, so the test system is critical for the facility operation. Two or even three shifts are common depending on production needs and the facility cannot afford any significant downtime. Thus, a challenge was to design and build a test system that worked and was very robust.

Another huge challenge was the lack of documentation on the existing system, requiring a sizable amount of reverse engineering to understand the test system operation before development on the new system could begin.

Furthermore, one of the most important challenges surrounded replacement of substantial amounts of original test equipment before the new test equipment could be installed. Thus, we absolutely had to minimize the time and risk in this upgrade changeover.

Technical Highlights

system-architecture-capacitor-testing

A schematic of the overall system architecture is shown in the figure. The major components of the system are:

  • Master PC for supervisory control and test execution management
  • NI cRIOs with FPGAs and Ethernet for independent yet PC-supervised operation
  • Station-specific FPGA code for replacing wire-wrap circuitry functionality
  • Integration with existing MES, safety equipment, tooling, and measurement hardware

The architecture chosen was made very modular by the capabilities offered by the cRIO. The Master PC interfaced with station-specific measurement instrumentation as needed, such as GPIB controlled equipment, and coordinated control and outcomes from the cRIOs. This additional equipment is not shown in the figure.

Solution

The Master PC coordinated all the activities including interfacing with the existing MES database and printers at the manufacturing facility. In addition, this PC provided the operator interface and, when needed, access to engineering screen on a diagnostic laptop.

The cRIOs were essential to the success of this test system. Each cRIO functioned as the equivalent of a high-speed standalone instrument.

The cRIOs at each carousel test position had to provide the following features:

  • Digital I/O for machine feedback, safeties, and fault conditions
  • State machines to coordinate with external commands and signals
  • Perform numeric calculations to emulate the old analog circuitry
  • Control loops for currents associated with voltages needed by different capacitors
  • Communication support with the master PC
  • Computation and detection of internal fault and UUT pass/fail conditions

We were able to duplicate the behavior of the wire-wrapped circuitry by converting the schematic diagrams of these circuits into FPGA code and then tweaking that code to mimicking the actual signals we measured with data acquisition equipment on the original test hardware.

The outputs of the circuitry were reconstructed on the FPGA with band-pass filtering, calibration compensation, point-to-point RMS, and phase & frequency functions. This functionality was implemented in fixed-point math and the 24-bit inputs on the A/D provided sufficient resolution and bandwidth for a faithful reproduction of the electronic circuitry. These embedded cRIOs provided a very effective solution to what otherwise might have required another set of costly and rigid custom circuits.

Finally, for optimizing the task of replacing the old equipment, we used a set of cRIOs, not shown in Figure 1, to provide Hardware-In-the-Loop (HIL) simulation of the manufacturing and measurement equipment. These cRIOs imitated the rest of the machine by providing inputs to and reacting to outputs from the embedded cRIO controllers, thus supporting comprehensive verification of the new test system before the tear-out of the existing hardware. Furthermore, these HIL cRIOs enabled fault injection for conditions that would have been difficult and possibly dangerous to create on the actual equipment.

Yes, I need a manufacturing test system »

Important elements of end-of-line testing equipment

Important elements for an end-of-line tester will vary somewhat based on whether it’s a high-mix/low-volume production scenario or a high-volume production scenario.

Common key elements of an end-of-line tester:

  • Aggregate results – so you can look for efficiency gains and common component issues
  • Verification that every step was executed, especially critical when traceability is important or required by your customer
  • Reduction in operator errors by automating the setup and reading of any computer controllable measurement equipment
  • Ability to identify prominent reject modes by analyzing the electronic records produced by the test station

Aspects specific to high-mix/low-volume end-of-line test:

  • Combine step-by-step work instructions and step-by-step feedback from the operator along with semi-automated measurements. Merge the assembly instructions and testing steps into one system – so the operator doesn’t have to flip back and forth (ease of use and less prone to error).
  • Track assembly status and test results across multiple assembly cells, due to different tests on the same part or subcomponent testing leading to final assembly
  • Have a simple way to manage the work instructions for all the different types of parts you make – electronic docs simplify the setup of the assembly & test for each part so you don’t have to physically locate the assembly manual for the part being built.
  • Cost savings based on increased efficiency in operator performance
  • Coordinated test results according to a part’s serial number when a particular part is tested at several test stations

Aspects specific to high-volume production end-of-line test:

  • # of changeovers: How much effort is involved in a changeover? Can aspects, such as test equipment reconfiguration, be automated?
  • Up-time: Can maintenance of the test equipment, such as annual calibration and replacement of worn-out parts, be executed quickly? Are spare parts readily available for both COTS and custom tester components, such as cables and harnesses?
  • Database organization: Is consideration being given to the performance of data archiving after several years of operation while the test system has stored huge amounts of data.

If you’re looking for help with your end-of-line test system, reach out here to chat with us.

I need a custom end-of-line tester »

End-of-line testing is a final verification step / fail safe between you and your customer.  We understand your reputation is on the line.

We’ve developed the software (and interfaced with the tester hardware) for over 800 end-of-line test systems, with some hardware involvement (e.g. NI hardware selection) for ~300 of those, and delivered the complete package (both hardware & software) for roughly 100 end-of-line test systems.

We know our way around end-of-line test.

Stu McFarlane
Stu McFarlanePresident
This website uses cookies and third party services. See our privacy policy for more info. OK