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 (http://www.plctalk.net/qanda/showthread.php?postid=11533#post11533) from Kim Gold (as well as that whole thread). This may be a better "fix" for your problem.

beerchug

-Eric

[mwatkins]

Here is the encoder read and counting part of the program.

[Steve Bailey]

I'm tending to agree that it sounds like noise.

How about a modification of my earlier pseudocode that compares the current value to the previous value and doesn't allow you to use a new value until it has been stable for some period of time.

Rung 1: If Current_value = Previous_Value Then Enable Timer;
Else Reset Timer

Rung 2: If Timer.Done = True Then Set Valid_Data Flag;
Else Clear Valid_Data Flag

Rung 3: Copy Current_Value to Previous_Value

[mwatkins]

I will try and modify the program.

Can you recommend a noise filter for a DC signal that will block AC?
Thanks

[Prince]

In communication circuits whenever they wanted to block AC and let the DC go they use a Big coil and that will work.

In DC regulation when they want to work with noise out they use a capacitor between the signal and the ground (it might work as you are not using a fast I/O)

I did have a problem with Industrial noises working on a relay driver circuit I used the second and it decreased the problem but did not solve it. I detached the grounds and that was the answer !

can't you just separate the encoder working ground from the plc ground ?

Regarding the first question of 5v and 10v If I were you I would use an optic Isolator (eg TLP521 or cny17-1 There surely must have been industrial devices you can use instead of making circuits) and bios the sides differently regarding my desired voltage.

I have another suggestion ? can't you use an encoder equipped with a differential signal level communication instead of directly connecting it to the plc ?

P.S : Sorry for my English

[john paley]

My 2 cents on the whole thing:

Everybody's talking about the encoder losing a count. That's not happening--the logic is losing a count. This is a 0-360 degree encoder simply reporting position. If i understand, you're not losing a count(s), but a full revolution.

I would keep a running total of encoder revs by sensing for rollover:

FORWARD

IF INPUT < STORE, ROLLOVER =1
IF ROLLOVER =1, count = count + 360
COUNT= COUNT + INPUT
REVOLUTIONS = COUNT/360
MOVE INPUT TO STORE
ROLLOVER = 0


REVERSE

IF INPUT > STORE, ROLLOVER =1
IF ROLLOVER =1, count = count - 360
COUNT= COUNT - INPUT
REVOLUTIONS (POSITION) = COUNT/360 (FLOATING POINT)
MOVE INPUT TO STORE
ROLLOVER = 0

The obvious question--Are you sure the encoder turns with the process--all the time--can the mechanical connection be compromised???

I just thought of another--Can the hoist slip in the fwd direction a little while reversing--because of load, perhaps. Is the action "jerky"?? This could screw up my method no end--possibly causing one true rollover to be counted as two, and all of the sudden you're one rev off. Look at those brakes again. Does the hoist bump fwd before the motor kicks in when starting to reverse?? If it moves fwd when the controller expects rev, or vice versa, miscounts can, and eventually will, occur. It all depends if it slips near a rollover point.

It sounds like you've got one system that works very well, so you know how to do it. But the other system has some "pesky" problem that compromises your method. Look for mechanical and/or wiring things to find the culprit.

That's just my opinion--I could be wrong!

[BobB]

It may be a noise problem. Further to the other suggestions mad so far, you say you have a screen on the cable to the inputs. Questions. Is the screen only grounded at 1 end, preferably the PLC end? Grounding at both ends can cause all sorts of problems with noise. Have you considered using a different device in addition to the encoder to check revolutions? In critical applications I normally use a PE or prox as a check on the revolutions only - not the actual count. You can simply use a self resetting timer that is started when the crane moves with a diff up trigger on the output to MOVE data from a register to a second register. Then MOVE the current count to the first register. Compare with a known BCD value you would expect to see in the time frame of the counter. You can get very fancy and put in a dead band, you can also use maths commands to extract the exact count if you have rotated past zero. You can use long compares and add the number of rotations into the equation as well. If the compare does not compute you have a problem.
I am presently doing a similar thing with an absolute encoder on Device Net and using the "stuff the figures into words and compare" technique to determine that 1) the encoder is working and 2) that the values are within a settable dead band. If not, stop the crane. The main difference is that the absolute encoder gives me real BCD figures across the Device Net network. The principle is the same.
If I can help, contact me Bob Bishop (bobbishop1@optushome.com.au) beerchug