LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple DAQ boards/multiple VIs?

Suppose I have two DAQ boards installed in a PC (PCI-6071E's, for instance). Can I have two separate VIs each performing data acquisition on one or the other of the boards without running into conflicts? In other words, VI A would acquire data from board A and VI B would acquire data from board B. I know this wouldn't work if I tried to have VIs A&B acquire data from one DAQ board. Any difference if I run the VIs under LabVIEW RT?
0 Kudos
Message 1 of 4
(3,038 Views)
On the surface, you wouldn't see any conflicts. The two boards are separate, and have separate DMAs going.

Where you would start to have problems is when you started to do really high speed/high channel count data acquisition, especially (or perhaps only) with Windows operating systems.

There would be a performance improvement with RT, but only because you wouldn't have to deal with Windows.

When setting up your acquisition, with RT, you can plan precisely what is going on as long as you know what pharlap (or whatever OpSys is running) does as far as processor time. With Windows, this is impossible, as the operating system does what it wants, when it wants, and you can't plan for any of this. Additionally, you have a tremendous amount of overhe
ad with Windows.

I hope this helps.

-Mike
0 Kudos
Message 2 of 4
(3,038 Views)
Hi Vahugh,

In addition to the points made by the GURU I would like to add some additional points of clarification.

"VI A" and "VI B" should be well behaved, and play nice together.

By this statement I mean the they have to share the common resources such that both have what they need to operate properly.

No one VI can use up all of the CPU time.
Similarly with memory and bus access.

If you take a look at the shipped examples that demonstrate continuous double buffered acquisition, you should be able to run two copies (save as different names) at the same time.

When doing these types of apps, I will shoot for the minimum update rates I can get away with.

Set things up so the hardware just lets the data pile up in a over-sized DAQ buffer and just get u
pdates every second or so (just guessing at time).

Taking this approach should avoid most of the problems that you could run into except (as the GURU mentioned) bus speed (DMA's) and any post processing tasks like analysis, filtering, displaying, and logging.
BUT
these are another story.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 4
(3,038 Views)
Thanks for your comments. As I envision my application, VI A will run at full tilt but in infrequent, short bursts. VI B will run continuously in the background, never using many CPU cycles or much bus bandwidth. For safety, I may introduce some intertask communication to cause B to block during the brief intervals when A is active.
0 Kudos
Message 4 of 4
(3,038 Views)