encoder error

[PaulG.]

I am writing some encoder test software and appear to be getting a +0.01 degree error per degree. It cumulates up to 360. I am using a US Digital AD4-8 that outputs hex. Even the out-of-the-box vi that came with the AD4 is giving the same error. I'm stumped. Encoders don't have settings. And I've been all over the documentation and don't see anything I might be missing. Ideas? Thanks in advance.

[dstrandb]

Hi PaulG,

Have you taken a look at this KnowledgeBase article, which goes through several good troubleshooting steps for encoder errors? Does US Digital provide any sort of testing program (other than the VI) that would allow you to monitor the encoder counts while the motor spins?

[PaulG.]

None of the info in the KnowledgeBase is helpful. This is a fairly standard plug-and-play hookup. What I can try I have: x1 x2 x4, index off, reset, index on, etc. The documentation says nothing about resolution or accuracy settings. I'm using the serial output via a vi. The US Digital VI's use calls to dll's and give the same slightly off output. If my numbers were entirely screwed up I would be less frustrated. But the numbers are only off by just a *little*. Consistently off just a little. But just enough to make the test worthless. Rats!

[Highland_Controls]

Is that error growing in one direction?  Do you lose counts if you go the other direction?

[PaulG.]

Yes. Both directions. If I increment -1 degree 360x or +1degree 360x same error. By the time I get to 360 (by my test stand) the encoder under test is giving me about 364. It's not speed related or mechanical slippage. I'm already running at the lowest speed possible and the error is too consistent to be mechanical, although I did tighten everything just to be sure.

[Highland_Controls]

Quadrature encoders only know counts, so where is the conversion to degrees happening?  Can you read counts instead?  Start at a known position, query for counts and set to zero if needed.  Then move 360 degrees and query for counts again.  What is the resolution of the encoder?  Is it connected directly to your device that is turning?

[PaulG.]

After some head banging I came to the conclusion that 360 degrees on my test stand = 364.05 on my "standard". So I'm taking the raw degrees count on my standard, dividing by 364.05 and subtracting from my test stand output. The readings are very close, about +/- .02 from each other. My problem: I will certainly take it, as our limit is +/- 0.03. Where does this 364.05 per revolution come from? I was expecting 360. Admittedly my experience working with encoders is more technical (hardware) so I'm a little confused. I hate using "fudge factors" unless I absolutely understand why I need to use them. Any insight would be helpful for a sanity check.

[dstrandb]

Hi Paul,

Do you have a manual for the encoder? I've been looking online, but I've been unable to find one so far. I'd be interested to see if the manual says anything about the encoder resolution, and potentially where this factor might come from.

[PaulG.]

The encoder standard is a BEI Motion systems model 5VL679LS. It's ancient and I can find no documentation on it. The adapter is a US Digital AD4B which is based on a LS7166 24-bit quadrature counter. Nothing fancy here. I've been all through the 7166 data sheet and can find nothing on resolution settings. There is a settable offset but that just offsets the output.

[PaulG. · Accepted solution]

Had to dig deep into some old code to figure this out. Buried deep, deep in the old code a counts per turn constant is getting set differently than the way I'm doing it. My way is wrong.  My value for the constant was wrong. Must have been close in a roundabout way ... that's why the funny offset ... had to dig deep, deep into old documentation to get the correct value.