Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

cDAQ DAQmx timing sample clock DO / DI on same module

Solved!
Go to solution

Hello,

 

Simulate system :

CDAQ ==> 9178

Module 1 ==> 9375

Module 2 ==> 9201

 

What I want to do :

I would like to change the sample rate of my DI's to have the same sample rate than the AI's channel.

No problem when I use different modules for the DO's and DI's but when the DI's and DO's are on the same module the system no longer works...

 

The problem :

When I use the DAQmx timing VI the error -201105 occurs when I start the DI task.

 

[Error -201105 occurred at: DAQmx Start Task.vi:7220001
Possible reasons:
The resource requested by this task has already been reserved by another task which has parameters incompatible with this task.
Release this resource for other tasks that use this device or change their settings to be compatible with this task.
Task name: _unnamedTask <52>]

 

But when I use the property node to change the sample rate no more problems to start the task!

Can someone explain me the difference between this 2 methods please?

And why I can't use the DAQmx timing VI to do my configuration?(when I use the same module for DO and DI)

 

I made a little VI to simulate my problem.

 

Thanks a lot for your help and do not hesitate to ask me questions if I have not been clear enough.

 

 

0 Kudos
Message 1 of 12
(464 Views)

Hello,

first of all you have to tell us the LABVIEW version you are using

 

writing an inspirational quote does not make you inspired! inspired guy

0 Kudos
Message 2 of 12
(383 Views)

Hello,

 

You are right!

 

I'm using Labview 2018 v18.0.1 (32 bits)

(and NI MAX V18.5)

 

Best regards

Message 3 of 12
(377 Views)

I don't know exactly what resource conflict is causing that error - my familiarity with cDAQ is fairly limited.  But the reason the property node config does *not* produce an error is probably because you left out the key property "Sample Timing Type".

 

There are other things for you to address.

 

- you shouldn't be configuring your AI task sample clock to come from "/cDAQ1/di/StartTrigger".   You should probably be sharing a sample clock instead.  If it doesn't work to use "...di/SampleClock" with DI as the master, try using "...ai/SampleClock" with AI as the master

 

- it makes no sense to set up for 5000 Hz sampling, and then read 1 sample at a time in a loop with a 50 msec Wait delay -- limiting it to 20 Hz, and *guaranteeing* buffer backlog which will soon become a fatal task error.  You'll be better off removing the wait and requesting 250 samples per loop to produce the same 20 Hz loop rate.

 

- as I work through this, I suspect maybe your error arises because of explicitly wiring the "...di/SampleClock" terminal into the DI task's call to DAQmx Timing.  Try leaving that input unwired and let DAQmx do its default thing.   This may not seem intuitive, but I think your usage is getting interpreted by DAQmx as an impossible circular reference.  "Use the signal that I have not yet caused to exist."

 

 

-Kevin P

0 Kudos
Message 4 of 12
(370 Views)

Hello Kevin,

 

I don't know exactly what resource conflict is causing that error - my familiarity with cDAQ is fairly limited.
But the reason the property node config does *not* produce an error is probably because you left out the key property "Sample Timing Type".

 

Thanks for the response and your are right when a put the sample timing type I come back to the same error!

There are other things for you to address.
- you shouldn't be configuring your AI task sample clock to come from "/cDAQ1/di/StartTrigger".
You should probably be sharing a sample clock instead. If it doesn't work to use "...di/SampleClock" with DI as the master, try using "...ai/SampleClock" with AI as the master

 

Yes small error of my part... I had a sync between AI and DI but then I corrected the VI and forgot to change the SampleClock

- it makes no sense to set up for 5000 Hz sampling, and then read 1 sample at a time in a loop with a 50 msec Wait delay
-- limiting it to 20 Hz, and *guaranteeing* buffer backlog which will soon become a fatal task error.
You'll be better off removing the wait and requesting 250 samples per loop to produce the same 20 Hz loop rate.

 

Totally, I admit having copy paste to go as quicly as possible with my configuration and I then applied a quick while loop to simply highlight the error in starting the task and not the acquisition!

 

- as I work through this, I suspect maybe your error arises because of explicitly wiring the "...di/SampleClock" terminal into the DI task's call to DAQmx Timing.
Try leaving that input unwired and let DAQmx do its default thing.
This may not seem intuitive, but I think your usage is getting interpreted by DAQmx as an impossible circular reference. "Use the signal that I have not yet caused to exist."

 

I totally see what you mean but unfortunately even like that it's non-functional =/

 

Anyway, thank you very much for your help!

0 Kudos
Message 5 of 12
(356 Views)

Are you getting the same resource contention error as before?  Have you tried the idea where you let the AI task act as the master task instead of DI?   My thought there is only speculative, but I am aware that many cDAQ chassis tend to provide more clocking & timing support for AI than for DI/DO.

 

 

-Kevin P

0 Kudos
Message 6 of 12
(336 Views)

Hello,

 

Yes, exactly the same.

Yes I have tried one time with the DI in master and AI slave and then to put the AI on master and then DI in slave.

The only way to not have the error is to let DO and DI module with default settings and put the AI with is own clock but in this case I lose my synchro and I need it =/

0 Kudos
Message 7 of 12
(301 Views)

Can you post the version of code where you have AI as master and DI/DO as slaves?   Also, which task produces the resource conflict error when you try to start it?   What happens if you change the order for starting DI and DO (though both should still be started before AI when AI acts as master.)

 

Finally, are you sure the port and line designations are right for your DI and your DO?  The first code you posted used ports 0 and 1, which kinda suggests to me that there's only one port for DI and one for DO.  I only skimmed the spec sheet for your module, but I saw 16 lines of DI and 16 of DO.  I haven't dealt with many devices that have 16-line ports, most have either been 8 or 32.   No reason yours *couldn't* be 16, just trying to think of other possible reasons for your error.

 

 

-Kevin P

0 Kudos
Message 8 of 12
(290 Views)

Test panels for a simulated 9175 seem to confirm that port 0 has 16 DI lines and port 1 has 16 DO lines.  So never mind that last part I speculated about.

 

 

-Kevin P

0 Kudos
Message 9 of 12
(288 Views)

Here you have the version with different tests and combinations I have done.

(you have some differents disable structure with differents combinations I have tried)

 

It's always when I try to start the DI or DO.

If you start DO first and then DI this is the DI who cause the error -201105

and if you start the DI first and then the DO this is the DO that produce the error -201105

 

Thanks and have a nice day

Jonathan

0 Kudos
Message 10 of 12
(270 Views)