Time values in logged thermocouple data not realistic

[MKTribble]

I'm in desperate need of LabVIEW programming help!  When the run arrow is clicked, my VI is designed to simultaneously start logging filtered thermocouple data and send a TTL-type pulse out of a CTR port on my ELVIS II+.  The pulse part of my code works fine (it's from an example VI), but the thermocouple part has a big issue.  The temperature data logs correctly, but the times associated with each data point are completely wrong.  I measured the time I ran my code the most recent time--it was about 20 seconds.  The logged data shows what appear to be the correct number of data points, but the last time value is only 2.88 seconds.  I have a feeling the filter might be part of the issue, but I don't know how to fix it.  I would be so completely grateful for any help anyone can provide!  My VI and LVM output files are attached.

Megan

[johnsold]

It looks like you have configured your system to sample continuously at 200 Hz and then you are reading one sample at a time. You convert the voltage reading to temperature, apply a filter (to one point!), and write to a file. Then you read the next point. This will be the data acquired (converted) 5 ms after the first point, regardless of how long it took the loop to get back ot this operation. (It was stored in a buffer by DAQmx). So it might well have taken 20 seconds but you only processed the data which occurred in the first 2.9 seconds.  The file records the timestamps from the acquisition, not the time of the file write.

So, you need to decide what you want to do. Do you want to take one data point every 5 ms, do you want to take ~28 readings per second (which is about how long your processing apparently takes), or do you want to get data at some other rate?  How often do you need to update the displays? Your users probably cannot see either 200 or 28 updates per second. How often do you need to write to the file? Note that it is not necessary for the display updates or the file writes to occur at the same rate as the data acquisition.

After you decide what you want to do, someone can recommend an alternative program architecture to do waht you want.

Lynn

[MKTribble]

Hi Lynn, thanks for your response.

I want my program to sample temperature readings at a user-defined frequency (not extremely fast--every 5 seconds at the very slowest) and not be unstable when the temperature changes.  Without the filter, the readings jump to exponentially high and low values whenever I touch the TC to test its response--I want to avoid that. The program should output the values in a measurement file in time versus temperature.  It's also nice to have the visual output on the graph showing how the temperature is changing with respect to time, so I'd like to keep that.

I'm not sure if I answered your question the way you wanted--please let me know if you have any questions.

Thanks for your help!

[johnsold]

It sounds as though you may have two separate problems. One is the timing of readings and file updates and the other is what you are calling "unstable" readings.

Please provide some numerical values for the "unstable" readings. What do you mean by "exponentially high or low values?"  Obviously you expect the values to change when you touch the thermocouple. If the readings are way out of range (much different from your finger temperature), the problem is likely in hardware and should be corrected there, if possible, rather than trying to "filter it out" later. Filters tend to not be good ways to handle impulse-like interference. The transient response of the filter is excited by the impulse and you have to wait for it to die out. 

Please post some data which shows one or more fo the instabilities, along with your estimate of wht the actual temperatures should have been.

There are many ways to address the timing issues. First, define both the slowest and the fastest frequencies from which you will alow the user to select for temperature readings. You indicated that one reading every 5 seconds is the slowest. What is the fastest? How many options wil the user have between those limits? What else does the system do besides the temperature measurements? Will the user change the rate while the program is running or only before starting the acquisition?

Lyn