LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx seems late?

Hi,

 

I am developing an application where it is critical that I have the latest available data from a DAQ card.  However, the data I am getting seems like it is between one and four iterations old.

 

In order to investigate this, I created a small vi and connected my output device (9263) to my input device (6008).  The VI simply writes a value to a channel and then read the values from that channel since the last read.  I also added some very long waits to ensure each device had plenty of time to read and write data.

 

The result is perplexing.  I would expect the output to show a step up to the value that was just written, but instead, it shows a step up to the value written in the last iteration.  Either I did something wrong setting it up, or I don't understand how either the read or write VI's work.  Could you help me figure out why it is behaving this way?

 

I am attaching the VI and an image of the result I get.   I expect the "change to" indicator to match the step up voltage on the graph, but as you can see, the graph trails the indicator by one iteration.

 

Thanks for your help.

 

Greg 

Download All
0 Kudos
Message 1 of 8
(4,301 Views)

Hi Greg,

 

I was able to run your program on my machine with a PCI-6251 and it seemed like the data was current.  I have modified your code a little bit, so we can see the difference between the read and write a little easier.  Could you try running the attached code and seeing if the two arrays are different?  It may be something that is specific to your device.

Regards,
Jim Schwartz
0 Kudos
Message 2 of 8
(4,264 Views)

Jim,

 

Can you save the modified code as LV 8.0.1?  I cannot open it as you posted it.

 

Thanks,

Greg 

0 Kudos
Message 3 of 8
(4,236 Views)

Hi Greg,

 

Here is the VI in 8.0.  Let me know what you find.  This could be due to the way USB does transfers, as I was not able to see the behavior from my PCI card. 

Regards,
Jim Schwartz
0 Kudos
Message 4 of 8
(4,215 Views)

Hi Jim,

 

Your code seems to work correctly with my hardware.  I will dig in and try to figure out where the difference is.

 

Thanks,

Greg 

0 Kudos
Message 5 of 8
(4,177 Views)

Jim,

 

The difference seems to be in my use of continuous acquisition.  When you just collect one sample as you did, everything seems to work fine.  However, I am trying to collect all the data since the previous read, and that is where it gets messed up.

 

I am attaching a copy of your vi modified for continuous acquisition.

 

The other thing I don't understand is why there are no available samples 100ms after I start the task.  This isn't very important, but maybe it has some bearing on the more important question of why I don't have current data.

 

Thanks,

Greg 

0 Kudos
Message 6 of 8
(4,122 Views)

I have not looked into your code, but I have seen issues with a USB (a 6221) device which took a little time to start up with complicated tasks.

I had no issues with a PCI 6221. For me this was not a problem, I only had to make sure I had all the data I needed, not the time.

 

I would advise you to look into specific buffer settings for your device and make the buffer as small as possible. I am not sure how much you can tweak a 6008, but you might want to use hardware triggers instead of software.

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 7 of 8
(4,116 Views)

Hi Greg,

 

I believe that the behavior that you are seeing is casued by the way data is transferred with USB.  USB transfers the data in chunks to the PC, whereas the data is immediately available with PCI devices.  The KnowledgeBase below explains about what is happening:

 

Why do USB M-Series Devices Aquire not Data on the First Read?

Regards,
Jim Schwartz
0 Kudos
Message 8 of 8
(4,096 Views)