Data Acquisition with DAQmx

[olber]

Hi all,

I am trying to make a VI that gives a continuous readout of two NI DAQ channels, with the option of saving to data file. The VI should also be able to generate two sine signals (one for each channel) of a certain amplitude, frequency and duration. Currently I have found no other possibility to realise this than making two separate while loops.

The problem is, there seem to be gaps in the readout. In one loop iteration 500 samples are read and displayed, the plot updates every 0.5 seconds. At the start of every iteration there seems to be missing some part of the signal (c. f. front_panel_master.png), only half of every cycle seems to be displayed and saved in the measurement file. This doesn't happen if I change the waveform chart to only update every 1 s (parameter in MT_read sub VI).

The two DAQ cards in question (one for reading, the other for writing) are NI 9222 (cDAQ1Mod3, reading) and NI 9263 (cDAQ1Mod4, writing).

[cbutcher]

Some thoughts that might help you

• If you're running on Windows (cDAQ, not cRIO) then timed loops probably don't do anything. Just use While loops (more on this lower down)
• Your Write loop has an Event Structure, so it will only write when you trigger the event (Start Signal Gen).
  • You then have a fixed number of samples in Signal_Gen, and a For loop to check if the task is done, "Duration" times.
  • If you switch to a Finite Samples generation, you won't need to check so much. You could place the Is Task Done in a While loop with a 10 or 100ms wait, and avoid needing a Duration value for that subVI
  • Stop will never stop the generation (from the caller)
• Each loop you're reading 0.5s worth of data, but the timed loop holds you to 1s per iteration (hence missing bits, since the write is running continuously). As mentioned above, the Timed Loops don't typically help much here - if you relied on the Read to set the rate of the loop, your loop would "automatically" keep the right time.

[Kevin_Price]

---

Each loop you're reading 0.5s worth of data, but the timed loop holds you to 1s per iteration

---

I just wanted to add emphasis to this remark from cbutcher.   The general topic of overconstrained loop timing when running DAQmx tasks has been a recurring theme I've been working to point out both fairly recently, and much longer ago (as well as several points in between).

It's a key concept to absorb, and once you do, you'll be a much better position to think about the relationship (and the distinction!) between your DAQ tasks and the timing needs of your *application*.

If you want to regulate the timing of a loop in your application, choose exactly 1 method for doing it.  Let it be either timing regulated within the app ("Wait" function in a regular loop, possibly an official Timed Loop) OR timing determined by reading fixed packet sizes from a hw-timed DAQmx task.   But not both at once.  That's an overconstraint that almost always leads to problems.

-Kevin P

[Bob_Schor · Accepted solution]

NI has some excellent tutorials on DAQmx available by searching on the Web.  My favorite (which showed me how DAQmx is designed to work) has a title similar to "Learn 10 Functions in NI-DAQmx and Handle 80 Percent of your Data Acquisition Applications".

A key concept that Kevin mentioned is the following:  suppose you set up a DAQmx Task to take 1000 samples at 1 kHz, and you set it to run continuously (this last point is important).  Suppose you put it in a While Loop with nothing else in the Loop (except a Stop button).  How fast will it run?  Exactly once/second, right?  Now, take another loop and put nothing inside it except a Wait (ms) function with 1000 wired to it (or, alternatively, a Timed Loop on a Windows platform).  How fast will it run?  Well, if your antivirus kicks in, or other things happen, it might not run once/second.

When in doubt, use the DAQ clocks, they are designed to be precise and accurate, and nothing interrupts them.

Bob Schor