LabVIEW Consultants / LabVIEW Programming Services | LabVIEW System Integration
US-based manufacturers: Need a LabVIEW Expert?
This puts us in the top 2% worldwide
Need some existing code updated? Need a whole new LabVIEW-based test system?
While we go by many names (e.g. LabVIEW experts, LabVIEW system integrators, LabVIEW consultants, LabVIEW specialists, LabVIEW programmers, LabVIEW developers), the key takeaway is that we can take the software development and hardware integration off your plate.
Capabilities & Expertise (LabVIEW and NI hardware related)
We have one or more:
Certified LabVIEW Architect
Certified LabVIEW Developer
Certified TestStand Architect
Talk to a LabVIEW Consultant. |
|---|
We’ve helped teams at some of the world’s most innovative companies
Testimonials
“Very impressed…kudos to Viewpoint”
I really want to thank you for all your help getting us to this stage in automating our testing. We had our customer in this week to oversee some testing and they were very impressed, which is definitely kudos to Viewpoint.
“Significant value”
The Viewpoint team provides significant value to our projects, and I really enjoy working with Viewpoint.
“Valuable part of our global team”
I have been working with Viewpoint for 15+ years on multiple projects. They have always provided creative and quick solutions to all of the problems we have placed in front of them. I have always considered them a valuable part of our global team.
LabVIEW Case Studies | Projects
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 |
Custom electronics and COTS hardware combine into a unique torque measurement system
Custom electronics and COTS hardware combine into a unique torque measurement system
Custom electronics C Series module designed for pulse detection.
A combined custom and COTS Compact RIO solution provides simpler maintenance and longer lifecycle.
Client
Large international supplier of motors, coupling components, and related equipment
Challenge
Our client had an existing torque measurement system that was designed and developed many years ago. Components for it were obsolete and remaining inventory was limited. Tech support for their world-wide clients was about to become a critical challenge. A replacement torque measurement system needed to be designed and built.
We were contacted to leverage our expertise in four areas:
- Custom electronics design and build,
- NI’s embedded Compact RIO (cRIO) systems,
- Expertise in reverse engineering, and
- Operator application development.
An important part of the challenge was that we needed to reverse engineer the existing system because of incomplete documentation about the operation of the system under the wide range of use cases.
Also, the client wanted us to update the operator application used for:
- real-time display of measurements,
- configuration of the measurement system,
- and initial system installation checkout,
among other features.
Finally, and importantly, the hardware needed to be Class 1/Div 2 compliant for operation in a hazardous environment, along with CE and UL conformance.
Solution
We decided to use the NI cRIO platform since it was ready for use in an industrial setting, having specifications such as extended temperature range, large shock and vibration capability, a small physical footprint, and the required Class 1/Div 2 certifications. This approach reduced the review for Class 1/Div 2 compliance, and the certifications from CE, FCC, and UL, to be mainly focused on our custom electronics, although, of course, the entire system needs to comply too.
The NI cRIO selected for this project consisted of:
- a controller,
- a chassis,
- and various COTS C Series modules for signal measurement and communications I/O.
Significantly for this project, the cRIO platform offered a hardware development kit, which enabled us to design and build a custom C Series module containing the custom electronics to convert signals output from the customer-supplied sensors into torque measurements.
Benefits
Besides the obvious benefit of relieving our client’s tech support urgency, caused by the shrinking parts inventory, this new system is:
- more maintainable due to much of the hardware being off-the-shelf,
- customizable since much of the functionality is provided by software, and
- supportable since the components are reconfigurable and modifiable.
Because most of the system “smarts” are delivered by software in this redesigned system (not by a specific hardware design), feature updates and tech support are simpler and more manageable than with the previous system. In fact, when it was found that some of the initial requirements were not well described by the client, we leveraged this flexibility during system debug to maintain the delivery schedule.
Since most of the system is made from off-the-shelf components, the client benefits from NI handling much of the hardware lifecycle management. Now the client only needs to focus on the custom C Series module we provided, a much smaller task and one which we can help them monitor as needed. An important consideration in our design was component life cycle so the client need not worry about obsolescence for many years.
System Overview
The signals from the two position sensors are manipulated by our custom electronics to convert them to digital pulses. The essence of this manipulation is signal-amplitude-dependent thresholding combined with de-bouncing hysteresis. The custom electronics uses an on-board FPGA to communicate with the cRIO chassis and, with custom VHDL interface code, to provide data to LabVIEW FPGA I/O nodes. That data is then passed to the cRIO FPGA to detect the edges of the two digital signals and timestamp them with high resolution.
The time delay between the two edges is converted to a torque measurement through a calibration procedure. The calibration information is supplied by the client and can be modified to account for different mechanical configurations of the couplings and shafts used by their clients. The environmental temperature, measured by a COTS C Series module, is incorporated into that calibration correction.
The measurements available from the system are:
- torque,
- speed,
- temperature,
- and horsepower.
These values are held in the system’s Modbus registers. Various other parameters are sent back and forth between a PC and the cRIO controller for configuration, system status, and troubleshooting as needed.
We developed a LabVIEW Windows application for a PC through which the users interact with the torque measurement system. This PC application handles the communication between and configuration of the cRIO as a Modbus Slave device using TCP and/or 485 signals. A PLC also communicates with the system for controlling their motor, monitoring their equipment, and performing safe shutdown if needed.
LabVIEW was used for the applications on the Windows PC and the embedded cRIO. Part of the cRIO embedded app used LabVIEW RT and part used LabVIEW FPGA. The latter was needed to tap into the cRIO’s FPGA for its 25 ns resolution for the time delay measurements. That resolution, some signal processing, and the sensor calibration resulted in excellent performance.
| SOFTWARE DEVELOPED |
|---|
| LabVIEW Windows application for configuration, troubleshooting, and real-time display. |
| LabVIEW RT and LabVIEW FPGA application to interface to the sensor waveforms and produce torque measurements. |
| Modbus communications for connectivity to the Windows PC and to a PLC used for monitoring, control, and safe shutdown. |
| HARDWARE USED |
|---|
| Custom signal conditioning electronics to convert sensor waveforms to digital pulse trains. |
| Custom c-series module enclosing the signal conditioning electronics. |
| cRIO chassis containing custom C Series and temperature measurement module. |
Automated production test of EO/IR imaging subsystem
Automated production test of EO/IR imaging subsystem
Assessing quality of mission-critical electronics for imaging
Increased throughput by automated signal skew adjustment and pixel verification
Client – Worldwide supplier of products for aerospace and defense
Challenge
Our client wanted a test system that would significantly increase production rates for a very specialized focal plane array (FPA) and associated readout integrated circuit (ROIC) electronics.
In broad strokes, the system needed to support the following:
- Increase production test throughput as much as reasonably possible within budget and schedule constraints.
- Provide some low-code or no-code way to create new test protocols.
- Protect the DUT using hardware and software interlocks.
- Verify the correctness of test image(s) and all its pixels.
Solution
The FPA and ROIC testing for this client used many of the same techniques we have implemented for FPA/ROIC testers at some of our other clients. Thus, the solution was built around our AEDIS platform and some custom connectivity hardware which paired the DUT to the AEDIS hardware.
Specifically, the test needed to:
- Send digital signals from the AEDIS hardware to initiate and coordinate the test steps.
- De-skew bitstreams from the DUT.
- Organize and rearrange the bitstreams into image pixels.
- Provide custom “personality” modules to connect the DUT and AEDIS hardware.
- Protect the DUT from connection and power faults.
Benefits
All the bulleted items above are common requests from our clients and are supplied with the AEDIS platform or easily accommodated by design of the platform. Consequently, AEDIS often meets 80% or even 90% of typical client needs.
Thus, the client was able to cost-justify an AEDIS-based solution for two main reasons:
- overall system costs for an AEDIS-based solution were significantly less than a completely custom system and
- the increased production rates provided plenty of schedule buyback.
Furthermore, the script-based, low-code capabilities offered by AEDIS enabled:
- Support of different test images.
- Control of image transfer initiation, handling responses from the DUT, and flow.
- Version control (by the client) of script-based test configurations.
- Defined parsing of bitstreams to create the image pixels to simplify downstream image collection.
System Overview
The test system was built around AEDIS, which is a combination of five major components:
- NI FlexRIO PXI modules and chassis.
- Signal conditioning hardware.
- A REST API interface for the client’s test sequencer and LabVIEW FPGA for the hardware interfacing.
- An out-of-the-box browser-based app to interact with the AEDIS system.
- A source measure unit to supply and test the DUT’s power needs.
With this design, AEDIS acts as an instrument to incorporate into the client’s overall test system.
The NI FlexRIO modules use Xilinx FPGAs for digital I/O at the rates and channel counts required to fully test the FPA on the DUT. Some digital lines were used for commands to the FPA while most were used to receive output from the FPA.
The AEDIS interfacing hardware acts as an ITA while converting the FPA/ROIC signals to types expected by the FlexRIO. A custom “personality” module provides the physical connectivity from the client’s hardware cabling to the ITA. The AEDIS software handles the test configuration setup, data acquisition, and data storage via high-speed RAID drives.
During development of the test system, AEDIS hardware and software were also used to emulate the actual FPA and electronics to verify, before deployment, that the test system was working as required. This same setup can also be used for periodic verification as might be needed for an annual equipment performance audit.
Finally, configuration files were built from user-created scripts to give the client flexibility for adding new test capabilities for the DUT.
Some of the significant hardware and software challenges mitigated by this combination of PXI FlexRIO and AEDIS are:
- Interface to tester: The AEDIS system is treated as an instrument managed by an overall test system. The client developed some custom C# code to interface to the AEDIS REST API interface to automate their test procedures.
- DUT interfacing: Standard (keyed) cabling ran between the DUT and the custom AEDIS “personality” card to match cabling to the DUT. The output of this personality module went to the AEDIS LVDS modules.
- Channel skew: The high-frequency digital LVDS signals from the DUT can develop noticeable timing skews between channels upon arrival at the FlexRIO inputs due to signal path length differences. The test system had to detect and accommodate for these skews before combining the bits streams into bytes, then pixels, then an image.
- High data rates: Not only were the digital data output at high frequency but many channels were needed to accommodate the full frame rate of the DUT. The FPGA and the PXI backplane needed enough processing and transport bandwidth to accommodate the throughput.
- Interlocks: Keyed cabling and “signal present” software checks assured proper connections between the DUT and the AEDIS hardware before testing would begin. These safety checks were justified due to the high cost of each DUT.
- User-defined scripts: Scripts created and edited by the user provided flexibility to address future test types and system obsolescence. For example, the scripts defined details such as a) the DUT-specific commands (some of which could not be shared with us for secrecy reasons), b) when the image is being captured (or ignored), and c) if the image is stored to disk or RAM.
| SOFTWARE FUNCTIONS |
|---|
| Browser-based app for manual operation and recipe creation and editing |
| REST API interface for support of automated operation |
| Configuration of the test via scripts |
| Pre-test interlock checks |
| Data collection, bit stream processing, and mapping digital bitstream to pixels |
| HARDWARE USED |
|---|
| Standard AEDIS components for signal buffering, conditioning, and signal acquisition |
| Custom personality hardware for connectivity and physical connection interlocks |
| Signal test points in AEDIS breakout ITA modules enabled use of a logic analyzer for troubleshooting and further verification |
Automated Measurement System – Verifying Flow Rate Performance in a Medical Device
Automated Measurement System – Verifying Flow Rate Performance in a Medical Device
Assessing quality and managing traceability of a medical device
Automation increases throughput by testing multiple units independently
Client
Worldwide supplier of products for surgery
Challenge
Our client wanted to perform detailed quality checks on the performance of some of their fluid dispensing products. These products dispense fluid over long periods of time (hours) so rigorous testing of each unit in production would take too long. But, being medical devices, these products need to follow ISO 28620 standards and FDA 21 CFR Part 820 regulations, so a rigorous test process is helpful to fulfill these needs. The automated test system below is part of that overall fulfilment.
The client came to Viewpoint with the following high-level desires for a system to test the product:
- Support independent configuration and testing for up to 6 units.
- Simplify overall test setup by copying the configuration from one unit to another.
- Handle different volume amounts supported by assorted models.
- Measure from each unit the weight of fluid dispensed as a function of time. (Weight was converted to volume using the fluid density.)
- Compute the “instantaneous” flow rate (volume vs time) as the test progresses.
- Keep track of the calibration status of the weight scales at each of the 6 positions in the test system.
- Enable some measurements to be excluded at the start and end of the run for calculations of average flow rate.
- Provide graphs and metrics of results to enable faster review of the data during the test.
- Add ability to comment on each unit while testing is in progress, and after, and track these for compliance.
- Print (PDF) a report on each unit’s results along with its identifying info, such as subcomponent lot numbers, the test datetime stamp, and the operator’s ID.
Solution
The client had an initial version of the testing application which they developed for testing their various initial design iterations. Viewpoint enhanced this existing application with the features listed above. The motivations for this enhancement were to:
- Automate testing of the initial production units more thoroughly than the existing application allowed.
- Enhance the user experience for easier testing.
A major aspect of the user experience was to support testing of multiple units independently from each other so that unit testing on one device could start/stop while other devices were installed in (or removed from) the tester without interrupting tests on other units.
- This need was especially important since some models might take twice as long to test as other models or the setup of one unit might need additional adjustments before starting. This meant that starting and stopping all at the same time could reduce utilization of the tester, and it made sense to have independent and parallel operation.
- Furthermore, with parallel testing, the tester was not constrained to having a full set of units to begin testing operation, since the tester could run with only 1 unit installed.
The other major enhancements focused on the user experience by offering real-time data of a particular unit’s testing, as well as real-time graphs to show progress. These graphs were useful because the operator could clearly see when a unit was not performing as expected and the test for that unit could be aborted without affecting testing on the other units.
Since this testing needs to follow the requirements in the ISO 28620 standard and 21 CFR Part 820, it was important for the application to be aware of the calibration status of each of the 6 weight scales, one for each position in the test system.
Benefits
The main goal of this project was to augment the test operator’s ability to set up the testing of products while providing real-time visual feedback to the operator about the testing status.
Some of the benefits of this automated test system were:
- The test automation provided consistency resulting from the software-enforced test process.
- Test status via the visual feedback helped increase the efficiency of the operator.
- Enhance the user experience for easier testing.
System Overview
The application was developed in LabVIEW and measurements were made via RS-232 communications to each of the 6 weight scales. Once a unit was installed in the tester and the operator started the test on that unit, the application:
- tared that unit’s scale,
- started the flow,
- and collected weight measurements frequently to build a curve of “instantaneous” flow versus time.
These “instantaneous” flow numbers were used to compute statistics such as maximum flow and average flow over the course of the entire test run.
Some of the primary functionality of this system includes:
- Independent tests: testing a specific unit doesn’t interfere with testing of others.
- Graphs of flow rate during the test execution: visualize the unit’s performance during the hours-long test time, not just at the end.
- Calibration check: the next calibration date of each of the weight scales are maintained in a configuration file, so the operator can check that the test system is ready to run a test at a particular position.
- Different volumes: since each unit is tested independently, the system can handle different volumes for each position in the tester.
- Enhanced commenting: operators can enter comments about each unit (or all of them) and have these comments archived for compliance purposes.
| SOFTWARE FUNCTIONS |
|---|
| Logging of weight versus time for up to 6 test positions via RS-232 communications to scales. |
| Manage the configuration and commenting of the test. |
| Save, recall, and copy configuration information to ease the operator’s setup effort and time. |
| Display graphically the curves of flow versus time while the test progresses. |
| Compute statistics on the flow after test completion. |
| HARDWARE USED |
|---|
| Multiport ethernet to RS-232 serial communications. |
Custom Automated Test System – Quantifying Energy and Durability Performance for Refrigeration
Custom Automated Test System – Quantifying Energy and Durability Performance for Refrigeration
Automation reduces manual labor while improving traceability
Assessing performance for improved energy ratings and longevity
Client – Zero Zone – Commercial refrigeration systems manufacturer
Challenge
Zero Zone wanted to improve the capabilities and durability of their new reach-in refrigeration products.
You might think that refrigeration is a mundane product line, but that is just not true! So many innovations are occurring as manufacturers are redesigning their products to improve their environmental footprint through better energy efficiency, coolants, and durability.
Assessment requires an understanding of the performance of the refrigeration units under many conditions. Zero Zone was taking measurements with a datalogger with too few channels, and no synchronization, to other devices that feed into the system. Plus, they had multiple models of their reach-in refrigerators that needed to be assessed. Furthermore, simplifying the data collection and analysis would make it easier to validate against ASHRAE standards.
Zero Zone came to Viewpoint with the following high-level desires:
- Expand the measurements by adding more channels and channel types (e.g., 4-20 mA, ±10 VDC and digital I/O).
- Provide graphs and KPIs to enable faster analysis of the data during the test.
- Minimize the chance of data loss during long test runs.
- Synchronize data collection and actuation.
- Automate storage of measurements per a user-defined period to eliminate manual start/stop of data collection.
- Simplify the manual configuration setup.
- Enable a way to find relevant data perhaps months or years after the test run.
Solution
Viewpoint developed a monitoring and control durability test system that could exercise Zero Zone’s refrigerators through hundreds of operation cycles over multiple conditions to simulate actual usage in, for example, a grocery store.
During initial conversations, we collaborated closely with Zero Zone to brainstorm on some potential approaches. We made some suggestions that could satisfy their desires while also managing their time and cost budgets.
For example, by automatically populating the cells in an Excel template based on their original systems’ Excel spreadsheet, we provided streamlined report generation without having to rewrite all the calculation code embedded in their Excel file in another app. The compromises we jointly endorsed were:
- Run an app on a PC to configure and monitor the test.
- Use both NI Compact RIO and Compact DAQ to enable robust and synchronized data collection and control with the ability to expand channels by adding modules in both the cRIO and cDAQ chassis.
- Store data on a local PC rather than a remote server to minimize the probability of data lost during the test run.
- Save configurations into Excel files for recall, and cloning, of prior setups.
- Write measurements automatically into the same Excel file for archive of the test setup and measurements.
- Create, in this same Excel file through cell formulas, the summary report from the summary calculations. This approach allowed flexibility for changes to internal and external test standards.
- Upload the summary data and test reference info into a SQL database for data management and long-term test statistics.
Digital outputs (DOs) were used to control various aspects of the test, such as door open/close and defrost on/off cycles. For flexibility, the user can specify the sequencing of these DO channels, in the Excel file used for the test, with various parameters that define the duty cycle, period, number of cycles, and start delay. The timing of these DO state changes was synchronized to the data acquisition by the real-time loop in the cRIO.
This system was deployed to 6 test bays, each one of which might be testing a unit for as little as a few weeks or as much as a few months.
Benefits
The main goal of this project was to reduce the effort and associated human error in the design and execution of the test run.
Some of the primary benefits for this automated system were:
- Reduced Errors: pre-verified template files used for test configuration and data storage lent consistency to test setup and execution.
- Less Testing Time and Effort: the automatic execution of the test and storage of measurements enabled running tests for multiple days (and nights) without technician interaction. Technicians could work on setting up other units for test rather than babysit the existing test. On average, based on the duration of the test time, testing throughput increased by approximately 25% to 40%.
- Shorter Reporting Time and Effort: reports were available about 85% faster than the time previously spent creating manually. The quicker feedback saved costs through early detection of unit problems and faster teardown at the end.
Some additional major benefits were:
- More details on refrigerator operation: “Wow! We never saw that before.”
- Database consolidation: statistical analysis takes hours not days and includes all tests run in the lab, not just ASHRAE tests. This central database enables long term retrieval of all test data.
- Reuse: techs embraced ability to reuse and modify previous setups.
- Consistency: driving the test definition through an Excel file encouraged uniformity.
- Traceability: documented and timestamped calibration measurements.
- Flexibility: channel counts, acquisition modules configuration, calibration, and calculation formulas were straightforward to change for new test setups.
The test automation provided by this system greatly reduced the labor involved in configuring, running, and analyzing the test run. Furthermore, the customer benefited from the consistency that resulted from the software-enforced process.
System Overview
We developed the application in LabVIEW and LabVIEW RT combined with a cRIO connected to a cDAQ via TSN Ethernet.
The data acquisition modules slotted into the cRIO and cDAQ chassis handled the I/O to the customer sensors and actuators. The sensors mostly measured:
- temperature,
- pressure,
- flow,
- power, and
- voltage.
| SOFTWARE FUNCTIONS |
|---|
| Data logging of between 50 and 150 channels and control via digital signals |
| Interface with Excel files for configuration, data logging, and summary calculations |
| SQL database for summary and test setup data |
| Real-time loop for robust operation |
| HARDWARE USED |
|---|
| NI cRIO 8-slot chassis, TSN enabled |
| NI cDAQ 8-slot chassis, TSN enabled |
| Various NI cSeries signal conditioning modules |
Custom Automated Test System – Characterization of Heat Transfer System Thermal Performance
Custom Automated Test System – Characterization of Heat Transfer System Thermal Performance
R&D testing required flexibility in control schemes and measurement I/O
Client – ATSI, a large-scale System Engineering Provider
Challenge
Our client, ATSI, Inc., headquartered in Amherst NY, designs and builds complex structures and process systems, from industrial construction projects to mechanical systems for power engineering. A previous, long-standing Viewpoint customer that does research and design of thermal energy systems approached ATSI to engage in the build of a specialized test skid that would be used to assess and characterize a heat transfer system. Our long-standing end-customer requested a data acquisition subsystem based on LabVIEW.
Furthermore, the end-customer requested a subsystem that supported flexibility in the data acquisition by channel count and type, since the R&D nature necessitated adaptability. The overall test system needed to automate progress through a sequence of setpoints and ramps.
Solution
ATSI designed the automated control and sequencing with a Modicon PLC. Viewpoint augmented ATSI’s engineering resources to provide the data acquisition subsystem and setpoint sequence editing. This sequence was passed to the PLC for automated sequencing thought the setpoint list. Because our mutual end-customer did not provide explicit design details, we had flexibility to decide which aspects of the control and data acquisition needs would be automated by the Modicon PLC and which by the PC running LabVIEW.
Since Viewpoint had previously developed a similar application for our end-customer, with some of the required data acquisition needs, we chose to leverage and enhance that software platform for this project. That choice drove some of the other designs and defined the scope of work for Viewpoint and ATSI.
Some overall design decisions were:
- The LabVIEW application provided data acquisition, test configuration, and operator screens.
- The Modicon-based subsystems provided process control and safety.
- A PLC HMI for process system operation and status as well as control loop tuning.
- NI Compact DAQ (cDAQ) offered flexible PC-based acquisition channels for high sample rate historical data collection.
- A sequence editor on the PC defined the test setpoints, durations, and limits to pass to the PLC for execution.
The test configuration encompassed cDAQ channel configuration, PLC tag configuration, sequence editing, and graphical views on the acquired data. Some channels were acquired at slow rates, e.g., up to about 1 S/s for sensors measuring parameters such as temperature and flow, while others had fast rates, e.g., 1 kS/s to 10s of kS/s for sensors measuring parameters such as transient pressure and vibration. Handling the datafile storage and display of this wide range of data types and rates was important for the end-customer to compare and correlate the effects of changing operating conditions.
Data logging is configured by the sequence editor to occur on certain conditions such as immediately entering a new step, time delayed after entering a step, and activated by the PLC upon reaching stable setpoint control. This flexibility gave the end-customer management of when data collection occurred to ease the comparison and correlation of readings from selected sensors.
After the configuration is completed, the sequence is passed to the PLC. The operator starts the test on the PLC HMI and the PLC automates the test run. Data collected during the test run could be displayed in live graphs during testing, used for verification of setup and operation; post-test in stacked graphs and overlaid plots; and exported for specialized analysis, display, and review.
Benefits
The design of this system was driven largely by the need for flexibility. Sensors and channels could be added, the test sequence could be edited with a variable number of steps with editable execution features, and the data acquisition and storage permitted various rates and logging criteria.
These design choices offered the following advantages:
- As a partner of the team, Viewpoint acted as staff augmentation for ATSI by providing experienced engineers with expert LabVIEW and data acquisition capabilities.
- Flexibility of test sequences, including setpoints and their stabilization criteria.
- Tight integration between the Modicon PLC and LabVIEW-based PC enables critical control and safety to execute reliably and yet adjustably.
- Customized mechanical all-welded skid plugs into end-customer’s test article.
- Setup of data logging including configurable sample rates.
- Ability to add channels by plugging in supplemental DAQmx-based cDAQ modules.
- The LabVIEW application architecture is actor-based for straightforward inclusion of new data sources as needed in the future.
- New data sources are registered with the object-based data aggregator.
- The system handles multiple days of test execution
- The multi-pronged viewer allows verification checks while in setup an operation as well as post-test review.
System Overview
The custom automated test system supplied to the end-customer was a hybrid, made up of PC-based and PLC-based components coupled with the fluid-handling components on the skid. The hardware listed below includes only the data acquisition, control, and safety items, and only a high-level description of the mechanical aspects.
| SOFTWARE FUNCTIONS |
|---|
| NI LabVIEW for Windows [Viewpoint] |
| NI LabVIEW Modbus driver [Viewpoint] |
| NI DAQmx hardware drivers [Viewpoint] |
| Actor-based object-oriented LabVIEW application for the PC [Viewpoint] |
| Modicon Concept software [ATSI] |
| Blue Open Studio HMI software [ATSI] |
| Function Block Programming for the PLC [ATSI] |
| HARDWARE USED |
|---|
| Modicon PLC and modules for pressure, temperature, flow and other process variables |
| NI Compact DAQ modules, including 4-20 mA, RTD, thermocouple, thermistor |
| 600 VDC Power supplies |
| Components to flow fluid, including pumps, valves, pressure regulators |
| Intel Tower PC for LabVIEW |
| Mini Industrial PC for HMI |
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 – 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:
- 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.
- All test configuration and data files generated by the software must be compatible with Microsoft Excel.
- 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 |
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 |
Semi-Automation of an Optical Component Manufacturing Process
Semi-Automation of an Optical Component Manufacturing Process
Automation reduces waste, manufacturing cycle time and human error
Client – Optical component manufacturer of precision structured surfaces
Challenge
Our client needed to introduce automation to a highly manual manufacturing process for injection molding of precision components. The manual process was slow, and yields were low, causing excessive waste. The low yield was traced to the inability to control the critical process variables.
Solution
Viewpoint decided to integrate a PLC, a motion controller, and LabVIEW to develop a solution for a “first phase” automation system to replace the highly manual process.
The PLC:
- controls eight axes of motion,
- controls the UV light for curing,
- and interfaces to other process equipment such as valves and sensors .
The LabVIEW application:
- guides the operator through the manufacturing process step by step,
- interacts with the PLC,
- and displays real-time process data and log data to a file for further review post manufacturing.
Benefits
Besides the automation benefits of consistency and speed, the client wanted the ability to adjust configuration settings and limits for almost every aspect of the operation, such as setpoints and motion stage positions. Configuration screens were developed that let an operator run through the manufacturing steps manually while making adjustments on-the-fly; perfect for “dry-run” production simulations. These screens require special permissions to operate in engineering mode rather than production mode.
The other benefits are:
- Reduction of set-up cycle time increasing component throughput.
- Reduction of variability of the manufacturing process.
- Increased product yield resulting in reduced waste.
- Reduced probability of product contamination due to automation and cycle time reduction.
- Data files enable review of past manufacturing data and potential process improvements.
- Part traceability enables better process understanding and control.
- Prompts and machine status checks help guide novice operators.
- System is configurable for different product lines.
System Overview
The entire system consists of the following components:
- A PLC controlling the motors responsible for positioning the tooling and other process equipment.
- A standalone controller responsible for controlling the process temperature.
- A LabVIEW application to serve as the operator’s interface to the manufacturing process. The application is responsible for tasks including:
- Guide the operator through the process.
- Provide important information about the process to the operator.
- Display any warnings/alarms detected by the PLC.
- Write process data to a file.
| SOFTWARE FUNCTIONS |
|---|
| Read Data from Stand Alone Controllers |
| Read from, Write to PLC |
| Write Data to File |
| Comprehensive User Interface |
| Process Sequencer |
| HARDWARE UTILIZED |
|---|
| Stand Alone Temperature Controllers |
| PLC |
| Motion Equipment |
| Vision Equipment |
| INTERFACES / PROTOCOLS |
|---|
| RS-485 |
| OPC UA |
High-Speed Digital Subsystem Emulator
High-Speed Digital Subsystem Emulator
Client: A large company involved in C4ISR
At maximum throughput, the AEDIS systems needed to consume and produce more than about 800 MB/s/slot.
Background
A large company involved in C4ISR was developing a system for a new high-speed digital sensor device. Viewpoint was contracted to build a test system used in design validation and ultimately endurance testing of the sensor. Since the sensor was a component of a larger system which was being developed at the same time, another test system was created to simulate the sensor by feeding signals into the system. This ability to use HIL testing for both the sensor and the downstream sensor electronics enabled parallel development, thus saving time and reducing schedule.
Challenge
Both the amount of data and the frequencies of the various digital signals were nearly at the limit of hardware capabilities. At maximum throughput, the systems needed to consume during record and produce during playback about 800 MB/s/slot. The FPGA clock on the FlexRIO had to run up to 300 MHz. The skew between triggers for data transmission needed to be less than 5 ns even between multiple FlexRIO cards even when the parallel data paths have inherent skews associated with the sensor. Finally, the systems needed to handle clocks that might be out-of-phase.
Achieving these requirements required significant engineering design in the face of multiple possible roadblocks, any one of which could have eliminated a successful outcome.
Furthermore, as usual, the development timeline was tight. In this case, it was a very tight 3 months. Basing the solution on our AEDIS platform was critical to meeting this challenge.
Viewpoint’s Solution
To meet the timeline, we had to work in parallel across several fronts:
- LabVIEW-based application development for both record and playback
- LabVIEW FPGA development for marshalling data between the controller and DRAM
- Custom FAM circuit board design and build
- FlexRIO FPGA CLIP nodes and code for low-level data handling
Technical Highlights
This sensor had several parallel data paths of clock and data lines with clock speeds up to 300 MHz on each path requiring exacting design and build of a custom FlexRIO Adapter Module (FAM) and unique custom CLIP nodes for extending the FlexRIO FPGA capabilities. The FAM also had a special connector for interfacing to the customer’s hardware.
Additional NI hardware and software completed the system components.
Results
The choice to base the AEDIS emulators on NI hardware and software was critical to completing this project. The open architecture in both hardware (custom FAM) and software (CLIP Nodes) enabled us to include some very creative extensions to the base toolset without which the project would not have succeeded in the allotted pressured schedule and on a predetermined budget. We were able to stretch the capabilities of the hardware and software very close to their maximum specifications by combining COTS and custom much more cost effectively than a purely custom design. Further, with HIL tests, both the sensor and the sensor electronics could be developed in parallel, leading to a significant schedule buyback for our client.
LabVIEW Layers
The host application, written in LabVIEW, managed the configuration of the data acquisition and the control of the LabVIEW RT-based FlexRIO systems. The configuration primarily dealt with the number of sensor channels in use, skew settings between digital lines, and other parameters that dealt with the organization of the data passed between the sensor and the FlexRIO.
Two FlexRIO applications were written, one for record and one for playback. Each FlexRIO application was written in LabVIEW, and managed the configuration of the FlexRIO cards and the movement of data between the FlexRIO cards and the RAID drives. Note that Windows supported for the RAID driver. Between 10 and 32 DMA channels were used for streaming, depending on the number of sensor channels being used.
And, each FlexRIO application had an FPGA layer, written in LabVIEW FPGA enhanced with custom CLIP nodes. For the record application, we developed a custom DRAM FIFO on the FPGA to assist with the latencies on the PXIe bus. For the playback application, we were able to stream directly from DRAM.
FlexRIO Considerations
The FlexRIO and stock FAMs from NI were initially considered as candidates for this project. Clearly, working with commercial-off-the-shelf (COTS) components would be most effective. Three options were available at the project start which could accommodate the required clock frequencies, but none offered both the required channel counts and skew/routing limitations. Hence, we had to design a custom FAM. This decision, made before the start of the project, turned out to be wise in hindsight because the parallel development path resulted in some shifts of sensor requirements which could be accommodated with the custom FAM but might have led to a dead-end with a COTS FAM.
FlexRIO CLIP
In LabVIEW FPGA, a CLIP Node is a method to import custom FPGA IP (i.e., code) into a LabVIEW FPGA application. CLIP stands for Component-Level Intellectual Property. We needed to use special Socketed CLIP Nodes (i.e., VHDL that can access FPGA pins) for this project because we could expose additional features of the Xilinx Virtex-5 not exposed in LabVIEW FPGA by accessing Xilinx primitives. Some specific features were:
- Faster FPGA clocking
- Additional clocking options
- Individual clock and skew control
- Custom PLL de-jitter nodes
Essentially, the FPGA design had a majority of FPGA code developed in LabVIEW FPGA and we used CLIP Nodes for interfacing the signals between the FlexRIO and the FAM.
FlexRIO Adapter Module
As mentioned earlier, we had to create a custom FAM because of the need to route high speed signals from customer-specific high density connectors while synchronizing signals across multiple data channels and FPGA modules to within one (300 MHz) clock cycle.
At these high-speeds, the FAM needed careful buffering and impedance matching both on the signals as well internal components on the FAM PCB. At the start of the design, we utilized Mentor Graphics HyperLynx High Speed DDR signaling Simulation software to minimize signal reflections prior to building actual hardware. This step saved countless hours in spinning physical hardware designs.
We designed the FAM to allow channel routing and access to additional clock and trigger pins on the Xilinx chip and PXIe backplane.
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
How to select a LabVIEW consultant
Maybe you’re LabVIEW programmer quit or retired, or maybe you’ve got some internal capabilities but need some additional support because everyone’s too busy. From hourly rates to a range of skills, there are several factors to consider. We’ll help you weigh each one. See How to Select a LabView Consultant.
LabVIEW developers: local vs remote
Headquartered in Rochester NY, we help customers all over the U.S. See the Pros and Cons of a local vs remote supplier for LabVIEW-based test system development.
3,000+
LabVIEW solutions deliveredGreat for automated measurement & control: manufacturing test, product validation, machine control and condition monitoring.
700+
LabVIEW FPGA systems deliveredGreat for applications requiring seriously deterministic timing, reliable code execution, and multi-channel synchronized processing.
1,000+
LabVIEW RT systems deliveredThe combination of LabVIEW RT and the RTOS on which it runs allows for the creation of applications with bounded jitter and latency.
500+
cRIO-based systems deliveredCombining a cRIO controller with the multitude of C Series modules creates a functional real-time controller in a small footprint.
1,500+
PXI-based solutions deliveredBroad range of off-the-shelf expansion cards & processing horsepower make PXI a formidable choice for many automated test applications.