getting DAQmxErrorResourcesInUseForRoute_Routing error when using master device as a timer

[I_B]

Hello Chris,

I just tried using the counter on the slave device and receive the same error message we have been dealing with all along.  I modified the original source code file I sent you (i.e. that sets the master device refernce as 'OnboardClock') with the following update:

DAQmxErrChk (DAQmxCreateTask("myCounter",&counterTaskHandle));
DAQmxErrChk (DAQmxCreateCICountEdgesChan( counterTaskHandle, "NI6220a/Ctr0", "", DAQmx_Val_Rising, 0, DAQmx_Val_CountUp ) );
DAQmxErrChk (DAQmxSetCICountEdgesTerm( counterTaskHandle, "NI6220a/Ctr0", "100kHzTimebase" ) );

 The error message I receive when starting the slave task is as follows:

DAQmx Error: Specified route cannot be satisfied, because it requires resources
that are currently in use by another route.
Property: DAQmx_RefClk_Src
Source Device: NI6225a
Source Terminal: 10MHzRefClock

Required Resources in Use by
Task Name: myCounter
Source Device: NI6220a
Source Terminal: None
Destination Device: NI6220a
Destination Terminal: RefClock

Task Name: mySlave

Status Code: -89137

 I get the same error message when using Ctr1 on the slave device.

I am starting to question whether analog input and counters can be used at the same time when synchronizing multiple devices.  Is this a possiblity?

Ian

[Chris-NI]

Hi Ian,

Please try specifying your clock as "/NI6225a/20MHzRefClk" (apologies - I left the first slash off on my last post) instead of "/6225a/10MHzRefClk".  The 10MHzRefClk on the 6225 should be exportable on your RTSI lines, but for some reason it is not working in C++.  I was able to get the 10MHzRefClk working in LabVIEW with the exact same setup but not in C++ and received the same error (-89120) as you.  For now, please use your 20MHzRefClk with the following command:

DAQmxErrChk (DAQmxSetRefClkSrc(slaveTaskHandle,"/NI6225a/20MHzRefClk"));

In doing this, you may also need to manually specify the rate of your slave device's reference clock rate at 20 MHz.

I suspect the error on the 10MHzRefClk as a source (when correctly using the first slash in the device name as mentioned above) may be a bug.  I will continue to investigate this and submit a Corrective Action Request for our R&D team if there is in fact a bug here.

This latest change should get you taken care of.

Regards,

[I_B]

Hello Chris,

No luck, same problem.   I even ran the tests with a second PCI-6225.

For testing purpose, would you please send me your C/C++ source code file.

Thanks,

Ian

[Chris-NI]

Hi Ian,

This is odd that your code did not work correctly.  There must be something different between what I have here and what you have.  I would rather not post unsupported code on our forums, but I would be happy to take a look at your current build and let you know what differences there are.  Additionally, I have attached working LabVIEW 2012 code that uses the latest version of DAQmx (9.6) and accomplishes what you are trying to do.

Regards,

[I_B]

Hello Chris,

I have attached the VS2010 solution.   Would you please compile and test it.

Thank you,

Ian

[Chris-NI]

Hi Ian,

A quick change to lines 39 and 40 got your code running on my machine:

    DAQmxErrChk (DAQmxSetRefClkSrc(slaveTaskHandle,"/6221/20MHzTimebase"));
    DAQmxErrChk (DAQmxSetRefClkRate(slaveTaskHandle,20000000));

This method requires no need for line 38.

Regards,

[I_B]

Hello Chris,

I have a question for you at the end of this post but first a bit of good news.  The code is now running as expected.  What was missing was that I was not setting the reference clock rate for the slave task. For example, the following works:

DAQmxErrChk (DAQmxSetRefClkSrc(slaveTaskHandle,"/NI6225a/20MHzRefClock"));
DAQmxErrChk (DAQmxSetRefClkRate(slaveTaskHandle,20000000));

In addition, setting the reference clock to ‘20MHzTimebase’ and '10MHzRefClock' also work providing the appropriate clock rate is set.

What is interesting is that the original NI sample code also sets the reference clock to '10MHzRefClock':

DAQmxErrChk (DAQmxSetRefClkSrc(masterTaskHandle,"OnboardClock"));
DAQmxErrChk (DAQmxGetRefClkSrc(masterTaskHandle,str1,256));
DAQmxErrChk (DAQmxGetRefClkRate(masterTaskHandle,&clkRate));
DAQmxErrChk (DAQmxSetRefClkSrc(slaveTaskHandle,str1));
DAQmxErrChk (DAQmxSetRefClkRate(slaveTaskHandle,clkRate));

I modified the original code by adding a counter task.   Adding a counter caused the original sample code to generate the errors that I have already reported.  So why can '10MHzRefClock' be used in one case but not the other?  I found the modifications made to the original code could be successfully run as long as the reference clock was not set for the master device.  In other words, the following lines must be removed from the original code so that the reference clock and time are only set for the slave device:

DAQmxErrChk (DAQmxSetRefClkSrc(masterTaskHandle,"OnboardClock"));
DAQmxErrChk (DAQmxGetRefClkSrc(masterTaskHandle,str1,256));
DAQmxErrChk (DAQmxGetRefClkRate(masterTaskHandle,&clkRate));

Here is my question for you.  You mentioned in your 09-11-2012 response that, “You do not actually have to set a source for your master's reference clock as the DAQmx driver takes care of this under the hood for you”. What reference clock does DAQmx set for the master device if my code does not manually set it?  Calling the function 'DAQmxGetRefClkSrc()' returns the value 'none'.  So is the slave device really synchronized with the master device?

Thanks,

Ian

[Chris-NI]

Hi Ian,

I am currently on vacation through September 24 but I can give you a brief explanation here.

It does not matter which reference clock your slave uses as long as it is from the master device.  All reference clocks are divided down from the master timebase and, thus, are all phase coherent with one another (in sync).  It does not matter if your master device uses a 10 MHz reference clock and your slave imports the master's 20 MHz clock because they are both derived from the same master timebase on the master device.

The original sample code is for a specific use case and does not take into account a simultaneous counter task.  DAQmx commits specific reference clock settings on your master device for your counter task.  Therefore, when you start your counter task, you reserve the master device's reference clock resource.  Then when you start your master task, your application tries to commit new settings to your master device's reference clock, but that resource is already in use by your counter so it cannot be modified.  This explains the error you were receiving and this is why you cannot DAQmxSetRefClkSrc in your master task.  The get functions can still be there but have no use since we are not using those values.

Regarding your final question, DAQmx chooses whatever reference clock is best suited for your requested sampling rate given the currently available resources on your device.  All clocks on your device, as I mentioned before, are phase coherent with respect to the onboard master timebase, so it really doesn't matter which one is used.  Manually specifying a reference clock is mostly only useful when importing external clocks, otherwise you run can into resource conflicts as you have seen here.  There are some exceptions, however, where you want to manually specify an internal reference clock first, and this is explained in the following Knowledge Base article:

Why Do I Get a Resource Error When Using a Reference Clock with NI-DAQmx Devices? - http://digital.ni.com/public.nsf/allkb/3D99C0ECBCC9FA9C862576E800556235

There is a lot of great information on all of this on our website.  Here are some links I recommend you take a look at if you would like more details:

M Series User Manual (see pages 152-159 for clock routing and RTSI synchronization information) - http://www.ni.com/pdf/manuals/371022k.pdf

M Series FAQ - http://www.ni.com/white-paper/3614/en

What is a Phase-Locked Loop? (RTSI uses this when importing external reference clocks) - http://digital.ni.com/public.nsf/allkb/07BC8D77D4E9AE258625708B007CE74F

DAQmx Reference Material on Clocks - http://zone.ni.com/reference/en-XX/help/370466V-01/mxcncpts/clocks/

DAQmx Terminal Names - http://zone.ni.com/reference/en-XX/help/370466V-01/mxcncpts/termnames/

I will be unavailable for the next week, but hopefully this gets your code up and running (it sounds like it has).  If you want to have a general discussion about how timing, routing, and resource reserving works on M Series devices, I would recommend starting a new thread since it will be more focused on a broad topic rather than a specific code issue since we've worked past your application-specific question.

Regards,