Producer-Consumer, TDMS Log on Button

[skinnert]

The program I've enclosed does what I need it to do quite well for the most part. I'm asking this question because I'm getting more data than I want and it's inconvenient to work with. 

In short, I have a sytem setup to record pressure data from an explosion in a very short time period, the entire event is over in less than 100 ms, it typically occurs between 1 and 2 seconds after the ignition signal goes out. Therefore I want to record about 2 seconds of data total. The system has to run in a monitor mode for several minutes before any ignition while I fiddle with various elements associated with the experiment. It DOES NOT record during the monitoring phase but it must be running so I can fiddle with the experiment. 

I think have two small issues that are increasing the size of my TDMS file.

1. When I hit the big red "STOP" button the system continues to record data for several seconds. I think it has something to do with the queue not being empty. It appears to be stopping at the correct relative time, but the data hasn't been streamed to disk yet. I can live with this but I suspect it's indicative of a bigger problem.
2. When I hit "Record" I have a 5s delay built in to engage a FLIR camera which has a variable startup delay (red circle in picture, record button not shown). This shouldn't get recorded because a "true" signal doesn't go to the record case (blue circle) until after the 5s has elapsed.

Example dataset below. To generate this data I started the VI and let it run for 30 seconds (I didn't have to let it run but that is more like a "real" test), after roughly 30 seconds I hit record and it started the 5 second countdown to ignition, I observed the ignition signal and waited to hit "stop" at roughly the 1 second mark on the count up. The VI continued to run until the timer read 8.32 seconds. The signals I recorded are just the TTL pulses that would normally go to my cameras, everything else is unplugged. Awyay, it looks like the system stopped acquirig data when I hit stop but the fact that it kept running tells me my queue didn't empty. 

In the sample data the white line is the FLIR TTL signal. It lasts about 1 second (recording at 100 kHz), it should be a 1 second square pulse (or 100000 points), looks like the front got cut off. Sometimes it gets the whole pulse, sometimes it completely misses it. I think it has something to do with when I hit record relative to what is happening with the buffer. 

The blue square wave that starts at 5 seconds is the 1/2 second TTL pulse that goes out to the high speed cameras and ignites the explosion. This is actually where the recording should start, where 0 seconds should be. I'm not certain why I'm getting the precursor data. In other words, all the data to the left of 500000 (5s) should not be recorded. The data ends just shy of 1/2 second (~50k points) after the blue pulse ends. This is right around the 1 second mark I tried to hit when I generated this data.

What is the result? Well, I'm recording 10 channels at 100 kHz so I end up with a 50 mb file instead of a 10 MB file and an extra 500k points that I have to strip off. This is tedious and time consuming, it really adds up considering I'll be doing this testing hundreds or thousands of times.

My questons. How do I delay recording until after that first delay is up? What am I missing? Is there some sort of a "TDMS clear queue"command?

Thanks for your time!

[mfitzsimons]

Skinnert,

Your program has many deficiencies that will make it very difficult to get your program to execute correctly.  The architecture is linear and hard to follow its flow.  Adding to the issues is the lack of wire labels and comments.

The program is flawed from the first step.  You open 10 analog channels of DAQ but you are only saving a reference to the last channel opened.  It may be working by some magic of LabVIEW but not recommended.

I would like to help out but there is just too much to take in to get a good answer.  The goal of the forums to help people out.  In your case you need to simplify the code and the question you post on the forums down to a paragraph or at most two.  There is just too much for me to provide an answer.  Ask a better question and you will get a better answer.

Good luck!

[mfitzsimons]

Skinnert,

Your program has many deficiencies that will make it very difficult to get your program to execute correctly.  The architecture is linear and hard to follow its flow.  Adding to the issues is the lack of wire labels and comments.

The program is flawed from the first step.  You open 10 analog channels of DAQ but you are only saving a reference to the last channel opened.  It may be working by some magic of LabVIEW but not recommended.

I would like to help out but there is just too much to take in to get a good answer.  The goal of the forums to help people out.  In your case you need to simplify the code and the question you post on the forums down to a paragraph or at most two.  There is just too much for me to provide an answer.  Ask a better question and you will get a better answer.

Good luck!

[skinnert]

Alright, I'll work on that. I appreciate you looking at the code. 

Not sure what you mean by the "only saving the reference to the last channel open." Can you expand on that a little?

It may be working because that portion of the code came out of the DAQ Assistant. Using the DAQ assistant put an artificial limit on my acquisition speed, when I converted the DAQ assistant and moved that portion outside the while loop my code ran a lot smoother. Perhaps it's something that's stuck way down in there?

Thanks again!