NI-DAQmx Error -50103: The Specified Resource is Reserved

[Jim Kring]

I have a large system where we are using DAQmx to acquire several analog voltages. Due to architectural considerations, we have decided to use separate DAQmx tasks for reading each channel.

Here's the problem. We occasionally get error -50103 which states that "The Specified Resource is Reserved". I was able to find an NI knowledge base entry, Causes of NI-DAQmx Error 50103 "The Specified Resource is Reserved", which addresses this issue. Basically, the problem is that DAQmx Read is reentrant and I'm trying to read two channels (using separate DAQmx tasks) on the same board at the same time.

Why would this cause an error? The DAQmx Read VI has a "timeout" input that defaults to 10 seconds! Why can't DAQmx Read simply wait until the resource is no longer "reserved" and then read the channel. If the resource does not become free before the timeout occurs, then I am fine with getting a timeout error or even error -50103.

IMO, this is either a bug or a very poor design of the DAQmx API/behavior.

My solution is to create a wrapper VI around DAQmx Read which implements a retry (in a While Loop) when error -50103 occurs, until the timeout expires. I'm also going to contact NI to see if I can convince them that this is a bug or valid feature request. Either way, I'll post updates here if I learn anything from NI.

Does anyone else have experience with or thoughts about this issue?

Thanks,

-Jim

[Grampa_of_Oliva_n_Eden]

I do not know if it helps but...

I was reading the on one of those USB-cDAQ devices and it said it could only support one active task at a time.

So maybe there are devices that do allow more than one active task at a time in which case the behaviour may be correct and appropriate.

Ben

[jdunham]

QUOTE(Jim Kring @ Aug 13 2007, 02:05 PM)

I have a large system where we are using DAQmx to acquire several analog voltages. Due to architectural considerations, we have decided to use separate DAQmx tasks for reading each channel.

Here's the problem. We occasionally get error -50103 which states that "The Specified Resource is Reserved". I was able to find an NI knowledge base entry, http://digital.ni.com/public.nsf/allkb/04BEDD9E9E91ED3486256D180048116D' target="_blank">Causes of NI-DAQmx Error 50103 "The Specified Resource is Reserved", which addresses this issue. Basically, the problem is that DAQmx Read is reentrant and I'm trying to read two channels (using separate DAQmx tasks) on the same board at the same time.

Why would this cause an error? The DAQmx Read VI has a "timeout" input that defaults to 10 seconds! Why can't DAQmx Read simply wait until the resource is no longer "reserved" and then read the channel. If the resource does not become free before the timeout occurs, then I am fine with getting a timeout error or even error -50103.

IMO, this is either a bug or a very poor design of the DAQmx API/behavior.

My solution is to create a wrapper VI around DAQmx Read which implements a retry (in a While Loop) when error -50103 occurs, until the timeout expires.

I believe that the reserved resource is actually the analog sample clock subsystem, which can't be shared. The API doesn't assume this because it could be different for other hardware, but with E series and M series I think this is true; hence the runtime error. You would think that with all of the timers, they could run tasks in parallel, but then the signal routing definitions of those timing signals would become ambiguous.

In general I would agree that the DAQmx API is not the greatest. Just try to take two slaved DAQ boards and make one task which includes all of the channels on both boards. We were kind of bummed to learn that this is totally not possible even with all of the virtual channel stuff.

If there were a call which could return an immediate (non-timed) value from an analog channel, then that might work (assuming you don't care about sampling and timing, but I suspect there is no such call in the API.

Last time I had to do somthing similar, I made the DAQmx task global, and then accessed the specific channels independently, which is pretty easy to do.

Good luck, and thanks for all the coolness at NI Week.

Jason

[Neville D]

Hi Jim,

Are you reading the channels hardware timed or software timed?

What sort of hardware are you using?

Hardware timing might reserve the scan clock resulting in the 'resource reserved' error.

Neville.

[MikaelH]

QUOTE(Ben @ Aug 14 2007, 07:11 AM)

I was reading the on one of those USB-cDAQ devices and it said it could only support one active task at a time.

I had the same problem using a USB-cDAQ.

I wanted the design (lots of analog and digital sensors), to be independent from each other i.e. one object per sensor.

But due to the limitations of the USB-cDAQ drivers, I created a Singleton, Daq reader object.

That all the sensor objects requested information from.

When the sensor objects requested data they could get the last value, or force to wait for a new updated value.

They could also request an average value from the last x samples.

This could be done since the Daq reader object, stored the last acquired values in a circular buffer.

This design requires that the Daq reader object, knows the fastest sampling time, so each object (when they were created) told the Daq reader object it's fastest sampling time.

//Mikael

[Jim Kring]

Hello Everyone,

Thanks for the responses!

I am using a PXI-6225, which is an M Series device. I have not configured any additional timing -- I'm simply calling DAQmx Create Channel several times at startup to create all of my channels and then calling DAQmx Read (Analog DBL 1 Chan 1 Samp) to read any given channel on demand.

Thanks,

-Jim

[jdunham]

QUOTE(Jim Kring @ Aug 13 2007, 03:09 PM)

I am using a http://sine.ni.com/nips/cds/view/p/lang/en/nid/201614' target="_blank">PXI-6225, which is an M Series device. I have not configured any additional timing -- I'm simply calling DAQmx Create Channel several times at startup to create all of my channels and then calling DAQmx Read (Analog DBL 1 Chan 1 Samp) to read any given channel on demand.

I suspect that the timers are integral to the operation of the M-series. When I did something like this, I did try to use separate tasks and never got it to work. I ended up using one task, and reading the channels independently. Architecturally it was annoying because I had to know about all possible tasks in one VI and configure them all before doing any of the reads. If you find a different way, it would be great to hear about it, but I gave up.

To access the channels independently (after the global task start), just set DAQmxRead.ChannelsToRead immediately before calling DAQmx read. I was using sample timing so I also set the property node to read the last N samples which I wanted.

Note that if you set DAQmxRead.RelativeTo = Most Recent Sample, and Offset = 0, it will actually wait until the next sample arrives (Traditional NI-DAQ did this too). You generally want Offset = -1 if you really want the currently available sample with no waiting.

I don't know what happens if you don't request any sample timing at all, but I would read the timing from the property nodes and find out what you are getting.

Good luck, and don't spend too much time without calling NI for more help.

[Jim Kring]

QUOTE(jdunham @ Aug 13 2007, 03:37 PM)

I suspect that the timers are integral to the operation of the M-series. When I did something like this, I did try to use separate tasks and never got it to work. I ended up using one task, and reading the channels independently. Architecturally it was annoying because I had to know about all possible tasks in one VI and configure them all before doing any of the reads. If you find a different way, it would be great to hear about it, but I gave up.

To access the channels independently (after the global task start), just set DAQmxRead.ChannelsToRead immediately before calling DAQmx read. I was using sample timing so I also set the property node to read the last N samples which I wanted.

Note that if you set DAQmxRead.RelativeTo = Most Recent Sample, and Offset = 0, it will actually wait until the next sample arrives (Traditional NI-DAQ did this too). You generally want Offset = -1 if you really want the currently available sample with no waiting.

I don't know what happens if you don't request any sample timing at all, but I would read the timing from the property nodes and find out what you are getting.

Good luck, and don't spend too much time without calling NI for more help.

Jason,

Thanks for the advice. I'm sure I can get it working. It's just pretty odd that my use case isn't addressed under the hood. I've seen this error several times in trivial scenarios and I can't understand why it should be the user's problem to avoid the "resource busy" error when a timeout is specified.

I opened a support request with NI at the same time (2 hours ago) that I started this thread on LAVA. So far I've only gotten automated responses from NI stating that someone will respond to me within 6 hours. The fact that I've already gotten about 5 responses on LAVA is a testament to what an awesome resource and community we have here

Cheers,

-Jim

[jdunham]

QUOTE(Jim Kring @ Aug 13 2007, 03:57 PM)

Jason,

Thanks for the advice. I'm sure I can get it working. It's just pretty odd that my use case isn't addressed under the hood. I've seen this error several times in trivial scenarios and I can't understand why it should be the user's problem to avoid the "resource busy" error when a timeout is specified.

I opened a support request with NI at the same time (2 hours ago) that I started this thread on LAVA. So far I've only gotten automated responses from NI stating that someone will respond to me within 6 hours. The fact that I've already gotten about 5 responses on LAVA is a testament to what an awesome resource and community we have here

Cheers,

-Jim

In my app, I needed long term timed acquisition on some of the channels, so I suspect you may be able to get it working with your retries (how annoying!) whereas I could not.

I presume DAQmx Read is the VI throwing the error. The read process has a property called auto-start. which basically runs DAQmx Start Task if you didn't bother to. You can turn this off, but the default is on. Since the timeout function is really for the reading of the channel not for the autostarting, it sort of makes sense that the driver does not contain code to loop on starting the task, when you are really doing a read and it is starting (and then stopping) the task as an extra favor to you.

You could run your loop on DAQmx Start rather than DAQmx Read, but I guess that doesn't buy you anything except code clarity. You are still at the mercy of the shared timing subsystem. If you can get this logged as a bug against the API, then more power to you!

[Jim Kring]

QUOTE(jdunham @ Aug 13 2007, 04:42 PM)

In my app, I needed long term timed acquisition on some of the channels, so I suspect you may be able to get it working with your retries (how annoying!) whereas I could not.

I presume DAQmx Read is the VI throwing the error. The read process has a property called auto-start. which basically runs DAQmx Start Task if you didn't bother to. You can turn this off, but the default is on. Since the timeout function is really for the reading of the channel not for the autostarting, it sort of makes sense that the driver does not contain code to loop on starting the task, when you are really doing a read and it is starting (and then stopping) the task as an extra favor to you.

You could run your loop on DAQmx Start rather than DAQmx Read, but I guess that doesn't buy you anything except code clarity. You are still at the mercy of the shared timing subsystem. If you can get this logged as a bug against the API, then more power to you!

Since the whole point of DAQmx is to have context sensitive functions (on top of a well designed state model) that simply "do the right thing" when they are called, I'm guessing that the DAQmx API designers would agree that calling the DAQmx Read function on a task that is not yet running should repeatedly try to start the task (until a timeout occurs) if a "resource already in use" error occurs inside the DAQmx Read function.

This bug is going down...

[LAVA 1.0 Content]

QUOTE(Jim Kring @ Aug 13 2007, 08:02 PM)

Since the whole point of DAQmx is to have context sensitive functions (on top of a well designed state model) that simply "do the right thing" when they are called, I'm guessing that the DAQmx API designers would agree that calling the DAQmx Read function on a task that is not yet running should repeatedly try to start the task (until a timeout occurs) if a "resource already in use" error occurs inside the DAQmx Read function.

This bug is going down...

Jim,

I could not agree with you more. My solution to the problem is semaphores, I create a wrapper around Daqmx read with an acquire semaphore before the DAQmx read and a release after. I pass the reference to the semaphore using a VIG or just obtain the named semaphore inside the wrapper. This gives the Daqmx Read the functionality you would expect it to already have, it works pretty good.

[Kevin P]

I've rarely done software-timed data acq, but I did just throw together a dirt simple example on an M-series board a couple minutes ago. Created 2 AI tasks. Called DAQmx Read in 2 separate While loops that had no delays. I got the same error as you a fairly low (but non-negligible) percentage of the time. I then wrapped both DAQmx Read calls in an additional While loop that would "continue on Error", and put the output iteration counts into a pair of charts.

Most of the time, I'd get 0 counts meaning that both Read calls worked without collision. When there was a collision, it was pretty dramatic, requiring 10's and 100's of retries. The collision rate increased dramatically when I moused stuff around onscreen.

I know that kind of error is asserted when you try to define 2 separate hardware-timed tasks with their own sampling clocks, but I didn't realize it could also happen on software-timed AI. I guess the timing subsystem does get reserved and used briefly as the driver negotiates the multiplexing and issues a single "sample and hold" pulse for the A/D.

Personally, I wouldn't have expected the driver to keep re-trying on its own. But I approach from the perspective of almost always doing hardware-timed data acq -- if there's a conflict when I make the call, it's very likely to remain throughout any reasonable timeout period. So I'd just as soon have the function call return quickly with an error. That said, I definitely see your point too. It just looks like the driver implementation is also biased to a long-term hardware-timed acq point of view.

I'd think that your best bet is to use van18's semaphore suggestion. I haven't yet found a need to use it for NI cards, but I did make a similar wrapper-with-semaphore in an app where multiple parallel processes needed to talk to an external instrument over VISA.

-Kevin P.

[afsoun rahnama]

hello guys

I have 2 input channels in my VI and I'm getting the same error because of running 2 tasks at the same time. I know a solution for that could be to combine all channels into one task but this solution wont work for me and I need these 2 channels to run in 2 separate tasks because I need  to use different trigerring for each input signal and if I combine them into one task it is not possible anymore.

Is there any way I can keep them running in separate tasks and also get rid of that 50103 error?

 

FYI: I'm really new to the labview.. 

 

here is my vi attached..

OFDR 10.28.2014.vi

[Rolf Kalbermatter]

You use hardware based timing for your tasks. The only way to get this working as you describe is to buy two seperate DAQ boards and run each of the two AI tasks on one of them. There is one timer circuitry on each board for analog input timing and you can't have two tasks trying to use that circuitry at the same time. There is no software trick to make this work as you want.

 

You could modify your requirements and start the two AI channels together and do the trigger detection afterwards in the read data though. You could even configure the AI task to start together with the AO task by making it a slave of the AO clock.

[akonstan]

Hello! I getting this error, when I try to read values from PXIe-4300, using 2 different tasks of DAQmx.

The first task is using channels 0 and 1 are configured as AI Voltage, and try to read "Analog 2D DBL NChan NSamp" method.
The second task is using the rest channels of the same module are configured as AI Voltage and try to read "Analog 1D DBL NCan 1Samp" method.  

Maybe error is there?
 

Edited November 22, 2021 by akonstan

[Rolf Kalbermatter]

3 hours ago, akonstan said:

Hello! I getting this error, when I try to read values from PXIe-4300, using 2 different tasks of DAQmx.

The first task is using channels 0 and 1 are configured as AI Voltage, and try to read "Analog 2D DBL NChan NSamp" method.
The second task is using the rest channels of the same module are configured as AI Voltage and try to read "Analog 1D DBL NCan 1Samp" method.  

Maybe error is there?
 

It's still the same. You can not have multiple tasks accessing the same DAQ card for Analog input. You need to combine the channels into one task and one scan rate and then pick out the data as needed and distribute it to the different subsystems as needed.

[Muhd Hannes Daniel]

Hi I currently having problem using NI-DAQmx and DasyLab at the same time.When I run in NI-DAQmx but when i run it at the same time in dasylab there an error occur which is the specified resource is reserved.May I know how i can avoid this problem.I cannot Labview to edit the DAQ-mx system and its pretty annoying. Thanks

[Rolf Kalbermatter]

On 2/27/2024 at 1:54 PM, Muhd Hannes Daniel said:

Hi I currently having problem using NI-DAQmx and DasyLab at the same time.When I run in NI-DAQmx but when i run it at the same time in dasylab there an error occur which is the specified resource is reserved.May I know how i can avoid this problem.I cannot Labview to edit the DAQ-mx system and its pretty annoying. Thanks

A particular device can ONLY be used by one application at any time. Either you can use it on Dasylab or in NI-MAX but not in both at the same time. That is standard procedure. A hardware device is a global resource and two applications trying to do anything on them at the same time will at best produces spaghetti but potentially also crashes.