Vi running so slow to write/Read a Digital I/O on cDAQ-9185

[bill0w]

Hi, I'm currently trying to use the NI-9185,when i run VI to Read/Write Digital I/O or to read analog measurement, it takes 400 ms to excute the VI.

Spoiler

Is there any solution to minimize that time like a configuration or something elese ?

I use DAQmx 17.6, LabVIEW 17 and the VI was called into Teststand 16.  

I use those Modules:

-Module DO : NI 9477

-Module DI NI9425

-Module Analog Measurument : NI9205

-Module Universa Measurument : NI9219

[JiwhanS]

Hi bill0w,

The likely cause of your slow execution speed is from the coercion of the DAQmx Global Channel input for the Start Task function. I would try to create the task from scratch within the VI itself. The link below explains the basic DAQmx functions in LabVIEW.

Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications

http://www.ni.com/product-documentation/2835/en/

[bill0w]

Hi JiwhanS,

Even when i use directly the address of channels without using the Global Channels i have the same problem. i still have the same issue.

[JiwhanS]

Can you post a screenshot  of how you are using the address of the channels?

If you are calling this VI in Teststand, have you timed it in LabVIEW outside of Teststand?

[bill0w]

Yes, it takes between 300 ms and 450 ms when i run it outside of TestStand.

[Kevin_Price]

It's generally going to be faster if you could create (and perhaps also start) the task during your pre-test setup.  Hold onto the task ref and use it for your TestStand step where all you then need to do is write the appropriate output value.  You can stop and clear the task during post-test cleanup.

The create and clear in particular tend to be a bit more time consuming, so it's best not to incur their overhead any more often than necessary.

-Kevin P

[bill0w]

I already did it, the same problem, could i update the frimware of the cDAQ? 

[Kevin_Price]

Can't speak to the cDAQ firmware but am doubtful that's the problem.  There'd likely have already been a widespread outcry about similar troubles.

Can you please post the full code you use to do the timing benchmark, preferably back-saved to an earlier version (2016 is what I'd need, earlier might be better for others)?  There's a long history on the forums of timing benchmarks that don't measure exactly what they intend to and I figure we better rule that out first.  (And in fairness, LabVIEW's parallelism and dataflow rules can make it a bit trickier to do benchmarking well).

-Kevin P

[bill0w]

When i use a simulated cDAQ and run this VI the execution time was 30 ms, even when i use others acquisition card as PCI or PXI. but i find this problem only on cDAQ. I think the problem is from the version of DAQmx or cDAQ firmware.

This is VI i used to command output, i used into sequence in Teststand. even i run only this VI out of the full code i find this issue.

[Kevin_Price]

That's the same (functional) code you posted initially back in msg #1.   What do you get when you move the Tick Count calls inward so that you are *only* timing the call to DAQmx Write?   That's what I suggested in msg #6.

In general, PCI or PXI cards will demonstrate lower latency than a card connected by a communication link (like USB or ethernet cDAQ) for many operations.  The amount you're seeing *does* seem excessive, but so far it seems you keep approaching the problem the same way where you create the task from scratch every time you want to set the digital output.

First be sure you're approaching the problem in the *best* way.   Create and start the task ahead of time, then check timing only for the functional part, i.e., DAQmx Write.  Be sure to test it purely in LabVIEW as well, outside of TestStand.  *Then* you'll have a more complete set of info for getting to the bottom of things.

-Kevin P