DAQ write+read analog channels

[Nicku]

Hi,

I need some urgent help to solve a simple problem:

My job is to write an analog channel to a DAQ device and then to read two analog channels from the same device.

These should be done at the 5 KHz rate.

For smaller rates I can do it using normal loops (or timed loops). But I don't know how to do it using DAQ features.

Please give me an example.

I have found something but I am not sure if it can be used in this way (see the attachment)

Thank you!

[Mcdan]

Nicku,

What hardware are you using and what platform will you be running your application on?  How hard are your timing requirements?  The reason I ask is that I think it is unlikely you'll be able to sustain a 5 kHz rate for long period of time on a non real time OS.

DAQmx does have a feature known as Hardware Timed Single Point which is appropriate for this use case (note, this feature is not supported on USB devices as this bus is high latency enough that the feature does not make much sense).  Hardware timed single point uses hardware timing, and provides an error or warning if the loop does not iterate fast enough to keep up with the hardware clock. I would recommend that you look at the shipping example PID Control-Single Channel.vi.  On my machine with LabVIEW 2011, the example is located at C:\Program Files\National Instruments\LabVIEW 2011\examples\DAQmx\Control\Control.llb\PID Control-Single Channel.vi.

Hope that helps,

Dan

[Nicku]

Thank you Dan,

The device used is NI_USB 6211 and the tests will be done by another person.

So from your email I understood that is not recommended to use Hardware Timed Single Point.

And just for my information: in your example what happened if I will try to read two adjacent analog channels (that means analog->multiple channels->single measurement)? It is possible? I'm asking because then we have a multiple point...Right?

Do you think this USB device will work at 5 KHz rate?

Anyway it seems it must be used sometime even at 10 KHz.

So I still waiting for a guaranteed solution!

[JÞB]

nicklu-

I actually do not see much wrong with the vi you posted.  for these slow sample rates (5-10 KHz) the usb will be happy to chug right along.  Moreover you are not doing any intesive processing of the signals like logging to a file or intense calulations so you should be good to go.  If you do need to do intensive operations on the data you would add a queue and pass the data out of the loop to a consumer loop that would do the heavy lifting.

The only improvement for this simple vi would be to replace the "Start Task"s with "Control Task"s like so:

Its a rather minor improvement and should be unnoticable at thes rates but if you want to learn "Why" to do this have a look in the DAQmx help file "Task State Model." with Autostart =true the task transitions to the state it started from- much less overhead if the task is in the comitted state.

[Mcdan]

Nicku,

You are correct, the example I referenced will not work with the USB-6211, as Hardware Timed Single Point is not supported on this device.  If you had a device that did support this functionality, and you needed to read more than one channel, you would need to use a different version of DAQmx Read (Analog 1D DBL NChan 1Samp).  This would still be considered single point, as you are still only reading a single sample.  However, running on a non-real time OS I don't think that you'd ever be able to sustain rates from 5 kHz - 10 kHz dependably.

I do not believe that you will be able to achieve a loop rate of 5 kHz with the USB-6221.  USB is a fairly high latency bus, and since you're doing single point operations you will suffer this latency every time you attempt to read data from the device.  USB and Windows is really not a good choice for control type applications that need to guarantee timing.

Dan

P.S. Jeff's suggestion to explicitly commit the task is definitely a good one

[Mcdan]

Quick correction to my last post... I did not notice that your original VI called DAQmx Start.  In this case I think it is preferred to call start before your loop rather than calling commit, since start will put the tasks in running state outside of the while loop.  In Jeff's proposed change, the tasks would need to transition from committed to running and then back to committed each iteration of the loop.  As originally written, the tasks will be in the running state before the while loop and remain there until they are cleared.

Dan

[JÞB]

---

@Mcdan wrote:

Quick correction to my last post... I did not notice that your original VI called DAQmx Start.  In this case I think it is preferred to call start before your loop rather than calling commit, since start will put the tasks in running state outside of the while loop.  In Jeff's proposed change, the tasks would need to transition from committed to running and then back to committed each iteration of the loop.  As originally written, the tasks will be in the running state before the while loop and remain there until they are cleared.

Dan

---

Dan- You missed the Autostart(T)-  and, ALL tasks go from committed to run and back to committed,( unless abnormally terminated by a explicit abort while running starting from a state other than committed,) the commit state is the least overhead for any task that is not continuous or regenerating.  The original post started the task from Verify state- and required DAQmx to reserve and commit the DAQ resources for each read or write and then (since it Started from verify) implictilly uncommit and un reserve the resouce after "running" in each loop iteration.  Sean N "Popped-the-hood" and gave difinitive advice on the DAQmx task state handeler in this post (warning ----wrap head with duct tape before reading) 

Sorry to derail the thread but, accuracy counts too.  I can't let a user stay stuck behind an "8-ball" with misconceptions (nice avatar by the way)

[Mcdan]

Jeff,

I agree that accuracy counts, and I think these are good discussions because they really can make the difference in someone's experience with DAQmx.  For the case of hardware timed finite tasks, committed is essentially the least overhead state that a task can sit in, as it must be stopped and restarted to read/generate more than one record worth of data.  However, the VI posted is not using hardware timing.  As such these tasks are treated as continuous tasks, and once explicitly started do not need to transition back after read/write is complete (auto-start has no effect on a task that was explicitly started).  This likely saves a few USB transactions each loop iteration for the OP's device.  My rule of thumb is that you should always explicitly advance DAQmx's state machine as far as possible for a given task.

Just to make sure I was telling the truth, I took the OP's VI, replaced the timed loop with a for loop and did a benchmark using my USB-6351 (VI attached).  I ran 1000 iterations of the loop with each configuration (explicit start vs explicit commit).  With explicit commit, I get a run time around 10 seconds.  With explicit start this drops to around 3 seconds.

I hope that information is useful,

Dan

[JÞB]

Dan- MEGA Kudos!  (Maybe a KB article in that gem of knowledge)

Glad to be corrected

[Nicku]

Thank you all,

I still have a problem before checking my test program: The Create timing Source (Frequency).vi generates an error (see attachment).

So I have created a small program for the counter frequency generation test (see attachment) but I got the same error.

What is wrong here?