Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

board synchronization using RTSI7 in ansi C

Hello,

I'm stuck.  I want to synchronize an AI clock on an S series board with an AO clock on an M series board.  I've connected a cable across the RTSI ports (26 pins connected pins 9:34 due to the limitations of parts at hand). 

I can route S/20MHzTimebase to S/RTSI7, and I can route M/RTSI7 to M/PFI7 using DAQmxConnectTerms, I see the 20MHz clock on my oscilloscope, so I know the routing to and through RTSI7 is good.

But I cannot get my AO Task to go on the M Series board !

I am using DAQmxCfgSampClkTiming(TaskAO,<source>,...), I tried RTSI7, I tried S/20MHzTimebase for the source -- I'm guessing these don't work because DAQmxCfgSampClkTiming expects the actual clock not a timebase in the argument.  So I connected M/RTSI7 to M/ao/SampleClockTimebase, whatever I put for <source> gives me an error like this...

- - -
Specified route cannot be satisfied, because it requires resources that are currently in use by another route.
Property: DAQmx_SampClk_Timebase_Src
Property: DAQmx_SampClk_Timebase_ActiveEdge
Source Device: Dev2 (...that's the M device)
Source Terminal: 20MHzTimebase

Required Resources in Use by
Source Device: Dev2
Source Terminal: RTSI7
Destination Device: Dev2
Destination Terminal: ao/SampleClockTimebase

Task Name: TaskAO

Status Code: -89137
- - -

I'm beginning to think that I can't use DAQmxCfgSampClkTiming(). 

Anybody know of an example showing how to set up my Slave timing ?

Thanks for any help !

-rajeev-
0 Kudos
Message 1 of 8
(3,968 Views)
Rajeev!
 
Thank you for contacting National Instruments!
 
On an M-Series card, you can call Dev1/RTSI7 directly.  You don't have to internally route the RTSI signal to a PFI line.  That internal routing is giving you the error.  The driver has routed it to PFI line and now you are trying to also access it. 
 
One catch!  Once you route terminals in DAQmx, it holds the routing.  You will want to call the unconnect terminals to free up the RTSI7 line.
 
Jeff P.
0 Kudos
Message 2 of 8
(3,960 Views)
Jeffrey,

Thanks for your reply.  Routing RTSI7=>PFI is not the problem, that part works -- I only used it to verify that RTSI7 actually does have a clock on it.  I also took it out of the code after verification.  Although I have not called UnconnectTerms(), my code resets all boards before doing anything else.

The problem I have is that a 20 MHz signal on RTSI7 (verified !) and want to use it as timebase for an AO task on my M Series 6221.

Regards,

-rajeev-

0 Kudos
Message 3 of 8
(3,958 Views)
Rajeev,
 
I think I figured out what the problem is.  In theory, we are not doing anything wrong.  The only problem is that the random RTSI line you chose, RTSI7, is reserved for the onboard 20MHz line on the M-series card.  That is why we are receiving the error about a line in use already.  Choose a different RTSI line, and you should be good to do.  I found this in the NI-DAQmx C Reference Help that ships with the driver.  Here is the words from that file. 
 

RTSIn

Real Time System Integration bus

—general-purpose input/output lines. RTSI7 is the exception. It is the only line to use for the 20 MHz Timebase signal.

 

-Jeff P.

0 Kudos
Message 4 of 8
(3,955 Views)
Jeffrey,

Thanks for persisting.  In fact, I am using RTSI7 precisely because it is driven by the 20 MHz timebase on my
S series board -- and that's the signal I want my M series board (AO Task) to use as a timebase.  My
impression is that the RTSI7 restriction does apply to the S series board, but the M series board (it's a 6221)
doesn't distinguish between the RTSI lines.  (But I may not be remembering that correctly.)

-rajeev-

0 Kudos
Message 5 of 8
(3,951 Views)

Rajeev,

You may want to take a look at this post.  I am going to continue looking around!

http://forums.ni.com/ni/board/message?board.id=250&message.id=9743&requireLogin=False

 

 

0 Kudos
Message 6 of 8
(3,948 Views)
Jeffrey,

Indeed that thread is spot-on.  I guess I have to become better at searching through the forum archives !

I don't feel too bad for being stuck on this, between an experienced user and an NI principal engineer, it
took them 5 exchanges (10 messages) to resolve the problem, and that too using undocumented features !

It is quite remarkable to me that the NI engineer who took ownership of this issue, on his *fifth* post is still
saying that he hasn't tried out what he's suggesting.  And that the customer's question on his last post --
"How on earth did you find that?" was never answered !

Thanks to your help, I hope to make some progress on this.

-rajeev-

0 Kudos
Message 7 of 8
(3,942 Views)
Rajeev,
 
I'm glad that worked out for you.  We have a searchable index of all of our discussion forums, so we can better serve  you, the customer.  Smiley HappySmiley Tongue
0 Kudos
Message 8 of 8
(3,938 Views)