03-17-2011 10:54 AM
I am building a basic data acquisition system that collects various sensor voltages and thermocouple temperatures and displays them on a running waveform chart. I am using a third party DAQ not the DAQmx. The system only needs to collect every 10 seconds or so. I am wondering what is the best practice is for storing the data - should the raw voltages be stored along with scaling information or should the final scaled engineering units be stored? i.e. flow, pressure, vacuum. Perhaps both? I have seen the producer-consumer design pattern but that seems overkill. An example for a simple data acquisition/storage/display would be great.
Thanks
03-17-2011 11:14 AM
Hey,
Since your acquisition is not that fast, the way you store the data should depend on how you want to analyze it afterwords.
E.g. when using NI DIAdem use TDM or TDMS along with the Write Measurement File.vi. When you use Excel or any other Data Management Software you might use tab-deliminated ASCII files. In LabVIEW you can use the high level Write Spreadsheet File.vi for that.
Using the Example Finder with "File I/O" you will find numerous examples for both.
Christian
03-17-2011 11:17 AM
Hi Tim,
you seem to be having 3 different loops.
- Daq loop
- File I/O loop
- UI loop
if you really sample that slow, then there is no issue with using just one loop, allthough it's not "proper" programming.
If you really want to keep it simple, just use a state engine. A good start would be the one in attachemennt
03-17-2011 12:44 PM
Christian_M: Thanks for the info on TDMS vs text. My question is not so much the file format but what to store in the file. The DAQ data come in as a raw voltage. The data is then scaled into engineering units and the engineering units are displayed in on the front panel. When recording the information to file (regardless of the format - binary, text, csv, etc) should the voltage/DAQ data should be stored or the scaled values such as PSI, temperature, LPM etc.
Thanks!
03-17-2011 01:20 PM
I'd store the final scaled engineering units. That way anyone else has the data in it's final form without have to scale them.
-AK2DM
03-18-2011 04:29 AM
Hey,
It still the same, the way you store it should depend on the way you want to analyze it. If you don't need the raw values afterwords, take the scaled ones.
If you want to have offset and LSB or whatever in your calculations/reports, you have to save it.
Neither is good or bad, it just depends on the information you will need later on.
Christian
03-18-2011 04:57 AM
Looks like there is a confusion that whether you really like to store the data or not?
1. To whom are you developing this application.?
If for a customer then you can straight away ask him what is his requirement. Whether some other external software or tool is going to use this data. Or is the customer is planning to share this data with others?
2. If its for your internal usage, then you can best decide based on the usability what needs to be stored..
03-23-2011 09:00 AM
All: I am currently storing the data as engineering units but was considering storing the raw DAQ data, DAQ configuration etc. and wanted opinions. Thanks! I am writing to a tab delimited file with the array-to-spreadsheet-string and write-to-file instruction. The file is pulled into Excel and various calculations and charts are created. The end users are internal engineers and researchers.
ABCPrograms: Thanks for the sample.
All: ABCPrograms makes reference to "proper programming" What IS proper programming in LabVIEW? I have written software in various languages and have made use of events for GUI, error handling, communications etc etc. In my case, I have the Base development system, which means no events. Obviously the answer is loops but the whole data-flow model and restriction to loops has stalled me a bit. I have searched NI site for various examples, design patterns etc. What I have found are solutions to specific problems but no "complete" example/skeleton. ie. Multiple loops, but not how do pass data "between loops", deal with user front panel events, error handling and error logging. Can anyone point me to an example for a simple data acquisition/storage/display that has error trapping and error logging? How does one raise and catch error events from all these loops without events or a central error handler? How does one gracefully exit all these loops without error events? An example for a simple data acquisition/storage/display with error handling and error logging would be great.
Thanks again!
03-26-2011 12:28 AM
Hi TimTech.
I believe the following linked document may answer some of your questions regarding proper style/technique for LabVIEW programming.
LabVIEW Development Guidelines: LabVIEW Style Guide (Chapter 6)
http://www.ni.com/pdf/manuals/321393d.pdf#labview_style_guide
Regards,
Michael G
03-29-2011 11:20 AM
Thanks for the pointer to the style section.