Can one counter's output drive more thatn one counter's gate?

[Gamote]

I am a self-learning newbie.

I use a PCI-6601 counting card. Labview 7.1 in Windows XP. And I know it is lame, but I am using traditional DAQ. I will try to switch to the fancy DAQxm one of theses days.

I am trying to gate three counters with one of the output's counters. That is, i.e. using output of counter 0 to gate counter's 1, 2 and 3. I have just learned, that the best way of gating one coutner with another counter's output is using the RTSI bus. So, I will set the gate of 1, 2 and 3 to be RTSI0 and then route the output of counter 0 to RTSI0.

I am wondering if there are any problems with the driving current and/or voltage of this set-up.

And now, the A+ mark question is, is it possible to synchronize all the system, so that I now that counters 1, 2 and 3 get the gating signal at the same time and so, they count in the same time window?

Thank you

Gabriel

[Kevin_Price]

I can't make any guarantees about current / voltage, but I strongly suspect you'll have no worries.  I've driven multiple acquisitions across the RTSI bus driven by a single counter output many times with no trouble.  Given the purpose of the RTSI bus for timing signals, I'd expect that any signal routed up to it will be able to drive many different cards' timing inputs.  Whatever the exact electrical voodoo is that makes that happen.

As for syncing, well, mostly yes.  The only caveat has to do with nanosecond-level stuff due to signal paths and propagation times.  The timing will certainly be identical to within some handful of nanoseconds or so.   It'd be a very rare case where you'd need to concern yourself with it.

-Kevin P.

[Gamote]

Thank you Kevin,

I was mainly refering to driving counters in the same card, but I understand that your answer applies to both.

So, I have tried to implement it in my vi, and voila! You were right, and the "electronics voodoo" works perfectly, I seem to gate them simultaneously without problems. Here come the BUTS:

The three counters seem to give different results, to the same signal (in this case, the internal clock).

Moreover, I would say that when I arm the counters they should reset to zero, wouldn't they?, and if I keep my gating signal to zero, they should not count anything. The truth is that if I read the counts just after arming them I have a few counts, and I do not understand why.

Actually, the first count always gives very different results.

So, I guess that the path to complete success goes through syncronizing the counters. Any kind soul, would tutorial me on that? Pointing to reliable sources also counts.

Thanks again

[Gamote]

Hello again,

yesterday I was way too optimistic. The vi is not working properly at all. Yesterday I set the gate polarity to low and then the counters were reading everything (as in a not gated mode). It seems as if my routing of the signal is not working properly and the gate is alwasy at the low level (Yes, I noticed something wrong in the number of counts, but I thought it was because of the clock. Yes, I am bumping my head on the wall right now.)

Anyway, I have tried driving a single counter, and I still can't manage to do so, neither by routing the output to the gate, nor by routing it to the source. So, I guess I am doing a very naive mistake.

After reading the somehow spread out information from NI about the subject, it seems that the only reasonable way of doing this routing internally is through the RTSI line, because there are many restrictions with the PFI lines, and I haven't found any suitable one. I left the vi in my previous post, just in case somebody wants to check it.

My questions are: Do I have to set any jumpers or something to use the RTSI bus? Can I check the RTSI bus directly with my oscilloscope (I guess that the RTSI is that connector at the edge of the counting card, isn't it?) 

Thanks a lot again!

[Kevin_Price]

Hi again,

Unfortunately my network PC is pretty far from my LV PC and so when I finally took a quick look at the code, I didn't remember the exact question or issue you were having.  And now that I'm back online, I don't remember exactly what I saw in the code. 

That being said, I do recall that some things about the code struck me as non-ideal so there's probably some hope for improvement there.  I also wasn't sure what you intended by "gating" because in traditional NI-DAQ the same term "gating" can mean "store a sample" or "choose whether or not to count input pulses".

Agreed that routing 1 counter output to 3 other counters can probably be handled easiest using RTSI.  A couple jumper wires and some screwdriver work would be another option.

There are no jumpers you need to set related to the use of the RTSI bus.  I suspect you should see your signals there with a scope, though I've never had to resort to that.  Before resorting to that, I'd recommend some simpler troubleshooting using slight modifications of example vi's.

1. Modify an example that generates a continuous pulsetrain so that:

a) you route the output of counter 0 to RTSI0

b) the example polls a user-interface "Stop" button in a loop and doesn't stop the pulsetrain task until you press that button.

2. Modify an example that continuously counts events so that:

a) counter 2 or counter 3 is used to count events coming from RTSI0

b) the example loops and queries the count repeatedly until you hit a "stop" button.

This should only take a few minutes to setup and can verify that RTSI works, as I strongly expect it will.  Then it's back to your app code to see why your app doesn't work as expected.  I'll print this thread and try to take a closer look soon.

-Kevin P.

[Gamote]

Thank you again Kevin, actually I finally have managed to solve the problem. It seems as if I was not routing the output signal from the right counter. Now, everything works fine, so for those with a similar problem the answer to my first question is

YES, the output of one counter can drive more than one counter.

and

the only way I have found to do that, without using a screwdriver is by routing the signal to an RTSI line and making the other counters read that signal from there.

Thank you for your time. Of course, if you discover any of those non-ideal issues in my program, I will appreciate learning from your insights.

Cheers!

[Kevin_Price]

General comment:

Routing to RTSI is indeed the way to do this stuff under traditional NI-DAQ.  I used to do that all the time to avoid the need to break out a screwdriver on the terminal block, even when simply sharing signals within a single board.  However, DAQmx really does make this stuff easier.  I *think* that under the hood it's managing and configuring via RTSI, but as far as the programming interface it looks and feels like you specify connections directly.  I.e., you can configure Counter 3 to count edges on the signal known as 'Ctr0InternalOutput'.  You never have to tell Ctr0 to route its output up to RTSI or anything.

Code comments:

1. The pulse generator counter uses a much older style set of config vi's that aren't the best choice for an NI-TIO counter board like the 660x series.  I actually thought this might be one of your problems, though apparently it wasn't.  If you *must* stick with traditional NI-DAQ, you should at least be using the counter vi's with the "CTR" in the icon rather than a "123" in the icon. 

2. Your counters aren't sync'ed because they would need to be configured to start off a common Trigger signal.  As it is, they start in fairly quick succession but may be offset by some millisec.  Of course, the occasional query you do of the count value is also software-timed, so your app may not need better sync'ing than this.

3. Once you get this working under traditional NI-DAQ, it'd be a good project for you to try to duplicate the functionality in DAQmx.  DAQmx continues to be actively developed and supported while trad. NI-DAQ is on the march toward obsolescence.  (No more new development, many newer boards work *only* with DAQmx, etc.)  If you keep doing LabVIEW and data acq, you're gonna have to learn it sooner or later...

Notes: I forget the exact rules, but if you've been running a board with trad NI-DAQ and want to switch to DAQmx on that board, you should first perform a "board reset" in MAX.  Or maybe it's when switching from DAQmx to trad.   Probably a good idea for either direction.   Also, DAQmx uses different terminology.  Your style of "gating" is now known as "pause triggering."  Sync'ing counters to start input measurements simultaneously requires a special trigger known as an "Arm Start Trigger."  Personally, I found while making the switch from trad NI-DAQ to DAQmx that the counter operations required the biggest learning curve to get used to the new methods, terminology, and syntax.  The analog and digital stuff was more seamless.

-Kevin P.

[Gamote]

Thanks a lot again for your time and answers!

Actually syncing the counters (to start and also count at teh same time) is one of my short time projects. So, let me ask you:

-You seem to suggest using a trigger. Do you mean an external one, or for example one of the onboard clocks would be enough? Even better, what about the same counter which produces de gating (pause triggering in the new language)?

- Is it more straightforward with DAQmx? I plan to learn it soon, but I would like to have this up and running first.

- Any other suggestions to sync the acquisition? Although I guess in this case is not that important, as the counters are "paused triggered" and the readout is made in the time the counters are not running. Then, any other suggestions for starting the counters at the same time?

Thanks a lot!

[Kevin_Price]

-You seem to suggest using a trigger. Do you mean an external one, or for example one of the onboard clocks would be enough? Even better, what about the same counter which produces de gating (pause triggering in the new language)?

Not an onboard clock because they run continuously.  I typically liked to use a DIO bit such as DIO0 (aka PFI0).  I would set the output bit low, then configure the counters to trigger off the rising edge and start them.   Then I would toggle the bit to create the rising edge trigger that would sync them.  You probably could also use the counter that's producing the gating, but there's a little bit of an electrical race condition going on between responding to the trigger edge and responding to the gating level.  A plain old microswitch can be used for manual triggering too.

- Is it more straightforward with DAQmx? I plan to learn it soon, but I would like to have this up and running first.

Given where you're at now, I'd get it up and running under traditional NI-DAQ first.  DAQmx really does require a significantly bigger learning curve for counters than for the other types of data acq.  (This may not be so bad if you don't start with lots of experience and ingrained common practices from traditional.  Maybe my difficulty was partly due to the amount of un-learning I had to do first.)

- Any other suggestions to sync the acquisition? Although I guess in this case is not that important, as the counters are "paused triggered" and the readout is made in the time the counters are not running. Then, any other suggestions for starting the counters at the same time?

If you were gated to "count while high" and you setup triggering off a "falling edge", you probably could use your gating pulsetrain as a trigger without much risk of the electrical race condition I mentioned earlier.  The key would be to start the 3 counting counters first and then start the triggering and gating pulsetrain.

The importance of the syncing all depends on what you need to accomplish with this app.  I'm not sure whether or not you should be more concerned.

-Kevin P.