Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Feedback on Getting Started with CompactRIO - Logging Data to Disk

The FPGA VI is being called and run by the RT VI.  The FPGA is being run and then the FIFO read is occurring right afterwards.  Therefore the FIFO should never run without the recording VI having called it to run, and the FIFO should not overflow for that reason.  Are you making sure you are only clicking Run on the RT VI?  The FIFO VI should not be open at this point and if it is, could be influencing your timing.

 

The FIFO.Read method reads elements of the DMA FIFO from the host memory part of the FIFO. The Read method returns Data when the Number of Elements is available. If the Timeout period ends before the Number of Elements is available, Data is empty.  Thus, if there are the specified number of elements before the timeout, it will return those when it has those.

 

Regards,

 

Elizabeth K. 

National Instruments | Applications Engineer | www.ni.com/support 

0 Kudos
Message 11 of 108
(2,644 Views)

Point 1 - you caught my mistake there - I'd fired off the FPGA VI earlier and was confused as to why the RT wasn't functioning properly afterwards. What an obvious mistake, thanks for spotting that!

 

Point 2 - If FIFO.Read returns when 2100 elements are found, and it's not returning zeros, my FPGA data collection and writing to FIFO must be running very much slower than expected? I've got my loop timer set at 500uSec, suggesting 2khz sampling of 6 channels, yet I'm now not seeing a log of anything like that many data points per second. Having just run the system with a loop speed of 500uSec, otherwise configured as specified (2100 element read, 350x6 array fills) I get a channel length of 1400 after 10 seconds recording time. No timeouts flagged, no idea about overflows as the VI front panel for the FPGA.VI is not "active" when it has been run by RT.VI, despite it clearly running as I'm getting data.

0 Kudos
Message 12 of 108
(2,627 Views)

A few notes:

 

- Since you are reading the "Overflow?" in the RT portion of the code, you do not have to have the FPGA front panel active in order to see if it registers an overflow.

 

- I do not think that you will be able to reach the sampling rate that you want because of the limitation of your 9219 module. It samples at 100 S/s/ch simultaneous inputs.  So although all four of them can be sampled at the same time, it still means that the fastest you can get one sample from all four of the channels is 1/100 = 0.01 = 10mSec.  Therefore the FPGA loop will not be going at 500uSec.  You can check to see how fast your while loop is going by using these instructions: Measuring While Loop Execution Rate (FPGA Module).

 

Regards,

 

Elizabeth K. 

National Instruments | Applications Engineer | www.ni.com/support 

0 Kudos
Message 13 of 108
(2,612 Views)

I appreciate the comments WRT the 9219 module but previous discussions have yielded the expectation that sampling the 9219 more frequently will simply read redundant data, not slow the loop time down - that would be fine, so long as that data is in line with the other channels that are capable of returning faster updates - i.e. a stream of one value for 10ms, then a stream of the updated value etc. If the 9219 is slowing my loop speed so significantly it practically makes the whole point of using the CRio null in this instance - your logging speed is restricted to that of your slowest module? I could use the other AI module to read the thermocouples but I suspect the resolution is too low for my purposes.

0 Kudos
Message 14 of 108
(2,610 Views)

"- Since you are reading the "Overflow?" in the RT portion of the code, you do not have to have the FPGA front panel active in order to see if it registers an overflow."

 

Yes, slightly odd that it's in the example I modified. I was of course relating the overflow viewing to the previous mistake where I was running the RT VI with the existing FPGA already running (and displaying an overflow), since correcting this mistake the FPGA front panel remains inactive so I've no idea if it's overflowing. All I'm getting is very slow results.

0 Kudos
Message 15 of 108
(2,605 Views)

I'm also more than slightly miffed that the 9201 datasheet suggests that it's got adjustable gain, as I could have used it at the 80mV setting as planned (http://sine.ni.com/ds/app/doc/p/id/ds-184/lang/en), when in reality it does not. I might not have bought this module had I realised. Smiley Sad

0 Kudos
Message 16 of 108
(2,600 Views)

I do not think that it will read redundant data, although I was not able to test on a 9219 to verify that.  And to be clear, are you sampling in High Speed mode?  Are you using a thermocouple?  And how are you benchmarking this acquisition?  Could you post the code that you are using the benchmark it?

 

As for the overflow discussion, I am still a bit confused.  All of the indicators and controls on the front panel of an FPGA VI are able to be read from the RT FPGA Read/Write control.  Therefore the overflow indicator on the front panel of the FPGA can be read and viewed on the RT portion.

 

I am a bit puzzled at the datasheet for the 9201 mentions an 80mV setting.  The product page and the specifications state only +/- 10V.

 

Regards,

 

Elizabeth K. 

National Instruments | Applications Engineer | www.ni.com/support 

0 Kudos
Message 17 of 108
(2,582 Views)

Curious - the creator of this thread/tutorial suggests it would read redundant (http://forums.ni.com/t5/Real-Time-Measurement-and/FIFO-settings-cRIO-9219/m-p/1396402#), and from a technical standpoint I'd have thought it possible to achieve either (either commanded sample with associated delay or continuous sampling with redundant data returned). As for sampling in high speed mode - yes.  I'm sampling with a slightly modified version of the code I posted above (just with a fixed FPGA loop speed of 500uSec rather than an adjustable control) and benchmarking by timing a minute of sampling, then dividing appropriately.

 

"As for the overflow discussion, I am still a bit confused.  All of the indicators and controls on the front panel of an FPGA VI are able to be read from the RT FPGA Read/Write control.  Therefore the overflow indicator on the front panel of the FPGA can be read and viewed on the RT portion."

 

I'm still working on this, I've currently no idea what can and can't be passed too and fro, or how, this is why I was following this basic tutorial.  This tutorial has an overflow flag in the FPGA VI and a timeout on the RT side, there's no passing of overflow to the RT VI demonstrated and as yet I've not found an example of how to achieve it, though I've not been looking as I've switched to using a PCI 6221 temporarily as I need results urgently and will have to save the lovely process of learning to get anything useful out of the crio for my spare time.

 

WRT the 9201 - the product page does state +-10V, but the specifications link right off the product page (i.e. the one you go to to look in more detail) says otherwise. Of course if I'd read them in even more detail and had the hindsight of actually having the device to double check I'd notice that half of the content of that spec page is wrong, also claiming:

 

  • Signal conditioning for high voltage (±60 V), thermocouples, RTDs, accelerometers, microphones, strain gages, current inputs
  • Advanced features such as smart TEDS sensor capability, antialiasing filters, open-thermocouple detection
  • ±80 mV, ±10 V, or ±60 V analog input ranges
  • 12-, 16-, or 24-bit (delta-sigma) resolution
  • Up to 800 kS/s multiplexed or up to 100 kS/s simultaneous-sampling analog-to-digital converter (ADC)
  • Up to 32 channels per module
  • Up to 2,300 Vrms isolation (withstand), up to 250 Vrms isolation (continuous)
  • NIST-traceable calibration certificate for guaranteed accuracy

Nothing seems to do what I expect anymore!

 

Cheers for your help so far though, I'll keep working on it in the background, in the mean time I'm off to try to hook up a quad encoder to the 6221 for triggering, wish me luck!

0 Kudos
Message 18 of 108
(2,571 Views)

I am glad you are working through the getting started guide to learn LabVIEW FPGA and Real Time.  It might take a little bit to get acclimated to the new environment, but I think you are already off to a great start.

 

I have added some benchmarking tools to the FPGA VI you posted earlier which will tell you how fast your FPGA loop is running.  You will need to pull that indicator off the FPGA as discussed below.

 

In order to view data from the front panel of the FPGA VI in your Real Time code, you will use a FPGA Read/Write Control.  Basically anything that is purple on the RT side comes from the FPGA.  You can pull the overflow information as well as the newly added timing information from this control.  In the Real Time code that you posted earlier, the Overflow information from the FPGA was pulled using this Read/Write control, which can be seen below.

 

FPGA Read.PNG

 

I have submitted a request to get the erroneous 9201 information off the product page.  Thanks for bringing that to our attention.

 

 

Elizabeth K. 

National Instruments | Applications Engineer | www.ni.com/support 

 

0 Kudos
Message 19 of 108
(2,546 Views)

I followed the tutorial exactly. However, when i run the VI I don't have a file created, nor the control diagram show any reading. The FIFO is saying "FIFO empty" and "do nothing". Did i miss anything for this?? my equpiment is cRIO 9025 and NI 9213 thermocouple module.

 

Thanks

 

 

 

0 Kudos
Message 20 of 108
(2,532 Views)