Multi Channel AI and AO Issue

[JoeWork]

Unfortunately it appears I have fallen into the trap of forgetting that more than one DAQmx task can't be started on the same device.  I have a situation that I need to be able to read and write multiple formats (single and multipoint) of analog information to two cards, PXIe-6363 and PXIe-6739.

I figure what I need to create is a single DAQmx task that will continuously aquire and send analog data to the channels I define.  For single point data values I will just use array manipulation.  I will also have to set the sample speed to the highest requirement for the project.  I was then planning to use queues to transfer the data between the analog VI and the VIs that will produce or consume the data.

I have one module now that I am working with.  I would like to be able to come up with a simple way to define the additional channels that I need for the rest of the task.  I thought creating a multi-channel DAQmx task from a script file would be the best.  I would really like to avoid manual channel definitions in the VI if possible.

I have been researching this for a while, but really haven't come up with the best option.  If you have ideas or a possible solution you can share I would appreciate it.

Also if any of this is unclear please reply.

Thanks for your time.

Joe

[Kevin_Price]

To be clear about multiple DAQmx tasks: the restriction is generally about having only 1 timing subsystem available for each distinct task type.  The timing subsystem is needed for buffered tasks.  Your 6363 board can run simultaneous buffered tasks if only 1 is AI, 1 is AO, 1 is DI, 1 is DO.   Several simultaneous buffered counter tasks can be run too, since more timing resources are available to the counter/timer.  Additionally, the same board can run many more single-point software-timed tasks.

What you *can't* do is have 2 independent buffered AI tasks or 2 independent AO tasks.  Folks usually combine channels into a single task, and if different rates were wanted, they sort that out with post- or pre-processing.

Other than that, I'm afraid I don't really understand where you're stuck.  What you describe as a "script file" is something I've typically done with a .ini file.  Further, I use the excellent MGI Read/Write Anything toolkit to make .ini files almost magically simple.  (It's available for free through VI Package Manager.  Thank the good folks at Moore Good Ideas for it.)

-Kevin P