FFT to Monitor Bushing Chatter

Has anyone been able to get a frequency domain calculation out of an analog signal in structed text?

Taylor Turner said:

Has anyone been able to get a frequency domain calculation out of an analog signal in structed text?

Click to expand...

I think this can be done. To me, it depends on your hardware and what frequencies you are interested in.

- Can you synchronize your analog input on a schedule?
- Is the jitter in the A/D sampling small enough that is does not affect your calculations. 1% jitter would be great, but I think you can make it work for 10%.

For example, if you can sync your analog input for a vibration input at 100 ms, and there is no jitter, you can get information for 10 Hz. If you allow for jitter plus or minus 1 ms, I think you can get decent FFT information out of your data for 8 Hz. If the jitter expands to 10 ms ... I think you can still get information for 1 Hz or so

The only analog inputs that I can think of that are built for FFR are in power relays

It's likely possible, it's a formula after all, but it's an intensive computation and the sampling needs to be timed (which on a platform like Rockwell can be tricky).

My biggest concern however wouldn't be so much the calculation and practical aspects of the implementation but more along the lines of proving the implementation. Bad data is worse than no data.
The stuff that exists today to look into this isn't particularly expensive (unless you go with Rockwell's offering) and can provide a lot of data to be analysed. I use sensonics where I work, but there's more around.

No I have not done in a PLC in structured text, but I have used it in a 2-D domain to remove noise from an image. I see a few issues, in no particular order after the first:

• CPU cycles per scan available to execute the FFT algorithm
  • This is probably the limiting factor of what can be done
  • This is the fundamental concern that ties in to all the issues that follow
• Sample rate
  • more samples per second means less CPU cycles available to execute the FFT
• Sample count i.e. sampling duration
  • How many samples contribute to the FFT?
  • This affects the frequencies analyzed
• Incremental calculations
  • Perhaps there are 64 scans of collecting data, then 64, (or 640?) scans that execute the FFT calculation piecewise on those data i.e. a multi-scan loop
  • I haven't looked at the algorithm in a while, but I wonder if it could be put into an incremental form, where each new sample requires O(N) calculations to "remove" the oldest sample and add the newest
    • Sampling into a circular buffer could be used here; IIRC the FFT result does not depend on which two adjacent samples in a circular sequence are considered the last and first
    • Would this degrade precision over time?
• Resolution
  • Are CPU- and/or time-intensive double-precision floating-point calculations necessary, and if so, is that an issue for the selected PLC?
  • Is an integer-based form of the FFT possible cf. the first few entries here?
    • This might solve the precision issue above.
    • The Galileo spacecraft Solid-State Imaging instrument implemented an integer form of the Discrete-Cosine Transform (DCT) in its 8-bit CPUs to compress data after the antenna failed to open and the expected telemetry bandwidth dropped by two orders of magnitude.
    • Querying The Google about [integer fft algorithm] yields many results