DAQ Assistant with multiple Channels: Set Time of Charts to 0 and use serveral Windows / Front Panels

[Challenge19]

Hello everyone, 

I am a newcomer in programming and I'm searching for assistance in some issues which I cannot solve on my own. These problems are about having one DAQ Assistant with different channels which should be treated independently in a way that the measurements can be started and stopped independently and also having the buttons and graphs in different windows.

The Task:

Using an A/D-Converter for different Manometers, I want to work with the Channels of one DAQ Assistant independently. For two of the Manometers there was a program, where pneumatic valves automatically open and close at certain pressures (this should not bother you). The data (time and pressures) is saved to a file and shown in two charts. The third Manometer just measures another pressure and this data is also saved.

The Problem:

Now I want to combine these two programs and to do so I thought about putting a while loop around the DAQ Assistant which is constantly running. Then, if one of the Start-Buttons is pressed, an experiment should run. Thats why the button is switched when pressed and I put a case-structure around the concerning parts of the program. However, I do not know how I can control the measured time correctly. When I use absolute time (which I would not like to do) at least the chart shows all of the data points. Still, if I now stop the experiment and start it again, the same file is written to and there are no data points while the start button was not active. If there was just one experiment, I would put the "Get Time/Date in seconds" outside of the loop and subtract it like shown in the image.

Does someone maybe know how I can fix this problem? (multiple windows maybe discussed later)

Thanks a lot for your help!

[Bob_Schor]

You've just joined the LabVIEW Forums, probably haven't stumbled upon the Unofficial Rules for the Forum, and probably haven't read enough posts to know how unhelpful it is when you post a picture (static, non-executable) of part of your VI.  My personal preference is to ask for an attached VI (warts and all), or if part of a LabVIEW Project (which I'm guessing you haven't learned about), a compressed ("zipped") version of the Project Folder.  So there are multiple "irrelevant" things to tell you to improve (a lot!) your code, but that's not your question.

The Dreaded DAQ Assistant (DDA) is (in my opinion) a "crutch" to convince those getting started with LabVIEW the idea that LabVIEW is "easy", "takes no time and effort to learn", and "can get you collecting data with no effort".  Well, not exactly ...  If you want just to "acquire and display", or "acquire and save", or "acquire and do simple analysis", Express VIs (of which the DAQ Assistant is an example) are the "way to go if you don't want to learn LabVIEW".  Otherwise, you need to spend a little effort and learn the basics of LabVIEW, the things you can find on the first page of this Forum under LabVIEW Training Resources.

Google is also your friend.  Try typing "Learn 10 Functions in NI-DAQmx and Solve 80 Percent of Your Data Acquisition Applications" -- it mentions the DDA, but then quickly shows you how to use MAX, Tasks, and the DAQmx Functions (and you only really usually need 4-5 of them) to do what you need.

In particular, independent control of independent DAQ Channels require independent loops.  LabVIEW, by design, is very good at handling independent loops -- it uses a Data Flow model of programming, where the Data (and its "Flow") control how the Program runs.

While you are "learning", I'd recommend trying to create multiple programs to control individual Manometers.  You might be able to combine the two channels involving pneumatic valves, but you'd need to learn how to integrate Valve handling, so starting off with independent, one-task routines and later combining them is probably a safer and easier way to get started.  And do try to banish the DDA and its Evil Twin, the Dynamic Data Wire (use Waveforms, or simple Arrays of Dbls, instead).

Bob Schor