Quad Encoder distance reading has too high error

[gregbosma]

I've written an MC024-120 program for a quadrature encoder to track the feeding of a hose. Any ideas why the amount of error in one direction is different from the error in the opposite direction?

To test it, I've put together a prototype, fed out 20 feet of hose, and brought it back to the zero point. While testing, we noticed the measurement on Service Tool is short by half an inch while feeding out-- fairly acceptable. After retracting the hose back to the zero point, the Service Tool showed the hose was still sticking out by 6 inches! 

Attached is my counting method on the programming side-- essentially adding QuadCount to the current total count, with a method of zeroing. To convert this count into a distance, I'm using a "Scale" function that references known values (# of pulses at 10 feet).

For hardware, the encoder is on an idler wheel that rides along the hose. The encoder reads 250 pulses per revolution, at approximately 5.125 inches per revolution. The hose can travel at anywhere between 0 and 3 ft/s using a motorized feed system.

Any ideas why the amount of error in one direction is different from the error in the opposite direction?

[FluidPowerTom]

Could the mechanism be slipping on the retract?  I'd recommend testing this by uncoupling the encoder and turning it's shaft 20 or whatever turns in one direction and back, and then try it for the other direction.  That way you'll know for sure it isn't the mechanism.

Is this issue consistent after multiple tests?

Could something be triggering your zero or calibration routine?  Maybe have either of those routines set a latch so that you'll know if they're going true for even one cycle.

[gregbosma]

@FluidPowerTom, thanks for the suggestions!

Slipping is definitely a possibility-- the encoder's in an awkward spot so I'll see if I can get a mirror or camera pointed at the right angle and catch that.

The issue is somewhat consistent after multiple tests-- it seems there's always some unacceptable amount of error between 3 and 6 inches after retracting back to the zero point. With that wide of a range, I'd suspect an intermittent fault-- some counts not registering properly (due to speed?), or slipping as you mentioned.

While I'm checking for slipping, I've updated the service tool with the latches you suggested. With the amounts of error I'm getting, the probability of this being a root cause is low but I won't ignore it!

[G30RG3]

Hi,

I've seen you've set your pinconfig.range to 1.  I'm not sure, but I think I had a similar issue a while back and solved it by setting the value to 0.  If you don't need the voltage elsewhere in your program, I would suggest to try with the standard range, even if the voltage goes outside the 5V. 

b.r. G30RG3

[gregbosma]

@G30RG3

I can try changing the range, but I'm unsure it'll help... I'll post again with the results.

I've read my encoder signal on a DAQ and saw a square wave with some overshoot/oscillation on each rising edge. I'm worried the oscillation will cause extra counts if my digital thresholds are too low.

[G30RG3]

In that case, I would set the DigThresLow as low as seems stable (as long as all counts are made and a small margin and you're good).  The DigThresHigh at 5000 or higher. Your oscillations won't be catched as extra counts if the signal doesn't go under the DTL.  2000 and 12000 might be better than your current values

[acmall]

I have not used a quadrature encoder but I have several applications that use hydraulic motors with a pulse type speed sensor on 24V. These particular ones work reliability for me on the 5.25V range with default Thresholds and Bias 2 (Pull Down). As G30RG3 has said the overshoot and/or oscillation should not cause an issue as long as it does not cross both the upper and lower thresholds.

There is a document called Input Configurations PLUS+1 Controllers, you can find it by searching for 520L0931 on the Danfoss website. It has not been updated since 2013 and some of the information is out of date but, it states the following under the Quadrature Encoder section: -

Configuration should be set to 5.25 Volt range. This is necessary for proper operation as a digital input.

It might also be worth checking your encoder documentation to see if you should set a pull up (Bias 1) or pull down (Bias 2) on the input configuration.

I have also seen issues were there was a long cable run and the cables were not properly screened or the screen was not properly terminated.

[SJ Industries]

I am definatley new to this so i may also have done something wrong, i have used an encoder dial for a controller input in place of a potentiometer, i found that i could not get accurate results using the inbuilt quadcount function, it would miss pulses, as it is a hand dial I could only do a max of 100rpm by manufacturer specs, generally much lower in reality, down to one pulse increments. I still used the same 2 pins and just set them too a straight digital input, I then wrote a program to use them to add on to or subtract using the logic on the truth table to determine direction. It works well without loss of pulses, the freq input still works too, i used that as a multiplier to enable fast wind up on the output. I think under a certain frequency or rpm the quad count does not work. An encoder with a higher pulse rate might work.

[oiltronic]

Similar problem on a hose machine was because the hose was allowed to retract way faster than being pulled out, missing pulses.  A different power-drive large hose reel would not wind the hose consistently, depending on the pressure inside the hose, ambient & hose temperature, whether the hose was wet or dry, and the way the hose was wrapped on the drum.  Encoder was only accurate to know when the hose was fully extended.