Analog read too slow. Expected behavior ?

[Gossamer]

I have a simple diagram for capturing 100 samples from analog input of NI 6216.

Sample rate is defined as 1kHz and I am reading 100 samples. I dont expect execution to be completed in 100ms, but from start to end it takes 2sec. I have tight cycle time of the machine, so 2sec is quite a lot for a simple task of collecting a few data samples.

UI gets blocked/unresponsive during the execution of this diagram. 

Actually, DAQmx Stop Task.vi seems to be taking most of the time.

Am I doing something wrong with setting up of the task ? 

[crossrulz]

Creating and setting up a task takes a lot of time.  So if you are repeatedly performing this read in an application, I would create the task as part of the application initialization.  Then you just have to start the task and perform the read where you need to.  It should come in a lot closer to 100ms then.  Also, since you are doing a Finite Samples, you don't need to stop the task.  It stops itself after the 100 samples, as defined by the Samples Per Channel input on the DAQmx Timing VI, have been read.  And you should not clear the task until your application stops.

[Gossamer]

I dont really call that function very often. My machine cycle consists of 4 analog acquisitions of 4 different analog inputs. Each one is a separate call at different point in the state machine. After machine finishes one cycle it could sit idle for minutes before next cycle starts. That was the reason for creating and deleting of the task within the block. To release the resource that is not used.

It is still kinda strange that it would take 2 seconds to create-delete task. I only noticed this issue yesterday, while code is active for last month or so.

Two days ago I was testing the same code and cycle time was 8sec. Now that same code (no modifications of the test code) takes 16sec. I was adding some UI elements in main VI, but I cant see the correlation.

Could it be that my NI-6216 is somehow acting strange ?

[Kevin_Price]

I would *usually* expect task creation and clearing to consume something in the realm of 10's of msec.

A full 2 seconds with an unresponsive UI (or 8 or 16) strongly suggests to me that the *real* culprit is elsewhere.  The long time spent on the code you posted is likely a *symptom* and not a *cause*.

It appears that the 6216 is a USB-only device.  I'd be looking into USB settings under Windows, particularly ones related to power-saving "features" which are regular sources of havoc on the message boards here.  

-Kevin P

[Gossamer]

I just loaded that VI, I posted in my first post, separately from the main project. I added one channel from DAQ card and ran the VI. Still 2sec to complete the acquisition.

So there is nothing else loading or running in the background. Issue is definitely not elsewhere.

I can assume then that USB driver/setting is the cause of the slowdown. 

I will search around for USB related issues, one of them might fix my problem as well..

Thanks

[crossrulz]

---

@Gossamer wrote:

I will search around for USB related issues, one of them might fix my problem as well..

Go into Device Manager and go into the properties for the USB hubs.  There should be a Power tab and in there an option to allow Windows to turn off the hub to save power.  Turn that off.

[Gossamer]

Issue was indeed related to the usb driver, but in my case was the Virtual machine handling of the USB.

As VM's can be configured to support USB 3.0 or 2.0, setting compatibility level to USB3.0 slowed down the DAQ. Counter intuitively.

Setting it back to USB 2.0 fixed my issue. DAQ is "snappy" again, for what I am trying to achieve anyway.

Power saving trick is good to know as well, as I am sure it will come handy at some point..