DAQmx resource availability check.

[Mcdan]

Hi Pavan,

Sorry I didn't get a chance to reply to you sooner, but I've just returned from vacation.  Your M-Series device does have one ADC which is multiplexed between all of your analog input channels.  However the analog input subsystem is a bit more tightly coupled than the analog output portion of the device.  When you commit a DAQmx task, the hardware itself is programmed with a list of channels to be scanned.  Once this list has been programmed, there is no way to modify it without stopping and uncommitting the task which is presently running.  There is other coupling as far as how data is passed back through the device and into your PC's memory.  Because of this, I would expect that the driver would error any time you try to start *any* AI task if one already has resources reserved.  Because of this you have only a couple of options (that I can think of at the moment).  First is to explicitly reserve and unreserve tasks as mentioned in the example above.  The second method would be to continuously read all of the necessary channels (h/w timed) and throw away data points that are unnecessary.  The pitfalls with this method being that the data managment could be pretty complex, and you could run in to sample rate limitations, again related to the multiplexed ADC (ie... max rate you could sample any one channel out would be (250 kS/s / Number of Channels) and all channels would get sampled at this rate).

Hope this helps,

Dan

[pavanb]

Dan, I have only one Task and the rest are all s/w timed DAQmx channels (all of which is setup in MAX and used in LV), the DAQ reads could run in parallel asynchronously. Since h/w and s/w timed AI and s/w timed AI amongst itself don't conflict, I don't need semaphores or task reservations etc (correct??) I have over 80 channels on win and RT and am using 10 - 20 VIs on this alone therefore I don't want to do extra coding if I don't have to.

Btw, the notes on the m-series boards architecture and interaction with the driver, where can I get more documentation on that.

You can get in touch with me directly at pbathla@slc.MyEmployersNameOnly=moog.com.

Thanks.

[Mcdan]

Pavan,

Basically any Read operation you perform with DAQmx will need to do resource reservation.  As such, when you read your channels, they will need resources which your task already has reserved and I would expect that you will see resource reservation errors.  You can use the DAQmx Control Task.vi to reserve the resource necessary to read your channel just like you can for a DAQmx task.  Because of this, you should be able to use the same scheme mentioned above (in Wait Example.vi).  A few other points I think could make your application a bit more efficient... When you read a DAQmx channel, basically the driver is creating a task to do this (this is why using DAQmx Control Task.vi will work).  If you were to actually create tasks for all your channels (or possibly one task for all of your channels) and possibly use DAQmx Control Task.vi to verify this task when your application initializes then DAQmx would not need to do this each time read is called.  This task could then be cleared when your application is finished.  Without knowing more about the specifics of your application, I would be concerned that with the possibility of 80 channels waiting for the same resources to be available at the same time, some of these channels may need to wait longer than you'd like.  This is why I recommended that you could possibly create a single task which contained all of the channels you've set up in Max.  When this task is read, it will read data from all of the channels and I would imagine that some of that data will probably be thrown away, but it should make waiting for reserved resources a bit more deterministic.

Hope this helps,

Dan

[pavanb]

Dan, Thank you for your response.

There is no overlap in the pins/channels used. I have a h/w timed task that contains 2 channels, AI 1 & AI 2. Then 2 channels (not tasks) the contain AI 15 & AI 16 used s/w timed. Do I need to explicity call reserve and unreserve? Won't the implicit DAQmx read alone work, without throwing an error?

If it throws an error then I will call reserve and unreserve, I can afford the wait.

thanks

[Mcdan]

Pavan,

The reason that the implicit DAQmx read on your channels will cause a resource reservation error is because all channels on your device share the same ADAGE (and in some sense data path).  The device needs to know which channels to scan, and what to do with the data every time the ADAGE has completed a conversion.  In order for any task (or read of a channel or list of channels) to occur, the driver needs to program the hardware with this channel list.  This is not something which changes dynamically during the run of a task (and you should view your read of one of your channels as a run of a task).  So when either your hardware timed task or one of your channels is run, they will attempt to reserve the ADC (and correspondingly the mechanism which controls which channels are programmed to be scanned).  If any one of your channels or task have already reserved this resource, then you will see the resource reservation error.  The reason you can do this with software timed analog output writes is that each analog output channel physically has its own DAC (and in the case of software timed writes, its own data path).  I think your best bet will be to use reserve and unreserve, and should be able to do this with a mechanism such as in the previously attached Wait Example.vi

Hope this helps,

Dan

[pavanb]

Thank you for all your help, this puts my question to rest.

[Mcdan]

Pavan,

I noticed that the spell checker led me astray in my previous post... it seems to have changed ADC into ADAGE 😞

Anyhow, I'm glad to have answered your question.  Best of luck with your application, and post back here if you have any further questions.

Dan

[pavanb]

I am back.

The devil is in the detials. There's one part of the big app where we are using couple of shared vars bound to DAQmx global channels. This FP bound indicator is being polled very slowly in a while loop once every 3 seconds. I gess this might conflict with driver calls to other AI channels.  Would you recommend steering away from this? SV bound to channels is easy and boosts our programming productivity, I would like to use it if possible.

I alos realized that there is a Server polling rate which is how fast the DAQmx I/O server polls the channels? This is like doubly polling. Where I poll the SV and the engine polls the driver/channel. So the SV polling won't conflict with the driver but the i/o server would, correct?

thanks.

[Mcdan]

Hi Pavan,

I will preface this by saying that I have almost no experience using shared variables in general and shared variables (SV) bound to DAQmx channels in particular.  I did take some time to experiment with this, basically by creating and running a regular AI task while at the same time stopping and starting a VI which reads from a SV bound to a DAQmx channel in a loop.  It would appear as though binding a DAQmx channel to a SV, then running the VI in which this occurs will reserve the resources necessary for this channel for the duration of the run of that VI.  As such, no other AI task can be run while this occurs.  Conversely, it appears that if the resources necessary for the DAQmx channel bound to the SV are reserved when the VI which attempts to read it is run, then all attempts to read from the SV will return an error until the VI is restarted.  Looking at this behavior, it appears as though the SV engine will reserve all resources on the channel being read once someone subscribes to the SV, and will not relinquish them until that subscription is cancelled.  From our previous discussions it would seem as though this could be a problem for you.

As such, you may be better off not using the SV in this case (or at least not one bound to a DAQmx Channel).  If you like the shared variable, then I would recommend that you do the following.  Create a VI which reads (DAQmx Read) your global channel (using the resource reservation scheme we talked about before).  Take the output of this read, and write that to a SV.  Although it's a bit more work to get data to the shared variable, it should avoid hairy resource reservation issues, and should not affect the consumer of data from this variable.

I hope this made sense... as I said before I really have not had much of an opportunity to play with shared variables, so there may be a better solution.

Hope this helps,

Dan