cDAQ Command-Query & Reply Update Speed

[Gan Uesli Starling]

I have a LabVIEW program, which when operating with simulated input data is blazing fast during mock-up. As soon as I hooked into a real cDAQ on Windows, however, the update speed fell off to 4 seconds. That's awful slow. I don't really have a whole lot of channels. I have read tasks for Volts of maybe 5 channels, write tasks for both On./Off for maybe 10 channels (simultaneous) and write tasks for 4-20mA of only 5 channels. How may I improve on that? Is it maybe a priority issue in Windows or to do with USB? What? How to improve? Thanks in advance.

[hooovahh]

I'd be curious to see how your tasks are created and the type that they are.  Are you starting and stopping tasks all the time?  I'd suggest setting them up to be continuous, and then just read the values that essentially are in the buffer, then close when you need to modify the task or the application is done.

I think you're going to have to do some debugging and figure out where the extra slow downs are occurring, and maybe write some test code to test the performance of doing the same thing, different ways.  I've not seen a the type of slow down you describe, and it sounds pretty extreme.  Oh are you connected to any USB hub?  If this is a desktop try the USB ports on the back of the computer instead of the ones on the front.  Any other computers you can test with?

[Gan Uesli Starling]

Yes, I am starting and stopping the tasks every time on each iteration of the loop. Such is the examples in the books I have seen. So I've always just done that.

Should I instead start them outside the loop, then carry them through round-and-round, stopping only outside the loop? Not really sure what that would look like.

[Gan Uesli Starling]

Okay. That was indeed the issue. I figured out starting the tasks outside the loop and that helped a LOT. Thanks.

[hooovahh]

Glad you figured it out.  The Open, Operate, Close paradigm (with operate taking place in a loop) is pretty common in LabVIEW and is often see for File I/O, VISA, and other hardware stuff.  I'm guessing with simulated hardware an Open and a Close just takes much less time than communicating with actual hardware.  There are times when open and close can take place in the loop, but it is generally useful when you only call the operate once in a great while, allowing for the hardware to be used for some other task.