order analysis cut short

[ULIHZ]

I was doing order analysis on some motor run-up run-down data ( from 200 ~ 5000 rpm). It was noticed that when dealing with run-down data (defined as starting rpm 4900, ending rpm 200), the calculation stops at around 2000 rpm. The help file said that the rpm channel has to be equally spaced, but I tried multiple things, including generate a straight line rpm channel but still had no luck. If I reduce the window size (say, from 4096 to 2048), the ending rpm will go down some, but still not to the specified end value.

I finally inverted the rpm and signal channel (made the “run up”) then did the same analysis (starting at 200, ending at 4900) and it worked.

Why?

[Bellissima]

Hi ULIHZ, 

DIAdem by default requires data to be graphed from lowest value to highest.  I think the issues you were seeing were because the data was originally in the inverse order.  

Best wishes!

[ULIHZ]

If so, is there other workarounds I can use (instead of inverse the data)?  It is known that motor run-up an run-down will have different responses, hence order analysis with rpm from high to low is a must. 

The order analysis function did not stop working (and allow inputting starting rpm higher than the ending one), just not working correctly (and without any warning or prediction to show at what rpm it will stop calculation). 

[Bellissima]

Hi ULIHZ, 

What are you using for your x and y values?  What exactly are you seeing?  What exactly are you expecting to see?

Regards,  

[ULIHZ]

when do order analysis, the three input channels are time, signal, and rpm.  The results can be plotted (the default surface plot) with X axis of order, Y axis of Rotational speed.

When I do my runup analysis (from 200 to 4900 rpm in steps of 50), I will get order curves every 50 rpm from start to end (named "OrderRPMxxxx"), when I do the same (from 4900 to 200 rpm), I got order curves every 500 rpm from 4900 to 2000 (or 1950, depending on the data used).  I tried multiple settings in order to fix it, but the only way to make a change was reduce the window size.  Reduced the size from 4096 to 1048, I had order curves from 4900 to 1400 rpm. 

I read the following note in the help file:"Note The rpm intervals must be equidistant. Sufficient values also have to exist to run an FFT. If not, DIAdem reduces the end value first, until only one step is possible, and then DIAdem reduces the FFT length to make a calculation possible."

Making perfact straight line rpm channel maks no difference. It is hard to know what was considered "sufficient values".

 The result from inverted rpm/data channels

 example of cut short rundown order analysis: ending rpm 1950

[ULIHZ]

Amanda,

I am attaching a test case if you would like to try.

Thanks!

[Bellissima]

Hi ULIHZ, 

Is there a reason you cannot work with the inverted data?  It is difficult for me to see the differences in your graphs.  It sounds like something similar to your error messages is happening to  your graphs currently.  Inverting the data will be the easiest work-around. 

Regards,

[ULIHZ]

I would like to know what was wrong (either i or the program), that is, have fully understanding of the problem instead of stop with a work around.   I have seen order analysis using different software calculating three up-down cycles, hence consider it is mathematically possible.

The differences of my plots are very obvious: the correct one contains rpm from 200 to 4900, the problem one only have 1950 to 4900.

There was no error message during the order analysis, and I cannot correlate the notes from the help file with my situation.

Your can try to do an order analysis using my test data (needs to generate a time channel, I did not include it in order to keep the file size smaller than 6M).

I was using the script:

Call SUDDlgShow("Main", ResourceDrv & "AnaChnOrdAFCalc")

with the following parameters:

order calculation

maximum order = 20

recalculate filter when RPM change by: 5

Calculation type dB

reference value for 0 dB = 1

RPM parameters:

Start value 4900

end value 200

step width 50

FFT length 4096

Amplitude: RMS amplitude

Third Octave calculation: No

FFF window type: Hanning

Amplitude attenuation correction: random

In this case, the oderRPM stops at 1300.

[Bellissima]

Hello ULIHZ, 

Have you tried graphing similar data without the script to rule the script out as a possible cause?  I would definitely suggest attempting this.  

Regards,

[ULIHZ]

Have you tried some "extra" work and see what was going on?  There is nothing to to with the plot it self.  There was no data to plot at lower rpm.  If you think the script was the issue, then what could it be?  Have you read the script, an tried to duplicat my case with my data, or generate a set of data yourself?