Disadvantage of dedicated task for each channel vs. multiple channels in one task

[MPlanck]

Hello,

My current acquisition software (C++/GCC) wraps the rather unhandy niDAQmx C methods to interface with the DAQ hardware in a class that represents one acquisition task. This way I can create multiple instances, e.g. counter input, analog input and analog output, set their terminals, and the class takes care of all the lowlevel work such as making sure a fake internal analog input is started if there are only counter inputs such that the sample clock starts, or setting up N-Sample callbacks, etc.

This seems to work just fine, and also the timing seems to be good, due to the triggered start of all tasks across multiple instances of my wrapper. For the triggered start I use

DAQmxCfgDigEdgeStartTrig(mTask,mTriggerTerminal.toAscii().constData(),DAQmx_Val_Rising)

internally.

Now my actual question: What is the benefit of multiple channels when everything seems to work fine with multiple tasks and only one channel per task? I see only the disadvantage, that one would need to first categorize the needed acquisitions into types (ai, ao, ci,...) because multiple channels in a single task must be of the same type. With my approach I don't need to care because every channel always gets its own task.

I'm sure I'm missing something here. Maybe someone can explain this to me, maybe some limitation of multiple tasks, that I haven't read about yet.

[royam · Accepted solution]

Hey!

Unless you have hardware specified to handle it (Simultaneous Sampling) or modular instruments ( see link )

you cannot run two tasks at the same time that access analog inputs for example, because the

ADC is a shared resource connected to a multiplexer, and only one task can operate on it at any given time. ( see here )

Similar restrictions often apply to other types of operations.

I'm not aware of any performance issues, maybe a bit more memory could be used.

So, as long as your hardware supports what you are doing, you should be ok I think,

and it is only an issue of clarity and comprehensibility, usability and structure.

As you are working with classes, I'm sure you've heard about encapsulation - so this is basically a

question of how you choose to design your application.

Also, when working in LabVIEW, tasks feel more natural to the principle of dataflow, because you have one wire for your data aquisition,

and it works very well with our standard design patterns.

So, if it's better for you (and works with the hardware), you might as well give every channel his own task.

Hope this could clarify some things, 

kind regards,

Rome

NI Germany

[MPlanck]

Thank you, this indeed helped alot getting a better understanding of what's going on inside the DAQ boxes. And those links are very helpful, too!