How to track a part using a "shift register"?

i have a conveyor application that will index parts through various stations. the parts have the same basic attributes such as sku, weight, lenght, density, etc. basically a mixed group of datatypes will make up a part.

i will need to track the unique parts through the conveyor system.

i am new to controllogix but it seems like i need to develop a udt that represents a part and then allocate in memory a structure that represents the possible locations on my conveyor and "shift" the parts along as the conveyor is indexed.

if anyone could get me started on how to set something like this up, i would greatly appreciate it!

Try this


http://www.plcs.net/chapters/shift20.htm

shift register

try this

http://www.mrplc.com/kb/index.php?page=index_v2&id=71&c=12

geniusintraining said:

Try this


http://www.plcs.net/chapters/shift20.htm

Click to expand...

thank you for the reply. i really need to shift more than bits...i need to shift all of the data.

A better method for tracking is not a shift register, with a shift register the bits/words can get quite big.

The way I use for tracking objects on conveyors is quite simple. Two words for each object, the first is its ID, the second is where it is on the conveyor, incremented each tracking pulse (you could switch conveyor for section in machine).

The first two words could be kept for status and how many objects are on the conveyor.

I.E.

Status = Running
No. Objects = 2

Object 1 ID = 50
Object 1 Pos = 120 (mm)

Object 2 ID = 49
Object 2 Pos = 188 (mm)

Object 3 ID = 0
Object 3 Pos = 0 (mm) [EMPTY]

Size the data buffer to the maximum objects you can get in.

A new object in shifts the object list up 1, an object out clears the last object (in both cases No. Objects inc/dec as appropriate).

You then have a seperate data area for each objects info, say you can only have a maximum of 50 objects, then set uo space for 55 objects with all the data for that object. Object 50 looks in dedicated area for object 50 etc. As the objects come into the system you increment the ID and call it the next available No., once 55 is reached the next is 1.


Edit:

This is also good in my business, tracking at 1000mm/sec, to see things. Otherwise the shoot through data area too quick.

SilverLoop said:

thank you for the reply. i really need to shift more than bits...i need to shift all of the data.

Click to expand...

Then I would try as Peter has shown, you would need to do moves, not bit shifts, what type of PLC are you using?

What are you using to track the movement? encoder? resolver? or just a enable from a run condition?

Peter what type of business?

For my system:

Baggage at airports. Encoders have been tried in the past, but temperature changes have caused errors.


Usually now its a star wheel and proximity switch (four edge star, making one shots every rising/falling edge = 8 one shots per revolution). Typical design would be each one shot = 50mm of movement on the belt.

Step 7 PLC's now, previously with Modicons.

Note to self: why am I answering this, it wasn't asked to me!! its been a long hard day of customer testing here!!!

Don't move the data!!! Move indexes

A key factor is trading efficiency for simplicity. I couldn't recommend a method without knowing:

1. Number of stations
2. Number of parts
3. How quickly the parts move.
4. More about the encoder resolution and how fast it will turn.

A control logix should be able to do this easily using its array indexing capability.

I seriously doubt the encoder problems PeterW encountered were due to temperature unless it was a very cheap encoder. There are encoders working in much hotter and colder places than in the UK.

What I don't like about star wheels is they can rock and you will get all sorts of counts without really moving.

I would use an absolute encoder. Every one wants cheap and easy. Well what if the power goes off. You don't want to lose the position of all the parts do you? Absolute encoders will pay for themselves with just a few power outages depending on the value of what is on the production line. I am a big fan of SSI rotary encoders.

Actually I never encountered the encoder problems, that was a historical Siemens installation I was told of.

Most airports companies use starwheels due to simplicity and the fact that there are hundreds of conveyors (more than 20 miles on current project) and starwheel resolution is good enough for accuracy needed.

The rocking, I take you mean as vibration whilst the px is just detecting an edge. This is known to happen but usually you condition the detection with the output on.

Peter Nachtwey said:

A key factor is trading efficiency for simplicity. I couldn't recommend a method without knowing:

1. Number of stations
2. Number of parts
3. How quickly the parts move.
4. More about the encoder resolution and how fast it will turn.

A control logix should be able to do this easily using its array indexing capability.

I seriously doubt the encoder problems PeterW encountered were due to temperature unless it was a very cheap encoder. There are encoders working in much hotter and colder places than in the UK.

What I don't like about star wheels is they can rock and you will get all sorts of counts without really moving.

I would use an absolute encoder. Every one wants cheap and easy. Well what if the power goes off. You don't want to lose the position of all the parts do you? Absolute encoders will pay for themselves with just a few power outages depending on the value of what is on the production line. I am a big fan of SSI rotary encoders.

Click to expand...

Spot-on. These statements echo my experiance exactly. Power outages are far more devious than temperature changes.

Peter Nachtwey said:

I couldn't recommend a method without knowing:.....I would use an absolute encoder....

Click to expand...

Peter Nachtwey,

You are contradicting yourself in your statement, unless you were talking about two different applications (PeterW and SilverLoop ), I use many types in my process, I do agree with the fact that more is needed from SilverLoop to best suit their app., I would not use a high end type for PeterW app. but I would use a very good quality one, that may cost more but in the end with 20 miles of conveyor quality is more important then precision.

Hell.. PeterW and his crew are just going to throw and kick our stuff around anyway, have you ever saw the way they treat our stuff

Peter Nachtwey said:

A key factor is trading efficiency for simplicity. I couldn't recommend a method without knowing:

1. Number of stations
2. Number of parts
3. How quickly the parts move.
4. More about the encoder resolution and how fast it will turn.

A control logix should be able to do this easily using its array indexing capability.

I seriously doubt the encoder problems PeterW encountered were due to temperature unless it was a very cheap encoder. There are encoders working in much hotter and colder places than in the UK.

What I don't like about star wheels is they can rock and you will get all sorts of counts without really moving.

I would use an absolute encoder. Every one wants cheap and easy. Well what if the power goes off. You don't want to lose the position of all the parts do you? Absolute encoders will pay for themselves with just a few power outages depending on the value of what is on the production line. I am a big fan of SSI rotary encoders.

Click to expand...

there are 10 possible locations for a part and one open location at all times.

one main section of "conveyor" is actually a "walking beam" that extends, raises, retracts, and lowers...each time thus indexing a part to another station a consistent index position.

the last part of the system has a conveyor motor with powerflex 70 vfd and AB 845H encoder (incremental) connected.

the idea i had was to actually "move" the part and carry with it its data to each possible location. this movement of data would happen when the walking beam was indexed and the motor driven conveyor was running.

geniusintraining said:

Peter Nachtwey,
You are contradicting yourself in your statement,

Click to expand...

Yes, some appilcations do not have a lot of value on the production line so they just get trashed each time the system must reset. However, I would bet sliverloop would like to keep track of where his metal is if the power goes out.

Efficiency is not going to be a problem in this application when using a control logix. There are few items to keep track of and they don't move too quickly. Some day, some one will have a sorter or conveyor application that require some fancy techniques.

I am seeing more an more usage of SSI encoders partly because restarts are much quicker. No homing or running off material.

..

mellis said:

Silverloop,

Since you are still in development, it's not that bad of a situation. If you have to do this online to a running program, it's a bit trickier.

Simply create the local tags you need with the same tag name.

Then delete the controller scoped tags.

The project should re-verify correctly with the local tags.

You can automate the creation of the local tags using the tag import/export feature. Edit the csv file by adding the appropriate program name in the "scope" column". (Blank in the scope column is controller scope) Importing the csv will create the program tags. You still have to delete the controller tags manually in RSLogix5000.

Good luck,

Edit: Seems the question disappeared while I was typing...

Click to expand...

my apologies...i meant it as a separate post.