Error -89137 on simultaneous AI and AO tasks: cryptic resource

[rclary]

None of the topics I found relating to error -89137 really addresses what seems to me to be an unusual error description.

I have simultaneous AO and AI processes, each with their own task and their own loop on the same device and triggered off the same digital input channel. The AO task is a finite sample waveform and the timing is set by the input waveform. The AI task is continuous sample with implicit clock.

I cannot attach my actual application, but I have attached a minimum working example. However, while I believe the attached code captures all the relevant processes, it must be missing something because it works and my actual application does not. Which leads me to seek help deciphering the error code thrown by my actual application:

AO Configure Hardware.vi<append>
<B>Property: </B>Start.DigEdge.Src
<B>Property: </B>Start.DigEdge.Edge
<B>Source Device: </B>Dev11
<B>Source Terminal: </B>PFI0

<B>Required Resources in Use by</B>
<B>Device: </B>Dev11
<B>Reserved Terminal: </B>AO/PFI0

<B>Task Name: </B>_unnamedTask<59>

Dev11 is a simulated USB-6002. I've had resource reservation errors before, but what confuses me is the reserved terminal "AO/PFIO". I don't know where that name comes from. Why isn't it "Dev11/PFIO"? But as the attached code demonstrates, Dev11/PFIO should not be the issue (multiple tasks can trigger off the same digital channel).

Can anyone help me decipher this?

[rclary]

I was mistaken that the attached MWE did not produce the same error. Depending on which task is created sooner, the reserved resource is "AO/PFIO" or "AI/PFIO". I didn't notice it sooner because I was looking at the wrong loop. Another strange thing to me is that the error is raised after the DAQmx Read/Write, respectively rather than after the DAQmx Start Digital Edge. The good news, then, is that someone can help me solve this problem with the provided MWE 🙂

[Bob_Schor]

Well, I tried your code with a real USB-6002.  I noticed a couple of things -- there was no indication of what was generating the PFI signal (so I connected PFI0 to DI1:0, and wrote code to raise this high, generating a trigger).  When I did this, I got the same error you got.

I've not tried triggering multiple DAQ tasks from the same hardware trigger.  However, I recall an example where AO immediately follows AI, and there was a way (maybe through another PFI channel?) to synchronize them.  Possibly check the DAQmx Examples that come with LabVIEW, but I know it's out there.

So a question I have -- you have set up your DAQmx code to sample at 1 Hz, yet you do "single Samples" (which, to my surprise, ignored the 1 Hz Sampling Rate) and use the rather imprecise and inaccurate Windows Clock running the Delay function to sample at 100 Hz.  Here's a suggestion -- set up (as you have) Continuous Samples, set a rate of 1 KHz and a Sample Size of 10 samples, then do N Sample acquisition, compute the mean, and Presto, you have sampling at 100 Hz with the Clock being the more accurate, more precise USB-6002 clock.

Bob Schor

[rclary]

Bob,

Thanks for replying. A couple of points. The sample rates and delay in the example code are arbitrary (I just threw in some numbers). My actual application uses 1kHz timing and reads 100 samples at a time. I don't think this is relevant to the resource issue that I was really focused on here, but pleas correct me if I'm wrong.

Also, just to be clear, I intend an _external_ trigger source to be connected to PFI0. When using a real USB-6002, I expect the tasks to be waiting for that trigger before reading/writing. On the simulated USB-6002, triggers are automatically received at the DAQmx Start vi.

I'll look for the example that you suggest and see if offers any new information...

[Bob_Schor]

About the External Trigger -- yes, I knew that.  I've written similar code, and had a box that generated the trigger.  However, for testing, I used my own USB-6009 without the Trigger Box (which also involved some circuitry to shape the TTL pulse).  To get the code to run "as though I was using the Real McCoy", I put a "Stim" button on the Front Panel and had it generate a pulse on a DO line wired to the PFI input -- worked like a charm (as the USB-6009 didn't really care from where those electrons came).

Bob Schor

[Kevin_Price]

On many NI DAQ boards, I've commonly had 2 or more tasks configured to use the same PFI pin as a trigger or clock signal.  This has generally been supported with no particular issue.

Most of this experience has been with desktop or PXI boards though.  I've found from various threads here that USB boards sometimes have some special restrictions, especially the simpler, lower cost boards.  It's possible your USB device doesn't support the kind of flexible routing you're counting on.  I did a quick look in the manual without finding a definite answer -- maybe you can try physically wiring your trigger signal to *both* PFI0 and PFI1, and then configure each task to use a different PFI pin?

-Kevin P

[Ben]

Reaching back and grasping for straws...

Try passing the wire for both tasks through a sequence frame just prior to the "Start" for each.

Inside the seq frame add a "DAQmx Control Task" VI with an action of type "Commit".

The help for that function does not help much but if it is the same issue I saw way-back,  NOW SPECULATING when a task is started all of the associated resources are reserved for that task. That would include the trigger line. But if we tell DAQmx to "commit" it is telling DAQmx that it will be using these resources. It may allow you to "share" the trigger resource.

No hardware here so I can not test if I am full of scat or not.

Ben

[rclary]

This may be the solution I end up implementing...

[rclary]

Ben, I'll give this a try and post back...

[JÞB]

6002?

Most of the 60xx USB devices are software timed only.

I can't open your code. Inline the VI snippet