Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -50103 When Starting Digital Output Task on PXIe 6612

Solved!
Go to solution

I've been trying to figure out why I keep receiving error -50103* on my PXIe 6612 but I haven't found anything that I recognize as causing a problem.

 

I receive the error after the "DAQmx Start Task" VI for a digital output task. Overall, in the whole program, I have two digital output tasks and the first one appears to work fine. Both tasks have separate lines, and none are repeated, but they are on the same port. I've included screen captures of the relevant tasks and hopefully someone can notice something I've missed or point me in the right direction.

 

The first Digital Output task:

ABrooksKGC_1-1579117054550.png

 

The second Digital Output task where the error occurs:

ABrooksKGC_0-1579116749262.png

 

While it's not visible here, there's a data dependence introduced with the error wire to ensure execution order.

 

*Error -50103: "Possible Reason(s): The specified resource is reserved. The operation could not be completed as specified."

 

- A. Brooks

0 Kudos
Message 1 of 5
(2,375 Views)
Solution
Accepted by ABrooksKGC

I'm about 90+% sure about this.

 

Only 1 timing engine is available for DO, thus you cannot have 2 hardware-timed DO tasks running at the same time on your "Slot4" board.  Whichever one starts first will own the timing engine and the one that attempts to start second will throw the error. 

    The only workaround would be to put the two DO lines on Slot4/port0 into the same task, and then manage whatever you need to manage to update both line 26 and 31 together in advance of each new sample clock cycle.

 

I would also note that 5000 Hz is a pretty agressive output rate for hw-timed single point if running Windows.  Maybe ok under RT though.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 5
(2,334 Views)

Ah, that could very well be it.

 

I wasn't looking closely at that since a previous version of the program, where the code was parallel instead of in series, had appeared functional. Based on other things, I'm willing to bet that program had other issues that would mask this one though. I'll make some changes tomorrow, just to be sure, but that would definitely explain the behavior.

 

If you don't mind, where do you know the number of timing engines for DO from? I'd like to document this for later and it would help to have a source reference. I don't remember seeing that in the DAQmx introductory documents but it's very possible that I overlooked it.

 


I would also note that 5000 Hz is a pretty agressive output rate for hw-timed single point if running Windows.  Maybe ok under RT though.

 

-Kevin P


I should have mentioned that I'm running this on PharLap ETS 13.1 RT OS, sorry.

 

Thank you very much for the prompt feedback.

 

-A. Brooks

0 Kudos
Message 3 of 5
(2,329 Views)

RE: "1 timing engine" for DO

   Sorry, but I honestly don't recall how I've come to know that.  I've been using NI DAQ devices for over 2 decades and it's a case of accumulated knowledge.  It's just something that's generally been true for most of the common & general purpose desktop and PXI boards I've know about over the years.  Each common I/O subsystem -- AI, AO, DI, DO -- has only 1 dedicated timing engine (or in some cases, 0 in low-budget cards)..

 

The rules changed a bit with cDAQ, where the *chassis* gets some total # of total timing engines and has more flexibility about how to distribute them among tasks.  So on cDAQ, one often *can* have multiple simultaneous hw-timed tasks of the same type.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 5
(2,313 Views)

So, for anyone looking at this later and wondering if there's an official reference about this problem, I found these documents after @Kevin_Price kindly pointed me in the right direction:

 

1) Maximum number of DAQ tasks that can be run simultaneously on "PXI/PXIe DAQ, PCI/PCIe DAQ card or a USB DAQ device[s]".

2) List of devices that can support multiple simultaneous DAQ tasks.

3) Overview of tasks in NI-DAQmx, with a brief mention of maximum configurable tasks.

 

Hopefully that will save someone some time if they ever encounter this issue like I have.

 

-A. Brooks

Message 5 of 5
(2,269 Views)