Counter Output/Counter Input PXI Signals Behaving Erratically

[testdesign]

Question for all your LabVIEW guru's out there,

I am running a frequency loopback test using the NI PXI 6229 MIO DAQ card.  I am generating a "Counter Output" pulse train signal which feeds through my device under test and then back out of my device under test and back into the PXI 6229 for a "Counter Input" frequency measurement.  Both the "Counter Output" and the "Counter Input" are assigned different PFI lines using DAQmx in LabVIEW.

I have 4 lines to test on my DUT.  All four lines run this same frequency measurement but with different PFI lines on the PXI 6229.  Each line is test independently.

This is my setup for the 4 lines:

Path 1: P2.0 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.1 (Counter Input - Frequency Measurement)
Path 2: P2.2 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.3 (Counter Input - Frequency Measurement)
Path 3: P2.4 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.5 (Counter Input - Frequency Measurement)
Path 4: P2.6 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.7 (Counter Input - Frequency Measurement)

where:
P2.0 = PFI8
P2.1 = PFI9
P2.2 = PFI10
P2.3 = PFI11
P2.4 = PFI12
P2.5 = PFI13
P2.6 = PFI14
P2.7 = PFI15

I have a LabVIEW VI which generates the "Counter Output" and reads the "Counter Input" frequency.  I am seeing weird behavior from the PXI 6229 card. I can test "Path 1" and "Path 2" and the frequency I read is what I generated. No issue there. However, when I test "Path 3" and "Path 4" the frequency measurement is erratic.  The readings are two different frequencies repeated over and over again and none of those frequencies are the expected frequency which was generated out of the "Counter Output."  If I reset the card, and start by testing "Path 3" and "Path 4" the frequency readings are correct and the erratic behavior is gone.  However, when I try to then test "Path 2" and "Path 1" now those lines have the erratic frequency issue. I can continue resetting the card and see same issue. The PFI lines that I test first will always pass.

To summarize:

Steps Taken:
1. Test Path 1 = SUCCESS
2. Test Path 2 = SUCCESS
3. Test Path 3 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
4. Test Path 4 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
5. Reset the PXI 6229 Card
6. Test Path 3 = SUCCESS
7. Test Path 4 = SUCCESS
8. Test Path 3 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
9. Test Path 4 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)

I am wondering if Port 2 (P2.0-P2.7) on the 6229 card has certain dependecies and this is why I am seeing issues.  I am trying to get around this issue so that I don't have to always reset the card.

Are P2.0-P2.3 (PFI8-PFI11) and P2.4-P2.7 (PFI12-PFI15) treated differently or require different setup?  How do I resolve this issue?

Thanks so much!

[John_P1]

I have a theory...

The DAQ card follows a policy called "lazy uncommit" wherein the terminal used for the output will continue to be connected to the counter even after the task has completed (until the terminal is needed for something else).  So as you run more tests, the counter output will end up driving more lines.  This behavior should be easy enough to confirm.

As the DAQ card drives more lines, I'd imagine this affects the actual signal.  You could scope it to check, but it sounds like either the rise/fall times are becoming longer or some extra noise is being introduced on the line.  

---

The readings are two different frequencies repeated over and over again and none of those frequencies are the expected frequency which was generated out of the "Counter Output."

---

This implies you are picking up an extra edge during transitions--this isn't too uncommon if the signal is noisy since there is no built-in hysteresis on the DAQ card.  I would expect the measured frequencies to have periods that sum to either the full period or the semi-period of your actual signal (depending on how many duplicate edges are detected).

Suggestions are as follows:

To stop the DAQ card from driving multiple PFI lines, it would probably be easiest to just programmatically reset the device in between your tests (using DAQmx Reset Device).  If you can't reset the device (e.g. because you are running some other task that can't be interrupted) then you can instead configure a dummy task that uses the PFI line in question as an input.

To stop the DAQ card from picking up multiple edges during transitions, you should configure a digital filter on the input terminals.  If you reset the device it sounds like this might not be necessary... it's up to you if you want to configure this or not.

Best Regards,

[testdesign]

Thanks John.  That give me a better explanation of what could be the cause of it.  I noticed that both "resetting the card" and "setting port 2 lines all = 0" resolve the issue I was seeing.

Does NI have any plans on resolving this "lazy uncommit" issue?  I would assume others see this issue as well.

[John_P1]

Setting the lines to 0 will work --anything that uses the line for a different purpose than the counter output task will disconnect the counter.  There is actually a DAQmx Tristate Output Terminal call that I forgot about that could put the line into high impedance (which is the factory default power-up state after a device reset).

I can't speak for NI, but I wouldn't expect "lazy uncommit" to go away.  Removing it would slow down certain applications.

Best Regards,