LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Analog Input Voltage Lag

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.

 

MAX.PNG

 

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.

Block Diagram.PNG

 

Front Panel.PNG

 

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?

Cory K
0 Kudos
Message 1 of 6
(3,018 Views)

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?

0 Kudos
Message 2 of 6
(3,012 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 3 of 6
(3,007 Views)

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

 

Warning.PNG

 

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

 

Test Panel.PNG

 

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
0 Kudos
Message 4 of 6
(3,004 Views)

@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.

Cory K
0 Kudos
Message 5 of 6
(2,998 Views)

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.Smiley Wink

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)

 

 


"Should be" isn't "Is" -Jay
Message 6 of 6
(2,974 Views)