Linear Quadrature encoder on USB-6210 not reading properly. What am I missing

[DeOdderKeith]

I have a Celesco PT150-0050-111-51X0-7803 Linear Encoder with Input A connected to PFI0 and Input B connected to PFI1.

I'm reading the ctr1 and getting values, however, it wouldn't operate consistently.

The Count value seems to be a function of how fast I move the actuator.

I've attached the VI here.

It was adapted from the provided example for Encoder Reading. But I'm guessing that I need to add some kind of clocking mechanism?

Any suggestions?

Keith

[Kevin_Price]

What are you expecting?

Counters count.  If you move the actuator faster, the count will change faster.   Beyond that, you'd need to give us more details -- what you're aiming to do, what's happening instead, and be specific about the kind of data you want to collect.

-Kevin P

[DeOdderKeith]

1.  Is this a valid setup with A on PFI0 and B on PFI1?

2. When I extend the device I see the values counting up and allowing the device to return it ALMOST goes back to zero. This "almost" seems to be dependent on the speed I allow the device to return to the assumed zero position.

3. Here is my code...

[Kevin_Price]

Most modern-era devices with counters provide a *lot* of flexibility for assigning PFI terminals to use for different functional purposes.  (Internally, this means lots of available signal routings, as can also be seen in MAX).   If DAQmx isn't throwing an error when you config A on PFI0 and B on PFI1, then I think it's safe to assume your device supports those routings.

You're configured for "2 pulse counting" which is relatively unusual.  Are you sure that's right?  It's much more common for an encoder to produce quadrature output.

Under 2 pulse counting mode, an encoder that's actually quadrature will cause the count to "flutter" back and forth between 0 and 1 (or 0 and -1).  Every A edge counts up and every B edge counts down.  On an out and back move, you might get 1 extra A edge each way and end up with a total of 2 counts off from 0.

-Kevin P

[DeOdderKeith]

My original code used X1 instead of 2 pulse counting...

The encoder is an extender cord with some type of retractor (spring I'm assuming)

I thought that when I extend the cord it would count UP, and when it retracts, it would go back to zero.

But this one doesn't do that. Sometimes it goes down to some value close to zero, but not consistently, and not always...

Sorry for the clearly fuzzy description

KM

[Kevin_Price]

Once you bring those mechanics into it, then failure to return *exactly* to 0 might also be a mechanical issue.  Gear backlash can do this, friction can do this, a cord that unwinds and winds on its spool in a slightly different pattern can do this, a cord that can stretch a bit under tension can do this, and so on.

-Kevin P

[DeOdderKeith]

Turns out the answer to all of this angst was to add Filtering !!! 

By adding the filters to both inputs, the "noise" was removed...

KM