Unpairing Counter Outputs

[Snevets]

Hi,

I have recently discovered that the counters on a 6602 board are configured in pairs. This is causing problems for my application and I would like to unpair these counters so that variable N pulses can be sent to each counter without a gate signal on the other counter.

How would I go about doing this?

Thanks!

[Kevin_Price]

Coincidentally, I just answered a very similar question.   The short summary is that you can likely prevent the undesired gate signals by configuring your finite pulse train manually as a pause-triggered continuous pulse train and a single pulse whose output signal is suppressed.  The longer version can be found here.

-Kevin P

[Snevets]

Thanks for the response Kevin.

Unfortunately I don't think that will work for my application. I need to measure the specific number of pulses sent by each counter. If I understand you correctly, you're suggesting that I have the pulses be consistently generated all the time and have a time-based gating of when these pulses would actually be sent. Is this what you're saying?

[JoelWhittC]

The second paragraph of this KnowledgeBase article may help you figure out how to unpair the counters:

http://digital.ni.com/public.nsf/allkb/A441EB181C1D582C86256A4800689D6D

"If you do not want to use the output of a counter as its counter pair gate, you can route signals internally using DAQ programming. The best way to do so is to take advantage of the RTSI pins between PCI cards or the PXI_TRIG lines between PXI cards."

Thanks,

Joel C

National Instruments

[Kevin_Price]

Yes, you understood me correctly.  I'm pretty sure now that I made some wrong guesses about your app though.  

Can you describe the app in more detail?  How many pulse train signals are you trying to generate?   Are they generating different frequencies and/or do they generate for different total times?

Must you accurately control the # of pulses generated?  Or do you only need to accurate count the #?

-Kevin P

[Snevets]

I'm sending steps to two position motors. I need to be able to control these positions down to single-step accuracy since my optimized position peak has a FWHM of 100steps. I'm counting the number of steps sent either by labview or using an external control switch on two of the other counters on my board.

[Kevin_Price]

Sorry, still not seeing why the pairing is an issue.

You can control positions to single-step accuracy by generating 2 finite pulsetrains.  Each of those task requires a counter pair, for a total of 4 counters. 

For the sake of argument, I'll suppose you generate with counters 0 and 2 and the tasks use counters 1 and 3 implicitly behind the scenes.

This alone will *control* the number of steps generated.  But if you also need to verify in hardware, you need 2 more counters to count those pulses.  That makes a total of 6.  Your board has 8.   So what exactly is the problem?  Is it just that you'd like complete flexibility about which counters generate the finite pulsetrains, such as generating with counters 0 and 1?   If that's the problem, the only answer I know is the more complex config I pointed to in the first place.  The idea of "pairing" when implicitly using 2 counters together for 1 finite pulsetrain signal is a hard restriction.

-Kevin P

[Snevets]

The pairing is an issue because when I write a set number of steps to one of my motors, the other motor sees this gate window on the paired channel and takes 2 steps that are not tracked by my program, moving it slightly out of position each time the first motor is moved.

---

@Kevin_Price wrote:

You can control positions to single-step accuracy by generating 2 finite pulsetrains.  Each of those task requires a counter pair, for a total of 4 counters. 

For the sake of argument, I'll suppose you generate with counters 0 and 2 and the tasks use counters 1 and 3 implicitly behind the scenes.

---

I'm a little confused by this. Why would I use two pulsetrains to control one motor's position? I am reading the steps on another pair of counters for the verification that you talked about.

I have decided to just rewire my experiment so that the two motors are written by two counters that are not in a pair. The solution to reroute the signal would probably fix the problem I'm currently having, but if I end up needing to use the counter I'm rerouting the signal to I'll be back in the same problem.

[Kevin_Price]

The workaround you are planning to do was exactly what I was driving at.  The 2 different unpaired counters would send 2 finite pulsetrains to the 2 motors that need them.

I didn't see this as a big issue because I was supposing it was just a matter of rewiring one counter output on a terminal block.  But perhaps you have a situation where rewiring isn't so easy.

One way or the other, each finite pulsetrain on a 6602 is gonna need 2 counters.  If you program it the easy way, the counters will be used in pairs, and I don't think you can suppress the paired counter's gating signal.  If you program it the more manual way I described, you *may* be able to suppress the gating signal but the 2nd counter is still going to be used up.

-Kevin P