FlexRIO Streaming Protocol for externally triggered ADC

[mcg480]

I am attempting to use the FlexRIO data streaming protocol to pull data from a custom ADC adapter module that is externally triggered.  Documentation for these functions is extremely lacking.  See:

http://zone.ni.com/reference/en-XX/help/372614J-01/target5devicehelp/idl_streaming_vis/

This is about all the information I can find.  There are one or two example projects, but these are finite acquisitions with no triggering.  I think I understand how to set up the Target VI, it is the Host VI I am unclear about.  See attached images (the Host VI is cut-off, but to the left is just initialization and to the right is just setting the output up for a waveform graph).  

Right now my Host VI is running in a slow 20 Hz loop.  My ADC trigger is 100 kHz (with 800 samples read from 2 channels per trigger event), so I am simply flushing the FIFO before enabling the stream on each loop.  This means I am losing a significant amount of data.  

I think the right way to do it would be to set up the Host VI for Finite Stream, and tell it to collect 1600 x 1e5 / 20 samples (50 msec worth of data), then send that to another loop via a queue to write to disk.  Unclear if the Target side will require the use of DRAM or not - I'm guessing yes.  

Basically I'm looking for some example projects that use the FlexRIO Streaming Protocol with Trigger, and ideally Streaming + DRAM FIFO, has anyone come across something like this?  

[Case_in_Point]

Hey mcg,

Have you looked at the FlexRIO Getting Started projects underneath specific IO modules in the Example Finder? Because those examples do implement triggering on the FlexRIO and operate continuously. If you haven't they might be worth a look; the 5783 one should be a good example to look at, since it's implementing a few types of possible triggering as well as interleaving samples from multiple channels on the FAM into one FIFO. Also note that there's no need to flush the FIFO, since on the target VI data is only being pushed into the FIFO when the trigger condition is met. So you should only have good data in the FIFO. 

I don't think you'd need to implement DRAM on the target to hold the data; a FIFO should be sufficient? You're not going to need to hold onto large chunks of data on the FPGA itself. On the Host side though you probably will want to queue the data and process it in a consumer loop.

Cason

NI Applications Engr.

[mcg480]

Cason, 

Thank you so much, this seems to be what I was looking for.  It was just a matter of not being able to navigate the "find examples" tool - I couldn't find that particular example with the search function.  

Cheers,

M

[mcg480]

I'm going to bump this one because I have another related question.

I can't seem to find any examples that use the Streaming protocol in Continuous mode.  Specifically "Start Continuous Stream.vi" on the Host side.  Every time I try to put my stream into the continuous state, the stream state immediately switches to "Error" state instead.  There isn't much documentation, but the Context Help says this could occur due to buffer underflow/overflow, but I don't see how this is possible so quickly.  I'm calling "Start Continuous Stream" outside of my Host while loop, and just using the loop to pull data from the FIFO.  

In the end I'm trying to pull a few hundred samples from the ADC every trigger, which is happening at about 1kHz.  If there is a better way to do this I am open to it.  All the examples I've found so far are for Finite Streams.  

I've attached some pictures - I check the stream state in various places as I start up the Host VI to see when it errors out.  Stream states 1 and 2 are "Idle", and 3 + subsequent are "Error" until I reset it at the end of the while loop.

[Case_in_Point]

I admit I personally haven't ever used the Continuous Stream option from the IDL. I've always still used Finite Stream acquisitions, even in cases where in the grander scale it's a continuous acquisition. Looking at your code how you laid it out, though, I think it makes sense why the Start Continuous would error out immediately. If I'm following the logic correctly (and I'm making some assumptions) you don't send the Ready for Trigger from the Host to the FPGA until you're into the While loop. Most likely, that means the FPGA isn't going to actually write anything into the FIFO until then. So the FIFO would still be empty at the time you call Start Continuous Stream, so it'll underflow immediately.

To use Continuous Stream, there has to already be data in the FIFO at the moment the stream starts, and there has to always be data in the FIFO as long it's still going. Any over or underflow is going to make it error out. This is why we typically use the Finite Stream option; it's just easier to make sure you don't get cases where you underflow.

Cason

NI Applications Engr

[mcg480]

Inside the start trigger sub-VI on the Target side, one of the requirements for "data valid" out (that goes into the Stream Control) is that the state must be "Finite Transfer" or "Continuous" so this means no data is sent to the FIFO until the state goes to Continuous.  This VI is semi-custom (see attached), but it's based on the "Streaming Start Trigger" VI in the Streaming library, all I did was add the trigger reset to it.  Does that mean this trigger VI is not compatible with Continuous mode?

I don't fully understand the underflow issue, what exactly is underflowing?  The DMA FIFO?  Or does the "stream" have its own internal FIFO?

Basically I need to ensure I don't miss the first trigger event, or any subsequent triggers for that matter.  I can run the whole thing in Finite Transfer mode, if possible.  I just assumed that I would lose data between while loops when I reactivate the stream.  

[Case_in_Point]

So the Streaming IDL is ostensibly just a useful state machine, although on the Host side it does grab the FIFO reference so I suppose it is doing some interaction with the actual FIFO for it's reporting. I don't really know the condition where the underflow would occur, but it is specifically called out in the documentation. However, with how you've implemented things I don't think it's that functionally different from the examples I've looked through. For any triggered acquisition, for instance, you're most likely going to have started the stream before getting any valid trigger and thus there still wouldn't be any data in the FIFO at the point you start the transfer from the host. I'll have to look more at how exactly this is expected to work. If you try and initiate a Finite Stream, just as a sanity check, do you get the same error?

Cason

NI Applications Engr.

[mcg480]

Thanks for your continued assistance.  Finite streams were not giving me the same error.  I think I figured out the issue last night, however.  I should have mentioned this from the start, but my hardware trigger input is present from the start, before trying to go to Continuous mode.  In addition, I think the default state for "Ready for Start Trigger" was set to high, so basically as soon as the state goes to Continuous mode the data starts to stream.  The DMA FIFO I was using was only 2047 elements in size, so I think the problem was actually overflow not underflow - my FIFO was filling up faster than it could be read out.

I implemented a DRAM FIFO based on the example in "NI 5751B Getting Started.lvproj" and this alleviated the issue.  In case anyone stumbles on this thread I will attach some screenshots.  I didn't have to change anything in the Host VI.  Unfortunately it takes twice as long to compile now!  

Thanks again for the help.