Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

PCI-6602 - What to do with unused counter inputs?

I've got an application where I need to track the position on two quadrature encoders.  I've developed my application with VB6 however, I've been using a sample LabView program called "Meas-Ang-Pos-Buff.vi" for testing purposes.  (I got the example off the NI discussion board).  I'm seeing some very odd results that I can't explain. 
 
For testing purposes, I've got one encoder tied to multiple channels on my 6602.  I have the same 'A' signal and the same 'B' signal (from the one encoder) jumpered to multiple encoder channels.  I'm using a onboard pulse generator to generate the latch pulse (connected to the Index/Z of each counter) to ensure there is no skew in my count values.  I'm using an external servo to turn the encoder at a rate equal to my application speed.
 
The unexplanable results I'm seeing are below:
If I'm monitoring counters 0, 1 and 2, I see the following.
1)  If I have counters 0,1,2 and 3 inputs connected to the same 'A' & 'B' from my encoder, the counts on all 4 channels (0,1,2,3) track perfectly.
2)  If I disconnect counter 3 and only have counters 0,1, and 2 connected to the encoder, then counter 0 and 2 track perfectly, but counter 1 looses pulses (only when traveling in one direction, the other direction seems to be fine)
3)  If I connect counter 3 to ground and have counters 0,1, and 2 connected to the encoder, I get the same result - bad.
4)  If I connect EVERY counter input (2,3,4,5,6) to ground and only monitor counters 0 and 1, I still get bad results.
 
In summary, I ONLY am able to see the same number of counts while monitoring 3 channels IF 7 of the 8 counters are connected together (the 8th being my latch).
 
This happened to me in the past on a previous setup that did the same thing, but I was able to fix it by moving from counter 1 to counter 4.  At that time, I chalked it up to a bad counter 1, but I think there is a bigger issue since it is happening again.
 
Please any advice would be appreciated.
0 Kudos
Message 1 of 18
(5,998 Views)
Hi drichey,

Sounds like some very odd behaviour.  Did you have to make any changes to the example program you found on the DeveloperZone? Also, what version of DAQmx do you have installed?

 You did not mention what happens if you try to monitor only one counter.  Are you able to get one counter to work with one of the shipping programs that come with LabVIEW (Meas Angular Position-Buffered-Cont-Ext Clk VI would be a good example to try).


Message Edited by Hani R on 02-08-2008 05:10 PM


Best Regards

Hani R.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 18
(5,979 Views)

Thanks for the response.  This one has really got me confused and any help is greatly appreciated.

To answer your questions, no I have not modified the sample program and I'm using NI DAQ v8.5.

I've decided to break the problem down to see if I could find a pattern, but no such luck.  Here is the testing that I've done.

I'm making the following connections while using the sample program I mentioned earlier:

Counter 0...............PFI_39 (term 02) - Channel_A(0).................PFI_37 (term 40) - Channel_B(0)

Counter 1...............PFI_35 (term 07) - Channel_A(1).................PFI_33 (term 06) - Channel_B(1)

Counter 2...............PFI_31 (term 34) - Channel_A(2).................PFI_29 (term 66) - Channel_B(2)

Counter 3...............PFI_27 (term 31) - Channel_A(3).................PFI_25 (term 63) - Channel_B(3)

Note:  I connect the "Z" channel for gating purposes in my VB application, but this isn't required in the LabView sample program since the gating appears to be done internally.

My testing results:

1.  If I jumper my one encoder to channels 0,1,2, & 3 at the same time, everything works great.  Each channel reports the same number of counts regardless of whether I'm turning the encoder in the positive or negative direction.

2.  If I disconnect channel 3 and only have 0,1 & 2 connected, then 0 & 2 track perfectly, but channel 1 looses counts in the negative direction.

3.  If I only connect channels 0 & 1, then channel 0 counts perfectly in both the pos and neg direction, but channel 1 looses counts in the negative direction.

4.  If I connect any channel by itself (0,1,2 or 3), each one counts perfectly.

5.  If I connect channels 0 & 4, everything seems to be fine.

Like I said in my previous e-mail, if this hadn't already happened to me in a previous application, then I would chalk it up to a bad board.  If I didn't get good results on each individual channel then I would chalk it up to a bad encoder pulse train.  However, it definitely seems to have something to do with connecting multiple counters at the same time in a Motion Encoder Application.  I have read the 6602 User Manual backwards and forwards looking for a nugget of explanation, but have found none.  There was a section entitled "Counter Input Selections" on page 4-12 (table 4-2) that might offer some explanation, but neither me or my colleagues could understand what was being described.  Any help deciphering that would be appreciated.

As of now, I'm going to proceed with my application, using channels 0 &4 (just as I've done in the past), however I don't feel comfortable not having an explanation for the 6602's behavior.  Any insight would be greatly appreciated.

 

 

0 Kudos
Message 3 of 18
(5,960 Views)

Hello drichey,

I have been investigating this issue with an identical setup and I’ve been able to partially reproduce your results.  I’ve confirmed that connecting four counters:  ctr. 0, 1, 2, and 3 to the same encoder works correctly and that if I disconnect counter 3 then I get incorrect readings from at least two (if not all three) of the remaining counters (0, 1, and 2).

I know that on the PCI-6602 there is some internal pairing between counters 0 and 1, 2 and 3, 4 and 5, and 6 and 7 for making more complex measurements, and it’s possible they are interfering with your measurements.  Can you run your tests using channels:  0, 2, 4, and 6 the same way you did with 0, 1, 2, and 3?  I haven’t been able to verify that this pairing is the problem, but if you can confirm that it works or doesn’t work with these even numbered channels then it can help determine the cause of this strange behavior.

I will be looking into using one encoder for each counter to see if I can eliminate the input signals as the problem.  Please reply back with the results of the even numbered counter channels so that we can further troubleshoot.

Have a good night!

Brooks
0 Kudos
Message 4 of 18
(5,942 Views)

Thank you for showing interest in my problem.

I did what you asked and connected channels 0,2,4&6 to the same encoder input.  I tested in both directions (pos & neg) and didn't seem to have a problem when monitoring channels 0,2 & 4.  The counts were the same each time.  However, when I monitored 0,2 &6 I noticed that channel 6 fell short (in counts) each time in the negative direction.  It was fine in the positive direction.  (I DID have all four counters connected the entire time, I could only monitor 3 at a time because that is what the sample LabView program is set up for.  No big deal.)

I noticed in the 6602 User Manual that it made reference to the "counter pairs" you are talking about, but the manual does not elaborate about any conflicts that might occur between the channels.  I would appreciate any explanation you can provide for this behavior.

Thanks again.

0 Kudos
Message 5 of 18
(5,926 Views)

Hello drichey,

 

Can you tell me which example code you are using so that I can try it with the same code?

 

In my tests I was using the Measure Angular Position.vi example from the example finder (located in this folder: Hardware Input and Output> DAQmx> Counter Measurements> Position> Measure Angular Position.vi).  I copied this code 4 times on the block diagram so that I could read all 4 counters.  Using this I was able to replicate the erratic behavior you described, but I was losing more than just counts from one of the counters in one direction so I wanted to see if that difference was caused by hardware or software.

 

Please let me know if you are using the example Hani suggested, the example code you found on the forums, or something else.  If you are using the code you found on the forums can you provide a link to it so I can get it as well?

 

Cheers,

Brooks
0 Kudos
Message 6 of 18
(5,912 Views)
The example program I'm using is called  "meas-ang-pos-buff.zip".  I found it by going to Support and typing "6602 position measurement" in the search window.  It was the first article that pulled up.  I will attempt to put the link below, but if it doesn't work, then do the search I described above.  Thanks.
 
Here is the link:
 
 
0 Kudos
Message 7 of 18
(5,904 Views)

Hello drichey,

I was able to correct all of the strange behavior by connecting the ground of my quadrature encoder to the ground of my PCI-6602.  If this is your problem you should be able to correct it by connecting the ground of the quadrature encoder to any of the "D GND" pins on the PCI-6602.  Without this ground connection the signal from the quadrature encoder was floating relative to the measurement the 6602 was making and so the digital counts were erratic.

Let me know if this issue persists after making the ground connection.

Have a good afternoon!

Brooks
0 Kudos
Message 8 of 18
(5,869 Views)
Brooks_C,
 
Here's a real head-scratcher for you.  I hope you can shed some light on this (or at least recreate it) so I don't have to admit that me and NI boards have a "bad karma" thing going on!
 
I looked at my connections and verified that I DID have the ground reference from the encoder connected to PIN 36 (GND) on my TBX-68 board.  That being the case, I pulled up the sample program you stated that you were using (Measure Angular Position.vi) and verified that I was still seeing a problem.  My board was still wired up from our previous test, therefore channels 0,2,4 & 6 were connected.  As expected, the problem was still there.
 
I looked at the 6602 user manual and verified that PIN 36 was indeed a GND terminal and it says that it is.  For the heck of it, I moved my ground connection from PIN 36 (GND) to PIN 39 (GND).  Ran the test.  EVERYTHING WORKED!  Out of disgust I moved the ground connection from PIN 39 (GND) to PIN 41 (GND).  Once again, everything worked fine.
 
Since I really didn't believe what I was seeing at this point, I moved the ground connection BACK to PIN 36 (GND) and the problem reappeared.  I lost counts.
 
I left the ground connection on PIN 41 (GND) and tried the following channel combinations:
0,2,4,6 - WORKED
0,2,4    - WORKED
0,2,3    - WORKED
 
I don't understand what exactly could be different about PIN 36 (GND) that is causing a problem, but there is definitely a problem of some sort.  I guess it'll take a NI hardware expert to figure that one out.  What are the chances of me picking THE ONE "GND" terminal that wouldn't work?!
 
Please see if you can recreate the problem.  If not, then I can only assume that either the "planets are not aligned" or I have a bad connection on either my 6602 board or the TBX-68 board.
 
Thanks again for all your information and time!
 


Message Edited by drichey on 02-19-2008 10:07 AM
0 Kudos
Message 9 of 18
(5,853 Views)
Just a few brief thoughts:
 
1. Generally, I don't recall seeing differences in behavior based on which specific DGND I've wired into.  As a practice, I try to use one that is physically nearby the signal connection.
 
2.  Any chance that your encoders are generating a *differential* output rather than a driven, TTL-compatible output?  Some versions of differential output are partially compatible with TTL, such that they usually produce the expected behavior but can't be relied upon to do so always.
 
3. TBX-68?   ???    You're interfacing the 6602 to a TBX-68?   Are you sure?   I've never tried that, but I wouldn't expect it to be a good idea...
 
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 10 of 18
(5,847 Views)