Automating & Educating the World’s Leading Companies for Over 30 Years

The Challenge 

Create a flexible system to monitor the health of Piezo Transducers over time to determine the effects of radiation exposure over their working life. The automated data collection system had to increase the productivity of transducer testing over the existing manual method of periodic testing with a desktop oscilloscope. 

The Solution

Data Science Automation created a system that utilizes a rack mount PXI chassis to centralize the data collection hardware.  Two PXI switch cards allow connection of up to eight transducers to either a PXI Oscilloscope card operating with a  pulser/receiver or digital multi meter (DMM) for resistance measurement.  

Abstract 

A nuclear power plant research company had a need to test Piezo transducers they planned to use for structural health  monitoring. The client needed to perform long term radiation exposure testing of multiple transducers to determine the exposure effects over the transducers’ life-cycle. The automated test system developed by Data Science Automation utilizes a  PXI-1042 chassis with ZTEC oscilloscope to digitize the piezo signal and a DMM to measure transducer resistance. Signal  routing is switched between the two instrument paths and one of eight transducers by two NI PXI-2593 multiplexer cards  configured in the 8x1 terminated multiplexer topology.  

Overview 

Prior to the development of this test system, the only way of acquiring the required data was to manually measure the piezo  transducer response to a pulse event generated by the NDT-5800 Pulser/Receiver with a desktop oscilloscope. This method of  testing was not acceptable due to the extended times between sampling times on the multiple transducers. Data Science  Automation designed the automated system to make the long term testing a much simpler and productive process. The test  platform includes a PXI-1042 chassis with a PXI-8331 MXI controller allowing control of the PXI platform from the rack  mount PC while at the same time providing easy front panel connection access (Figure 1). 

Figure 1 - PXI-1042 Chassis is the Heart of the Test System - Easy Connection Access 

The PXI chassis is populated with a ZTEC ZT4211 Digital Oscilloscope for reading the Olympus NDT-5800PR signals from  the transducers. The Olympus NDT-5800PR provides the excitation signal (a pulse). The piezo element response is routed to  the ZT4211 where an external trigger initiates the acquisition of the response. The ZT4211 acquires data at a rate of 1 GS/s and holds the data in onboard memory until the run-time application software created by Data Science Automation requests a  data transfer from the onboard memory. 

In addition to testing the transducer responses to their normal excitation pulse using the measurement protocol described  above, the system can also connect each of the eight transducers to another card in the PXI chassis, the Signametrics  SMX2064 7 ½ Digit Digital Multimeter in order to read the resistance of the transducer piezo element. 

The key elements that made the enhanced productivity of this system possible were the NI-2593 Multiplexing cards. These  cards were configured in the 8x1 Terminated Multiplexer (MUX) topology. Figure 2 shows how the NI-2593 cards were  connected in the system. Configuration and channel switching was accomplished utilizing the DAQmx suite. The DAQmx  implementation for the switch control is very intuitive. 

 

Figure 2 - NI-2593 System Connections - 8x1 MUX Mode 

Main Interface and Operating Modes 

The Piezo Transducer Monitoring (PTM) system can tests the transducers in three different modes: 1. The first mode is the periodic test mode where the same test conditions are run over time with periodic spacing  between sample sets.  

2. The second mode of tests by single sampling individual transducers using individual user-defined set up information  for the transducer.   

3. The third mode of operation is a continuous testing mode where transducers are constantly tested and the data  displayed on a waveform chart.  

In addition to performing live testing capability the PTM system can also view historic acoustic data files. The periodic testing mode is configured from the “Sample Parameters” page on the Tab Control (Figure 3). Once the test matrix is configured as desired and the operator specifies a periodic time interval, the periodic testing may be started from the  Sample Parameters page. When a periodic sampling test is acquiring data, a single or continuous test may not be started. If a  periodic sample is going to be started within 60 seconds the PTM software stops the individual test or continuous test and  gives precedence to the automatically initiated periodic test. 

Figure 3 - Sample Parameters Page - Periodic Sampling and Test Matrix Configuration 

If there is enough time between periodic sample sets, the operator may use that time to run individual tests or continuous tests  on individual transducers. Individual tests, continuous tests and viewing of historic data are all accomplished from the “Single Transducer View” tab  (Figure 4). 

Figure 4 - Single Transducer View Page - Continuous Testing 

As can be seen from Figure 4 above, when the system is running in continuous mode the buttons that allow historic viewing  and single sampling modes are disabled. When in continuous mode the operator can change which transducer and parameter  set is tested during testing. The operator can also navigate back to the Sample Parameters page and change settings as the  continuous testing is underway. Those settings would then be applied on the next update to the instruments. 

Architecture 

The main application code is based on the Producer/Consumer (Events) Design Pattern. The Producer (upper) loop responds  to either dynamic events or static registered events that correspond to the front panel controls. The queued data element  passed from the producer to consumer loop is a cluster containing an enumerated type definition and a variant. This data type  allows the consumer loop to be sent a command with any data needed by the case reacting to the command. The variant is  converted into the data type needed. See Figure 5 for an example of the communication between the main producer loop and  the main consumer loop.

  Figure 5 - Producer/Consumer Queue Communication 

Sub-Modules 

In order to build a more scalable architecture to handle all the requirements of the system outlined by the client, the basic  system was broken down into modules – following the principles outlined in the Software Design Method section of the  LabVIEW Core courses. The modules (seen in Figure 6) created for this application are: 

Configuration File module 

• PS580A module 
• NDT-5800PR module 
• ZTEC ZT4211 module 
• Signametrics SMX-2064 module 
• NI-2593 Switch module 
• Test Control module 
• Acoustic Data File module 
• Resistance Data file module 
• Parameter Data file module 
• Waveform Chart module

Figure 6 - Software Modules and Waveform Update Loop 

Each module is designed to be self contained. No code that directly interacts with the subject of the module (i.e. the  configuration file, or DAQmx switch drivers) is used in other subVIs or modules. Each is architected with a While Loop and  User Event Structure. The Event Structure is configured with dynamic events that allow interaction with any other software  module. Handshaking is accomplished with the system requesting an action from the module through its generic Generate  Event VI that sends a request to the User Event structure for handling. Each Event Structure also contains an enumeration  driven case structure in the Timeout case of the Event Structure. This allows for state based programming in response to any  dynamic event request.  

An example of the event structure architecture is illustrated below by the Switch Module code. Figure 7 shows the dynamic  event case that reacts to the Generate Event request called by the Generate Event subVI (Figure 8). Figure 9 shows the  Timeout case that then reacts to the requested action.   

Utilizing architecture such as this allows modification of the code in the module, but leaves the external code used by other modules unchanged. The external module (e.g. the Test Control module) would still only utilize the Switch module Generic  Event VI to request a new switch configuration. 

Figure 7 - Dynamic Event Case Example - Switch Module 

Figure 8 - Switch Generate Event SubVI - Called by Other Modules

  Figure 9 - Timeout Case with Enum Controlled Case Structure 

The Test Control module is the brains of the system that ties all the individual modules together in response to the mode of  testing (periodic, single or continuous) that is selected by the operator. Newly acquired data is displayed through an update in  the “Waveform Update Loop” (Figure 6) on the main block diagram. This can update either the small graphs on the  “Transducer Status” page (Figure 10) or the large single chart on the “Single Transducer View” (Figure 4). Data is  transmitted to the “Waveform Update Loop” via singleton queue structure. The data is removed for updating the graph and  then re-queued for handling by the appropriate File module. Only Acoustic data is plotted. Resistance data is only saved to  file. After the data is saved locally by any of the three data modules it is then copied to the remote server directories specified  by the Configuration File. At the same time that data is saved, a parameter file is also saved with the settings of all the instruments at the time of the  acquisition.

Figure 10 - “Transducer Status” Page Showing Results from Six Tests (Only Parameter Set 1 is displayed) 

Summary 

The success of this project was due to the standardization of the PXI platform and the high quality switching components  available from National Instruments. The customer now has a very robust and scalable system that allows them to  productively analyze the health of piezo transducers with little operator interaction over extended periods of time thus saving  hundreds of hours per year with improved reliability and reproducibility.