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.
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.