Encoder Problems

[mwatkins]

Hi guys,
I have an encoder problem, and worst thing of all it only happens once or twice a week. We have two identical heat treat lines and only one is having a problem and the programs are identical. These lines run 3 shifts 5 days a week. So the Hoist runs quite a bit.
I did an upgrade over Xmas from PLC2's to SLC 5/04. The problem was there before the change out.
The Encoder sends out a 0-359 BCD signal that is going into a DC input card (Inputs 0-9.) Each time the encoder turns over I am counting up/down for the number of revolutions. Then length of the line accounts for 25 revolutions.
The problem is that it skips a count. The Hoist will be off one revolution when goes to pickup/drop off a carrier. Never in the same spot. Initially when we did the change out there was noise from the 480 to the hosit motor that was inducing about 7 volts on the dc inputs (really screwing with the signal count). We moved the encoder connections out of the junciton box where the 480 was and this fixed the "noise".
The cables for the encoder are shielded and I am not seeing the noise on the dc input lines. But can't tell if we are still getting some type of noise when the crash occurs.
One question I have is: is there a filter I can put on the DC inputs or something I can do so that the proceesor turn on voltage is higher than 10v and the turn off is higher than 5v?
Thanks for the help.
Mike

[mwatkins]

Another quenstion:
any ideas on how to do a comparision for reading the bcd value coming in to check to see if it is a "good read".
For example if the number jumped from 150 to 350 then flag as NG.
Thanks

[Steve Bailey]

You've been living with this for a long time, so forgive me if I ask some questions related to things you've already considered.

You say that the system 'skips a count'. Does that mean that when the hoist is moving in a given direction it moves beyond the desired stop position or that it stops short?

Is it consistent? By that I mean if it's moving in the forward direction it always stops short (or long) and when moving in the negative direction it always stops long (or short).

I would expect that if the problem was noise-related, the stopping error would be random, sometimes long, sometimes short.

At what rate is the data changing? Could you be missing transitions due to PLC scan time issues?

Are you using inputs 10 through 15 on the module for anything else? If so, have you masked off the upper bits of the word so that the other signals can't affect the calculations?

Do you ever see invalid BCD digits (bit patterns 1010, 1011, 1100, 1101, 1110, 1111) in any position? That would be an indication that noise is a problem. It's also something that you could program an internal latch to detect, so you don't have to be in the right place at the right time to detect.

[mwatkins]

The hoist is off by one revolution and it can be in either direction.
it is not consistent.
I send a read signal to the encoder that I keep on for 30 ms then off for 100ms then I read the input.
No other inputs are tied to this card.
It only happens once or twice a week.
I don't work for the company I was hired to replace their PLC2's and write the program. I am doing this troubleshooting as a courtesy. I would like to have the system running free of problems when I leave.

[Shaun]

Just wondering you said the two programs are identical.
But each has their own set of wiring.
Have you check to see if both sets of wiring are identical and have rung them out,
also one of the bit connections maybe a bit corroided or slightly loose.

It would be nice to know if this problem is happening at the same machine location.

cheers,

shaun

[Steve Bailey]

any ideas on how to do a comparision for reading the bcd value coming in to check to see if it is a "good read".

Rung 1: Difference = Current_Value - Previous_Value

Rung 2: If Difference is negative Then Difference = Difference + 360

Rung 3: If Difference > Allowable Then Set 'Bad_Data' Flag

Rung 4: Previous_Value = Current_Value

The above is for forward travel where the BCD value is increasing. You'll need to modify it for reverse.

[mwatkins]

Can someone recommend a filter?
Thanks

[Steve Bailey]

Are you sure that all ten inputs are good and that all ten outputs (from the encoder) are working?

For example, if input 01 on the card was bad, or the encoder wasn't sending that signal, the count progression in the least significant digit would be 0, 1, 0, 1, 4, 5, 4, 5, 8, 9.

What does the 'read' command cause the encoder to do? Is there an 'acknowledge' signal from the encoder to indicate that it received the 'read' command?

[mwatkins]

The 10 inputs to the PLC are good and so is the one output.
Normally everything is fine. The count is correct except when the hoist is off station which is only happening about once or twice a week.
There is no acknowledge signal. The "read" commend basically tells the encoder to update its position then send a BCD value out. I am waiting 100 ms before I read that BCD value to ensure there is a settling time for the encoder. The manufacture recommends a minimum of 3ms.

[Pierre]

My 2 cents.

NEVER count when your are energizing or de-energizing the Breaks.

Add a few lines to your program to freeze the count for a very short time when your putting the break On or Off.

This could be it... or maybee its not.

[mwatkins]

Thanks Pierre
I already have taken care of this.

[Steve Bailey]

Is it possible that the encoder could have turned more than one revolution between 'read' commands? If I'm understanding the system correctly, you're keeping track of the number of revolutions inside the PLC. You're asserting the 'read' signal for 30 mS, waiting another 100 mS, then asserting the 'read' signal again, etc. What is the maximum travel expected during that 130 mS?

Would it be possible to command the encoder to continuously update and turn it very slowly to see if there are any shaft positions that cause problems? Could you swap encoders between the two lines to see if the problem follows the specific encoder?

[mwatkins]

The hoist is very slow moving, the motor actually goes through a recuction gear. It takes the encoder 3 seconds to do one revolution.
I have already put on a spare encoder.
I don't see anything different if I hold the encoder and turn it by hand and if it is running in auto.
This only happens 1 or 2 times in a 120 hour period. And the hoist is always running except when going up or down.

[bernie_carlton]

Please post what your current algorithm is to determine that a revolution has completed going either direction. This may generate more ideas. I'm not suggesting that the code may be faulty (obviously it's working fine on one line and most of the time on this line), it's just that it may help focus the suggestions on one area. I assume from your description that the position within the revolution is correct, just that the number of revolutions completed is +/- 1.

[Eric Nelson]

Check out THIS POST from Kim Gold (as well as that whole thread). This may be a better "fix" for your problem.

beerchug

-Eric