Analog Input Voltage Lag

[Cory_K]

I have a VI that should be reading in and displaying:

- 2 LVDTs (analog voltage)

- 1 load cell (analog voltage)

All three instruments are in a NI 9205 module, which is in a cDAQ-9178.

I have set up all three instruments as a single task, which each channel should complete one reading on demand.

This works fine when I run it in MAX. I get reasonable values at a very high acquisition rate without any noticeable delay.

In my VI, all I try to do is get 2 samples per second (500 ms delay) and graph all three of the instruments.

However, I am getting a very severe lag. When I start the program, I don't see my first point until about 30 seconds after I start it. 
Then each subsiquent point takes another 30 seconds or so. I am not doing anything with very large amounts of data, or anything with very high acquistion rates, so I don't know why this lag is occurring. Any thoughts?

[RavensFan]

You have a yellow exclamation point on the daq device in MAX.  What is causing that?  If you run the task within MAX, how long does it take to return the point?

[RVallieu]

Why are you not performing the scaling within the task?

Why are you trying to read a single point on demand and not using a buffered continuously running task and reading multiple samples, while letting the hardware handle the acquisition timing (removing the need for a wait function)?

Think about moving to a producer consumer/data driven architecture, continunous acquisition, with buffered read.  You are also always building array and redrawing the plot on each iteration - building arrays over a long period will slow things down and involve the memory manager.

[Cory_K]

The warning was because I am using an XP computer apparently. Just downloaded the hotfix they recommended.

When I check the channel using Test Panel, I get very fast responses without any noticeable delay, like on the order of 1000 Hz.

I see this very fast response rate when I run the whole task in MAX as well, so it has to be something in my VI I think.

[Cory_K]

---

@RVallieu wrote:

Why are you not performing the scaling within the task?

Why are you trying to read a single point on demand and not using a buffered continuously running task and reading multiple samples, while letting the hardware handle the acquisition timing (removing the need for a wait function)?

Think about moving to a producer consumer/data driven architecture, continunous acquisition, with buffered read.  You are also always building array and redrawing the plot on each iteration - building arrays over a long period will slow things down and involve the memory manager.

---

Perhaps I don't understand the continuous acquisition entirely, but if I set it to read 100 samples at 1 kHz, but I only want data at 2 Hz, isn't that just using up memory and resources unneccesarily? That is why I just had it read one point on demand. I don't have a strong grasp on what is occurring within the hardware, so that was just my intuition. I can certainly switch to a producer/consumer archictecture if that will take care of the issue.

[JÞB]

Try adding "Control Task" with a "Commit" before the loop to avoid the DAQmx state transition penaty of needing to re-verify re-reserve and re-commit (and back to unreserved) in each loop itteration.  Add an "Unreserve" after the loop too to release the resources.

Sean pop-ed the hood on the DAQmx state transitions in this post that was quite an eye opener for me.  In your case (three different modules in a cDAQ) thats a lot of resources to transition though all of those states and back evey half second.  (Although, I would expect a much shorter lag than you report)