Feedback on Getting Started with CompactRIO - Logging Data to Disk

[AndyNorthumbria]

Thanks, this guide was a great help in designing my first cRIO system for monitoring photovoltaic modules. Worked through this tutorial and created the system and then modified it to measure photovoltaic cell parameters and a pyranometer using an NI 9221 input module. Added a sine wave voltage output in the timed loop using an NI 9263 output module. I used the TDMS files produced in a seperate project that calculated module efficiency.

Andy, Northumbria University

[jcalusdi]

Hi everyone,

I worked through the tutorial to set up my cRIO hardware with an RT.vi, an FPGA.vi, and a FIFO as described in the second part of the example.  It is working fine except that I cannot control the loop rate of the FPGA vi using the count(uSec) control located in the RT vi.  I am assuming that this value is passed at startup to the FPGA vi to control the timing of the while loop in this vi. 
 
For the count(uSec) value in the RT vi, I have a value of 500 with a loop delay of 1000 (msec).  I am sampling a 4 kHz sine wave (period = 252 usec. approx)  and collecting about 44 samples per cycle (or period) of the input sine wave.  This translates into a sample interval of 5 usec ( 252 usec/44 samples).  I was expecting a sample interval of 500 usec as set by the count(uSec) control.

Also, my FIFO is set up with num_of_elements = 16383, type = target-to-host DMA, and datatype FXP.  I read 2000 bytes at a time from the FPGA node in the RT vi.  Any insight into the operation of this DAQ would be greatly appreciated!

My NI hardware configuration is the NI cRIO-9012 controller and the NI-9215 analog input module with LabView 2009, sp1.   I have also attached my vi's.  Thanks again to any help that can be provided. 

[V_Alex]

Hello everyone,

I am trying to acquire data on one channel with a speed of 1Mhz using CompactRIO 9074 and a NI 9223 measuring card. The data is saved to a TDMS file and transferred to the PC via ftp. To get the time data of the measuring data, the tick count sub-vi is implemented in the FPGA vi.

My problem is that the buffer overflows on the host side, regardless of how many data is read in one loop cycle (tried from 2 000 to 1 200 000). The read loop runs in a state machine.I tried different FIFO settings/data types and to make a typecast instead of the "type conversion", but that did not improve the speed and the data didn't make sense anymore as i always had the same numbers. I also tried not to stop the program even when the buffer is full, as i hoped to get at least the data that's still in the buffer. But as you can see in the attached picture, i lose a lot of data. The peaks describe the amount of time in us between two measuring points.

I would appreciate of someone could take a look on the program and help me to find out what i could improve to acquire data at 1mhz for up to 1 minute, or why there's so much data loss.

Best Regards

Alex

[Nick-C]

Your FPGA FIFOs are fine in terms of size. The problem you are running into is that you are removing elements from the FIFO and writing to a TDMS file in the same loop. This is causing the execution speed of that loop to drop so drastically that the FIFO is being read less often and therefore overflowing. 

You need to read data from the FIFO in a timed loop and then use a producer consumer design pattern to tranfer the data to another loop where you write the data to file. This way you don't allow the FIFO to overflow because you are spending time writing to file. 

http://www.ni.com/white-paper/3023/en

-Nick-

[JPP]

Hi, I am using a similar architecture, but with a queue operation to pass a cluster of various data instead of a FIFO. It seems to work fine, is there any problem with doing it this way ?

also I am writing the measurements to a waveform chart and I have noticed the time shown on the x axis is correct for the acquisition time of the data, but there is no timestamp on the data (is there ?) how does the chart 'know' what time the data points were acquired ?

thanks, Julian.

[JPP]

oops, no, it is not always the correct time with respect to the data when I delay the loop with the chart, but I know the fix...- convert to dynamic data type in the acquisition loop to get a timestamp on the data.

[V_Alex]

Thank you for your reply.

i changed the code as you recommended (see attached picture).

Now i have the problem that i get the following memory error after some time:

"

Error -52000

Source:

Invoke Method: FIFO.Read in StateMachine realtime mit zeit - Kopie.vi

Error -52000 occurred at Invoke Method: FIFO.Read in StateMachine realtime mit zeit - Kopie.vi

Possible reason(s):

The specified number of bytes could not be allocated.

"

The TDMS only includes the first ~500 000 measuring points.

Any suggestions?

Alex

[Nick-C]

Alex,

This error indicates to me that you are trying to configure the FIFO to a size that is not allowed on the RT side of the program. Have you tried configuring the FIFO to a size smaller than 50,000 elements?

I suspect you are experiencing an error because you don't have enough memory on your RT controller to allocate a buffer that large.

-Nick-

[V_Alex]

I tried also 10,000; 20,000 elements, but the VI will abort as well.

So this is a hardware issue? I am wondering because the files i get when experiencing an overflow are just about 4MB large, but at the program startup, there is about 78MB of free RAM available on the cRio.

How is that possible?

Alex

[Nick-C]

Alex,

Does the FPGA VI compile? It sounds like this error is coming from the RT side of the application, but I want to confirm there are no problems on the FPGA side. 

Does the error occur once the code starts running, or does the VI fail to run at all? If the VI errors out once running, can you probe the block diagram and find out exactly which VI is throwing this error?

I don't think this is a hardware limitation, sound more like a configuration problem. Can you please post the most updated version of the code? I will take a look at the code and see if I can pick out where the problem is.

-Nick-