Encoder Count Drift

marcwand

Member
Join Date
Oct 2007
Location
Istanbul
Posts
24
Hey Guys,

So I have done a bit of searching around, and I am sure that this is a problem that has been discussed in the past... but either it is so complicated that everyone knows to just work around it, or the solution is so basic that everyone (except me) knows how to deal with it!!!

I have seen a number of encoder installations used for positioning. timing, measuring.. incremental and absolute... mechanical, optical, high speed counter cards, and encoders that operate over devicenet...

In theory they seem to be infallible in their design and operation. However I am finding that each encoder application that is used for positioning here on site has a problem with the count drifting in relation to its physical machine position.

Here are a few examples -

Installation #1
AB Incremental Quadrature 1000 Pulse Encoder mounted on a shaft that moves slowly clockwise and counter clockwise. On one end of the chain is a counter weight, and on the other end is essentially a belt driven conveyor that is fixed on one end. Rotating the shaft / sprocket that the encoder is mounted to raises and lowers one end of the conveyor to position for loading. The encoder is wired into a 1747-HSCE card, count is scaled to mm position in PLC logic.

Problem:
Once encoder position is referenced, within about 3 days worth of positioning (1000 positions) the conveyor, I will find that my position as determined from the encoder is about 50mm higher than the physical position of the belt. This would occur without any power loss to the PLC, or any other interruptions that would cause an error in count. The error happens steadily and cumulatively over time until positioning is such that a positioning fault is alarmed.

Solution used:
Preset the HSC card automatically with a known value when a known field device is triggered. Basically automatically rehome the conveyor every now and then.

Installation #2
AB 842D Absolute Encoder on DeviceNet mounted to a rotating crank stacker arm assembly. The encoder is mounted on the central drive shaft of the crank and is scaled to give me 0 - 360 degrees depending on crank position. The DeviceNet is part of a SLC 500 rack.

Problem: After time the value coming back to the PLC over devicenet is physically out as compared to the physical position of the crank. An error of +/-10 degrees or more will cause problems with the stacking action. The connection between the encoder and the crank shaft is solid.

Solution: Operators to manually put the stacker arms to the zero position, then reset the count via a PB on the panelview and some explicit messaging to the encoder.

Installation #3
Same as #1 really, except AB incremental encoder wired into a 1756-HSC card located on the main rack.
Problem: Encoder count drifts, Though at a much slower rate than the encoder on the 1747 Rack.
Solution: Operators rehome position of machine hoist.

I have more examples of this, but they are basically the same issues seen in #1 and #3 as described. I have checked the physical wiring / shielding of the encoder cables and am satisfied that they are free from electrical noise or ground loop interference.

We pay a lot of money to use the right gear for the right job, and these devices are designed to monitor the rotation of the encoder and to provide repeatable and accurate readings. In theory I should not have to put positioning routines through a rehoming sequence because my count is drifting, but it seems like I have to.

In my simple mind six AB pulses one way should be the same as six BA pulses the other... And with the DeviceNet encoder, it is a 26bit absolute encoder and should scale its 0-360 degrees on that 26bit absolute value that is determined within the encoder itself.

Has anyone else seen this?? Can anyone explain why this occurs over both 'Hard Wired' encoders and 'Networked' encoders??

I have always managed to work around this, but this has become quite a pet peeve of mine and I am looking for answers!!

Thanks for any comments in advance.

 
In theory they seem to be infallible in their design and operation.
Correct. They are infallable. Loosing counts is unacceptable. You need a scope. The signals should be nice clean square waves at 5 volts.
Power supply too low? Unshielded cables with severe noise? Improper coupling causing slip?
Old units with weak LED's?
Oil getting in the optics?
Forget DeviceNet. That's not the problem.
 
Last edited:
Yeah, I have had the basics checked... On most of the encoders out here they have wired them in 4pr individual and overall screened dekron cable with the shield earthed at the PLC end. Encoders have been replaced with little to no improvement. Power supplies are powering encoders only. I do not like the couplings however... silicon rubber hose and a couple of hose clamps... blech!!

Regarding the DeviceNet encoder, it is an AB moulded cable of which I have no control over... There would be nothing to check other than the integrity of the DeviceNet network structure to verify that it is set up properly. I would expect that if for example the devicenet power supply was not correct for the job, or if the network was not properly shielded I would see other devices dropping off / faulting out / etc... you know.. standard DeviceNet problems... maybe that particular encoder is faulty and I am just lumping all of these issues into one big pile..?

If I ever get some time to do the things that I should be doing instead of running around with my head cut off trying to meet production requirements I will put one of these encoders on a scope to see what I can see.

It is just one of those things that is working enough to be considered by most out here to be working fine.. but nags me while I am trying to do more important things... like drinking beer!! haha..
 
I do not like the couplings however... silicon rubber hose and a couple of hose clamps... blech!!

This. Start here.
Get real couplings, AND make sure the encoders are properly lined up to what they are connected to.

Remember, couplings are really NOT intended to fix misalighnment.
 
I have seen this due to slippage, wear, or some mechanical change in your system. Most will go to home position every day or shift change and set the preset and save this to EPROM of the encoder. If the DeviceNet encoder data is not set-up correctly, you should see that your data is slightly off everytime through and possibly at the same location.
 
Yeah, I have had the basics checked... On most of the encoders out here they have wired them in 4pr individual and overall screened dekron cable with the shield earthed at the PLC end. Encoders have been replaced with little to no improvement. Power supplies are powering encoders only. I do not like the couplings however... silicon rubber hose and a couple of hose clamps... blech!!
Those aren't couplings. I done used the Google to look for encoder couplings and didn't find nary a one that used rubber hose and hose clamps--go figure! I suggest y'all replace those with something more appropriate like duct tape.

--your friend bubba

P.S. Make sure y'all use the good duct tape, you don't want this to fail because you went with the cheap tape.

🍻
 
How do you scale the encoder counts into positions? I bet you have a problem with irrational numbers.

As Peter has suggested, are you doing any scaling with the encoder data?

If you are please post what you are doing.

An enoder should never loose a pulse unless it is damaged. Now if you are "massaging" the data then this could be an issue.

Also when you are doing the positioning. Do you use actual when you head back to start or do you use a simple math function.

If you are using a high count encoder and moving real slow then you will see bounce. Especially if you are using a rubber hose for a coupling.
 

Similar Topics

Hi, I'm programming in RSLogix 500, and I'm wondering how I would program a Jog command that does not increase the encoder count. Basically we'd...
Replies
3
Views
287
Hi Everyone! i'm a newbie to PLC And i have a question, How do i count pulses from a encoder giving positional feedback? my plan is to use this...
Replies
5
Views
1,649
Hi everyone! My name is Vidy, I am having a problem whereby I was wondering on how would I go about trying to program using ladder logic to get...
Replies
2
Views
2,056
Have a machine we recieved for evaluation that is from Italy that has a compact logix 1769-L24er plc. It has a high speed counter that has a...
Replies
6
Views
3,732
Dear All, I have point IOs 1734-ib8 which is connected by an encoder resolution is 600 only but after using it losses count can any one idea how...
Replies
7
Views
2,256
Back
Top Bottom