07-23-2009 02:20 PM - last edited on 12-04-2009 07:53 AM by Doug_S
07-24-2009 09:59 AM
Hello everyone! I am very excited about this component and would love to hear about your experiences, ideas, pain points, etc. I will be monitoring this forum regularly; any feedback is both welcome and appreciated. I have already gotten some good ideas from customers and I plan to release a new version sometime in the fall of 2009.
Systems Engineer - Sound and Vibration
12-03-2009 04:10 PM
This may not be specific to your reference app, but I'd like to see an example of multiplexing the data into the dma from multiple modules running at different rates. This example shows how to extend the code to handle multiple modules, but not when they are running at different rates.
Nice example btw,
12-04-2009 04:18 PM
For multirate acquisitions the simplest approach is to allocate one DMA channel per rate and to make a duplicate copy of each rwfm VI for each FPGA acquisition loop. Certainly this approach is limited by the number of DMA channels you have available.
I've heard an R&D team here is researching a technology that would provide a multiplexing abstraction layer around one DMA channel that is scalable on the FPGA side. This would remove the DMA channel limitation but it wouldn't be available in the short term.
12-07-2009 10:51 AM
Yes, one DMA per rate is convenient when there are enough DMAs. I've worked an a number of applications where there aren't enough though. Right now, I'm working on one where I'm using a 9870, and the reference example I found to work with that card uses two DMAs right off the bat. I believe that a hybrid scan engine approach also ties up two DMAs.
I guess I'll look forward to that multiplexing abstraction layer material. I had posted a while ago with a proposed architecture for solving this issue, but it turned out that I had overhead issues when actually implementing it. I'm still looking for a good solution.
03-01-2010 10:56 AM
Maybe just an idea for the next release....
But wouldn't e useful to have this as an installer or a procedure to include those VI's inside the standard LabVIEW palette?
Could be nice...
Julien from NI Belgium
05-04-2010 09:14 AM
Hi Jeff. Do you know if research on the multiplexing abstraction layer produced any results? I'm working on a project and this approach would be useful. I need to make the acquisition of several modules (1 to 8) at different rates. Thanks in advance.
My best regards,
05-27-2010 03:10 PM
I am getting a "specified number of bytes could not be allocated" error in the rwfm_BufferCfg VI. I am not experienced enough to know what is the limit of bytes and how many I am exceeding it by.
I have closely mirrored the example for continuous acquisition. The samples per block is 40,000 and I see the buffer size is set at 400,000 (10x the read size). Is there a method available to determine amount of available memory?
05-27-2010 03:28 PM
I have typically started getting those errors around 30MB or so; I didn't investigate enough to know if it was a hard limit or if it was controller/application dependent. Also remember the total memory is 400,000 samples times the number of channels. Each sample in this implementation is 4 bytes so you are only allocating 1.6 MB per channel. You can use the RT Utility VI "RT Get Memory Usage.vi" to see how much your application is consuming before the DMA buffer VI is called.
My recommendation is to lower your factor from 10 to 5. If you have a healthy acquisition then 5 sill gives you plenty of margin to protect against overflows. Just watch the "Used Buffer %" indicator to see if your controller is keeping up or not. If it can't keep up then it really doesn't matter what the number is anyway.
If that doesn't help then let me know. Depending on your application there may be other options besides continuous acquisition.
S&V Systems Engineer