Parallel tasks in DAQ?

[TakeANap]

I have touched on the subject in an earlier thread and came halfway. Five identical modules are started at the same time and live their own lives. Depending on the test objects, each module does not end exactly at the same time.
Each module reads 2-3 of analog inputs and digital in and also controls a pair of digital ones.
How to configure that DAQ? Need a special DAQ? Should I start a task that goes continuously and writes to a buffer? How do I do that with digital out?

If I get some tips it would be great.

[santo_13]

I could not follow your questions.

In general, each DAQ can support only one simultaneous task (limited by available timing engines) for each task type. Could you please elaborate on your requirement?

[Kevin_Price]

Here are 2 very general strategies.  They get uglier in the details.

1. Stick solely to software-timed on-demand tasks for all your channels.  Expect contention for the limited DAQ device resources from 5 modules operating asynchronously.  Code around that contention to be robust against it.

    For example, each module configures its tasks without starting them.  When it's time to start, be prepared for resource contention errors if another module has a resource locked up.  So, loop over the calls to DAQmx Start and ignore/clear the specific error codes you will sometimes get.  (Note: yes, it can be hard to know how to identify them all.   It's usually based on trying to induce them on purpose and observing the error you get.)

    Once you succeed at starting without error, then you can proceed to your read or write.  Immediately after reading or writing, call DAQmx Stop to free up resources for other modules.   (You don't need to call DAQmx Clear).   The next time you need to run the same task, use the same task refnum and do the repeated Start attempts again.  And so on.

2. Create 1 or more "DAQ Managers" (perhaps 1 for each type of I/O?).   Only the DAQ Manager(s) have direct access to the hardware, so there won't be any resource contention.   But then each module must do its DAQ *indirectly* via the DAQ Manager.

    This will involve some kind of carefully planned out API or messaging protocol.  There are specific functions the DAQ Manager can perform, specific ways it can receive or return data.   The modules need to be compatible with these.

-Kevin P

[TakeANap]

Thank you. Your answer gave much information. 

I have tested some ideas. I configured some Tasks in MAX and in a big, primary, while loop I had some DAQmx Read with their own while loop. DAQmx Read stop the loop when error out got zero and data was transported out of the loop (I need to filter out some errors as U said). I can see that the DAQmx modules fights for attention! 
I just wanted to see the time elapsed between each DAQmx Read and how the driver/LV/DAQ deals with tasks. The time they use to replace a task for another one is short. It will do.  It will seems to be in parallel but it is in sequence. Timeout going to be important thou.

Question;

1. Please confirm; Do I need to use DAQmx stop after each DAQmx Read (outside the while)? 
2. Can I use tasks made in MAX? 

All five modules that test an object have, let say, 10 states that measures different things. Now I need to figure out a code that are more near reality and do some complementary tests.

[Kevin_Price · Accepted solution]

You should be able to use tasks built in MAX.  My idea for usage would look something like this:

1. No error on Start?  - go ahead and Read, then Stop.  Add a delay (here 1000 msec) until you read from this task again.

2. Certain specific error(s) related to resource contention? - just stop, and DON'T PASS THE ERROR THROUGH.  Default it to be "no error" coming out of the case structure.  Add a short delay (here 25 msec) before trying again.

3. All other errors? - just stop, let the error pass through and terminate the loop.  No delay.

-Kevin P

[TakeANap]

I understand. Nice construction. Thank you. I know how to proceed. 

What I don't understand is the delays. 🙂

Is it to get the system deterministic or to get DAQ/LV time to clean up something?

[Kevin_Price]

The general purpose of the delays are to free up CPU for your other tasks and processes.  The actual *duration* of the delays were just a simple guess of mine for the sake of illustration.

Specifically, the 25 msec delay after a sometimes-expected "resource contention" error is pretty short so you can try again quite soon.  You could shorten it if you need to, but there will be a point of diminishing returns before you get all the way down to 0.

The 1000 msec delay after a successful read was another guess to illustrate that again, even after a *successful* read, it's important to yield CPU to other tasks' attempts to gain similar access.  Again, you can shorten it if you want.

    Just realize that the shorter you make your delays, the more contention you'll have, and the more erratic each task's sample timing will be.  You'll be trading off max speed for timing consistency.

-Kevin P

[TakeANap]

Ok. Of course other processes needs time to. I get it. I thought it was for something else that I didn't know about DAQmx.

From what I can see, there is no real parallelism. A DAQmx Read/Write will generate a error if another DAQmx has the focus. That is understandably. I was afraid I was missing some important mechanism with DAQmx. I can be blind sometimes.

Thank you for your help.