Encoder and PLC logic

SCAN.PLC

Member
Join Date
Oct 2005
Location
scotland
Posts
53
Hi Every body,

the other day i was looking at encoders which is connected to plc.i have never worked with encoders neither any idea how one tracks the postion of system with encoder.as i know a high speed counter module sees the inputs at every rotation from encoder.
but how do we keep the track of it in plc as systems moves in linear path.
and how one resloves the position if in the middle , plc looses power supply and encoder data or counter data is lost.
i hope to get clear answers how the enocder is connected and loigc is implemented in PLC in general.

thanks in advance.
 
But remember that grey encoder retains the position, it is not like incremental encoder which losses the position(resets all it's counters).

For the PLC logic it is not that difficult, iam sure that one of the sparkies will post it for you.

Hagos
 
I've used absolute encoders (devicenet) piggy-backed with incremental encoders as a 'position backup'. By monitoring the incremental status during program execution, I can redefine incremental position by using a subroutine in the plc, either automatically, or user initiated. Be aware, this was the solution to MY problems, and may not be yours. You have to take into consideration the issues of power loss; any program should halt movement of machinery upon a power-up to avoid personal injury or worse.
 
I don't know if this will help, but I once saw a machine with a pusher bar whose position was monitored by an encoder. Every time there was a "power up", and the operator restarted the machine (with all due care for personal safety) the PLC program ran the pusher bar until it tripped a separate plain ol' limit switch. That point became "calibrated zero" and the process started from there.

Stationmaster
 
This page links to 2 pages about encoders, basic info and absolute.
http://www.patchn.com/motors.htm

As you can see absolute means it knows its position at all times, even after powerup. Resolvers are similar to absolute encoders and can also provided positioning info.

How the incrememtal encoder works with a plc, depends, but in general they just send a signal pulse to the plc, the plc keeps track of the count of these signals.

An example, 100ppr (pulses per revolution) encoder could mean 1 mm of travel per revolution (100 pulses). So if it turns 1000 revolutions (100000 pulses) you have gone 1 meter, IF distance is what you want to monitor. You could get speed, rate, use to determine how much material is put on or taken off a roll/spool.
 
There is a plenty of literature on encoders, but in a nutshell, here is what it is about.

First of all, all the encoders fall into two distinct groups: absolute and incremental.

Absolute encoders produce the position signal in parallel format. It means that a 4-bit encoder has 4 signal lines and provides a resolution of 16 pulses per rev (2 to the power of 4); a 10-bit encoder has 10 signal lines and is resolution is 2^10 = 1024 ppr and so on. For every position point within a complete revolution there is a distict pattern of signals that lets you now what position the encoder shaft is at.

All this means the following: a) an absolute encoder lets you know the exact (well, as much as the resolution allows) position of its shaft at any time, even if the power was lost; b) one does not need to use a high-speed counter or a similar module to read the encoder position, a set of ordinary discrete inputs is all that needed; c) absolute encoders are more expensive (10 sets of sensors for a 10-bit one, more pins in the connector etc.; d) absolute encoders by nature cannot tell you the position beyond a single revolution - there is even more expensive version called "multi-turn absolute encoder" which uses a built-in battery power source to keep track of multiple turns.

In addition, most absolute encoders produce the position signal not in straight binary code (0000 = 0, 0001 = 1, 0010 = 2 etc.) but in special format, called "Grey code" (or is it "Gray"? the point being this is not a color but the name of the guy who invented it). This special code minimizes the potential error due to the fact that any two consecutive numbers in it differ in one bit only. This way, an accidental noise on one of the signal lines will not cause a great error. So, when reading values from such an encoder, they have to be converted from Grey code to the regular binary: this is not hard but adds complexity.

From your description you seem to be dealing with an incremental encoder and those are much more widely used than absolute ones. An incremental encoder always has at least two signals, usually designated A and B. The essential trick is to have one signal follow another signal with 90 degrees phase shift (remember that one complete pulse is considered 360 degrees). Like this:

0c7b7a87672.gif


This is what is called a "quadrature set of signals" so encoders like that are often referred to as "quadrature encoders", "quad encoders" or "A quad B encoders".

If the encoder is rotating clockwise (move the diagram above mentally right-to-left), when signal A transitions from 0 to 1, signal B is 0 and when A transitions from 1 to 0, B is 1.

If the encoder is rotating counter-clockwise (now move the diagram left-to-right), when A transitions from 0 to 1, B is 1 and when A transitions from 1 to 0, B is 0.

So here is the important thing: an incremental encoder not only produces pulses, it immediately allows to know which direction is it going. A simple electronic circuit can detect the direction of rotation and, based on that, either increment or decrement a pulse count register - that is what high-speed counter cards do. So a PLC can always request the current pulse count value from the HSC module - the value would be correct since the module always knows (by analyzing the encoder signals as described above) whish direction the shaft was moving.

So, incremental encoders are much cheaper than absolute ones (only two signals instead of many); they are not limited to a single turn (pulses are accumulated by HSC as long as the encoder is spinning), but, as it has already been mentioned, there is a problem of losing the correct position after the power was down. Hence the procedure called "origin search", "referencing" or simply "homing" becomes necessary.

Homing in essence is just finding some known and repeatable position of the axis and resetting the position counter in HSC to zero (or any other known value). "This is my zero point, now start counting from here". In the simplest form, homing is done by moving the axis to a sensor known as "home switch" and resetting the counter after that. This is pretty crude and not very accurate. More refined methods involve moving in one direction until the switch signal transitions from 0 to 1, then reversing and catching the moment when the switch signal transitions from 1 to 0. Much better but still not always acceptable (most switches, after all, may trip at slightly different times; if someone moves the switch, your home position is off). Thankfully, most incremental encoders do help you to find the zero point, i.e. home position, precisely.

If you look at the diagram above, there is a third signal, called "C" (some encoder manufacturers call it "Z" or "index" signal). It does not produce pulses to count, all it does is one pulse per encoder revolution. Its sole purpose is to assist the precise homing.

Now, one more refinement to the homing procedure: after the home switch was detected, keep moving slowly, until the first C pulse comes up. That is your zero point. Note that the position of the home switch becomes not that important anymore: it only gives you a rough estimate of where to look for the C-pulse and homing becomes consistent and repeatable even if the switch is not that accurate or if someone had it slightly moved (well, within one axis revolution). Homing becomes as accurate as allowed by the encoder resolution. Some system (industrial robots, for example) don't even use home switches - they move to a hard stop, detect the increase in motor torque/current, change direction and seek a C-pulse. There are many ways to skin a cat - you will still get a cat skin rather than mink, though. :)
 
I have recently used absolute encoders on Device Net for control of the cranes on the Sydney Harbour Bridge. The encoders (as mentioned remembers where it is) were programmed to indicate the millimetre circumferance of the pulley around which the rope travels. This relates to measuring how far up the bridge the crane has travelled. This information is the utilised in the PLC to lift the inner arms which hold the crane to the bridge when passing cross braces. There is also a primary guide at these locations to keep the crane on the bridge when passing the cross braces. Interesting project and works very well.

Working on another job on the bridge at the moment. There are a number of gantries under the bridge. There have been problems with the long shaft "jamming". We are using incremental encoders to count each side of the long shaft and then driving 4-20ma into air motors to even up the travel on both sides of the long shaft to stop the gantry from jamming. The uotputs from the incremental encoders are just counted into registers and the counts are compared. There is an adjustment to the 4-20ma outputs then performed by the PLC to even up the travel. We are also using the "Z" phase as a double check and reset. The inputs to the counters are turned off unless the crane "go" push button is pressed to eliminate false counts from the "rocking" motion of the gantry.

There are a couple of different ones for you.
 
...but how do we keep the track of it in plc as systems moves in linear path. and how one resloves the position if in the middle , plc looses power supply and encoder data or counter data is lost.
Scan,

I think encoders have been covered for you, but perhaps the two questions above need a little more explanation.

How to keep track of an encoder in the PLC
Think of creating an exact simulation of the system movement, except INSIDE the PLC. If it is a conveyor, then the PLC needs a memory bit for every posible physical position on the conveyor. If you conveyor happened to be 20 meters long, and your encoder had enough resolution to track centimeter positions (20 x 100 = 2000 positions), then you would set aside 2000 continuous bits in PLC memory for tracking materials on the conveyor. If a bit = 1, then a part is located at that position on the conveyor. The PLC bits become a map or a model of the actual conveyor belt.

As parts are put onto the conveyor at one end, a photoeye detects them and puts a "1" at the position of the encoder (in PLC memory). This is often called a "Shift Register" or a "Bit-Shift Register". Each time the part moves physically, the appropriate bit in memory is shifted or moved to the new memory location. As parts leave the belt, the corresponding bit in memory is turned off.

How one resloves the position if PLC power is lost:

You do everything possible to make sure PLC power is not lost UNLESS system power is also lost. You also use non-volitile PLC memory (where possible) for the Shift Registers. If the shift register is in non-volitile memory and both system power and PLC power is lost, then you can restart the system at the same spot as it stopped. The shift register will still accurately show where each part is located (except for any sliding or drifting of the parts due to speed changes). You can also put the PLC on an Uninterruptible Power Supply (battery backup) so that it never looses power. Then the shift register will be accurate even if it is not in non-volitile memory.
 
Last edited:
encoder

I want to know about incremental & absolute encoder interfacing to PLC
how does it communicated with PLC ? by using fast Inputs or by communication [rs485/422]
actually I want to interface absolute encoder with Schneider PLC [m258] & I am new to this
 
I don't know anything about schneneder and the links in this thread are very good to read.

Interfacing encoders to PLCs depends on the encoder and the application but at the end the PLC will receive pulses through some sort of an interface to one or more of the PLC's inputs. Those inputs will be read as pulses of 1s and 0s and depending on how fast those pulses are coming and how fast the reaction to an event needs to be a "high speed counter" ,which is a hardware feature, maybe used. The pulses can be dealt with as counts or frequency. Then you will write code to deal with certain events. Those events could be for device positioning and motion control or anything else you want it to be.

Post your encoder specification and I'm sure someone with knowledge of Schneider will help you out.
 
how can i interface an encoder with 2 channels and index to siemens plc s7 1200 for getting position.Both the channels are using since it is bi directional.Please any one can help me how to develop a programor the logic to be implented using high speed counters for this.
 
There are many output types for incremental encoders. Since you mentioned rs422, it should be mentioned that rs422 is a voltage specification (I think it's often called line driver differential) and is often used for quickly changing binary signals over relatively long distances. That makes it good for encoders, as well as serial communications.
Unfortunately, I'm not familiar with your plc, so I don't know what kind of encoders it supports. But you want to start by looking through the plc documentation for whether the inputs are quadrature, 5v, 24v, differential, etc. Then find an encoder with a matching description

If you need absolute, you'll have a couple choices: Gray scale has already been discussed. SSI is a popular serial protocol, you would need an ssi card for your plc to read it. The last option is finding an encoder with an appropriate fieldbus, I've used profibus and Ethernet ip- I'm sure there's plenty of others.
 
Last edited:
Since we are on the subject and you are trying to learn, I have worked on resolver systems in the past. The provide exact shaft positioning, even in the event that line voltage is lost without the need for retentive memory. The downside is that they are more expensive and much more complicated to work with. There may be better instructions for this these days, but the system I worked on used drives to read the encoders and devicenet to transmit the position to to the PLC in a numerical value, where there was a nice bit of trig done on the numerical values to give the actual position to the logic.

http://www.dynapar.com/Technology/Encoder_Basics/Resolvers/

Plus, kudos to the posts so far. Good reading and I learned a lot from them.
 

Similar Topics

Hi Folks. Has anyone used an SEW EI7C encoder with an S71200 PLC? If yes, how is it done? I use this same encoder in EI76 mode with a...
Replies
0
Views
247
Hi y'all. I'm kind of used to program in TIA portal but not in simatic manager. So now I have a little problem at a client of mine. sometimes...
Replies
4
Views
515
I am working with this module xbf-hd02a from LS plc. I want to hold the encoder count in case of power failure, for this I am setting the present...
Replies
0
Views
697
I'm a beginner and not sure what to do. I want to monitor the rotation of a motor. I have a FX3U PLC and a RI58-O/100 encoder available. The...
Replies
2
Views
1,371
Hi, I am trying to learn how to use my encoder with my PLC. I recently got a high-speed counter module (H0-CTRIO2) for my DirectLogic05 PLC. I...
Replies
5
Views
2,182
Back
Top Bottom