DAQmx resource availability check.

[kbowers1]

I have a multithreaded application where each thread can try to access the DAQ card (E-series 6024) at the same time. At this point, I am running into conflicts with analog inputs only but I am also curious if analog outputs can conflict with each other or if an analog write can conflict with an analog read.

Using DAQmx 7.3, I need to be able to determine if I can perform a task before I attempt it. Can the reserved state of the task control function be used (i.e. as long as this passes it is okay to proceed)? Is there a better way? I would try a mutex but the actual test requires that two instances of the software run on the same PC and access the same DAQ card. I am not sure how to make a mutex that can synchronize separate a
pplications.

Without using the task control function, when do the transitions from unverified to verified, verified to reserved, reserved to committed... actually occur?

As an aside, I didn't run into this problem when I was using LW/CVI5.5 with the Easy IO library.

[squashmeister]

yes, you can (and should) use the reserved state of the task to figure out if you can proceed. In fact, I would recommend your app be written to explicitly call reserve before doing a read operation and then call unreserve after you are done reading. The reserve/unreserve semantics ensure that only one task can use a particular DAQ resource.

Multiple analog output tasks will run into the same issues, but they wont collide with analog input tasks.

The various states of the task are:
1) unverified (this is the state the task starts in when a task is created, channels are added, timing/triggering is configured)

2) when u call Verify using the Task Control function, the driver validates all the settings in the task.

3) When Reserve is called, the har
dware resources necessary for the task (e.g., clocks, DMA, analog input subsystem)are reserved for exclusive use. Until this point you can configure multiple analog input tasks on the same device w/o errors

4) Commit - when this is called, the settings are programmed and deployed into the hardware (trigger settings, clock settings, etc.) and the device is now primed to begin operations as soon as Start is called.

The following points should be noted:
- If you skip all of these steps above and directly call Start (e.g., Load a task & start it), the DAQmx driver implicitly transitions the task through the
verified ->reserved -> commmitted state.

Hope this info helps.

[pavanb]

Your response relates to my question on, http://forums.ni.com/ni/board/message?board.id=250&message.id=11221

You said, "When Reserve is called, the hardware resources necessary for the task (e.g., clocks, DMA, analog input subsystem)are reserved for exclusive use. Until this point you can configure multiple analog input tasks on the same device w/o errors"

I was wondering if you could use 2 AO & 2 DI channels (or several DIO/Counter/AI, mixed...) say AO1, AO2, DI1 & DI2 on the same DAQ card and then have 3 threads, one doing AO1 & DI1, 2nd doing AO2 & DI2 and the 3rd doing AO1 & DI2. Each of the threads will have an reserve & unreserve around each of these task/channels.

Will threads 1 & 2 happen in parallel? Also will the 3rd thread wait until AO1 & DI2 from the first 2 threads are completed? For that matter will the driver make all threads like #3 wait if I have several of this nature and not throw an error. Does a reserve happen at a channel level or a channel group level (all AI's or DIO's etc.)

[Mcdan]

Paven,

The reservation will occur on an as-needed basis. Let me attempt to explain. If you take your AO tasks for example, each channel has a separate DAQ which can be accessed through the driver on a point by point basis. However these DAQ share a single timing/FIFO mechanism. What this means is that as long as you are doing single point analog output, then both AO tasks should be able to run in parallel. However, if you are performing hardware timed analog output on both analog output channels, then both will need to reserve the timing circuitry, and you should get a resource reservation error when the 2nd AO task attempts to reserve the resources which are common to your first AO task. If one task is performing hardware timed generation, and the other is performing single point updates, then you should be able to run both of these in parallel. The same is true for your DI tasks. As long as they are not trying to reserve the same resources (ie.. same port/line, then you should be able to run them in parallel).

DAQmx will throw an error if it one task attempts to reserve a resource that a separate task has already reserved, rather than waiting. If waiting is the desired behavior, then I believe your best bet is to wrap the reserve call into a function which will perform the call, check it's status, then wait and retry if a resource reserved error is returned.

Hope this helps,
Dan

[pavanb]

---

@Mcdan wrote:
DAQmx will throw an error if it one task attempts to reserve a resource that a separate task has already reserved, rather than waiting. If waiting is the desired behavior, then I believe your best bet is to wrap the reserve call into a function which will perform the call, check it's status, then wait and retry if a resource reserved error is returned.

---

Does NI plan to include VIs for this?

Please refer to the question on, Lock DAQmx tasks & channels like visa locks for multi-threaded code

[Mcdan]

As far as I know, we are not planning on adding a similar VI to our DAQmx API. However I looked at the VISA example, and I believe that you should be able to do something very similar with the DAQmx Control Task (reserve). I have attached a modified version of that example that should demonstrate how this is done. Please note that I didn't have time to test this extensively, and it is intended simply as an example. The one assumption that I made is that each thread uses a separate DAQmx task (this would be synonymous with a VISA session in the VISA example).

Hope this helps,
Dan

[pavanb]

I appreciate the help.

thanks, pavan

[pavanb]

It's been a year since this post and I am email to see if there are any updates, examples, new VIs, documentation on this topic.  McDan is there any way we can talk directly. You can get in touch with me at pbathla@slc.MyEmployersNameOnly=moog.com, I'd appreciate it.

[Ryan_V[DE]]

Pavan,

There have not been any changes to the API in this area since your last post. Is there a reason that Dan's solution does not work for you? What you are running into is more of a hardware limitation than a software one. Perhaps if you elaborate a bit on the difficulties you are running into, we could suggest a solution. Please let us know, and I'll be happy to help.

Regards,

[pavanb]

---

@Mcdan wrote:
each channel has a separate DAQ which can be accessed through the driver on a point by point basis.

---

I anticipate needing a set of h/w timed AIs on one DAQmx Task and then several s/w timed AIs for an m-series board (6225) all running in parallel.  The AIs don't have separate ADCs like you mentioned above and are muxed. Will this work or will the driver throw an error. I won't need to explicitly reserve and un-reserve, correct?

thanks.