Configure Logging VI start and stop without losing or dropping data

[lestwest49]

Hi there,

I am currently using a M-series PCI-6280 and a counter card PCI-6601 to do measurements on Labview 2010. 

I have 3 tasks set up, 2 linear encoder counter tasks on the 6601 and 1 analog input task with 4 x inputs on my 6280.  These are all timed with a counter on the 6601 through an RTSI line.

On all of these tasks, I have a similar set-up as the picture in http://zone.ni.com/devzone/cda/tut/p/id/9574 except they are all set up as "Log" only and "create/replace" file for the configure logging.vi.  

Since I want to have the encoders continuously locate my position, I never "stop" the counter tasks.  However, I need to use the data acquired after every move along the path to obtain and process the location and the subsequent analog input data points I have.  What I have done, is I would "stop.vi" my sample clock on the counter, then open the tdms file, read the tdms file, get the array from there, close the tdms file, then "run.vi" the sample clock on the counter.  However, I found when I stop the sample clock, not ALL the data points have been streamed into the file.  

For example, say I move my carriage to 100mm to the right while logging, then stop the sample clock, obtain the array from the tdms file, find the size of this array called "X" for future use.  Then, I move the carraige back to the origin WITHOUT starting the clock again.  THEN I start the sample clock again and move 100mm towards the left.  After this is done, I again, stop the sample clock and obtain the data from my tdms file starting the offset of read at "X+1".  I EXPECT that this array SHOULD start at 0 then move on to 100mm to the left.  However, what it does, is I see the data start at 100mm from the right for a few data points, then JUMPS to 0, then moves to the left as expected.

I propose that this means that when I stop the sample clock, the data from the counters (buffer?) have not all been streamed to the tdms file yet, and when I start the clock again, the remaining gets dumped it.  Here, I am confused since I thought that "configure logging.vi" streams directly into the file without a buffer.

 I was wondering if I am doing anything wrong, expecting the wrong things, and if there is a way to implement what I want.  As in, is there a way to flush the remaning data in the "buffer" (i tried the flush tdms vi, but that didn't work and I didn't think it was relevant) after I stop the clock or something like that, or is my implementation competely off. 

Thanks for reading,

Lester

PS.  Having a way to read the most recent point from the counters would be awesome too.  However, everytime I set the offset/relative to most current, it says that I cant do that while logging, even though I saw a community post saying that it works with analog inputs.  Maybe this is off topic, but yeah, currently I'm just trying to get the arrays from tdms working, THANKS!

[lestwest49]

Oops maybe I should also upload my vi of how I set up my counters.  

Basically, the counters are set up hooked up to a sample clock from my RTSI0 port.  Then, to start and stop the data logging, I just start and stop the clock.

Sorry if it is messy, but I tried cleaning it up, but I'm not yet good at planning my wires yet.  

Also, I had to use "interrupts" for data transfer because the board only has one DMA.  I tried using my other board which has 2 DMAs, but I got the same result.

Thanks,

Lester

[WillPwr]

Hello, Lester!

It sounds to me like you'll need to insert a "wait" function into your code. You are right in that when you stop the sample clock, not all the data has been streamed to the TDMS file yet. "Configure logging" will actually still use the hardware FIFO/buffer, so you'll need to "wait" until this data is cleared before trying to open and read.

You've been on the right track so far, and I proper use of timing (the wait function) will take you through the next few steps.

Feel free to let us know as more questions come up!

[lestwest49]

Hi Will,

Thanks for the reply.

Hmm...I am not quite sure what you mean by wait.  Do you mean put a while loop after a stop the clock and just set a 100ms timer in there (I tried that, but it doens't work)?  I know there is a "wait until" vi for DAQmx but if I stop the clock, there is nothing to wait for.  But I will try putting the "wait until" vi in there first to see what would happen.

Thanks!

Lester

[karthik1024]

Before you go through the stop.vi insert a "DAQ Wait Until Done.vi" block which can be found the same place as the other DAQmx blocks. This will ensure that your program waits till all the samples are collected before moving on. Hope that helps.

Karthik

[lestwest49]

Hi Karthik,

However, since it's continuous, even the clock, it will "wait until done" forever?  I think I tried it, but I may have accidently put the wait until AFTER my stop.vi.... 

I will try on Monday.  Thanks guys.

Lester

[lestwest49]

Hi there,

I tried the suggestions, but it didn't work, and I don't think it would work because the counter input is continuous, so basically, the "wait until" VIs will never end.  I don't know if I explained my problem well, but I found a thread that did http://forums.ni.com/t5/Multifunction-DAQ/FIFO-flush-after-DMA/td-p/139141.

Basically, the thread asks if there is a way to let the FIFO know that data collecting for the CONTINUOUS extraction AT THIS POINT IN TIME is done, and then flush the remaining data that is left in the FIFO then allow me to start the data collecting again later on.

I was goign to reply to that thread for an update, but I don't know if it's proper to dig up a 2004 thread.

Thanks for your help guys,

Lester

[lestwest49]

Hi All,

I don't know if bumps are proper etiquitte, but sorry, bump.  Any help would be greatly appreciated.

Thanks,

Lester

[WillPwr · Accepted solution]

Hello, Lester!

There are a few solutions for you here.

First, since you don't need the excess data points, you can set the "DAQmx Read" Property Node to "Overwrite" any data from previous acquisitions. 

To do this, first select a "DAQmx Read Property Node" from the functions palette. The first property should default to "RelativeTo." Click on this, and instead select "OverWrite Mode" (see attached). Next, right-click on the input, create constant, and select "Overwrite Unread Samples" from the drop-down enum. After wiring the other inputs and outputs on the node, This should accomplish what you're looking for. If for some reason it doesn't, consider the following options.

Your second option is to limit the buffer size. If you know how long you want to acquire data for, you can use the sampling rate (it looks like 5000Hz, in your case) to determine the number of samples to acquire. Simply use the "DAQmx Buffer Property Node" and input the number of samples desired. When the required number of samples is acquired, the buffer will begin to overwrite the old samples. This, of course, is not a very flexible method, and obviously requires a pre-set number of data points.

Your final option is to do a brute-force open and close of your task with each acquisition. Simply use the "Clear Task" and "Create Task" functions with every new set of data desire. This should clear the buffer, but will be fairly slow (especially if you eventually change your program to take many sets of data very quickly). 

As mentioned, the "OverWrite" property in the "DAQmx Read" node should take care of this for you, but feel free to try the other options if they better suit your needs.

Let us know if you have any further questions!

Best,

Will H | Applications Engineer | National Instruments

[lestwest49]

Hi Will,

I have used the overwrite property nodes and they do not work for me for some reason, there is still missing data.  The buffer property node would not work in my application because I do not have a pre-set number of samples I want to obtain since I have varying distances I want to reach.  Therefore, even though I wanted to keep the task running, I elected the "Clear Task" method.  All the data is flushed, but then I have to recalibrate after every run.

Thanks for you help,

Lester