Here's something I've been pondering for a few weeks but have not found the time to test. Maybe someone has a better idea and can steer me in a different direction or tweak my thoughts.

We currently have this line which has parts entering traffic up stream at 4 different locations and and then is sorted back out down stream in 3 different exit points.

Currently, the system is programmed using 4 different FIFOs and those 3 exit points look in 3 different data files. These exit points each look at different word locations in those 3 different data files. Example, exit 3 looks at word 10 in data file 1, word 23 of data file 2 and word 30 of data file 3. Hope that's enough to explain the existing.

We are planning some changes to the system and getting this all lined up again has been a bit challening to get the proper placed for these exits to look in f different data files. Also, Up stream, the 3 downstream entrance points also have to lookk in these up stream data files for parts passing in front, so one entrance does not yield traffic when merging.

What I've been thinking is to drop down to one FFL/FFU so everything happens in one. Currently, each FFL/FFU enters a 0 (zero) with each chain pulse. (1') When an entrance gate opens, entrance 1 starts moving 111, 111, 111, etc, for I believe 20 chain pulses, then back to 0, 0, 0, etc. Entrance 2 (data file 2) dumps in 222, 222, 222, etc, 20 times then back to zeros.

OK, What I'm thinking is to continuously dump in the zeros no matter what, in one data file. When entrance one gate opens, I'll MOV 111, 111, etc 20 times into word 100 (assuming that's where I need to dump them in)Those 111 would MOV in immediately following the FFL and FFU in the same rung or in the next rung(s) when the FFL/FFU rung goes false. Entrance 2 would do the same, perhaps at word 140, and so on.

The thought here is such that when product is moving down the line, I can watch all in the same data file. When it comes to exiting the line, I'd only need to look at one location (word) in one data file. That's 3 places to look VS 12.

Also, when it comes to debugging and lining up all these entrance and exit points, I would only need adjust one 1 word in one data file for each of those 7 ent/exits. The old method has so many different data files (4) and look up points, etc, it took a lot of time fine tuning the tracking in so many different places.

If I can/need to clarify anything, let me know. (Maybe I sould have proof read above before posting. I've only had about 30 interruptions wile writing this. )

Sorry, I looked back in the above attempt at describing the old VS the new scheme. Maybe you can read through those inconsistencies.

For one, the FFL will move in a zero into the back and same time the FFU will remove which ever number comes along from the front of that one data file with each chain pulse.

In between each FFL/FFU shift of words triggered by these chain pulses, one or all 4 of those entry points will MOV in it's own string of 111, 222, 333 or or 444s, one at a time, in 4 different word locations as represented by that entry points location in the system. These entries are about 28 feet apart, but are not all equally spaced.

Again with the 3 exit points. Each will be set to look at a different word in this one data file which approximates it's physical location down the line. If product entering at entry #3 is set up to exit at discharge 2, exit gate 2 will open if it's seeing a 333 in it's place in the FIFO data table.

I guess my questions being, would there be any reason I could not or should not inject these entrance code strings into the middle of that FIFO data table? Is there some other method which might be easier or other generally preferred method of accomplishing this?

Basically I just want everything visible and moving in one, not 4 data tables and something simpler fine tune when done.

Thanks again and still sorry if I'm making this even more confusing. It's been a challenging day. (Challenging, but not PLC/code related. PLCs generally do exactly what you tell them to do. Fortunately or unfortunately, with out asking any questions other than, are you sure.)

I see what you are getting to below and believe I will be able to test some of these ideas in the currently running system later next week. I will have at least a couple weeks where I can test/watch the new code running along side the old and when time comes, remove the old and tie in the new. Anything new will b eeasier to see and follow than that which is in there now.

Thank you,
Dale

Quote:

Originally Posted by MichaelG

you are using FFL and FFU - I assume this is a RSlogix PLC eg SLC500 or PLC5?

What you are thinking of will work

Easier is to use the COP function and forget the FFL and FFU
If you look at the Execution time you will see that is is faster

Below written before rereading your post again and realizing that this is what you were doing in the FFL/FFU

Create a table of integers Length greater than maximum possible number of positions
Each Index pulse use COP to track each position
eg COP N7:1 N7:0 100 for 99 index positions

N7:0 is the last position on the conveyor - just about to fall off into the missed part bin
N7:100 = 0 (loading - No product onto the conveyor)

Mov 1 N7:90 to "load" part 1 onto the conveyor at position 90 from the end

Mov 2 N7:80 to "load" part 2 onto the conveyor at position 80 from the end IF N7:80 is not already 1

Use EQU N7:10 1 to detect that part number 1 is at Position 10 to unload

The key is those 1-foot-long chain pulses. For every converyor position that moves 1 feet when that pulse fires, then yes, you should try to put all those positions into the same PLC shift register to avoid the confusion caused by having many little shifter units. It will be easier to view your data with one FIFO register, but because you have 4 entry and 3 exit points, it will be more difficult to get parts in and out (in the PLC) of one FIFO. Due to the multiple entry-exit points, using Micheals COPY method (make your own data shifter) might be easier than using the formal FIFO instructions.

You say the pulses are 1 pulse every foot and the entry points are up to 28 feet apart.

It has me wondering, how long is this conveyor? How long are the parts? is it a single conveyor? what type of conveyor is it? Can the tracked parts slip? Can the conveyor slip? What is the furthest distance? What mechanism is used to divert the objects?

Well, here goes. This will either clarify or confuse the task at hand.

By the way, I have another FIFO/data table in this program I'm not currently using. I'm going to borrow it next week and throw in a quick COP scheme as stated above. I think it will work just fine and I can compare along side the 4 existing individual FIFOs. Main goal here is to get rid of 4 and replace with the one single data file, combining that which is now in those 4. The program is doing nothing with the control file bits so I see no need to stick with the FFL/FFU.

As for those discharge points down stream, that's something down the road, so we don't need to consider much on that now. As long as the data table takes care of the parts entering, it will no problem sorting it out to the new exits. At that time, the values I move into the entry points will be coded some way for varied actions at exits.

As for details on this conveyor, it is an over head power and free conveyor. This particular conveyor/drive is roughly 300' long. We have 18 drives throughout the plant some consideraly larger others smaller.

Parts we make get hung on these load bars which are 25' long each. Each of those load bars have a set of trolleys on each end and are either staged in various tandem load and unload cells and are released into these single transport lines. The area I'm redoing is the transport line these carriers/load bars have to merge into and be tracked all the way down to the end. (sometimes, I'll explain later.)

As stated, the entry points are aprox 28' apart with the last 2 (furthest up stream) being 40'. The load lanes, 7 total are tandem lines. Once the carriers are loaded, the operator press a release button, their stop gate opens and the carrier moves up to another stop just before the transport line.

These carriers then sit there until the section in the transport line is clear. When clear, gate opens, carrier drops out. There is a counter that's reset and that needs to count to some value before the PLC thinks that carrier (load bar) is out of the way.

As for carriers coming from up stream, as carriers come along down this line, they hit a limit switch just before each up coming entry point. That resets another counter to zero and that counter needs to count up to some value so that the lane it's passing thinks/know that carrier is past and the exit point is clear again. This is the physical carrier detection which works when the loads hung are <25' long.

On 4 of these entry points (was originally 2, I added 2 more), we regularly hang parts which are up to 40' long. This is where the tracking FIFOs come in. When one of these long carriers enter the transport line, the string of 333,333,333 or 444,444,444, etc move along down the line with the carrier and in a sense compensates for the additional 7.5' of product overhang off each end of the load bars. (The 3's and 4's only represent which load cell the carrier came from. Many 333s or 444s used (I think) just to make it look like one long carrier moving down the through the data file. Value bein gmoved in these data files can be any thing but 0 (zero). Each entery does not consider 0s as being a carrier in the way and prevent another carrier from merging in.

Other areas (drives) in the system also use FFL/FFU to deliver carriers to multiple powder coating booths, unload lanes, etc. Most do not use the control file bits/values but particular FIFOs do use 4 do the control POS value.

FYI, I've been programming, tweaking, optimizing on this system since 98. The project above it to redo the whole traffic control coming out of these load cells and get more load out per hour. As it is, it's not uncommon to loose 1/4. carrier here, 1/2 carrier there, with wasted spaces, not large enough to merge into. I have other plans with other parts of the merging scheme but need to fine tune these LONG loads first.

My preference for this type of tracking is to have a fixed map, and moving pointers for the load and unload points (ranges). I have discussed the concept may times, and used it about four times with great success.

Basically, scale your encoder or estimated conveyors' positions in a Float, and round it to find a spot in its map. The smallest package size/spacing determines the resolution needed by the map. When I have more time, I can dig up links, or search for sorting with OkiePC as the username.

__________________It's not all the variables I am most concerned with, it's the undiscovered constants.

Update, I took my spare integer data file and did the COP instruction and did the same as the one entrance long tracking FIFO. Easy and works great. Sometime next week I'm going insert the info from those other 3 long entry points to make sure that works as hoped. Providing all 4 lines insert into that one data table and track down the line in the same positions as intended, 3 other FFL/FFUs (4 total) and their data files will be removed.

I just want to get everything lined up perfectly before making the switch. No big rush on this change. It is a "spare time" project I'd thought about doing for some time. It will work better down the road with a couple future projects talked about recently and help with fine tuning lines downstream when long and short traffic does not seem to have merged properly. ( (Happens once in a while and not sure why later, after the mess had been cleaned up. Could be some body moving loads manually down the line, "thinking" they were helping.)

BTW, it was asked earlier if parts slip on conveyor or if conveyor slips. Pretty much no on both. There are a number of "hand offs" down this line where these carriers dog up on the rear trolley then back to the front trolleys but from carrier to carrier, it's very consistent with carriers staying in time/sync with the 1' chain pulses which are tracking them.

These carriers then sit there until the section in the transport line is clear. When clear, gate opens, carrier drops out. There is a counter that's reset and that needs to count to some value before the PLC thinks that carrier (load bar) is out of the way.

How does this counter determine whether the load is 25' or 40'? Is this counter counting the load out of the feed line so that the stop may be correctly closed?

How does this counter determine whether the load is 25' or 40'? Is this counter counting the load out of the feed line so that the stop may be correctly closed?

Counters tracking carriers. There are actually a couple counters tracking carriers. These counters only work the carrier traffic for the standard 25' carriers. Propelling these carriers down the line is a number of chain drives with "dogs" attached which are spaced 7' apart.

First off, each carrier entering into this transport line consumes 4 dog spaces. Gate open, carrier drops out into the transport line. Counter 1 resets to 0, then has to count 4 dogs. When that counter is done, the way is clear to drop out another carrier, provided another carrier is not coming by from up stream.

If a carrier id coming from up stream, it's detected before that merge point by a limit switch. This carrier detect resets counter #2 and prevents the gate from opening and dropping new carrier into the one coming from up stream. Counter #2 has to count to 7 dogs before being done. That's 3 dogs to be fully in the way and 4 more to get out of the way.

The physical carrier detection works well for keeping 25' carriers apart when passing these entry points. Counter 1 and counter 2 DN, the way is clear.

The FIFOs (now one COPy) files are used to keep the 40' carriers apart. Kind of like hitting one of those carrier detect limit switches one dog before the carrier gets to it and in a sense, making counter #2 to count 9 dogs instead of 7. Well, not really doing anything with the detect limit switches and counters 1&2, but basically, counter 1&2 are done and there's not a string of 777 777 777 777 444 444 444 or etc passing by in one of the look up addresses of one of those FIFO/data tables. Having one look up address in one single data table will simplify fine tuning the system. (I hope.)

Hope this answers some questions. (probably just makes it more confusing?)

How does this counter determine whether the load is 25' or 40'? Is this counter counting the load out of the feed line so that the stop may be correctly closed?

OOPS!

There is another counter (let's call it #3) which is a clear of stop counter. Gate opens, counts maybe 2 or 3 chain pulses by which time the carrier being released is clear clear of that stop, gate closes.