07-30-2013 10:31 PM
Hello erfigge,
If you are using the order analysis express VI from the Sound and Vibration Toolkit, I believe it requires two input signals: vibration response vs. time, and rotational speed vs. time (both signals should be in waveform format). If you have the raw pulses from the tachometer, you will need to convert that signal into a measure of rotational velocity. I believe that Preston has posted a few links with examples on how to do this.
07-31-2013 10:40 AM
Yeah, I struggled with getting the tach signal into the order analysis for a long time and never could get it to work right. I ended up using the peak search vi with the frequency that was input from the the scada.
My new issue is the vibration data fifo is now underflowing. That would be the top loop of my fpga code. I put a case structure around my IO (very bottom loop) and as long as that is shut off the vibration data will work fine, only uses about 0.2% or so of the buffer. However, as soon as I turn the IO case structure on it underflows for the fifo. What are typically easy ways to work with that? I can't say I entirely understand the timing ect on FPGA's yet. My first attempt at this is to slow down the IO loop. Right now it is running as fast as it can execute, and to be honest I don't know what that value is. Will slowing that loop down to a known frequency, lets say 20Mhz make a difference? Past that my next step is to remove the fixed point to single conversions and let the RT controller do that.
Thoughts?
08-01-2013 10:20 AM - edited 08-01-2013 10:40 AM
Ok, I think I have learned some things. I have drastically changed my code and I have reduced the size by a lot. Now the problem I'm running into is speed of the IO acquisition. I have about 20 io points that I need to read at 1000 - 4000 hz, to be honest speed of these doesn't really matter. However, I have 2 analog IO's that I need to read at 32,500 hz.
It seems to me the max speed I can run the 20 IO points is about 3500 hz. So, my thoughts are having two loops, one for the 2 points at 32,500 hz and the second loop set to run at something like 1000 hz. Then, I would take data on one loop, stop, clear the fifo and pass off to the other loop, let the second loop run, then stop it, clear the fifo and pass back to the first loop and repeat.
Does this operation make sense, and if so, would interupts from the RT controller be the best method to do this? I have attached my FPGA vi, basically I need to hand off between the top loop and the bottom loop.
FYI, I am using an sbRio 9612 and the onboard analog input which is a 9205 module.
08-02-2013
11:00 AM
- last edited on
12-02-2024
06:09 PM
by
Content Cleaner
Hello erfigge,
How are you determining the rate limits for your I/Os? I see that you are using FPGA I/O nodes and front panel objects to transfer data from the FPGA to the RT target. You may be able to get a performance boost by using DMA FIFO transfers.
LabVIEW 2012 Help: Transferring Data between the FPGA and Host (FPGA Module)
Developer Zone Tutorial: Transferring Data between Devices or Structures Using FIFOs (FPGA Module)
Community Example: Transfer multiple channels of data through one DMA FIFO on FPGA
You can certainly use interrupts to synchronize the loops between the FPGA and the RT target.
LabVIEW 2012 Help: Synchronizing FPGA VIs and Host VIs Using Interrupts (FPGA Interface)
08-02-2013 07:58 PM
I determined those rates by putting all the IO i needed into the top loop and running it into the DMA. Then I calculated the loop time from that. For all the IO I assumed that was as fast as I could go. It pretty much is nothing more than an IO loop dumping into a DMA. Am I doing something else wrong?
08-05-2013 05:26 PM
Hi erfigge,
I guess I'm just a little confused about how you set up your FIFOs. I only see 1 FIFO Write node in the FPGA VI, which is fine, but I don't see any data going to it. I see the Chan Scale Array going to the FIFO Write node, but I can't see where any of the analog data is being transferred. I am missing the FPGA Gain VI, so perhaps you are writing to that control in there, but that probably isn't the best way to transfer data into a FIFO. Take a look at the example I posted in my previous message, and apply the logic there to all of your analog channels.