Components

cancel
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 113
(17,846 Views)

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.

 

rwm_read.gif

 

Jeff Tipps

Systems Engineer - Sound and Vibration

Message 2 of 113
(17,839 Views)

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,

Chris

0 Kudos
Message 3 of 113
(17,504 Views)

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,

 

Jeff 

0 Kudos
Message 4 of 113
(17,484 Views)

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.

 

Chris

0 Kudos
Message 5 of 113
(17,469 Views)
Highlighted

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... πŸ˜„

 

Regards,

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 113
(17,107 Views)

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,

Vinicius

0 Kudos
Message 7 of 113
(16,742 Views)

Vincius,

 

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

 

Regards,

 

Jeff Tipps

S&V Systems Engineer

0 Kudos
Message 8 of 113
(16,729 Views)

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?

thanks! 

 -erik

0 Kudos
Message 9 of 113
(16,578 Views)

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.

 

RTMemory.png

 

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.

 

Regards,

 

Jeff Tipps

S&V Systems Engineer  

0 Kudos
Message 10 of 113
(16,573 Views)