pci 6132: counter too sensitive?

[Frank_Mathijs]

I'm using the pci 6132 to sample a microphone, with analog triggering on that same input channel.
At the same time, parallel, I need to follow an index of a conveyor belt on which the samples move, so I can track which mic signal corresponds to which sample.

It seems that because I'm using a trigger on the analog inputs, I couldn't use CTR0, so I'm using CTR1 (on PFI3) to track the conveyor steps.
The problem is that this counter is _very_ sensitive. I count 4-9 edges where there should have been one. so I had to implement code to check the timing of the steps and to manually increment a variable, instead of using the counter output directly.

The device doesn't support 'digital filter', I already tried adding capacitors to the hardware to clean up the signal of noise, see attached image. Not much or no improvements though.
I have the same results in MAX-testpanel.

Is there a way to configure a hysteresis, or any other option to control the counter better? Am I making another mistake? Or is this card just not suited for the job?

[johnsold]

I do not know anything about your particular card, but the falling edge of that signal is much slower than the minimum slope requirements for many logic device clock inputs.  It looks clean but undoubtedly takes a microsecond or so to pass through the transition region rather than a nanosecond.

I think a simple Schmidt trigger device will clean up the signal enough to avoid the multiple counts.  Look at the 74xx14 type devices.

Lynn

[Frank_Mathijs]

The slow edge was a result of me adding a capacitor, in an attempt to clean up the signal.

I removed them, and now I get a little better results, only once every 10 (falling or rising, seems to make little difference) I see the counter count multiple edges for only one step of the conveyor.

In the attached image, the signal without capacitor, you can see now in the rising edge a little downward spike, right before the edge starts. This was the reason I tried the capacitor. But given I have the same problem for rising or falling edge, my problem might be something else.

In the basic LV-example, there is a 'wait until multiple' in the while-loop, and this seems to work, or at least give a lot less miscounts... I'm confused by this, I thought the counting happened on the device and the while loop only 'asks the counters value every iteration'.

So how can a 'wait' in this loop help avoiding the multiple counts?

Btw: my connection is as follows: 24Vdc signal comes from the conveyor, into an optocoupler. The optocoupler is connected to PFI3, with +5V and a pulldown resistor to DGND (see second image)

[crossrulz]

I'm with Lynn.  I think you want to use the capcitors and a schmit triggered buffer.  This should give you a nice clean edge.

[johnsold]

Standard optocouplers are much too slow to connect to standard logic clock inputs.  Look at your rising and falling edges with a good oscilloscope and see what the rise and fall times actually are. Many logic devices require clock edges to be faster than submicrosecond rise and fall times.  It is very rare for a transistor output optocoupler to be that fast.

Lynn

[AnalogKid2DigitalMan]

I use the Avago HCPL series of high speed opto's quite often for counter/timer DAQ isolation, I think the rise/fall times are in the 10's of nanoseconds.

-AK2DM