Multiple DAQ boards/multiple VIs? 
Author Message
 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?

Mon, 14 Mar 2005 06:24:35 GMT  
 Multiple DAQ boards/multiple VIs?
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 overhead with Windows.

I hope this helps.


Mon, 14 Mar 2005 07:25:45 GMT  
 Multiple DAQ boards/multiple VIs?
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 updates 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.
these are another story.


Mon, 14 Mar 2005 20:12:37 GMT  
 Multiple DAQ boards/multiple VIs?
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

Mon, 14 Mar 2005 22:08:09 GMT  
 [ 4 post ] 

 Relevant Pages 

1. Reading a DAQ board from several VIs

2. About multiple VIs(for Brian)

3. Queues via Multiple VIs

4. Starting multiples VIs at the same time

5. how to open multiple vis at a time

6. Multiple boards

7. Multiple edits, multiple files

8. Multiple CPUs and multiple PCs

9. Multiple Dispatch (was Re: Replacing Multiple Inheritance with Java's Interfaces)

10. Multiple Windows on Multiple Machines

11. Multiple textures on one IndexFaceSet [multiple files, not a map]

12. Updating multiple fields on multiple rows


Powered by phpBB® Forum Software