RPM / Frequency Color Plot best strategy

[Alex @ IE]

Hello,

I'm trying to do some Order Spectra Analysis and I'm receiving an Out of Memory error once I'm trying to plot an RPM-Frequency colormap. I'm not sure I'm doing the right thing that is why I need some help from you. The data I'm trying to analyze it is offline data sampled at 51.2kS - a few minutes. I'm reading from the TDMS file chunks of 10 seconds (max 512kS) and for each chunk I'm using the OAT Analog Tacho processing for speed calculation and OAT Spectral MAP (Waterfall) to process the data. I'm using the Waterfall and not the Colormap because I'm buffering the spectrum using SVX Buffer Waterfall Graph (Waterfall Data).vi. Once I'm process all the chunks I'm converting all Waterfall Data to Colormap data using SXV Convert Waterfall to Colormap.vi. When I'm using the OAT spectral map, I select the window length depending of the X scale of the color plot, Width of the Colormap and Sampling Rate to make sure I will not have more that 1 frequency line / pixel. Unfortunately I can not do the same thing on the Y axis because I don't know the RPM limits of the signal so I can not adjust speed segment step to an RPM that is efficient for the resolution of the graph and maybe that cause the Out of Memory error when I'm trying to do RPM  / Frequency analysis. What is strange is that sometimes the output of the spectra analysis is very strange, the value of the dz (RPM step) is negative. For example if I set 125 RPM then the dz it comes -125. What could cause this issue and how can I improve my code ?

Thanks in advance,

Alex

[Beutlich]

Hi Alex,

There are some general ideas for improving the efficiency of your code listed in the article How Can I Optimize the Memory Use in My LabVIEW VI?. A full description is laid out in VI Memory Usage.

After trying those steps, if you still need more memory, try increasing the amount of memory that LabVIEW can access in your system as described in the article How Much Memory can LabVIEW 32-bit or 64-bit Use? or you could consider creating virtual memory as described in How Can Virtual Memory Help with Memory Issues in LabVIEW?

Another option is to isolate the source of the issue. You can use the VI Profiler to diagnose your VIs (if you have subVIs) and see which one is consuming too much memory. This is described in the article How Do I Use the VI Profile Window?

[Alex @ IE]

Hello Eric,

Thank you for you sugestion but I think I cannot optimase anyfurther my application. I've tried to make a simple VI with only the Spectral Map processing and it graps up to 700MB of RAM. Moving the application on a 64bit platform it's not a practical and easy way for me. I would like to process these files in chunks, but the issue for me is how to concatenate the outputs of the RPM/Frequency spectrograms considering that I can have on the same measurement Ramp-Up and Ramp-Down data. If I have a continuous Ramp-Up then let's say that in most of the cases the results are correct. I saw that on the Spectral Map express VI there is a input to choose between ramp-up and ramp-down, but the issue remain the same for me, how to concatenate the results from these VIs.

Thanks,

Alex

[dsb@NI]

Is it reasonable to concatenate two RPM vs Frequency spectral maps?

It only seems usable if the two datasets don't overlap the same RPM vs Frequency space. If I did have two datasets that overlapped, say 0-6000 RPM and 0-500 Hz, I don't know how I would conceptually concatenate the two datasets into one set because the two are not independent of each other. If it was Time vs Frequency or Revolution vs Frequency, the concatenation would seem to make more sense because the time between the two datasets would not overlap (similarly with revolution).

[dsb@NI]

We would expect dz to be negative for a case of coast down (speed decreasing).

Can you attach your code that reproduces the out of memory issue?

[Alex @ IE]

Hi Doug,

I agree with you, it might be not be relevant doing the concatenation in RPM/Frequency , but I have to do it because I'm forced to do the processing in chunks of data. The out of memory issue is happening when I'm trying to send to the Spectral Map block all data (see picture attached - I get the error before the breaking point and the RAM allocated for LabVIEW process raise up to 1.4 GB). That is why I want to process the data in chunks.

Best regards,

Alex

[dsb@NI]

Please describe your computer system in more detail.

Also, much of the data size when resampling is dependent on the actual data (especially speed and number of pulses per revolution) and the analysis configuration. Can you tell us how to simulate data that would make one of the shipping examples fail in the same way (out of memory)?

[Alex @ IE]

Hello Doug,

I've attached in archive the minimum processing code for colormap processing in oneshot.

Also I've loaded 2 files (one without error, but the allocated memory is already at 900MB), and another file that failed loading. I've attached the speed profile from another application to make an idea of what is looking like. Considering the sampling frequency (51.2kS/s) and the amount of data (3-4 minutes), I suppose the only valid method to process will be in chunks, that is why I have to find a solution for concatenation.

Best regards,

Alex

[AlanArmstead]

Hi Alex,

Here's a quick tip that may be worth trying.  When loading your data, instead of reading both channels at once and then indexing each of them out, try reading each channel individually.  The process of indexing the data from an array of waveforms into individual waveforms will make a copy of the data.  So, you can avoid one copy of the data by trying something like this:

-Alan

[AlanArmstead]

Also, the tachometer processing VI can be a little bit of a memory hog.  So, you could calculate the speed profile separately, save it to TDMS, then read it in from your colormap application.  Then you could just pass the speed profile data directly into your color map VI from the TDMS read.  So, you would only need to read one waveform channel and one speed profile channel.

-Alan