Acquiring with DAQmx within a subVI

[lorc34]

Hi,

I am a bit confused as how to use DAQmx

Lets say I have a rate of 1000 Hz, and I want 1000 samples. This will take 1 second to complete (the while loop iteration / code will take 1 second)

If I use 10 Hz and 1 sample, I will get 10 samples a second, with the loop taking 0.1 seconds to execute

However, this is when I have DAQmx clock outside the while loop and DAQmx read inside. 

If i make a subVI with the code all together, it will operate much faster than 0.1 seconds. Lets say 0.01 or 0.001.

As such, I have had to put a 100 ms wait timer in my loop in the main VI, and this makes it only access the DAQ data every 0.1 seconds.

But I am guessing this is not very efficient? Whats the best way for me to get 10 data points per second (I dont want 1000s per second written to the CSV file) with DAQmx?

I have uploaded the files in a zip file for Labview 2010

"ProducerConsumerMagnetometer.vi" is the main VI. This has 'acquire channel data' which acquires data. This subVI is in the mainVI in a while loop. Inside 'acquire channel data' is another subVI which takes the waveforms, and takes the waveform component out of them. There are also subVIs to interact with the analog output, digital input/output and timechecking

[ZYOng]

---

@lorc34 wrote:

If I use 10 Hz and 1 sample, I will get 10 samples a second, with the loop taking 0.1 seconds to execute

---

Since you stop and clear the task after calling DAQmx Read VI once for 1 sample, you only get 1 sample. That's why it only took 0.1 sec to execute.

I'm seeing you using the flow of Create + Read/Write + Clear/Stop in multiple places. This is very inefficient. I would recommend you to modify your code such as Create, Configuration and Start stay before the while loop, Read/Write in the while loop and the Stop/Clear after the while loop.

And since you are not streaming a lot of data but using the data for output, you not need a producer/consumer pattern. A simple state machine will do. If you want to use multiple loops, you can use local variables since the latest data is what you need.

[lorc34]

OK I will try implement what you said.

I will have to modify the code because I use a while loop for the timer, and this locks into the while loop, only exiting after 30 seconds or if the button is pushed. If i put this in the same state machine as the data acquisition, plotting, logging, it won't acquire, plot or log while its locked into the timer while loop. Thats why I used producer / consumer with a different loop for locking into the timer. But i am sure theres a way to do it

[Yamaeda]

---

@lorc34 wrote:

OK I will try implement what you said.

I will have to modify the code because I use a while loop for the timer, and this locks into the while loop, only exiting after 30 seconds or if the button is pushed. If i put this in the same state machine as the data acquisition, plotting, logging, it won't acquire, plot or log while its locked into the timer while loop. Thats why I used producer / consumer with a different loop for locking into the timer. But i am sure theres a way to do it

---

At those slow speeds you can easily plot and log as you get your measurements.

[lorc34]

The hard part is getting the timer to work in the same while loop as the acquisition, plot and logging

[Bob_Schor]

Sorry I took so long to look at your code.  You are correct -- you do not understand DAQmx!  There are resources on the Web that will help, but let me try to get you started.

I'm going to concentrate on two things -- timing, and handling the resulting data.

On a PC running Windows (and LabVIEW), the best clock for timing things is the hardware clocks built into NI DAQ hardware!  If you want to sample at 10 Hz, and want to handle every sample one-at-a-time (and think you can accomplish all you need to do in the 100 ms available to you before you need to worry about the next sample), all you do is put the DAQmx Read inside a While Loop, take the output, and do whatever you want to do with it in the 0.9992 (I'm guessing here) "free time" before the DAQmx Read needs to be ready to read the next sample.

[Hmm -- I just combined Timing and Handling the Data in a single paragraph!]

Some other things to consider:

• If you want one sample from your DAQmx Read, don't specify N samples and put "1" in Number of Samples, rather select "! Sample".
• Run the Error Line through all your sub-VIs!
• If you have several identical "data wires" (like one per A/D channel), bundle them into an Array or into a Cluster as a single "wire" rather than passing 4 wires into a sub-VI, which "crowds out" the much-more needed Error In/Error Out lines.
• (Almost Always) Use the 4-2-2-4 Connector Pane (with the lower corners reserved for Error In/Out).
• Instead of having 4 Charts, one per Channel, use one Chart and plot 4 Channels.  If you don't want them overlapping, you can do such things as add 3 to Channel 0 data, 2 to Channel 1, 1 to Channel 2, and 0 to Channel 3 to have them offset by one on the same Chart.  LabVIEW will give the plots different colors to distinguish them.
• Make a small program that just does the simple DAQmx stuff first.  Once you have data coming in and being plotted, you can worry about saving it, making decisions on it, etc.
• If you want to test writing a 4-channel Chart without needing DAQmx, generate an array of 4 random numbers to pass out to the Chart.

Bob Schor

[lorc34]

Hi Bob,

• If you want one sample from your DAQmx Read, don't specify N samples and put "1" in Number of Samples, rather select "! Sample". Done (typo here "1 Sample" I believe)
• Run the Error Line through all your sub-VIs! Done 
• If you have several identical "data wires" (like one per A/D channel), bundle them into an Array or into a Cluster as a single "wire" rather than passing 4 wires into a sub-VI, which "crowds out" the much-more needed Error In/Error Out lines. Done
• (Almost Always) Use the 4-2-2-4 Connector Pane (with the lower corners reserved for Error In/Out). Done (kind of) 
• Instead of having 4 Charts, one per Channel, use one Chart and plot 4 Channels.  If you don't want them overlapping, you can do such things as add 3 to Channel 0 data, 2 to Channel 1, 1 to Channel 2, and 0 to Channel 3 to have them offset by one on the same Chart.  LabVIEW will give the plots different colors to distinguish them. Done I will need to look further at this. My data ranges from -500 to 500 on each channel. So i need to add 1000 to each to offset them. But then the data ranges from -500 to 3500, so when the 4th channel is maxed out (i.e. its reading 500 uT) it will say 3500.

The latest VI I have is attached and including subVIs. I changed it from 'producer consumer' to just a simple state machine. ZyORG told me to do this. But I am not using local variables like they said but instead using shift registers.

Hopefully the program is well written now. It seems to satisfy all requirements and has a few upgrades, like if the level is re-exceeded while in alarm state, it will extend the alarm, while previously it wouldn't have.

The error handling may not be done properly though, not sure. I dont really know how needed it is because ideally the program will never stop / have an error but i know its useful for data flow