Showing results for 
Search instead for 
Did you mean: 

CompactRIO Waveform Library

Please provide feedback, comments and questions on the NI CompactRIO Waveform Library in this thread.

0 Kudos
Message 1 of 115

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.




Jeff Tipps

Systems Engineer - Sound and Vibration

Message 2 of 115

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,


0 Kudos
Message 3 of 115

Thanks Chris,


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.


Best Regards,



0 Kudos
Message 4 of 115

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.



0 Kudos
Message 5 of 115

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

Julien Roland - District Sales Manager
NI Belgium - Technical Support

Don't forget to rate a good answer
0 Kudos
Message 6 of 115

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 😎 at different rates. Thanks in advance.



My best regards,


0 Kudos
Message 7 of 115



My understanding is that technology is still in the resesarch phase so I wouldn't expect it in the near future.




Jeff Tipps

S&V Systems Engineer

0 Kudos
Message 8 of 115

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?



0 Kudos
Message 9 of 115

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" 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.




Jeff Tipps

S&V Systems Engineer  

0 Kudos
Message 10 of 115