simple timed analog data acquisition

[sweenski]

I am a first time LabVIEW user and am trying to learn as I go along. I need to write a data aquisition program that will read 2 analog channels simultaneously at a user inputted interval and write that data to a file preferrably with some sort of timestamp. I need it to run continuously until stopped by the user. I've managed to write a small program that will acquire the necessary data and write it to a file one time without the timestamp. Any attempts I have made to make it loop or run continuously have resulted in memory overflows and other errors. I have attached the part that I have that works (minus a timestamp). The far right hand part of the block diagram is what I have been attempting to loop. Any comments or suggestions are welcome. I would really like to keep the program as simple as possible but I fear I am making things more difficult than they need to be.

Download File:post-5626-1154964905.vi

[mross]

I am a first time LabVIEW user and am trying to learn as I go along. I need to write a data aquisition program that will read 2 analog channels simultaneously at a user inputted interval and write that data to a file preferrably with some sort of timestamp. I need it to run continuously until stopped by the user. I've managed to write a small program that will acquire the necessary data and write it to a file one time without the timestamp. Any attempts I have made to make it loop or run continuously have resulted in memory overflows and other errors. I have attached the part that I have that works (minus a timestamp). The far right hand part of the block diagram is what I have been attempting to loop. Any comments or suggestions are welcome. I would really like to keep the program as simple as possible but I fear I am making things more difficult than they need to be.

I am sort of behind the times and don't mess with the express vi's so I may be offering archaic advise...

There are two kinds of "canned" acquisition vi's that are shipped with LV. Continuous and buffered acquisitions. The continuous (which in theory could run for an infinite time interval) acquisitions are primarily used for visual display to an operator. The buffered acquisitions (operate for a finite time interval and produce an amount of data limited by the number of scans to be read) are more for data collection and analysis.

You can access the "history" of a chart in a continous acquisition vi to get at the data acquired after the fact for storage or analysis. This is headed in the direction of what say you want to do. You should look into this. However, I never do this myself.

All my acquisitions are done with storage and analysis in mind and I know exactly how to limit the of data I wish to acquire - I know the scan rate and number of scans. These are user settable before the acquisition is run, and you don't stop the aquisition in the middle. You wouldn't want to run a really long buffered acquisition and interuppt it before it is completed.

My first question is, what do you gain by allowing the rough control of having the operator turn the acquisition on and off? If you can limit the acquisition size ahead of time, even if it is to some ridiculously large amount of data, then buffered acquisitions may be simpler to deal with. You let the vi do its buffered thing and look at a graph of the data after it has finished. In my work I mostly want to compare like data sets. By having them all the same length and time scale it is very simple top make visual and numerical comparisons - after the fact not on the fly as more data is taken

If you have no need for comparing data sets after acquisition then the continuous approach is indeed useful. I find that many people start using the continuous acquisitions becasue they are the cool demos that are first seen, but in reality they want finite chunks of data that need further massaging to be useful, bufferd is better in this situation.

For "real" work, the not very real time "continuous" display of data on the screen is just a comfort and it is not very useful. Taking data for a prescribed period of time, at a particular rate, and finally post processing the information is more useful.

Can you tell me why exactly you want on the fly determination of the data record length rather than setting up a finite test period?

Can you say something about why you are acquiring the data, from what signal sources, and what decisions you need to make based on that record?

These answers can help me/us provide more useful advise for you in the long run. Your query is very general and the software provides so many ways to gather and process data...

Mike

[sweenski]

This program will be used to determine the oxidation rate of a metallic sample at elevated temperatures in terms of weight change per unit of time. The program receives 2 channels of analog input. The first channel is a mass from a Cahn microbalance in terms of millivolts. The second channel is a voltage also in millivolts from a K type thermocouple that can be converted to a temperature in degrees C. The temperature is mostly recorded to make sure it remains constant for the whole duration of the test. The idea behind the user imputed time interval is that if the rate of oxidation is in terms of minutes as opposed to hours, then sampling every 5 seconds would be helpful. If the test duration was 12 hours then the sampling could be done every few minutes or so. This is not entirely necessary, I am at liberty to set the time duration for each test so I could run all tests the same. For example, all durations could 12 hours with a sampling rate of 30 seconds. At this point, I don

[mross]

This program will be used to determine the oxidation rate of a metallic sample at elevated temperatures in terms of weight change per unit of time. The program receives 2 channels of analog input. The first channel is a mass from a Cahn microbalance in terms of millivolts. The second channel is a voltage also in millivolts from a K type thermocouple that can be converted to a temperature in degrees C. The temperature is mostly recorded to make sure it remains constant for the whole duration of the test. The idea behind the user imputed time interval is that if the rate of oxidation is in terms of minutes as opposed to hours, then sampling every 5 seconds would be helpful. If the test duration was 12 hours then the sampling could be done every few minutes or so. This is not entirely necessary, I am at liberty to set the time duration for each test so I could run all tests the same. For example, all durations could 12 hours with a sampling rate of 30 seconds. At this point, I don