encoder blues

Hello all, About 6 months ago I was attempting to wire and program an encoder to a plc. I ran into some snags. The card was taken from the TEST bench when we actually needed the card for a piece of equipment and I haven't really had a chance to hook up another one. At the time I was using a PLC5 and 6200 software (dont ask). The encoder was 1200 counts per rev. So... I was able to get the counts into the data table. I believe somehow or another I was moving them to an integer file. I then did some math to say IF equal to 1200 then reset to Zero. I then used another counter to count how many times I was at 1200. The reason for this was... I figured to kind of emulate IF one revolution translated to say 2 inches linear, and I wanted to move something 6 inches, I would need to keep track of the revolutions. The problem I had was this was not accurate at all. One thing I did notice was
if I turned the encoder Very Slowly until I reached 1199 counts and put a mark on the encoder shaft at 12 o'clock the next revolution my mark would be at about 12:05 and after spinning the encoder Fast several times my mark would be at about 4 o'clock or worse. So Im just wondering If Im going about this all wrong i.e. using the math instructions or am I on the right track? Any info would help. Thank you

Hi, I may be able to help but, I need a little more information.
Which plc5 are you using? 5/40E 5/60 etc...
What input card? 1771-CFM or other?

Is the input card in the same rack as the plc, or is it remote?


Ken

Your problem is latency. By the time the plc sees the count is greater than 1200, the plc gets around to issuing the reset AND the reset makes it to the counter card and is acted on a significant number of counts have come into the card. All these counts are lost when you reset.

The way I see it you have a cople of choices.
1) Use the zero pulse on your encoder to reset to zero using the hardware zero input on the card.

2) Don't reset the counter at all. Use math internal to the plc to keep track of revolutions. Just make sure you keep track of the extra counts as you cross 1200.

Keith

The processor was a 5-40E. It was not coming from a remote rack. The card was...here comes the hazing...Im not sure. I remember thinking it was a VERY high speed counter but it was just a run of the mill High speed counter. Ill see if I cant dig up the info I had at work tonite. I appreciate your quick response.

Well thanx Kamenges. I get the distinct feeling Im not gonna get much "work" done at work tonight. Presently I've got a test bench set up with a slc 5/04 and a plc5/30. Im also using rslogix, maybe it will be a bit easier. Howsa about I set up a new encoder using the newer setup and see how it goes, and I will ask again if I run into the same problems. If anyone would like to expand on my original problem I would still appreciate it. Thanx again.

I agree Kamenges.

Most pulse counter cards have outputs on the cards themselves. In your application, you should be able set one of the outputs to energize at a preset counter value. So...if 2 inches equal 1200 pulses, then set your output to engrgize at 3600 pulses, then use the output to stop your motion. You may have to determine the "lag" response value and use a slight offset. i.e. if you consistently run 25 pulses over, then decrease your desired value by 25.


Ken

One thing I do remember is the output was 5 volt TTl 'cause I had a LED hooked up to it. Not much use in the environment I work in though. And also the card would "automatically" reset to zero via the marker (I believe) after 1200 counts, hence, wouldn't I need to do the counting {3600) in the PLC logic, which introduces the latency factor?

Stop right there!!!!!

bulletin blues said:

I then did some math to say IF equal to 1200 then reset to Zero.
So Im just wondering If Im going about this all wrong i.e. using the math instructions or am I on the right track? Any info would help. Thank you

Click to expand...

Addendum to my 'why' rant.
[rant]
Why do people insist on reseting encoders?
[/rant]
Because they can? Why is this a bad idea?

Originally posted by bulletin blues:
The reason for this was... I figured to kind of emulate IF one revolution translated to say 2 inches linear, and I wanted to move something 6 inches, I would need to keep track of the revolutions.

Click to expand...

I glossed over that in my first post. You most likely don't need to keep track of revolutions unless revolutions are specifically important to you. If you are using a 1771-VHSC you get 999,999 counts before it rolls over. That gets you a little over 1,666" of travel before the counter rolls over. Even if you need to go farther than that there are ways to handle the rollover in the plc without resetting anything. The thing to remember is the goofy two-word count format you get back from the VHSC.

To answer Peter's two-part question:
#1: I have reset counters in the past when doing high-speed, repeating functions with the VHSC. The VHSC has high-speed outputs that can be programmed to turn on and off at specific counts. My cycle repeated faster than my scan time so I didn't have the option to rewrite the output trigger points every cycle. The VHSC doesn't have a built-in modulo function so I couldn't go that route. All I had available to me was to reset the counter with a high speed output triggered at a reset count.

#2: Two two things that pop into mind. The first is that resetting the counter can introduce a discontinuity in your feedback signal which would cause problems with any control loops using this feedback. The second is you run the risk of losing counts when you reset. If you don't actually lose 'real' counts you may portions of a count if some type of sub-count interpolation is used.

How'd I do, Dad?

Keith

Excellent......

kamenges said:

#2: Two two things that pop into mind. The first is that resetting the counter can introduce a discontinuity in your feedback signal which would cause problems with any control loops using this feedback.

Click to expand...

Yes, reseting the counter messes up the speed estimation for that period. This affects the differentiator term of a PID..

kamenges said:

The second is you run the risk of losing counts when you reset. If you don't actually lose 'real' counts you may portions of a count if some type of sub-count interpolation is used.

Click to expand...

This is the main reason. People don't realize that they can lose a portion on a count. Bulletin blues can be losing his counts due to this fact alone but I bet that in bulletin blue's case his attempt to reset the counter comes way after the encoder has passed 1200 because of delays. The counter should NEVER be reset. There should be a latch that latches the current value of the counter when the input is activated. Hopefully your PLC encoder interface has a hardware latch.

So why do people insist on reseting the counters? The are so many posts on this single topic. I am surprised the PLC don't have better documentation for their encoder cards that warns about these problems and that latching the current count is the proper technique.

Ok so I learned this (the hard way) years ago when doing my 1st positioning application. You can accurately reset the encoder/counter if the pulse rate is lower then the scan time. So in short resetting the count of the fly is usually NOT a very good idea and will usually cause more problems in an effort to resolve a problem that dosnt exist in the 1st place.

But Peter, would you clarify exactly what you mean by "latching" the count? Are you talking about using a high speed input to activate an interupt?

Latching

Latching is right way to read and home an encoder. Latching is moving the current value of the encoder into another hardware register on some event like when the home input is hit. The PLC ladder does NOT move the data, this should happen automatically in hardware on the encoder card almost instantly. Now the PLC can always compare the current count with the latched count to compute how far the axis is from home. Usually this calculation only needs to be done immediately after the home input has latched a new position. The rest of the time the normal differential update takes place as shown.


Notice, this method works well EVEN WHEN THE ENCODER OVERFLOWS. I didn't bother to show the velocity calculations.

The problem I see is that many so called High Speed Encoder Cards do not have a latch. If not one should still not reset the encoder. One should just use the current encoder counts as the latched home counts. At least this will not accumulate errors.

Note, we have many latches, we latch the current encoder counts when
when the home, extend limit or retract limit are active. Each input has its own latch register. We also latch the counts every update period or scan. Note this is also done using a hardware timer so there is NO software involved. This allows us to get position updates at regular intervals that are jitter free within a few nanoseconds. This allows us to calculate speed and the differentiator part of the PID more accurately.

There are many applications that require latches for registration. I DON'T WANT TO HEAR ABOUT MISSING COUNTS AGAIN!!! I DON'T WANT TO HERE SOMEONE SAY THEIR ENCODER OVERFLOWS. There is no excuse now.

Peter, Thanks for the explaination.