Sample clock source through RTSI

[sugar7]

Hello,

I have a short question on a sample clock source through RTSI.

In my setup, two PCI cards (PCI-6602 (dev2) and PCI-6110 (dev1)) are connected through a RTSI cable.

I'd like to generate a sample clock source on 6110 and use it on 6602 to count external input pulses.

In MAX test panel, I checked a counter was reading the external signals.

However, the attached vi do not work and count at all, then give an error of 200284.

Could you tell me what is wrong?

I guess something is not right on routing the clock signal. Do I need to use DAXmx connect terminals vi instead of external signal?

How can I check the two devices are connected properly through a RTSI cable?

I registered the cable and connected the devices on MAX without any issues. Is that enough?

Thank you for your kind suggesion and comments.

[BenRobinson]

Hi sugar7,

I have attached a link to a sample code very similar to the behavior that you are hoping for. The while loop will allow the code to continue running and pull out a number of samples based on the number of samples specified in the counter read operation each time the loop iterates. If you know the number of samples you plan to take each time the VI runs, the best way is to change the sample clocks to finite samples and specify the number of samples.

https://decibel.ni.com/content/docs/DOC-14202

[sugar7]

Hello Ben,

Thank you for your reply.

I took a look at the link you showed, but it's still not clear why

my code doesn't count when the sample clock source was generated in another PCI card and rounted to the counter

through a RTSI cable.

If I output sample clock pulses in the same counter as counting, then the vi works and returned a correct number of counted pulses.

So, most likely the vi has problems with routing using the RTSI cable.

When PCI cards are connected with a RTSI cable, should connectors be orientated in a certain direction?

Thank you for your kind support.

[BenRobinson]

Hi Sugar7,

There are some more simple ways of using the hardware clock on the 6110 as the timebase of the 6602. I have attached a code that shows how the timing property node can be used to set the timebase of the 6602 task. The attached screen shot also shows this property node. Using this property node, you will no longer need the counter output task from the 6110, so the only task line will be the counter acquire task.

The other change that you might consider is changing the sample mode of the sample clock to finite samples as you seem to be acquiring a finite number of samples before the task ends. If you would like the code to continue acquiring data points, then you may want to utilize a while loop around the read operation.

[sugar7]

Hello,

Thank you for your suggestions.

I modified the original vi as attached.

In the sampling part, a loop was omitted for simplicity.

I'm not sure this is what you meant and the vi still doesn't count.

I still get error 200284 and wondering what should be connected as a source to DAQmx timing.

Withoug source, I got error 200303 because this is buffered event counting.

best,

[Simon-P]

Greetings, Sugar7;

After having taken a quick look at your VI, I had a few questions. You are using the Dev1 20MHz Timebase for the acquisition as per the input into the property node, correct? 

Take a quick look at the following example, it might be of aid. Basically, in this one they explicitly demonstrate how to do export the timebase from one and into the other, which is, if I understand correctly, a part of the problem:

https://decibel.ni.com/content/docs/DOC-12184

I believe that in our case we would have a very similar task setup; we simply would not have the reading VI's on the top.

Does that help?

[Kevin_Price · Accepted solution]

Several things briefly:

• Orientation of RTSI cables must match.  Connectors are typically keyed to guarantee this, but if you're using a homemade ribbon cable, just keep it flat between the boards.
• The code you posted tries to use the internal 20MHz timebase as a sample clock.  That won't work for several reasons, and the fact you're trying suggests that you may have a faulty understanding of how counters work.  You do *not* need to "sample" at a high rate in order to catch the digital transitions.  The counter circuitry handles all that in hardware.  What you "sample" in a counter task is a count register value.  Digital TTL edges will increment that register value regardless of how often you "sample" it. 
• I suspect that you want to *count* the cycles of the clock signal from your 6110, whether that's a counter pulse train or a task-based AI sample clock.
• I'm posting an example that does unbuffered software-timed sampling at about 10 Hz.  It uses Dev2 to generate a 1000 Hz pulse train, and uses Dev1 to query the count register value in a loop.  This is simplified from the code you've posted to help disentangle task config issues from RTSI routing issues.  Start by using something simple like this to see if DAQmx succeeds in routing signals across RTSI.

-Kevin P

[Kevin_Price]

Here's a 2010 snippet of the example vi:

-Kevin P

[sugar7]

Hello,

Thank you for all of your comments and suggestions.

Most likely, the problem was due to the cable connection.

I use an extended RTSI cable from NI and after I changed connectors, then

my original vi (posted pictures) could count external pulses without any problems.

In the test vi posted, I tried to incorporate a suggestion made by Ben, though it wasn't clear to me.

I set sample clock at 1 kHz for counting. Is this still to fast?

Anyway, I appreciate your kind help and your time.