Test System Migration – Replacing and upgrading obsolete test systems
Problems you may be experiencing:
You have an existing test system.
- Maybe it is on its last legs because of some obsolete components which, once the last one fails, will kill the tester.
- Maybe the UUT design has been upgraded enough times that the system can no longer properly test the latest version.
- Maybe IT is forcing you to upgrade your OS.
- Maybe you’ve got an old rats nest of legacy code that you need ported to a more modern version or language.
You need to upgrade that system. But not just any replacement: it has to act like the existing one.
You want to be sure the automated test system upgrade:
Ideally, you’d like to push the new test system into the same place as the old one and just hit the proverbial go button.
You’re probably worried about the lack of documentation on the old tester: there are no drawings of the signal connections and no write-up on the exactly how the tests are performed. And, you likely have a budget challenge.
How We’ve Helped Our Clients
We notice that our clients have a nagging concern (fear?) about moving away from something that still works. By reviewing and understanding the possible differences in performance between old and updated systems, any differences can be minimized or justified. We have managed these differences by:
- Performing a thorough reverse engineering to understand the nuances and details of the old system so the new system matches the old as closely as reasonably possible
- Making sure that the reverse engineering includes operator usage as well as the functionality, in order to remove or reduce operator re-training and possible associated quality issues
- Assessing and addressing possible unexpected increases in reject rates associated with the (typically) better capabilities in the new measurement equipment as compared to the old equipment, since often the faster and more accurate new equipment uncovers previously unknown behaviors in product performance
- Working through any mismatches between new and old harnesses and connections to maintain familiarity in using the test equipment
- Reviewing the new capabilities so that they won’t mess up the old ones
Often, the most challenging part of these is explaining why the new test system is “correct” when producing different results than the old system. We help you make and understand these assessments. Sometimes, the only option is making the new hardware and software act like the old equipment.
Case Studies
Enhancing an existing test system for ease of maintenance
Enhancing an existing test system for ease of maintenance
Reduction of time and frustration motivates software upgrade of a capable but inflexible test system
Client – A world-wide manufacturer of refrigeration units
Challenge
Our client had been using a 15-year old test system LabVIEW-based application that was becoming difficult to update. Plus, the designs of their newest refrigeration units were more complex than ever, requiring new test steps.
On top of that, our client wanted to give the operator flexibility in sequencing the test steps. For example:
- the operator might want to run a specific test twice to verify operation.,
- The operator might want to restart a sequence in the middle after reworking a part.
- Or the test engineer might want to add another test step to further clarify operational data for historical trend analysis.
The existing application was based on a state machine architecture. While state machines can be edited to handle different sequence flows, this test application had numerous alterations over the past 15+ years to support the needs for testing new product designs. These amendments compounded over the years into an unwieldy test application.
New products were about to be introduced which would require additional modifications to the existing state machine and subsequent verification that:
- changes worked as planned and,
- changes didn’t affect any other existing modes of operation. This need was increasingly daunting.
The Design and Development Process
Very early in discussions, we showed our client a test application based on an object-oriented (OO) software architecture, and its associated user interface, that we had used in previous test system projects for other clients. We thought it might satisfy some of the desires we were hearing about:
- how the older state-machine-based test system was difficult to maintain,
- how some users were frustrated by the inflexibility of the test sequencer,
- and wondering why the system can’t be easier to update for new product requirements.
Moving the existing application over to this new architecture would clearly require more effort than another patch, so we had to decide if the cost for this approach would be justified based on two major benefits:
- Simplify the management and verification of future changes.
- Enable flexible test flows to give the test operator a better user experience.
Both benefits would accumulate cost savings for maintenance and upgrades going forward. After discussions with our client, we jointly decided this approach was justified.
After reviewing this OO approach, our client asked us to use it to develop a small test system for another component of the refrigerator products. This small system gave our client the chance to explore the “look and feel” of this new architecture and user interface design before embarking on the test system discussed in this case study.
That trial project was a success, and we were given the go-ahead. The benefits, as described above, were clear.
After the development was complete, we:
- worked with our client on integrating the test system into the existing test station,
- performed acceptance testing,
- and delivered the final items, like source code, to our client.
Solution
The initial upgrade tasks in creating this new application started by identifying the code for the test steps in the existing test application, which was based on that state-machine architecture, and then rewriting the test step functionality with the OO methodologies discussed earlier.
We also reworked the sequencing of steps to use an OO-based test sequencer. The test sequencer was reused from some of our prior projects.
For each test step in the existing test application, we repurposed the existing LabVIEW code in two ways:
- First, we identified code functionalities that were commonly used throughout the state machine for the purpose of defining a set of reusable step types.
- Second, we converted that common functionality into LabVIEW classes via copy-paste into the class methods, coupled with extraction of the configuration parameters needed to give each class the behavior needed for a particular step.
For example, the existing state machine contained many steps that provided a request-response method over a data bus. These similar steps were corralled into a single class with methods for data communication. Thus, each of the multiple original states in the existing application which requested parameter values could be made by calls to the same class in the new application simply by providing specific configuration inputs to the same class method.
Benefits
This OO design simplified updates to the test steps and their sequencing.
Furthermore, the operator interface was simpler, cleaner, and allowed the operator to manage the flow of the test steps. For example, operators could jump around in the test sequence when needed, say for reviewing the occasional confusing result or helping to develop the production test sequence.
The OO design of this new test system application was aimed squarely at improving the user experiences of both the operator and test engineer. Secondarily, the OO design will help the test system developer by untangling the original state machine code into supportable, extensible, and maintainable software.
Some specific benefits available from this new OO design:
- Reduced frustration – If the operator noted something confusing about the outcome of a test step, that step can be rerun without needing to restart the entire test sequence.
- Improved operational efficiency – The operator and/or test engineer can try a different sequence of test steps for operational or efficiency improvement.
- Faster test system updates – Two aspects make updates faster and cleaner. First, new product designs can be accommodated with less worry about whether the fragile state machine code will break, Second, the code modularity of OO test steps makes it easier to implement new tests.
These usability and maintainability features will save our client cost and schedule in future product upgrades as well as highlight the contributions of the test system on production efficiency.
System Overview
The test hardware was based on NI CompactDAQ and the application was written in LabVIEW. The automated test system provided the following main features:
- Test configuration based on the type of part being tested
- Test sequencing with part-specific test steps
- Test sequence execution can be managed by the operator in real-time
- Display of test results as the sequence progresses
- Archiving of test data for historical tracking
The test flow that this application runs is:
- The operator enters the model and serial numbers (typed in or scanned in).
- The test system looks up the model number and finds the test sequence to run.
- The test system populates the sequencer screen with the appropriate test sequence.
- The operator can select a step from which to start or just click the Start Test button to begin the entire sequence.
- Buttons at the bottom of the sequence display allow the user to Pause, Abort, or Resume the sequence.
- Executed test steps are highlighted in green (pass) or red (fail) to indicate how the sequence is progressing. The operator can scroll through the test sequence to review the outcome of each step.
- If the sequence is configured to do so, the sequence may pause at a failed step so the operator can repair and retest that step.
The unit under test (UUT) was monitored by the test system to view sensors both internal and external to the UUT. The external sensors are used to detect the environment of the unit, such as being in position, connected to power, and so on.
Besides a few thermocouples and digital inputs, measurement data used to determine pass/fail was obtained from the UUT via the data bus.
All these inputs were handled by a set of NI modules in a 4-Slot cDAQ chassis.
| SOFTWARE FUNCTIONS |
|---|
| Data communications |
| Acquire sensor data |
| Control digital output |
| Acquire digital inputs |
| Test sequence management and execution |
| Archiving of all test results |
| HARDWARE USED |
|---|
| 1 Port High Speed Communication Module |
| 8 Channel AI Module |
| 8 Channel Sourcing DO Module |
| 8 Channel Sinking DI Module |
Updating an obsolete LabVIEW-based system for measuring solar irradiance
Updating an obsolete LabVIEW-based system for measuring solar irradiance
Maintaining continuity between old and new systems was important for correlation with nearly 40 years of historical data
Client – California State University at Northridge (CSUN)
Challenge
Our client had over 4 decades of data on solar irradiance (the amount of light our sun emits). Over that decades-long time span, equipment suffers breakdowns and needs repair or replacement. We were called in to replace that old system with an upgraded system.
For this obsolescence upgrade, the solar irradiance measurements, before and after the equipment change-over, must compare to provide continuity in the measurements.
Consequently, our replacement system had to be checked against the existing system before it went completely defunct.
To that end, we needed to continue making the light measurements with the existing linescan photodiode array. This linescan device required some low-level digital signal control and handshaking to initialize and perform the measurement data collection.
Solution
The prior system used obsolete hardware from National Instruments (NI) such as an E-Series card multifunction data acquisition card and a TIO-10 timer-counter card.
Beside being obsolete, this hardware used on old computer bus. The combination of these defunct features was addressed with a new PC and data acquisition hardware.
Furthermore, some support components were also needing upgrade, such as a non-functional power supply.
We also upgraded a circa 2013 LabVIEW application and added some new functionality. Luckily, the CSUN team had the source code.
All these components were delivered as a turnkey system to CSUN.
Benefits
Obsolete measurement system update – enabled essentially unbroken measurements of solar irradiance over the nearly 40 years coupled with some overlapping data collection for comparison of previous and present data gave confidence that the upgraded system could continue to collect important solar irradiance data for many years to come.
The sun’s output does vary cyclically about +/- 0.035% on average following the sunspot cycles about every 11 years. Check out the plot of solar output over the past about 25 years in this link: https://spacemath.gsfc.nasa.gov/sun/Earth8.pdf
How we worked together
CSUN researchers connected with us after they reviewed our capabilities on our website and had a subsequent conversation. Although the CSUN team had a very good technical understanding of the required upgrades, they were not experts in automation systems and were looking for a system integrator for help.
From our perspective, all the details about the operation of the existing system would be in the LabVIEW source code and electric / signal system schematics. As mentioned earlier, CSUN did have the source code. Some older schematics needed a bit more digging by us to identify all the relevant hardware.
Our proposal was based on this system information and one or two clarifying discussions. CSUN accepted and funded our proposal and we began the upgrade effort.
We didn’t have access to some parts of the system, such as the linescan array, so we tested the completed upgrade as much as we could at Viewpoint and then scheduled a trip to CSUN for the final installation and commissioning.
Once on-site at CSUN, the only surprise was a power supply that wasn’t functioning as expected. CSUN replaced that unit while we were on-site. After all the upgraded components were in place, the system was tested and commissioning was completed successfully.
System Overview
CSUN uses two Cartesian Full Disk Telescopes (CFDTs) to measure solar irradiance. These telescopes can measure irradiance at various specific wavelengths of light. Measurements are made daily and compared with space-based measurements.
Specifically, comparisons are made between irradiance measurements obtained from instrumentation on the SORCE satellite with the measurements obtained from CSUN’s ground telescope-based measurements. The space- and ground-based equipment measure different ranges of light wavelengths. The SORCE measurements span a wide range of wavelengths. This satellite was launched in early 2003 and its mission was completed in early 2020 (https://lasp.colorado.edu/sorce/). Note that SORCE measurements do not have to contend with Earth’s atmosphere.
The CSUN equipment measures at a few specific wavelengths. Comparisons between the two methods is important because satellites don’t last forever, necessitating ground-based equipment that is confirmed from space-based measurements. And, of course, ground-based measurements must contend with Earth’s atmosphere, so correction factors must be calculated and confirmed. Assessing the validity of long-terms trends against shorter-term space-based data lends assurance to ground-based equipment measurement. The nearly 40-years of continuous CSUN measurements can proceed into the future with confidence.
The system we deployed replaced the obsolete equipment and software with:
- new measurement hardware,
- a workstation,
- and a failed power supply.
The application software was upgraded as well to:
- bring it up to the current LabVIEW version,
- add some new functionality,
- and Interface the linescan imager with the upgraded USB-based measurement hardware from NI.
| SOFTWARE FUNCTIONS |
|---|
| FITS image creation |
| Control of linescan array |
| Updated application with improved user interface |
| HARDWARE USED |
|---|
| Dell Workstation |
| NI USB Multifunction module |
| Cables, BNC breakout panel, power supplies |
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 |
Enhanced Portable Data Acquisition and Data Storage System
Enhanced Portable Data Acquisition and Data Storage System
Using a Real-Time Operating System (RTOS) provides a high level of synchronization and determinism for acquired data.
Client
Tier 1 Automotive Design and Manufacturing Supplier
Challenge
Our client had an existing data acquisition system, used for mechanical product validation testing, that had undergone many updates and patches for over 15 years. These updates and patches, performed by multiple developers, had rendered the software portion of the system somewhat unstable. Furthermore, the system hardware was based on NI SCXI, which was becoming obsolete. These issues prompted our client to migrate to an entirely new system.
New requirements for this upgrade included utilizing a PXI controller running NI Linux Real-Time, a RTOS, executing a LabVIEW RT application. The data acquisition software had to support a variable mix of signal conditioning modules in the PXI chassis. In addition, the data acquired from these signal conditioning modules needed to be synchronized within microseconds.
Solution
Viewpoint leveraged another application, developed for the client a few years prior, to harmonize the user interface and to reduce development effort. Most of the development time focused on support and configuration of the multiple module types and ensuring that the data synchronization functioned as required. The result was an ultra-flexible, portable, high-speed data acquisition software/hardware combination that can be used to acquire time-sensitive, synchronized data across multiple modules in a PXI chassis running a real-time operating system.
Benefits
The upgraded system offers the following features:
- Highly configurable real-time data acquisition hardware/software solution based on LabVIEW RT and PXI hardware. Our client works closely with OEMs to assure compatibility and durability with their products, often going to the OEM’s test cells to collect performance data. The configurability in modules and channels affords the fastest possible setup at the OEM’s site which minimizes time and cost in the test cell.
- Configuration files stored in a SQL database format. Saving channel and module setups in SQL allows the test engineer to locate previous hardware and data acquisition configurations. The usual alternative is a bulk save of an entire system setup rather than using a more granular, and hence, more flexible approach afforded by using the database.
- Immediate test feedback through graphs and analog indicators, used to assure data quality before leaving the test cell.
- Data playback features after the data has been acquired, used for in-depth review of data after leaving the test cell.
- Data acquisition on the RTOS provides assurance that the acquisition will not be interrupted by network or other OS activities, which was occasionally an issue with the prior Windows-based application.
- Synchronization between signal conditioning modules ensures time-critical data taken on separate modules can be compared and analyzed.
System Overview
The system consisted of custom LabVIEW RT software intended to run on an engineer’s laptop and the PXI real-time controller and a PXI chassis populated with a flexible assortment of NI signal conditioning modules (provided by the client).
The software used an object-oriented Actor-based architecture, which facilitates adding new signal conditioning modules and flexible communications between the host PC and the real-time controller.
| SOFTWARE FUNCTIONS |
|---|
| DAQ Task Configuration |
| Event-Based DAQ Trigger |
| Data Synchronization |
| Real-Time Data Visualization |
| Data File Playback Utility |
| Datalogging to TDMS File |
| HARDWARE USED |
|---|
| PXIe Chassis (4,9 or 18-Slot) |
| PXI Real-Time Controller |
| PXI Multifunction I/O Module |
| PXI Digital I/O Module |
| PXI Counter/Timer Module |
| PXI Thermocouple Module |
| PXI DSA Module |
| PXI LVDT Module |
| PXI High-Speed Bridge Module |
| PXI Voltage Input Module |
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 |
Industrial Monitoring for a Harsh Environment
Industrial Monitoring for a Harsh Environment
Developing an industrial monitoring system for ultrasound-based sensing in a harsh environment
Client – Energy Research Lab
Challenge
Our client was experiencing problems making temperature measurements in a hostile, irradiated environment. Traditional temperature sensors don’t last long in this environment, so our client was developing a sensor designed for these conditions.
Special equipment is required to drive this sensor. It’s an active sensor requiring an ultrasound pulser/receiver (P/R) and high-speed digitizer to make it function.
The prior attempt the client made at using an original set of special equipment was having reliability and connectivity issues. This reduced reliability was of critical concern due to the requirement for the sensor to operate for years without downtime.
In addition, the existing application was incapable of displaying live data and lacked a user-friendly interface. On top of that, data analysis had to be done after the application was run, causing delays.
Our client needed reliable and robust hardware to drive the sensors and an application that would eliminate the challenges associated with the existing system.
Solution
Viewpoint accomplished the following:
- Evaluated two different ultrasonic P/R sensor driver hardware solutions to select a solution that would provide the connectivity robustness, configurability, and correct sensor driver characteristics required for the given sensors.
- Decoupled the digitizer embedded in the original P/R by adding a PXI digitizer with better capability.
- Provided backward compatibility with previous measurement hardware to aid in performance comparisons with the new hardware.
- Developed a LabVIEW-based application that corrected all the issues with the existing application including real-time data analysis, real-time data visibility and a modern user interface. The new application also provided sensor performance traceability using the sensor’s serial number.
Benefits
The enhanced measurement system offers the following benefits:
- Reliable sensor subsystem to ensure uninterrupted data acquisition.
- Measurement hardware configurability for sample rate, collection duration, and pulsing repetition rate.
- Application configurability for automating the analysis, historical archiving, and results reporting.
- Real-time data analysis.
- Sensor traceability through serial number and data files.
- Engineering mode to take control of the entire measurement system.
- Improved data logging to include raw and analyzed data.
- Improved application user experience via robust data collection and configurability.
System Overview
The deployed temperature monitoring system consisted of the following components:
- COTS pulser/receiver hardware for driving the sensors.
- COTS high-speed DAQ for retrieving ultrasound signals.
- A LabVIEW-based software application to provide real time data monitoring, error/alarm notification, data analysis, data logging, part traceability and backward compatibility with the older sensor driver hardware.
| SOFTWARE FUNCTIONS |
|---|
| Acquire Data from Sensor Driver Device |
| Data Analysis |
| Write Raw Data to File |
| Write Analyzed Data to File |
| Configuration Utility |
| HARDWARE UTILIZED |
|---|
| Sensor Pulser/Receiver Driver |
| NI PXIe Expansion Chassis |
| NI PXI Oscilloscope Module |
| NI PXI Thunderbolt 3 Module |
| INTERFACES / PROTOCOLS |
|---|
| RS-232 |
| Thunderbolt 3 |
Custom FlexRIO Adaptor Module supports HIL Test Upgrade
Custom FlexRIO Adaptor Module supports HIL Test Upgrade
A custom-COTS approach reduces cost and delivery time.
Client – Major National Research Lab
Challenge
Our client has a client (the end-user) for which they developed an HIL test system several years prior. Parts were obsolete and the system needed an upgrade. The prior system had many custom-designed electronic components which could not be replaced without a complete redesign.
Consequently, our client wanted to use COTS. However, one device needed 28 VDC digital I/O, a couple of lines which carried significant current (amp, not milliamp, levels) and at switching rates much higher than a COTS solid state relay could provide.
Solution
Viewpoint reviewed the requirements and created a hybrid COTS-custom solution. We combined an NI FlexRIO module with a custom FlexRIO Adapter Module (FAM) for the front end to satisfy the 28 VDC signals levels and required current drive.
Benefits
- COTS FlexRIO integrates into the remainder of our client’s PXI-based test system.
- The Custom I/O was designed for flexibility. Our client can use this FAM for both their initial end-user and other programs / clients too.
- Reduced cost relative to a completely custom solution.
- Delivery time reduced by months relative to a custom solution
FAM Overview
The custom FAM interfaced with the NI FlexRIO module, which offered low-level digital I/O (3.3 V logic), to digital signal conditioning hardware that provided the 28 VDC signal levels and required current drive.
Each I/O pin was configurable as input or output (source or sink). Each bank of 4 channels had an adjustable threshold level set via an adjustable DAC output. Some of the channels are designed for amp-level current drive, while the remainder were 250 mA. All I/O was fused appropriately.
Viewpoint also developed LabVIEW FPGA and VHDL to enable our client and the end-user to:
- Configure the I/O as in or out.
- Communicate to the DAC to allow custom input threshold trigger levels.
- Read and write the digital data.
| SOFTWARE FUNCTIONS |
|---|
| Set the direction of each of the DIO channels |
| Set the threshold level on the input channels |
| Read / Write DIO Data |
| End User Application |
| HARDWARE UTILIZED |
|---|
| COTS NI FlexRIO |
| Custom FlexRIO Adaptor Module(FAM) |
| INTERFACES / PROTOCOLS |
|---|
| Customized VHDL Component Level Intellectual Property (CLIP) integrated with LabVIEW FPGA |
| LabVIEW FPGA as required along with LabVIEW and TestStand |
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
Endurance Tester for Mission-Critical Mechanical Component using NI cRIO
Endurance Tester for Mission-Critical Mechanical Aerospace Component using NI cRIO
Ability to run tests unattended and overnight reduces operator labor and compresses test schedules
Client – Major Aerospace Component Supplier / Manufacturer
Challenge
The client had an older VB & PLC-based aerospace test system in place already, but it was obsolete. A new endurance test system needed to be developed to validate prototyped components (in this case, aircraft & aerospace bearings). Many of the prototypes are one-off, so it was important that the test system not destroy the component.
Solution
A new endurance test system was developed to validate prototyped aerospace components. The test system can be configured for automatic shutdowns so as not to destroy the component under test in the event of unexpected performance of electro-mechanical subsystem components. The updated endurance tester supports product validation by allowing the product to run under various test conditions (e.g. speed, load, oil flow, temperature) and collecting data for analysis.
Viewpoint developed the software and selected the NI hardware (other hardware was selected by the client).
Benefits
System Overview
The updated cRIO-based endurance tester incorporates configurable profiles, data logging, and automatic shutdown to allow for safer extended validation testing. LabVIEW FPGA and LabVIEW RT were used together to interface with the test hardware sensors and controls. LabVIEW as used create the HMI for the test system.
| SOFTWARE FUNCTIONS |
|---|
| Closed loop control of bearing test oil flow |
| Axial load control |
| Driver for Emerson VFD |
| E-Stop and safety management (shutdowns based on alarm limits) |
| Data collection – temperature, pressure, flow, vibration, frequency |
| Operator/Diagnostic GUI for control of system |
| HARDWARE USED |
|---|
| NI CompactRIO (cRIO) |
| NI C Series Current Input Module |
| NI C Series Voltage Input Module |
| NI C Series Temperature Input Module |
| NI C Series Current Output Module |
| NI C Series Analog Input Module |
| NI C Series Sound and Vibration Input Module |
| NI C Series Digital Module |
| Emerson VFD (Variable Frequency Drive) |
| INTERFACES / PROTOCOLS |
|---|
| TCP/IP |
| TCP Modbus |
Endurance Tester using NI cRIO
Endurance Tester using NI cRIO
Multiple International Deployments Helps Prove Product Meets Spec.
Each endurance test can run upwards of 6 months.
Client: Major Automotive Component Supplier
Challenge
A new endurance test system was developed to give more precision in the control setpoint. This additional precision enabled potential clients to review the product performance in real-life situations. Each endurance test can run upwards of 6 months.
Solution
The updated endurance tester supports product validation by providing the desired parameter control method, allowing the client to prove more obviously that their part met the stated specification.
Viewpoint developed the software and selected the NI hardware for the first unit. The client is now deploying copies of this system to multiple international manufacturing plants.
Benefits
- Able to prove meeting a particular product specification of interest
- Closed loop parameter control
- Data collection
- Configurable Alarms
- Emergency shutdown functionality
System Overview
The cRIO-based endurance tester provides closed loop control, data collection, and alarming with controlled and emergency shutdown functions. The operator can manually configure a test or load a saved configuration. After a manual operator check to make sure the setup is operating correctly, a successful test will run its full duration and stop on its own.
| SOFTWARE FUNCTIONS |
|---|
| Touch PC interface / GUI |
| Closed loop parameter control |
| Data collection |
| Controlled & emergency shutdown |
| Alarming |
| HARDWARE USED |
|---|
| NI CompactRIO |
| NI analog input cSeries module |
| NI analog output cSeries module |
| NI digital input cSeries module |
| NI digital output cSeries module |
| INTERFACES / PROTOCOLS |
|---|
| TCP |
Product Validation using LabVIEW RT & LabVIEW FPGA – Electromechanical Actuator Test Stand
Product Validation using LabVIEW RT & LabVIEW FPGA – An electromechanical test stand for an aerospace actuator
Automated testing reduces operator man hours and increases production throughput.
Client – A manufacturer of actuators in the mil-aero industry.
Challenge
New Product Introduction (in this case a new controller and new actuators) drove the need for a new aerospace electromechanical test stand.
Solution
New NI PXI-based electromechanical test equipment provided automated HIL testing, report generation, and SPC data generation. The sequencing of the test procedure, reporting, and verifiable results were managed with the StepWise test executive platform.
Benefits
- Automated testing reduces operator man hours and increases production throughput.
- Meets strict customer requirements regarding testing and data recording in a verifiable manner.
- Automated Test Report Generation.
- Collects data to support SPC (Statistical Process Control).
- Ability to interact with the internal state of the controller FPGA via the LVDS communication link.
System Overview
Viewpoint developed the software and selected NI data acquisition and control hardware for the test stand. There are several layers of software functionality.
| HOST LABVIEW SOFTWARE LAYER |
|---|
| Test sequencer |
| Test steps (e.g. Frequency Response, Step Response, Dynamic Stiffness, Fault Response, Power Consumption) |
| Test Report Generator |
| GUI |
| REAL-TIME (RT) LABVIEW SOFTWARE LAYER |
|---|
| Data acquisition |
| 1553 comms |
| Function generator |
| Error detection |
| ESTOP |
| LABVIEW FPGA SOFTWARE LAYER |
|---|
| Synch data from 3 sources (tester, UUT, external DAQ device) |
| Stream high-speed data to disk |
| Stream high-speed data to analog outputs for HIL test |
| Custom communication protocol used by UUT over LVDS lines |
| HARDWARE RECOMMENDED |
|---|
| NI PXIe |
| NI FlexRIO card with LVDS adapter module |
| Multiple NI R Series cards |
| High speed, high voltage, isolated analog input cards |
| INTERFACES / PROTOCOLS |
|---|
| MIL-STD 1553 bus |
| LVDS |
| Ethernet |
| Custom TCP/IP |
*- images are conceptual only, not actual
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:
- 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.
- 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.
- 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 |
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 |
Custom Manufacturing Inspection System – with Machine vision and Advanced Motion Control
Custom Manufacturing Inspection System
with Machine Vision and Advanced Motion Control
Client – Xerox
Challenge
Our client had an old manufacturing inspection system (really two systems: one inspection system and an assembly/inspection system) that would no longer be supported by IT and was going to be removed from the network. They needed the operating system updated, so they decided to take this as an opportunity to port the old code from VB to C#.NET, as well as update some hardware.
As migration projects often do, this effort began by working with the client to solidify requirements, followed by a reverse engineering effort to understand the old system to try to make it match the new system as much as possible.
Solution
The updated manufacturing inspection system (one inspection system and an assembly/inspection system) included a new operating system, ported code, new motion control software, new machine vision software, and a new GUI.
Benefits
- OS Update – Updated operating system that is supported by the IT department and is less of a security risk
- Software Porting – Ported software to more maintainable language
- Measurement Accuracy – Increased inspection measurement accuracy for sub-set of measurements
- New GUI – improved operator user experience by improving readability, reducing # of required button clicks, and adding auto scroll functionality
- Report Generation – maintained existing format to interface with customer database
System Overview
The device under inspection is essentially an image sensor array used for scanning images in high end commercial-grade scanning printers. The inspection system utilizes machine vision and precision motion control to verify the location & orientation of several parts, with measurement accuracy measured in microns.
| SOFTWARE FUNCTIONS |
|---|
| Vision / metrology – pattern match and inspection |
| Camera interface |
| Motion controller interface |
| Command Recipe Decoder |
| Report Generation |
| Camera Calibration |
| Robot Controller Command Interface |
| GUI |
| HARDWARE (SELECTED & SUPPLIED BY CLIENT) |
|---|
| Cognex camera |
| ACS motion control system |
| 2-Dimensional Cartesian Robot & Controller |
| Inspection fixture |
| Power Supplies |
| INTERFACES |
|---|
| EtherCAT |
| Modbus/TCP |
Manufacturing Test – for mission-critical components
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
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 |
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
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.
