Incremental Encoder Application

Hello everyone!

We are trying to convert an existing proprietary system to a ControlLogix PLC. This is a sortation system which consist of a 580' conveyor running at about 160'/min and 75+ diverts. The current system uses a low resolution incremental encoder (360 Counts) and a "Carrier" Sensor which detect each carrier evenly space at 12"

The timing is very inconsistent. For example we set the scanner to be ON for 6" and they only stay on for 1-2". Since we are using a 16 bit encoder (FlexLogix 1794-ID2) We were forced to reset the encoder at every carrier. Because (580' X 360 count) is greater then an Integer value or the ID2 limit. So we decided to try to use a DINT for the conveyor count timing. We take the carrier count and multiply it by 1000 and add it to the actual encoder value which represents the distance between each carrier. For example 96100 would correspond to carrier 96 and encoder count 100. We are using a LIM instruction to trigger the scanner for 6" or 180 counts. Therefore the Low limit is 96100 and the high limit is 96280. Anyway it is just not working the way we want it to be. Our PLC scan time is about ~5ms and we are using ControNet with an update time of 5ms between the ControlLogix PLC and the FlexIO

I haven't really used encoders before and I was wondering if there would be a better way of doing this. I was thinking of getting the 1756-HSC and let the encoder counts for the length of the entire conveyor?

Any help would be greatly appreciated.

Thanks

Either there is more to this story or you are using overkill for the task...

You said you have a sensor that detects the carrier... I assume this starts the scan...?

If so... how about...

                  CARRIER FLOW =>

                +--------------------------------+

                |     ||| | | || || |            |

                |     |<---code---->|            |

                +--------------------------------+

                                                      |<---code---->|

                                                     LS1           LS2

                                          ^

                                          |

                                       SCANNER

When LS1 comes ON the scanner comes ON just ahead of the code.
The scanner scans until LS2 comes ON just after the code.

LS1 and NOT LS2 = SCAN

I'm not getting someting...How many counts per inch or per foot???

"Since we are using a 16 bit encoder..."
I think you mean "16 bit counter" ?? (a 16 bit encoder would seem to mean an absolute encoder).

"(580' X 360 count)" If this means 1 encoder rev per foot, then thats a total of 208800..way over the ability of a 16 bit accumulator, however why cant you rollover to two words? Then you should be able to count to Mars and back. Is this a hardware limitation?

The 1794-ID2 has a limitation of a 16-bit counter. I like the idea of rolling it over into a DINT but I was concern about loosing counts while the counter value is added to a DINT and that the encoder is reseted?

This is old stuff.

Don_Dubé said:

The 1794-ID2 has a limitation of a 16-bit counter.

Click to expand...

Why is a 16 bit counter a limitation? I don't get it. I use 16 bit counters all the time and I count to 4 billion+ using a dword.

Don_Dubé said:

I like the idea of rolling it over into a DINT

Click to expand...

Good!!

Don_Dubé said:

but I was concern about loosing counts while the counter value is added to a DINT and that the encoder is reseted?

Click to expand...

So don't reset the encoder. See my other posts about encoders, timers and counters.

First of all, I'm with Terry if all you have to do is the one function. A couple of limit switches/prox switches/photoeyes would be much easier to understand and get working.

If you need to perform multiple functions at varying locations the encoder method MAY be a better bet. I would need to know more about exactly what you are trying to do, though. But if you really feel you need to use an encoder you might want to consider a couple of things.

First of all, don't reset the encoder. As you said, when you reset the encoder count you need to worry about lost counts. Just let it run and deal with the rollover. My quick calculations say you will get an ID2 rollover every 20 seconds or so. That leaves alot of time to handle the rollover before the next one comes along. Just keep track of the total count in a double integer and you should be able to run continuously for about 6-1/2 days before you need to worry about the double integer flipping to a negative number. You may need to handle that also. This all assumes you are using a quadrature encoder and 4X decoding. If you are using 1X decoding all the times increase by a factor of 4.

Also, look at your encoder wiring. Make sure it is connected correctly for your counter mode and decode style. Also make sure your encoder cable shield is only tied to ground at one end. Your inconsistency may well be due to electrical noise on the encoder signal lines.

Good luck.
Keith

Is this conveyor an 'Alvey' system or similar?
Does the product sit wholly on one carrier, or does it span several carriers?
You can control these type of systems with no encoder and a series of bit shift registers clocked by the 'carrier sensor'.

Thanks everyone for you assistance! This is a Softrol system for an Industrial Launderer. The LS would be nice and simple but we need to use an encoder as many things are being done at the same time.

Few more questions though...

What is the best way to rollover an encoder count without loosing accuracy? I'm using a ControlLogix with a FlexIO 1794-ID2 which has a rolloverbit (bit 13). Can I simply use that bit to add 65535 (encoder limit) to the same DINT until I reach the desire value? Will that be accurate? Again I never really work with encoder. Also, what is the purpose of having 1X, 2X, 4X quadrature?

Thanks!
Don

The biggest problem with using encoders for continuous distance reading is the accumulating-error. This is caused by the inaccuracy of the "human-derived" inches-per-rev.

You might be able to figure out that one rev (with how ever many counts per rev) of your encoder equals 1.500-inches... or would that be 1.499-inches... or 1.501-inches... all it takes is 1000-revs and you are off by 1-inch! And it just keeps gettin' worse... unless you find a way to introduce a "sync".

On a small conveyor system one might be able to hang a "sync-flag". Whenever the flag comes around the count is zeroed. There would have to be a sync-flag every so often - the distance between flags would depend on the maximum error that could be tolerated. If the maximum allowed error is 1-inch and it takes 1000-revs to develop that error then the flags should be mounted less than 1500-inches apart.

On larger conveyor systems with multiple conveyors this becomes a bit more problematical. You have to "sync-your-syncs".

The encoder counter on one conveyor serves as the master encoder counter. That conveyor has sync-flags. Whenever a sync-flag comes 'round, you have to reset the counts on all conveyor encoder counters with the master conveyor encoder counter.

Of course... this means that all of the conveyors have to move in sync! You can't have one traveling faster or slower than the master.

If there is any kind of indexing going on, it is best to extend your count for as long as possible. Resetting your count after each index is not as accurate as running a multitude of indexes on a single run of counts.

If the count is reset after each index then, the first time a stop over-shoots the stop point, all subsequent moves over-shoot the stop point... and the error keeps growing.

If the count is reset after a long, single run of counts, and if the stop-points are calculated relative to Home (sync-point), then the stop-points are always within a few counts of the calculated stop-point... the actual stop-points are always trying to converge on the calculated stop-points over a longer distance.

This is like the game where you measure distance between two buildings using an "inch-ruler", a "twelve-inch-ruler" and a "yard-stick". The "yard-stick will ALWAYS provide the more accurate measurement!

Does this help at all?

In light of this, are there any other details you could provide that would help me help you?

Given Terrys response to accumulating errors etc.. I thought I'd interject with "how we do it".. Our setup is way more complicated then I'm going to discribe below, but you'll get the general idea. The basic issue is that we dont try to convert counts into inches and say this is how far to go in inches/feet etc.. It's just a matter of how many counts is each stop. Like the bottom of the hoistway, (resting on the buffers) = 0 counts, and the top of the hoistway may be 10,000 counts (depending on how much total travel). Everything else is inbetween. (not resetting the encoder count unless an error is detected)

This is how we do it:

Ok so on top of the car there is a quad encoder that is driven by a 9mm wide 5HTD open ended timing belt run the length of the travel. The resolution is approx 1/16".

After the system is installed the installer sets (setup mode A) up the selector (positioning system), by bringing the car to the lowest point (mechanical stop), and zeros out the HSC. The car is then moved to the 1st stop and then the installer Moves the encoder count into a Non Volitale memory address, then indexes the pointer, runs the car to the next level, MOVes the encoder count into the next memory address, indexes the pointer, then moves to the next level..etc..and so on. This retains the exact count for each landing. 1st landing might be 200; 2nd landing might be 2100; 3rd landing might be 5200..etc..

Afer the landing positions are stored, the installer places the program into Setup Mode B, which causes the program to calculate all the slowdowns, door zones, etc...for each floor, based on predetermined constants, that depend on the rated speed of the unit. (approx 2" per 10fpm) These values are also stored in Non-volitale memory.

In Setup Mode C the unit runs up the hoistway and detects the position of all the limits etc..(Door zones, terminal slowdowns, directionals, and final etc), and also loads thoes values into the Non Volitle memory..

When the unit is in normal operation, the encoder count is compaired to the position of the limits, and if there is an error, the unit goes into "correction mode" by slowing down and going to the terminal slowdown limit in whatever direction the unit is traveling. when it hits the limit, the value from that limit is loaded into the counter accumulator..and off running again.. A record of the corrections is logged. If there are three corrections, then the unit faults out and returns to the lowest landing, stops on a limit, and opens the door, and stops operation. (BTW, this has never actually occured, but the function is there..because someday it will).

Anyway as the car is running up and down, comparisions are made in the program (compairing the stored data to the encoder count)
to initate slowdowns, stops, etc..

In our setup the count can go as high as 99,999,999. 1/16" per count = 520,830 feet = 98+ miles... (were still about 120 miles short of the "space elevator"..but working on it..)

Encoder application

Terry Woods said:

Does this help at all?

Click to expand...

Definitely.

Terry Woods said:

In light of this, are there any other details you could provide that would help me help you?

Click to expand...

Yes a new job! (Seriously, not for the moment except for the additional question below)

Thanks Terry and everyone else. There is actually some indexing going on and the other person decided to reset the encoder at every carrier count instead of letting count for the conveyor length. The "Year Stick" is a good example. At first, we didn't know that you could rollover the encoder count. But I was not responsible for the programming part of that project. And I decided to ask to experience people after we started having problems. Fortunately the accuracy of the conyeyor is not so critical but I am starting to question the Scanner trigger duration (very important) which might not be ON for the desire length of time. I can confirm that very easily by looking at the scanners log file. I did make the suggestion of rolling over the count but I guess I will have to try harder.

What is the purpose of 1X, 2x and 4X quadrature encoder. To me it is just like taking the encoder count and use a Multiply instruction?

Don

Originally posted by Don_Dubé:

What is the purpose of 1X, 2x and 4X quadrature encoder. To me it is just like taking the encoder count and use a Multiply instruction?

Click to expand...

The different evaluation modes a a bit moire than a multiplication. Think of it more like measuring in inches, halves of and inch or quarters of an inch. The different evaluation modes determine how many encoder edges are counted per encoder electrical cycle. For example, 1X evaluation counts only the 'leading edge' of channel A. 2X evaluation counts both the leading and trailing edges of channel A. 4X evaluation counts leading and trailing edges of both channels A and B. So in one electrical cycle (channel A goes from off to on to off) you can get either one, two or four counts in your counter.
Keep in mind that this assumes a 50% duty cycle standard quadrature encoder. This means that the encoder transitions are all 90 electrical degrees apart (give or take some error). This is an unrealistic example, but lets assume you have an encoder that gives you one electrical cycle per inch of travel. With 1X evaluation you have a resolution of 1". With 2X evaluation you have a resolution of 1/2". With 4X evaluation you have a resolution of 1/4". All out of the same encoder, but not at the same time.
Now, how do you decide which way to go? Well, I'm kind of big on resolution so I usually go with the 4X evaluation. The only time I wouldn't is if I am trying to keep my count inside of a certain range and I can give up some resolution. Also, some encoder interfaces have a lower max frequency when you use 4X evaluation than they do with 1X or 2X evaluation. So raw speed might end up being an issue also.

Keith

Thanks Keith for your explanation on the difference on 1X 2X and 4X Quadrature Encoder.

You said you are indexing... does this mean "Stop and Go" type indexing? (I doubt it.)

Or... are you "indexing" from carrier to carrier, on-the-fly, without stopping?

What is the speed of this system?

Is this a single conveyor line?

How do you maintain the distance between carriers?

With respect to X1, X2 and X4... which are you using?

What is your "count-per-inch"?

What is the maximum number of carriers?

Encoder application

Terry Woods said:

You said you are indexing... does this mean "Stop and Go" type indexing? (I doubt it.)

Or... are you "indexing" from carrier to carrier, on-the-fly, without stopping??

Click to expand...

We are indexing from carier to carier on the fly without stopping. This is for an industrial launderer company, therefore we are scanning the shirts first and then the pants maybe 10 carriers later.

Terry Woods said:

What is the speed of this system?

Click to expand...

~160'/min

Terry Woods said:

Is this a single conveyor line?

Click to expand...

Yes

Terry Woods said:

How do you maintain the distance between carriers?

Click to expand...

It is fix. Every carrier are evenly space 12" apart.

Terry Woods said:

With respect to X1, X2 and X4... which are you using?

Click to expand...

Currently we are using 1X. We can live being 1" off per revolution.

Terry Woods said:

What is your "count-per-inch"?

Click to expand...

360 count/rev encoder, 1X
1 complete rev = 2 carriers = 24"
15 Counts / Rev

Terry Woods said:

What is the maximum number of carriers?

Click to expand...

579 carrier or (579' conveyor)