RSLogix 500 - Unit tracking and multiple unit load/unload

[Lancie1]

I need to know if there is a unit in either of these [exit] queue spots...

That should be easy with one bit indicator: If BOTH photosensors for the exit queue are OFF(empty exit points), then turn on the indicator bit for "EXITS AVAILABLE". The 2-unit Exit Queue is your worst bottleneck, so ony do the Exit mode or Empty step when both exit points are empty.

...and/or if there is one or two units currently exiting and enroute to fill these spots. If this is true, I need to prevent any other unit from exiting until there is an open queue.

(1) For efficient traffic control, divide your program into two rough steps or modes: Fill Workstations, and Empty Workstations. During FILL, all empty workstations are filled with units, highest empty workstation number filled first, then second highest. Then you switch to the EMPTY mode, and wait until TWO units are processed ("WAITING TO EXIT" bits are ON), allow those units to move to the exit queue in reverse order, then switch back to FILL mode. This two-step process allows the maximum movement of units with the least chance of a collision between entering and exiting units.

(2) Set up two 24-bit memory areas for all workstations (N7:1/1 to N7:2/9 for Workstations 1 to 24 in process mode). If a workstation is "processing" turn the "PROCESSING" bit for that workstation ON.

(3) After some T maximum time (longest possible processing time for that workstation) with that bit ON, set another bit in another memory area (N7:3/1 to N7:4/9) for "WAITING TO EXIT".

(4) When the "EXITS AVAILABLE" bit is ON, find the first two units allowed to exit by searching the "WAITING TO EXIT" bit locations in reverse order (highest bit first, then next highest). The reason for this is to avoid traffic jams. If you let the farthest-downstream finished unit exit first, then the next upstream, and so on, you will avoid collisions on the main conveyor. When two units Waiting to Exit are allowed onto the main conveyor, then you reset the "EXITS AVAILABLE" bit and also the "PROCESSING" bit for that workstation so that no more exiting units are allowed, and the FILL mode is restarted.

(5) You will need some time delay between EMPTY and FILL mode, to make sure that the last exiting unit is out of the way. The length of this time delay will depend on the time for a unit to travel from one station to the next. Set the timer delay to T, where T is the time for a unit to travel from one station to the next. Because the workstations are being filled highest to lowest, an exiting unit only has to about 1 workstation down the conveyor before another entering unprocessed unit can be started.

 

[MichaelG]

(4) When the "EXITS AVAILABLE" bit is ON, find the first two units allowed to exit by searching the "WAITING TO EXIT" bit locations in reverse order (highest bit first, then next highest). The reason for this is to avoid traffic jams. If you let the farthest-downstream finished unit exit first, then the next upstream, and so on, you will avoid collisions on the main conveyor. When two units Waiting to Exit are allowed onto the main conveyor, then you reset the "EXITS AVAILABLE" bit and also the "PROCESSING" bit for that workstation so that no more exiting units are allowed, and the FILL mode is restarted.

I would have thought that you would need to search from the last position that you checked - otherwise you may never empty the first slot

Smarter would be to be able to load and empty at the same time - order of complication is harder


Merry Xmas (10 am ) been Skyping to the US and UK already

 

[Peter Nachtwey]

There are "tracking" capabilities within any PLC application, the A-B SLC family using the FIFO (First In First Out)

The FIFO won't work. You can't InQueue and DeQueue from any play in the queue but a circular queue would work.

"stack" instruction, however, just the study of your application would require days even for an experienced application engineer.

Better not. An experienced application engineer has done a project like this before. That is why he is experienced.

Maybe you should seek help from an integrator and improve your programming skills while working together.

That is a good idea.

I would keep track of the positions in a circular queue and by encoder position. I would keep track of which widgets have been process with a bit.
With careful planning one can insert widgets between the gaps between widgets. The stations would have to be able to keep from putting a widget back on the conveyor until there is free space. It would be good to be able to hold up the widgets from even going on the conveyor or to speed the conveyor up to create more space between widgets if necessary and slow down the conveyor when it isn't necessary. A lot has to do with how long it takes to process with widgets at each station. Think of the optimal solution. It may be able to quickly pay for itself in no time if the current solution is wasting a lot of time.

I would hold out for a Compact Logix for this.

Surely someone has done a recirculating wood sorter system or something similar.

 

[Lancie1]

would have thought that you would need to search from the last position that you checked - otherwise you may never empty the first slot

That might be true, and certainly would be an easy option to implement. I think whether there is a problem emptying all slots will depend on the process time/exit time ratio. But Mike said the processing time is from 2 to 20 minutes. The exit time is only 30 seconds. Based on the ratio of process time/exit time, I don't think that that emptying the first slot will be a problem. If the last slot starts processing first, then the workstations should empty roughly in the same order, with exceptions for the stations that require more time. Several 2-minute stations may cycle before one 20-minute station finishes, but so what?

I think the goal is to maximize the flow of product, not to maximize the quantity of stations serviced. Because they are doing different jobs with different operators with different skills, and require different times, then maximizing the quantity serviced would not help the bottom line. But that will be a company decision, probably not left to the programmer.

 

[jdbrandt]

All,

If anyone has suggestions I would greatly appreciate them. I have attached an image I created that shows the layout of the area and the locations of the I/O.

I would be happy to provide additional information if any is needed.

Thank you everyone!

Mike

One approach would be to think simply, first of all.
Keep in mind that most of the existing logic will be trashed in this process. Trying to keep it in service will cost more time and frustration than it will save.
I've done a line like this, and the key is to identify the various 'tasks' that a section of conveyor is doing:
* Loading from xxx
* Unloading to yyy
* Idle while processing.
Also, relative to the "stations", they will have statuses as well:
* Being Loaded
* Unloading to ....
* HOLD while processing.
Generating these statuses and tasks will make the entire project easier...especially when troubleshooting.
The suggestions from the others, with regard to FIFO and LIFO type instructions are simply too complicated to implement, and impossible to maintain in the real world, in my experience.

Standard Disclaimer: The subject matter stated above is the opinion of the writer, based on the writer's experience, and offered with no warranty, in response to the originator's specific request.

 

[mwesely12]

All,

I apologize for my delayed response as I have been spending the holidays with family. I appreciate everyone's comments and suggestions and I will try to respond to them all.


dmargineau
I see how the FFL instruction would enable me to track the order in which units are ready to release. (After the process is completed, an operator manually signals the process end, and "releases" the unit for unload via a pushbutton. "Release" time is critical so we try and control the process so that no more than 3 units are released at a time.)


Lancie1
I walked through the link provided by Mickey about the BSR, but it appeared to me that only a single prox was used to activate the shift. Would it be possible to activate a shift through a word with multiple proxes?

There are currently 12 proxes along the main conveyor, one at each cross transfer. Would it be possible to set up a 12 bit BSR so that each bit represented one of the transfers and when a unit reached each prox the "1" would shift to the appropriate bit?

We do not currently have an encoder. Is this a simple installation? Theoretically, I would like to believe that the conveyor moves at a consistent pace, but I often observe large variability in speed between pallets moving along the conveyor.


cwal61
I think I am following your suggested logic, but I do not have any experience with the MOV instruction and to be honest, I'm not entirely sure what a register is. One concern I have is the possibility of allowing a unit to enter the system when there isn't an available station open, or if there is a station open and another unit is already en-route to load, but has not yet reached the open station. I would like to avoid any possibility of getting an unprocessed unit stuck on the main conveyor.

Currently, operators are not able to "add or slide" units. The only way units are able to move is if an operator signals that the unit is clear to release, and the system recognizes it.

With this logic, would a unit then have to stop at each transfer while it was entering/exiting to allow the MOV to process and the system to "read" that units state?

I would like to look into this option further!


MichaelG
Yes, any unit can go into any processing station. Each of the stations are identical in function.

We have recently been experimenting with using timers for this particular process on one of our lines, but it is not yet decided if this will remain.

For the sake of this discussion, I would say no, we do not know how long each unit will take to process.

The process does flow left to right according to the diagram. Currently, if there is a unit entering, no other units are able to enter behind it. In your example, if Station 09 was loading, nothing upstream would be allowed to move until the load process had completed and the transfer returned to the down position. The conveyor itself does not physically turn on or off.


The Plc Kid and nehpets
If have thought about the possibility of using RFID, but I was not aware if you could integrate the RFID with the RSLogix 500.

I am assuming that this would act similarly to cwal61's proposal? I would need the capability to read a tag at each station and then rewrite that it has been processed?


Doug-P
Referring to the diagram:
Yellow Circle - Proximity Switch (there is a prox at each station and at each transfer)
Blue Dot - Solenoid pins that hold units in place in the station
Green Funnel - Paddle Stop that catches pallets as they travel along, these are normally down and out of the way unless a station has "requested" a unit to enter and load
Purple Oval - Proximity Switch that confirms whether the lift transfer is raised or lowered



to be continued...

 

[todster]

It's not offered as a solution, just probably a not so brilliant idea.
You should be able to calculate time and distance. You know how far apart the prox sensors are. Use this to calculate conveyor speed and distance. Calculate the size of a tray or whatever plus additional space on each side for slippage or movement. Call this area a ZONE.

Track this ZONE through each prox sensor on the mainline. Each mainline prox sensor acts as an update and confirms if the item is there or not. The prox in the work zone will act as a divert confirm/item present. As the ZONE travels along, you toggle on or off bits that indicate whether the ZONE is empty or full, contains an unworked or worked piece, is from odd or even side, is headed to odd or even side, and a few other things you'll think of later.
Say N7:21 and N7:23 represent odd stations done and occupied. N7:22 and N7:24 represent even stations done and occupied. The bits could reflect whether the part is unfinished or finished and signal that it is ready to be re-introduced. The bits then get moved to N7:x:y when the item is moved back in a zone.

You're still going to have the same problem Daba mentioned unless you inhibit the Intake when all stations are occupied or there is more than enough on line to fill unoccupied downstream stations.
If for example N7:x/4 represents an unfinished item, it could be identified if it did slip through and reached end of line. It could also be used on the fly to schedule items for downstream diverts to open workstations. RFID will tell you the same thing N4:1/4 did....an unfinished part reached the EOL.
With a little creativity, a timer could be created that tracks the time it takes to go from Mainline update to update. This could then modify the travel timer to account for speed changes. You could also do something similar with the COP for the timers acc and then average them.

Oops, gotta go, my ride home just showed up...

 

[mwesely12]

continued...


Lancie1
I believe the processor is the
1747-L543C 5/04 CPU-64K Mem. OS401 Series C FRN 3-8

I attached a zipped file of the current coding that I am working with.

During FILL, all empty workstations are filled with units, highest empty workstation number filled first, then second highest. Then you switch to the EMPTY mode, and wait until TWO units are processed

This is similar to how the system currently works. First a unit is allowed to enter, and then a unit is allowed to exit and it cycles back and forth. If possible I would like to enable units to be doing both at the same time to overlap travel time. Currently the travel time for a single unit is very close to the entire lines Takt time and this process often paces our line. I need it to be capable of filling/emptying faster than the rest of the line.

When the "EXITS AVAILABLE" bit is ON, find the first two units allowed to exit by searching the "WAITING TO EXIT" bit locations in reverse order (highest bit first, then next highest).

If I had these WAITING TO EXIT bits set up, how would I scan through and enable one station to activate the unload sequence at a time until my queue spots were filled? Would this be another application for FIFO? The WAITING TO EXIT bits would have to be triggered by the operator after they have disconnected the unit rather than with a timer. So there should be a maximum of only two or three units WAITING TO EXIT at a time.

Several 2-minute stations may cycle before one 20-minute station finishes, but so what?

I think the goal is to maximize the flow of product, not to maximize the quantity of stations serviced. Because they are doing different jobs with different operators with different skills, and require different times, then maximizing the quantity serviced would not help the bottom line. But that will be a company decision, probably not left to the programmer.

It is very seldom that a unit will only be in process for a few minutes. This is only if it is a bad unit. Typically, each unit will be in-process for 13-15 minutes.

There are two operators for the whole system, one for each side. The majority of the work is machine time. Operators are only there to connect and disconnect units. And you are correct. The goal is to maximize flow through the system.


todster

You should be able to calculate time and distance. You know how far apart the prox sensors are. Use this to calculate conveyor speed and distance.

I would be nervous to rely on calculated time/distance. The pallets and the conveyor itself are not in the best shape and it is not uncommon for pallets to get stuck or hang up on a loose screw, etc.

Track this ZONE through each prox sensor on the mainline.

I have been trying to create moving zones along the conveyor to determine that the conveyor up/downstream is clear. I have done this by confirming that no units are currently traveling over a prox and no lift transfers are raised.

However, I am not sure how to use a similar method to track whether the unit is processed or not.

 

[mwesely12]

Is this possible?

I am wondering if there are tools in RSLogix that would enable me to do the following:

Unit Entering System and Loading into a Station

Example:
Scenario
- I have a unit that is waiting to enter onto the main conveyor through the system.
- Station 18 is available and ready to accept a unit.
- There is not a unit already en-route to fill Station 18.
- All of the pallet stops default in the down position unless they are about to catch an entering unit to transfer it into an adjacent station. (This allows exiting - units to freely and quickly travel out of the system)

Goal
I would like to be able to send an entering unit down the conveyor into a station (example 18) and have the pallet stop at (18) raise as soon as the unit hits the prox at (16)

This would enable a processed unit to exit upstream of (18) and pass over the transfer at (18) without being mistaken for the entering unit and transferred into (18)

Is it possible...
Is it possible to set up a BSR or something similar so that each bit (1-12) represent one of the prox's along the conveyor?

So when the unit gets called to Station 18, the BSR (or whatever it may be) is activated once the unit hits the prox at Stations 1/2 and the "1" shifts along as the unit reaches each additional prox. Then when the unit reaches the prox between Stations 15/16 it will trigger the pallet stop at Stations 17/18 to raise and catch the unit.

Is it also possible that this sequence can only be activated when an entering unit crosses the first prox? This would prevent an exiting unit from disrupting the sequence as it crosses proxes on its way out.


Thank you!

 

[Lancie1]

Lancie1: There are currently 12 proxes along the main conveyor, one at each cross transfer. Would it be possible to set up a 12 bit BSR so that each bit represented one of the transfers and when a unit reached each prox the "1" would shift to the appropriate bit?

Is it possible to set up a BSR or something similar so that each bit (1-12) represent one of the prox's along the conveyor?

Yes indeed it would be possible. A BSR can be triggered by more than one bit, if none of the trigger bits are ON at the same time as another (they operate in sequence and not in parallel).

To make a BSR useful, you have to ask the question "how will this be more useful than simply using the 12 prox switch inputs as they are?" In most cases, the reason to use a bit-shift instruction is to track the movement of an object, package, or part. Using it to track prox switch operation does not seem to add a lot of value. Could you instead use a BSR to track each unit as it moves through the prox switches? Now that sounds like it could be very useful. You may need a 24-bit BSR if you have 24 stations and they all can contain a unit.

Is it also possible that this sequence can only be activated when an entering unit crosses the first prox? This would prevent an exiting unit from disrupting the sequence as it crosses proxes on its way out.

Yes, as I wrote before, you need to set up Step or Direction Relays, EMPTY and FILL. When units are Exiting and the EMPTY Relay is on, then the remaining proxs in the exit path are sealed out (ignored).

EDIT: I have uploaded your RSLogix program and am studying it. Lad 2 is 512 rungs, a lot to digest. I assume that Lad 3 and Lad 4 are works in progress. I do not have a clear picture of how the each transfer station operates. I think it would be useful to everyone who is trying to help, if you could write a short description with the Steps (1, 2, 3, ectera) to (a) move a unit into a workstation, and (b) the steps to move a unit out of a workstation.

 

[MichaelG]

Lancie, mwesely12

The first thing I think to get right is the tracking, I think that we can put this on top of the existing code

My idea for tracking is to have a Table with One location for every place that a pallet can be located

I would not use a BSR - it does not mimic what the conveyor does when you raise and lower paddle stops, especially for later when you are unloading and loading at the same time

A couple of rules for the tracking - and the code
1) Only one pallet is permitted between stops (I am calling these zones)
2) A pallet is tracked into a Zone when the upstream stop is down, the PE is ON and the conveyor is running (I expect to always have the conveyor running)
3) A zone is marked as clear (oneshot) when the PE turns OFF and the Stop is Down
4) Station Load- This is Clears the Tracking for that Zone once the Stop lowers
5) Station Unload - This fills the Tracking for that Zone Zone once the tracking lowers



I would track numbers - The number is positive for loading Station number Negative for unloading Station number

Zone 1 - Infeed Zone
Zone 2 - for Stations 01,02
Zone 3 - for Stations 03,04

The tracking number is in one or two zones at a time, eg
Pallet in Zone 2 has Tracking number is 08
as the pallet passes PE 01,02 (PE on and Stopper Down) the tracking number is "loaded" into Zone 3
Tracking number 08 is in Zone 2 and Zone 3
As the end of Pallet passes PE 01,02 (PE turn off) Zone 2 is Cleared
Tracking number 08 is only in Zone 3



Code for each Zone
Permit Pallet to next Zone - Lowers the Stop
* Next Zone is Empty - able to receive Pallets
* Pallet is Not for Either of this zones work stations (eg Tracking number = 01 or 02)
* Load or unload Sequence is not running
* NEXT Zone is Requesting an unload sequence (gives unload precedence onto the conveyor)

Code for Load
Run existing sequences if the Tracking number is for this workstation
* Stop raised
* Pallet at the Stop
* Tracking Number = 01 or 02

Code for Unload
Run Existing Sequence if Conveyor is Empty and Unload Supervisor Permits
* This Zone Tracking is empty
* Previous Zone is Blocking
* Unload Supervisor Permits ( this is where you maintain 2 pallets on the outfeed and cycle through the stations )


Code for Infeed
A workstation is Empty - Load the Station number into Zone 1 and release down the conveyor
* Load Supervisor determines which Station to load
* Zone 2 is empty
* Zone 2 is Not Unloading


Load and Unload Supervisors - see another post

 

[cwal61]

One concern I have is the possibility of allowing a unit to enter the system when there isn't an available station open, or if there is a station open and another unit is already en-route to load, but has not yet reached the open station. I would like to avoid any possibility of getting an unprocessed unit stuck on the main conveyor.

Does the existing code allow this to happen? I would expect a Line Full condition to not allow that or a tote in transport to stop next tote until provisions are true for release.

I think I am following your suggested logic, but I do not have any experience with the MOV instruction and to be honest, I'm not entirely sure what a register is.

Register = a word or N7 file. MOV instruction? click help and choose instruction help. That's the best way to learn how all the instructions work.

Maybe consider Lancie's offer to help. He is more than capable. He has done so with others here and is very knowledgeable. He is probably all ready working on a solution since you posted the program. Good Luck and keep us posted.

P.S. Welcome to Form and the world of PLC's
.

 

[MichaelG]

Starting Design Ideas for comments

Unload Supervisor

* System waits until there are less that 2 unload pallets on the line or waiting to get onto the line
(Checks every Zone for station unload permitted or unloaded pallet, (be wary of duplicates) including the two outfeed Zones)
* It then cycles from the current zone until it finds a station that needs unloading
* That Station is then permitted to unload
* Loop back to top



Load supervisor -

Cycles through all stations for an empty station - when found place into a FIFO stack for release
Definition an empty station is
* Station PE is Off
* Not already in the FIFO queue
* Station number not in found in the tracking

Question - would it be better to do
Set empty when Station Zone tracking number is -ve Station
Reset when Zone 1 = Station number
Reset if Outfeed Zone = Station number ( Load error occurred )

 

[Lancie1]

MichealG, You made some good comments and offered some good solutions.

The first thing I think to get right is the tracking, I think that we can put this on top of the existing code

The existing code that we have from Mike is very long and convoluted. The rung explanatory comments are missing. There are over 5000 addresses and symbols in the program, but only 1100 are used. The PLC I/O is not configured, only has the processor but no I/O. I assume that Mike deleted parts of an existing program, maybe to protect the innocent!

My idea for tracking is to have a Table with One location for every place that a pallet can be located

That could be made to work. I suggested a table of words, with a bit position for every location (1 = Unit Present, 0 = no unit present).

I would not use a BSR - it does not mimic what the conveyor does when you raise and lower paddle stops, especially for later when you are unloading and loading at the same time...

I also do not see a clear way to use a bit-shift instruction AT THIS TIME. That does not mean that someone will not come up with a good method. The key is to find a way to track all units through all positions. That is probably going to mean a combination of methods. It may even be that it is not necessary to track ANY units. The goal is to move the maximum number of units to the exit point, so maybe we shouldn't care where they are between Point A and B?

 

[Doug-P]

My idea for tracking is to have a Table with One location for every place that a pallet can be located

A good place to start.

I'm just throwing this out for consideration: Our system is set up to track by the load blocking/unblocking PEs. This means when a load blocks a PE its destination is moved into a register. When the load UNblocks that same PE its destination is moved the next (sequential) register and so on. This provides some visibility for the time when the load is "in between" PEs.

For a system like this I'd just use the workstation number as the destination and set up the divert logic accordingly. Outbound loads could be given almost any code other than 1-18. As far as the release side, I'd set up an integer pointer sequencer to check for loads available to release - ie.

1. check station X for outbound work
2. if so release X when space is available else
3. check X-1, etc.
4. after checking station 1 reset to check 18 and repeat

This is necessary to insure that the stations farthest downstream get an opportunity to release.