DAQ-MX 8.3 freezes on slow sampling rates

[Santaprene]

Using NI DAQ-mx with USB-6009 and doing a VI Logger Task with 0.5sec sampling rate the PC goes into a coma for about 35 minutes, which is very annoying.
With KHz sampling rates I do not see this.
I'm guessing some amount of minmum data is needed to update the graph. ( ~ 70 points??)
Moreover, the Start/Stop "button" does not cleary indicate which state it is left in, does Green mean I can Start or does it mean it has started?

[Kevin_Price]

Please post the code.  There's a very good chance that the structure of the code is responsible for the delay you observe.  One typical situation would be something like this:

- Call to DAQmx Timing with settings for finite sampling of ~4000 data points, sampling rate of 2 Hz (corresponds to the 0.5 sec interval you mentioned).

- Call DAQmx Start

- Call to DAQmx Read with input for "# sample to read" unwired.  When unwired, the default value of (-1) is used, meaning "read all data after the entire finite buffer has been filled".  4000 points at 2 Hz will take 2000 seconds (33+ minutes) to acquire.   Had you sampled at 1 kHz, it'd only take 4 seconds instead.

That's all the time I've got now except to assure you that there *are* ways to structure your code that let you update graph displays regularly throughout a long acquisition.  A key term to search for is "Producer-Consumer architecture."

-Kevin P.

[Santaprene]

The program I use is the NImax.exe, Measurement & Automation Explorer (MAX), not really "my" code.

[Nicholas_B]

Hi Santa,

Are you using the VI Logger interface in MAX or LabVIEW?  You are right when you assumed that there is a minimum amount of data required to update the display. The way VI Logger works is that it does not update the display until the full amount of samples per channel have been acquired. For example, if you set up your VI Logger task to read continuously at 2Hz with 2 samples per channel, it will only take 1 second to update the display.  But if you are sampling at 2Hz and specify 100 samples per channel, it will take 50 seconds for the data to display. It will display those 100 points, then wait another 50 seconds to display the next 100...and so on.  That being said, it would take a setting of 4200 samples per channel (at 2Hz) to achieve a delay of 35 minutes (4200 / 2 = 2100 seconds = 35 minutes).  So can you tell me what setting you have in your task for Samples to Read? If it is very high (like 4000), try setting it to 10 and let me know if it still bogs down your PC.

As far as the button... when your task is not running you should see a green Run task button at the top of MAX.  When the task is running you should see a red Stop task button.  Do you see different behaviour?  If so, what version of MAX and DAQmx do you have?  (please verify that it is DAQmx 8.3)  Also, are you using VI Logger Lite or VI Logger Full?

Regards,

Nicholas B, National Instruments

[Tom_W_[DE]]

Hi Santaprene-

The same limitations Kevin points to could possibly also slow operation in VI Logger.  Can you please list the settings you use for Acquisition Mode, Samples to Read, and Rate? 

EDIT: Nick beat me to it with a more thorough explanation...

Thanks-

Message Edited by Tom W [DE] on 12-14-2006 09:50 AM

[Santaprene]

Clock settings:

Samples to read: 1000
Rate (Hz) 500m

Acqusition mode:

continous

Clock type:

Internal

[Nicholas_B]

Hi Santa,

Thank you for the info.  So if you take a look at my previous post, this 35 minute delay is expected with the parameters you have set.  You are telling VI Logger to wait until 1000 samples have been read.  And when the acquisition is performed at a rate of 0.5Hz, it takes 2000 seconds (or 33.333) minutes to acquire the 1000 samples. 

To reduce the time, increase your sample rate or decrease the numper of Samples to read.  With such a slow sampling rate, even setting Samples to read to a value of 1 will still take 2 seconds to display. 

Let me know if you have any additional questions, comments, or concerns. 

Regards,

Nicholas B, National Instruments

[Tom_W_[DE]]

Hi Santaprene-

Your combination of rate and samples to read mean that it will take (1/.5)*1000 = 2000s to return each time.  This is ~33 minutes and likely the cause of the delay you're seeing.  Adjust the samples to read to something reasonable given the sampling rate and the delay should go away.

Hopefully this helps-

Message Edited by Tom W [DE] on 12-14-2006 10:59 AM

[Tom_W_[DE]]

Hi Santaprene-

Can you please clarify the level of locking up that occurs while the computer is in the "coma?"  Does the VI Logger/MAX software appear to be locked up because the graph is not updating, or does the entire machine become unresponsive?

Thanks-

[Santaprene]

I'll try that.
I did not expect to have to adjust that being I'm requesting continous sampling at 500m. Samples to read is just a graph scaling issue. The graph I would expect should adapt to those parameters. I'm graphing for a very long time, up to a month, maybe more.

The graph lacks a NOW button, and sometimes jumps to the past, and sometimes 12 years into the future.

Three scroll buttons changes states on the red/green button.

A Stopped and Running indicator would be helpful for these slow sampling rates, where the display updates are infrequent.


I'm using the "light" version.