Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple X-Series Card Acquisition on PXI: Analog DAQ Timing is using DIO Resources?

I have a PXI system with 2x 6533 cards.  I have created a task that samples both cards together, basically by adding the channels from both cards to a single task.  This works fine.

 

However, I also use the DIO on these cards.  After I start the analog acquisition, I am getting this error when I try and set up the digital ports (which are being set up for output, but only need to be software controlled output):

 

Error -89137

Possible reason(s):

Specified route cannot be satisfied, because it requires resources that are currently in use by another route.

Property: RefClk.Src
Source Device: 6355-1
Source Terminal: None

Required Resources in Use by
Task Name: _unnamedTask<AB11>
Source Device: 6355-1
Source Terminal: PXIe_Clk100
Destination Device: 6355-1
Destination Terminal: RefClockInternal

Task Name: _unnamedTask<AB22>

Is there a simple way to update this to use a different clock so they don't step on each other?

 

I just want to sample DAQ continuously but still be able to control DIO on these cards.

I am not all that familiar with using the PXI chassis to do this, but it looks like the 

 

0 Kudos
Message 1 of 8
(1,206 Views)

You say X-series, but the 6533 is a DIO-only device.  Do you mean a pair of 6353's?

 

Are you trying to configure the Reference clock explicitly?  It's unlikely to be necessary.  Can you post the code, both for the AI and the DO?

 

 

-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 2 of 8
(1,170 Views)

My bad, They are 6355 cards, multifunction not X series.

 

I re-wrote the code to use two task, and I route the sample clock from one to the other over PXI_Trig0.  this works, And appears to allow me to control DIO without error.

 

However, this is kind of a pain.  I want to use the LogToFile option to stream these to TDMS.  Now I have to manage two TDMS files.

 

This in and of itself isn't terrible, but one thing I was going to do was to occasionally peek at the latest TDMS data.  Now I have to deal with two files, and synching the data is not easy.

 

So the question remains:  is there a way to have these cards log to a TDMS using a single task, without disrupting the DIO port tasks?

0 Kudos
Message 3 of 8
(1,154 Views)

When you use channel expansion to put channels from different devices into a single task, DAQmx does some automatic routing of timing signals to make it work.  This will consume certain resources, but I'm surprised that in a PXI system it leads to a conflict with any software-timed DIO task.

 

One thing I'd try is to reserve, commit, or start any DIO task(s) *before* configuring the multi-device AI task that uses channel expansion.

 

Beyond that, I'd want to see actual code saved with default values.

 

...Just thought of another thing.  Are you trying to create DIO tasks that span across both boards?  If so, don't.  Stick to separate tasks for each board or even separate tasks for each DIO line.  I would expect that to remove any contention for timing signal resources.

 

 

-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 8
(1,143 Views)

I tried to create and start the DIO tasks first, but then I get the errors when I create the AI.  So either way.

 

The DIO tasks are essentially individual port tasks on each card, so no... not cross-device channels.  Honestly, I am very surprised by this, as they aren't even configured with a clock.  Just initialize DO, start and write (the initial write to initialize the states).  From there they are just read and written to.  No timing involved.

 

Is there any way to see the resource usage/mapping for a configured task?  Maybe if I know what they are doing, I can try and modify the resources after I create the AI task.

0 Kudos
Message 5 of 8
(1,135 Views)

I don't know of a way to query a task for all its resource usage.  You can query *some* things individually, but probably not enough of the right things to help solve this.

 

There's a knowledge base article that talks about that error and suggests doing explicit configuration to assign the same Ref Clk to every task.  And then there's another forum thread that seems to have gotten success with a similar solution.

 

I guess it's worth a try to follow those pieces of advice.  But I also know I've got a PXI system running with many sync'ed tasks spread across 4 devices and I never configured a reference clock for any of them.   So I guess I'd start by seeing whether device resets alone get you to a state that works, then move on to the explicit Ref Clk config if it doesn't.

 

 

-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 6 of 8
(1,131 Views)

I think the issue may be that whoever set this up did so with the cards separated across the PXI buses, so I have to do some bridging.

 

Problem is that the hardware assembly process is tightly documented (medical device test), so moving the card is actually a pain in the ass.  Otherwise I would run down that route.

0 Kudos
Message 7 of 8
(1,122 Views)

Well, I tried moving the cards to the same segment of the chassis as well as specifying the same reference clock, and still had the same errors.  Looks like I will have to handle it the hard way.

0 Kudos
Message 8 of 8
(1,094 Views)