PXI-6123 counter connections

[brendel2]

Good afternoon.

As a labview novice, I apologize in advance for any poor communication on my part.  But, after scouring the discussion boards for a day and a half, I thought it time to post my situation.  Thanks in advance for any help/discussion.

Hardware:  PXI-6123

The setup:

Coming from an encoder on an electric motor I have 6 wires that carry 3 signals.

1)  A and A_not

2)  B and B_not

3)  Z and Z_not

The potential across A and A_not is a square-wave of +/- 10V who's period ocurrs 1024 times per motor revolution.

The potential across B and B_not is also +/- 10V and it's 90 degrees out of phase with the A signal

The potential across Z and Z_not is at -10V for the majority of the motor's rotation, but sends a +10V square signal briefly once per motor rotation.

(i.e. pretty standard encoder signal)

Problem:  I'd like to use the counter to process (RPM, angular position, etc.) these signals, but they are not in a TTL format.  The best I can do at the moment uses an external ground as a reference, such that the A signal moves +/- 5V relative to this ground.

The PXI-6123 card specs call for a 0-to-5V signal for its counters, and I'm worried that the -5V will damage the card.

I understand that I could bring in these square waves at analog signals, convert them to digital, and then use the counter to process the digital.  Is this the way to go?  The sampling rate associated with this conversion would have to be relatively fast in order to resolve the square waves, could this sampling/conversion process work separately from the sampling and recording of the other analog inputs?  I am recording 5 other analog inputs while the motor is rotating, and it would be undesirable to have to record these signals as very high rates.

So in summary, the big picture is:

-I have a +/- 5 V encoder signal from which I'd like to record the angular position of a motor.

-recording this angular position, in conjunction with other analog inputs, should not have to occur at very high sampling rates

It seems inputting the encoder signals into a counter is the best option.  Expect for 1 snag: I worry the -5V bias will damage the board.

Thanks in advance!

-Mike

[Paul-D]

Hi Brendel, this is Paul with Applications Engineer at NI.

You are correct that your card only supports 0-5V aka TTL counter inputs.  Only our industrial cards support the higher voltages.

There are a couple of ways we recommend to work around this, the first is to use a Schmitt Trigger to bring in your signal, and then convert it to the 0-5V you need.

The second is to use the analog triggering on your card to perform an analog comparison event, that I'll let the following links describe better than I can.

Explanations:

http://digital.ni.com/public.nsf/allkb/771D82A44F27A0AF86256DD0007FB9A1

http://digital.ni.com/public.nsf/allkb/39DF4F9A6F285E7986256B58006FC129

A forum post with a good discussion about it:

http://forums.ni.com/t5/Counter-Timer/Measuring-frequency-of-non-TTL-pulse-train-with-counters-on/m-...

And, some example code to look at:

http://zone.ni.com/devzone/cda/epd/p/id/2555

Let us know if you have any further questions.

Thanks,

Paul

[Kevin_Price]

You have an encoder that puts out differential signal pairs while you need single-ended TTL for your data acq board.  One way to convert them is with a "line receiver" chip/circuit to convert differential to TTL.  (This should happen close to your data acq terminal block rather than near the encoder).  There are others ways too.

Here's a link to a converter board I've personally used a couple times in the past, but you'd need to make sure it's compatible with the signals on your particular encoder.  There are cheaper ways to build a conversion circuit if $ are a bigger issue than time.  It's possible that your use of only the +A, +B, +Z outputs along with a digital ground reference could work, but that would

depend on a bunch of stuff.   All in all, it's safer to do the conversion properly than to just hope for the best.  A few dollars today often saves a lot of frustrating hours of troubleshooting later.

-Kevin P