This note is based on a real requirement presented to Prosig by a prospective user. It’s the sort of challenge that we relish. This case is a great example of a real-world signal processing requirement and also great test of some of the unique features of Prosig’s DATS software. It also shows the power and flexibility of the new DATS V7.0 worksheets.

Note: you can click on the images in the article to see a full size version

Overview of Requirement

The requirement was to extract segments of force time histories and analyze them whenever the speed of an associated pump was rotating within a specific RPM range (50-70rpm). The task presented two challenges:

1. working round undesirable features in the imported raw speed signals so that they could be used reliably in the extraction decision process, and
2. finding the individual maxima of (x,y,z) force channel spectra across multiple events and multiple runs.

The overall objective was to create an automatic procedure using DATS worksheets that solved these problems without writing any custom code.

Event extraction within specific speed range

The graph in Figure 1 shows a typical speed measurement. It is clear that for this particular run there is unusable data at both ends of the data capture. Even in the “good” region in the middle of this curve the speed doesn’t reach the required minimum level of interest. In a later run (shown in Figure 2) only the start portion is “bad” and the speed does reach the lower acceptable limit (50rpm); however, it does not cross the upper acceptable limit (70rpm) but merely drops back below the lower level. So, this is an example of a different type of speed signal where the conditions for extraction are met by a crossing of just the lower limit (but going in different directions).

A third type of speed signal was found where the speed crossed both the lower and upper limits (see Figure 3). However, as can be seen in the graph, there is an additional problem of an unwanted transient appearing in the middle of the capture, which unfortunately satisfies the speed criterion! This too had to be handled to avoid the erroneous extraction of a section of data that is too short to be analyzed properly. Also notice that in all these examples the bad data at the ends of the captures lie within the required speed ranges.

Solution

The first objective was to “clean up” the data so that any decisions regarding acceptable speeds could be based on noise-free data. This was achieved using three stages of processing:

1. forming the running mean (trend) of the raw speed signal,
2. clipping the signal to remove anything higher than 100rpm and replacing it with zero, and finally
3. smoothing.

These stages are shown in the worksheet fragment in Figure 4 below.

The smoothed speed curves (Figure 5) could now be used as suitable reference signals for the DATS Event Extraction module. Initially, those curves that never crossed the minimum threshold were discarded by calculating the maximum speed and using a simple decision switch DPU (DATS Program Unit) to test against this value. If they did cross the lower limit (50rpm) then a second decision had to be made as to whether the highest speed exceeded the upper limit (70rpm). This was necessary because the Event Extract module needed to know the criterion for automatically finding the end of each event.

The worksheet fragment shown in Figure 6 is a greatly simplified version of the actual worksheet but it shows how and where the (smoothed) speed signal was used for controlling the data flow. In fact, after the latest run had been pulled in at the Folder DPU, the data flow went in two directions; the first was the speed smoothing path and the second was the signal analysis path which processed only the X,Y and Z force signals. The event extraction could not start until the maximum of the latest smoothed speed curve had been calculated, so a Synchronization DPU was used to make the selection of the force signals “wait” until it was known that the latest speed curve was good.

The actual analysis of the events takes the form of a simple RMS Spectrum of each event in each run for each of the X,Y,Z force signals. The worksheet also has to handle the fact that the number of events varies from run to run. In order to find the maximum spectrum in each direction for each run it is was decided to calculate all the x,y,z event spectra for each run in a single dataset and then find the individual maxima for each direction by using signal selector DPUs to separate out the spectra for each direction. This is illustrated in the worksheet fragment in Figure 8. Having to determined the individual maxima for this run the results are merged into a single dataset and worksheet would then go on to process the next run.

The overall data flow of the complete worksheet (event extraction and analysis) is shown in Figure 9. In order to aid visualization parts of the analysis have been collected into groups.

The following two tabs change content below.

• Bio
• Latest Posts

Adrian Lincoln

Sound & Vibration Signal Processing Analyst at Prosig

Adrian Lincoln is an Applications Specialist at Prosig and works on signal processing applications, training and consultancy. He was formerly a Research Fellow at the Institute of Sound & Vibration Research (ISVR) at Southampton University. He is a Chartered Engineer and member of the British Computer Society and Institute of Mechanical Engineers.

Latest posts by Adrian Lincoln (see all)

• Averaging Frequency Response Functions From A Structure - June 17, 2016
• Seismic Qualification Testing (Part 1) - June 14, 2016
• What is Operating Deflection Shape (ODS) Analysis? - September 1, 2014