Cancel
Showing results for 
Search instead for 
Did you mean: 

LMS Test.Lab Throughput Processing Tips

Siemens Experimenter Siemens Experimenter
Siemens Experimenter

(view in My Videos)

 

LMS Test.Lab Throughput Processing Tipslogo.png

 

 

Data processing can be an arduous task, but it does not have to be! Here are some tips for navigating the processing settings and organizing results.

 

Getting Started

 

In LMS Test.Lab, any time data can be analyzed using the Time Data Processing worksheet (Picture 1) which is located at the bottom of the screen.

 

TimeDataProcessingWorksheet.pngPicture 1: Processing of throughput files can be done in the Time Data Processing worksheet.

 

This worksheet can be accessed via Tools -> Add-ins -> Signature Throughput Processing (Picture 2).

 

ThroughputProcessingAddIn.pngPicture 2: Turn on throughput processing by selecting “Tools -> Add-in” in the main menu.

After pressing “OK” in the Add-in menu, the Time Data Processing worksheet should appear as a new worksheet at the bottom of the screen. Any data selected in the Time Data Selection worksheet can be processed.

 

See the article below are three tips for using throughput processing:

 

  1. Measurement Mode: Stationary versus Tracked
  2. Data Naming
  3. Original Section versus Active Section

 

1. Measurement mode: Stationary versus Tracked

 

In the Time Data Processing worksheet, a major data processing choice is made by selecting either ‘Tracked’ or ‘Stationary’ measurement mode under “Change Settings” in the “Acquisition Parameters” section.

 

 

traced_vs_stationary.pngPicture 3: The Acquisition parameters menu contains Tracked versus Stationary choices for measurement mode.

 

One can select between ‘Tracked’ and ‘Stationary’ measurement mode (Picture 3).  Depending on which one is selected, the processed data results will be very different.

 

Stationary measurements

 

When ‘Stationary’ Measurement mode is selected, the processed results consist of a single averaged spectrum for each time data channel (Picture 4). 

 

stationary.pngPicture 4: Stationary mode results in single averaged spectrumWhen should stationary mode be used?

 

Imagine that the issue you are tasked with occurs only when the engine is at 2400 rpm. You can measure using the stationary method at 2400 rpm for 30 seconds. The results will show you a single spectrum revealing the highest amplitude frequencies so you can apply damping or other countermeasures to solve the issue.

 

In stationary mode, one can specify free run averaging with a specific overlap.  Different types of averaging methods (maximum, minimum, average, etc) can also be selected.

 

Tracked measurements

 

Setting ‘Tracked’ for the measurement mode results in several spectra at user defined increments. With this mode it is easy to visualize how the data changes as a function of time, rpm, or angle (Picture 5).

 

Imagine you work for an automotive manufacturer and customers are complaining about a noise they hear while driving. You are tasked with solving the issue but the only information you are given is that the noise gets worse as engine rpm increases.  You can instrument the vehicle with accelerometers, microphones, and an engine tachometer on the drive shaft. Using the tracked method, you can identify any high amplitude signals that change with engine rpm. In throughput processing, one can perform order analysis.

 

 

tracked.pngPicture 5: Tracked mode results in a series of spectrums which can be displayed in a waterfall graph

Tracked processing: Increment and Frame Settings

 

Often when using tracked processing, a tachometer is specified as a tracking channel (Picture 6). For example, one might process data from 1000 to 3000 rpm in increments of 25 rpm using the tachometer tracking channel.

 

frame_vs_increment.pngPicture 6: Frame size and increment settings used in tracked throughput processing

Tracked processing results in a buildup of several frequency functions, usually calculated spectra, and are often displayed in three dimensional plots called waterfalls (Picture 7) or colormaps. Each curve in the waterfall display is a separate processing calculation (or measurement), taken from the raw time data.  It is calculated based on user defined acquisition parameters, namely the increment and frame size.

 

Increments are the intervals between frame calculations. These intervals are usually either time or rpm based. For example in the Picture 7, a spectrum is calculated every 25 rpm, therefore our increment is 25 rpm.

 

waterfall.pngPicture 7: Waterfall graph showing tracked spectrums based on rpm

If tracking on time, the increment is the time interval (in seconds) between acquisitions. 

 

Picture 8 illustrates points of data acquisition in time at 1 second, 2 second, and 0.25 second increments.

 

 

increment.pngPicture 8: Various processing increments – Top: 1 second, Middle: 2 seconds, Bottom: 0.25 seconds

The frame size is the how much data is used for a calculation at each interval.  For example, an increment of 0.5 seconds and a frame of 1 second, would result in overlap processing of 50%.

 

When windows, such as Hanning windows, are used they are applied to the frame.

 

frame.pngPicture 9: Illustration of different frame sizes for data processing – Top: 1 second frame, Middle: 2 second frame, Bottom: 0.25 second frame

The relationship between the size of the increment and the size of the frame determines what data is used for processing.  Depending on the setting, it is possible that some data will not be used (ie, data “gaps”) or that some data will be used multiple times (ie, data “overlap”).

 

frame_vs_inc_illustration.pngPicture 10: Increment versus Frame size illustrations

One frame of data is collected, modified with a window, and reported as a single data point. The increment is the time between these data points.

 

When the frame size and increment match, all data are processed with no overlap, meaning no missed data (Picture 11). However, if there was a window applied, an amplitude and/or energy error could occur. This is because a Hanning window zeros much of the data at the beginning and end of the frame. If a large event coincided with the beginning of a frame, the Hanning window would significantly reduce the amplitude.

 

 

zero_overlap.png0% Overlap for processing of data when frame size and increment are equalUsing a frame size larger than the increment can help with that (Figure 12). The ‘overlap’ allows more averages within the time duration of the test and helps reduce the error associated with the window.

 

overlap.png10% Overlap for processing data, increment is smaller than frame sizeThe combination of the frame size and increment determines the overlap.  For example, frame size of 1 second, with a 0.5 second increment, corresponds to a 50% overlap.

 

2. Data Naming

 

By default the results from a Throughput Processing calculation are saved into the active section under a new run name.  The default is “Tp” which is an abbreviation of “Throughput Processing”.

When looking back at processed data, if they are all named “Tp 1”, “Tp 2”, “Tp 3”, rather than “Run 1 with High Load”, “Run 2 with Medium Load”, “Run 3 with Low Load”, it can be difficult to tell which run the data came from originally, which is useful information when analyzing and reporting.

 

RunName.pngPicture 13: In the center of the Time Data Processing worksheet, click on the button labelled “…” allows different run naming options

The button next to the Name field opens the ‘Results destination options’ window (Picture 13). If the ‘Run name’ setting is changed to ‘Run Name Postscript’ the results will be saved into a new run as before, but with the new run name appended to the original run name making it easy to tell where the data came from as shown in Picture 14.

 

RunName2.pngPicture 14: The ‘Run Name Postscript’ option contains the original run name and appends the extension. The ‘Run name’ option does not preserve the original name.

If data was processing without the ‘Run Name Postscript’ enabled, one can still find the original run name in the data properties.

 

DataProperties.pngPicture 15: Original run data properties

Right click on any processed data and select “Properties” to see information like:

 

  • Original project
  • Original project dir
  • Original run
  • Orignal section

 

3. Original Section versus Active Section

 

Take a LMS project with two sections: ‘Baseline’ and ‘Modified’.  Three data acquisition runs were performed in a baseline condition, and three runs were done in a modified condition.

 

TwoSectionsThreeRuns.pngPicture 16: LMS Test.Lab project with two sections and three runs with the same names

Both the ‘Baseline’ and ‘Modified’ section contain runs with the same name: “Run 1”, “Run 2”, and “Run 3” as shown in Picture 16

 

If all six runs are processed at once, the default “Active section” setting in Throughput processing would create multiple runs of similar names in one section (Picture 17). This is confusing, because it is not clear which runs are associated with ‘Modified’ and which as associated with ‘Baseline’.

 

ActiveSection.pngPicture 17: Throughput processing of all 6 runs with “Active Section” set and “Run name postscript”. Data is mixed.

When performing throughput processing, there is an important setting that can avoid this confusing situation (Picture 18). The ‘Save Destination’ can be changed from the default ‘Active Section’ to ‘Original Section’.

 

OriginalSectionMenu.pngPicture 18: The ‘Save Destination’ can be switched between ‘Active Section’ and ‘Original Section’

 

After processing the data, it is clear which data is from the ‘Baseline’ section and which data is from the ‘Modified’ section as shown in Picture 19.

 

OriginalSection.pngPicture 19: With ‘Original Section’ all processed data returns is clearly stored with original source

 

Note that if “Original Section” is selected, one must have the original project open.

 

Time files that are located outside the currently opened project cannot be processed with the ‘Original Section’ setting. This is because processed data can only be stored in the currently open project.

 

Conclusion

 

Hope you find these tips helpful for using Throughput Processing!

 

Questions?  Contact Us!

 

Related LMS Test.Lab ProcessingTips:

LMS Test.Lab Acquisition Tips:

LMS Test.Lab Display Tips:

Comments
Visionary
Visionary

If we're using tracked processing with tacho.  How can relate our rpm increment to overlap?  

Creator
Creator

I would guess that depends on a few things:

 

1.  RPM slew rate -The rate the RPM changes per second of your test object

2.  RPM Increment - Spacing between acquisitions in RPM as defined in your test setup. 

3.  Frame size - Amount of time required to capture each spectrum as defined in your test setup.

 

For example:

RPM slew rate = 100 rpm per second

RPM Increment = 50 rpm

Frame size = 1 second

 

The above should be an overlap of 50%

 

If the rpm slew rate was 50 rpm per second instead, there would be 0% overlap.  

 

Good information on frame size here: 

Enthusiast
Enthusiast

1. First Case (Frame size < Increment): Suppose tracked time is used, and the frame size is 0.5s, the increment is 0.8s. How does the time data block corresponding to the increment data point?  The below two corresponding relations,which is correct or both are error?

 

Original 0-0.5s             correspondes    0

Original 0.8-1.3s          correspondes    0.8

Original 1.6-2.1s          correspondes    1.6

 

OR

 

Original 0-0.5s             correspondes    0

Original 0.5-1.0s          correspondes    0.8

Original 1.5-2.0s          correspondes    1.6

 

2. Second Case (Frame size < Increment): Suppose tracked time is used, and the frame size is 2s, the increment is 0.8s. How does the time data block corresponding to the increment data point?  The below two corresponding relations,which is correct or both are error?

 

Original 0-2.0s             correspondes    0

Original 0.8-2.8s          correspondes    0.8

Original 1.6-3.6s          correspondes    1.6

Original 2.4-4.4s          correspondes    2.4

 

OR

 

Original 0-2.0s             correspondes    0

Original 0-2.0s             correspondes    0.8

Original 0-2.0s             correspondes    1.6

Original 2-4.0s             correspondes    2.4

 

3. For a product operational noise and control, how to set the relationship between the frame size and time increment? How about the total acquisition time? Should it be the integer multiple the frame size?

 

Roy

Siemens Phenom Siemens Phenom
Siemens Phenom

I think the article answered your question:  We use the increment to set the start of the FFT and then the frame size (1 / frequency resolution) determines how long the FFT takes.

 

First Case (Frame size < Increment): Suppose tracked time is used, and the frame size is 0.5s, the increment is 0.8s.

 

Original 0-0.5s            

Original 0.8-1.3s          

Original 1.6-2.1s 

 

How we annotate (or what you say correpondes) the block based on the beginning of the tracking step so 0, 0.8, 1.6 in this example when tracked on time.  If you test it, you can easily see that by looking at each block of the waterfall.

 

1-5-2018 10-08-32 AM.jpg

 

For your second case, the same goes:

 

Original 0-2.0s             correspondes    0

Original 0.8-2.8s          correspondes    0.8

Original 1.6-3.6s          correspondes    1.6

Original 2.4-4.4s          correspondes    2.4

 

If I calculate a time block rather a frequency spectrum, this is easy to see.  The tracking value at 0.8 seconds used 0.8-2.8 seconds of the throughput file.

 

 

1-5-2018 10-23-51 AM.jpg

 

Per (3) that is up to you.  Most customers don't want to skip any data so don't normally set the increment much larger than the frame size unless their test is several hours long and then the waterfall would be too big.  If you set the increment = frame size then you are not missing any data (unless you use windows).  Due to the window used you may want to specify some overlap as shown above.

 

Length of total acquisition time depends on length of the event you want to measure or how many averages you want to include.

Enthusiast
Enthusiast

 Hi Kevin,

Thank you for your reply. This question is more clear.

1. If we use tracked time mode, is it possible to use averaged spectral for one increment? That is to say, can we use two or more frame size FFT average result for one increment point?

2. How to calculate a time block in LMS Test.lab like the picture you showed before? 

 

Roy

Siemens Phenom Siemens Phenom
Siemens Phenom

Hello Roy,

 

Have you tried either of these?  Both are possible and relatively simple to accomplish.

 

1.  When tracking on time, you can turn on semi stationary averaging and set the number and type of averaging.  At least that is possible in current versions of LMS Test.Lab and the option is shown in a few of the screenshots above.

2.  This is easy.  When specifying the function to calcuate under Channel Processing, Time is an option.  In this case the windowed time block is saved.

Enthusiast
Enthusiast

Hi Kevin,

1. This can be done only based on stationary mode?

2018-01-09_154907.png

 

2. I tried with time function, but my result is different from you. The abscissa value of  every increment time curve are the same   from -0.64 to 0.64

2018-01-09_154256.png2018-01-09_154745.png

Siemens Phenom Siemens Phenom
Siemens Phenom

Hello Roy,

 

1)  No, set tracking mode to tracked on time or tacho.  Then below that turn on Use Semi-stationary averaging and press the More... button to setup the averaging at each tracking point.

 

1-9-2018 7-47-13 AM.jpg

 

2)  You need to right click on the X axis and change the format to throughput time rather than time.  This will show the time in the throughput file rather than the time for each block (which is the same).

 

1-9-2018 7-52-13 AM.jpg

Creator
Creator

Hi friends!

 

When I'm uploading the measurements of differents sessions (four differents tests, keeping only two references channel and roving the rest of channels), appears the follow message box:

 

Sin título.jpg

 

What the meaning of this? Can help me please.

 

Alvaro.

Siemens Phenom Siemens Phenom
Siemens Phenom

It looks like some of your channels had the same channel number so some were changed.  That is why channels 46 and 47 are orange - something has been modified and the results have not been saved.  I wouldn't worry about it.  You can still use these channels in Signature Throughput Processing if needed.  Or if you use Save or Save As... to save the channels into a new run they will turn Green after they are saved.

Contributors