encoder control with a plc

Andy

Member
Join Date
May 2002
Location
York uk
Posts
16
can anyone help me, im am trying to devise a program to control a dc motor, the motor is used for positioning of a backstop on a machine.
i have never done this before and im im looking for a start point or a example program that takes the encoder input and changes it to mm so it can be positioned. i have 3 more inputs which are max forward limit, max back limit and calibrate point limit and i want to write the size i want it to travel to from a location within the plc. the inputs from the encoder are a and not A so i know i will get a output that i assume will be BCD but if any one can help me on my way it will be apriciated.
cheers
andy
 
Could it be that you're really working with a pulse-type encoder?

Could it be that your limits are monitored by proximity switches?

Could it be that your backstop moves very slowly? Or, quickly?

Where are your sensors located relative to each other?

How are your sensors oriented?

With respect to your encoder information... I really doubt that it is in BCD form. I suspect it is a pulse-type encoder. In that case your PLC simply counts pulses. If the encoder is moving "Forward" the PLC counts "UP". If reverse, the PLC counts "DOWN". You have to maintain the Current "COUNT" to know where the back-stop is at any given time. Of course, as you indicated, there has to be a reference-point.

As far as "changing to mm", you need to know how many pulses represent 1-mm. Better yet, you need to know how many pulses represent 1-meter. You need to know how many pulses occur over the largest distance you can manage. At the same time, you want to have the largest number of pulses you can manage as well.

The maximum number of pulses can be attained by mounting the encoder on that axis which rotates the most. Typically, that is on the motor itself. However, in some gearing situations, the maximum number of rotations might occur on some other axis. Or, just for the sake of developing a large number of counts, you might use gearing just to drive the encoder.

The point is to make it so that each pulse represents the smallest amount of travel that is reasonably possible.

Some extreme examples:

VERY BAD CASE:
If you can get 10-pulses while the back-stop moves 100-mm, then you have...

10-Pulses / 100-mm = 1/10-pulse / 1-mm THIS IS VERY BAD!

You CAN NOT DETECT a 1-mm MOVE! You would have to move 10-mm just to get 1-pulse!

BETTER, BUT STILL A BAD CASE:
If you can get 100-pulses while the back-stop moves 100-mm, then you have...

100-Pulses / 100-mm = 1-pulse = 1-mm THIS IS STILL BAD!

The back-stop move could have an error of up to +.999999...-mm in Forward or up to -.999999...-mm in Reverse.

The back-stop could move as far as 1.9999...-mm (damned near 2-mm) on a single pulse.

BETTER CASE:
If you can get 1000-pulses while the back-stop moves 100-mm, then you have...

1000-Pulses / 100-mm = 10-pulses = 1-mm --->>> 1-pulse = 1/10-mm THIS IS BETTER!

The back-stop move could have an error of .099999...-mm.

MUCH BETTER CASE:
If you can get 10,000-pulses while the back-stop moves 100-mm, then you have...

10,000-Pulses / 100-mm = 100-pulses = 1-mm --->>> 1-pulse = 1/100-mm THIS IS MUCH BETTER!

The back-stop move could have an error of .009999...-mm.

EXCELLENT CASE:
If you can get 1,000,000-pulses while the back-stop moves 100-mm, then you have...

1,000,000-Pulses / 100-mm = 10,000-pulses = 1-mm --->>> 1-pulse = 1/10,000-mm THIS IS EXCELLENT!

The back-stop move could have an error of .000099...-mm.

Now, some of these numbers seem to be a little unmanageable for a typical 16-bit word (Max Value = 65,535). You handle this by tracking REVs.

If your encoder delivers 4000-Counts per Rev, then you'll run out out "number-space" at 65,535-Counts / 4000-Counts per Rev = 16.38375 Revs. So..., you count Revs as well as Counts to indicate the current position. Every 4000-Counts = 1 Rev. You then need to know how many Revs and Counts = 1-mm. Multiply accordingly.

Important Point to KNOW!
Now, at this point, it is very important to recognize that any subsequent moves should be based on the original reference point. That is, DO NOT make subsequent moves relative to the current position. Doing so incorporporates the error associated with the previous move.

If all of the previous subsequent-moves have been made relative to their particular "positions", then the latest current position has all of those errors associated with those previous moves incorporated into the current position.

For example, if you move to position-X, you will get there within the possible error. If you then use the previously-intended position as the origin for the next move, the next move is made relative to that error-prone position.

So, if you make each move relative to the previous "known-position", each subsequent move incorporates the error associated with that previous position as well as the error associated with all previous relative moves.

After a while, your position is off by more than 1- or 2-mm, and possibly worse, as time goes on.

So, the point is, make your moves absolute relative to the reference-point!!!

Damn! I didn't expect to go on so long. But then, this is a really critical aspect of motion control, and it needs to be understood by all that use it.

Andy,
One of THE MOST IMPORTANT things about process control is to learn how to "Ask the right questions". MANY times, if you finally figure out the right question to ask, the answer mysteriously appears before you get a chance to post the question!!!! That is, with a little bit of forethought, you can answer your question yourself!
 
Last edited:
Andy

If you let us know what PLC you are using, what encoder you are using, is it an absolute or incremental? How many connections are on the back of the encoder? This should give you a clue as to what type of encoder you are using

I have used a rotary absolute encoder, which outputs in gray code (0000, 0001, 0011, 0010 etc) and a linear encoder which outputs in 12 bit binary. Both these types we have scaled into cm's although the codeing for the gray code type is a bit more involved than the binary type.

An incremental encoder just uses pulses (as Terry stated) thus you just count the pulses within the PLC and scale accordingly.

You stated that the inputs from the encoder are a and A, is that all, Terry's answer goes a long way to explaining why an encoder with only two channels is bad. If you are set on using an incremental encoder then pick one that gives you a high resolution.

For our travel encoders we use one that gives us 2500 pulses per revolution per channel, we use 4 channels (a and A, b and B) that gives us 10000 pulses to count per revolution (reference Terry's MUCH BETTER CASE )

In Terry's answer he asks some questions at the beginnimg which need answering before we can give you the help that maybe you require.


Paul
 
Last edited:
I dont think it has been said in so many words yet, but to convert from counts to mm, basically its a linear equation y = Mx + B equation

where
y = mm
x = count
B = offset (if any)
m = ymax - ymin / xmax - xmin


I hope thats right :)

regards,

Steve
 

Similar Topics

Hi Guys Im currently doing a project where i am having move a motor to any given position fwd and rev.I was given a s7-300 plc with anologue in...
Replies
4
Views
15,432
Hi, I have an application that currently utilizes SEW drives and programming that we are attempting to convert to Allen Bradley CompactLogix and...
Replies
9
Views
1,181
A bit of background here: We use an incremental encoder with a counting module in our PLC configuration. Using dual phase / quadrature counting...
Replies
26
Views
9,088
I am working with a Allen Bradley Absolute Controller (842E-SIP5BA). I was wondering if anyone has any experience with them. Pros/Cons? Has...
Replies
3
Views
2,143
Hello, I am a part-time machine builder that has recently been exposed to the world of PLC controls. I subbed out the controls for my latest...
Replies
17
Views
5,358
Back
Top Bottom