I have 4 conveyors merging into 1. How do I make them send 1 item each onto the merge and repeat again? (abcd abcd abcd and so on)
How do I send 1 item from each merging conveyor the merge and repeat again?
Choose One
Couldn't you use Decision Points and have each conveyor acquire the merge conveyor, release one item, and then release the conveyor? Kind of like in these examples.
I am trying to do this:
It is like a round robin if available, discharge, but discharge to a merge and discharge in your slot
There's probably going to be a few ways to handle this, but I like using Lists for maximum control. So in my example model I have a List that has two sets of tokens interacting with it. The model is found here:
I'm also making some assumptions about how the merge lane wants to receive things, like assuming that you want to keep a strict order of 1, 2, 3, 4 even if something from, say, lane three is ready to release a flowitem when lanes one and two are not; you will always wait for lane one to go first.
One set of tokens represents the Flowitems on the four individual conveyor segments and they are getting Pushed onto a partitioned list using their Type label as a marker for what lane they are on, one through four.
The other token represents the merge lane's availability to Pull a new flowitem onto it.
Tokens representing items are created using an event triggered source when flowitems arrive to decision points on the feeder lanes. The items are then stopped using a 'Stop/Resume item on Conveyor' option from the Custom Code activity. then the tokens are pushed onto the list. When they get pulled, the item will be resumed and will execute a Wait for Event activity that holds the token until flowitem clears one of the gray decision points.
A single puller token is created at the start of the model and will cycle through it's block of activities when the merge lane is "ready" to receive its next flowitem. Right after it's made a Label that I've called PullFromLane will be incremented by 1. When the token first executes this activity it won't have that Label, so it will create it and set it's value to 1. It then executes the Pull from List activity where it looks for items to pull by what lane its in. So if the PullFromLane Label equals 1, it pulls an item from Lane 1, if it equals 2 it pulls from Lane 2 and so on. After the Puller successfully pulls from the list, if the PullFromLane Label is greater than or equal to 4, it is set back to zero otherwise keep its current value. A reference to the pulled item is stored in the pullers item label and is used during the Synchronize activity to make sure that the puller doesn't try to pull from the list again until the item it juist got from the list clears the merge area. The merge area is loosely defined by the gray decision points.
When the item token gets to the Synchronize activity that means it has cleared the merge area, which will release the item token to the sink activity and the Puller token is back to the 'Increment Lane Designation' activity, which allows it attempt to pull from the 'next' lane.
HI Regan,
Thank you, it was very useful.
In the current model, if a lane does not have items, the merge stops, waits for that lane to have an item to release and the resumes. Can we modify that to an if available case ?
Red releases, waits for 3 spots, releases again in the 4th slot. Same with green yellow and blue, but lets say when red releases, the yellow lane is empty. Then red releases after 3 slots until yellow is available again.
Thanks,
Nivedita
I'm not sure if I'm quite following what you mean, but I think you get what you want if, rather than using list partitions you could add a 'Type' field to the list that looks at the item's Type value and use an Order By query on the Pull activity that does an ascending sort on the requests on the merge lane:
My question is : I do not want to maintain a strict order of 1,2,3,4. If 3 is empty, the merge will not wait and do 1,2,4; 1,2,4; until 3 is available and then it resumes 1,2,3,4.
If 2 and 4 are not available, it keeps doing, 1,3; 1,3 until 2 becomes available and then does 1,2,3; 1,2,3 until 4 becomes available and so on.
Order by ASC should send items as FIFA in the order in which they come in. Is that correct ?
The Order By query I mentioned would release things from lower numbered lanes first if there are more than one thing waiting for the merge lane, so I don't think that's what you want.
Attached is a modified version of the original model that adds a Wait for Event for the puller token that will hold the Puller until something from the feeder lanes becomes available for the merge lane. I'll explain why I feel like I needed that below.
I also changed the pull from list to use a max wait timer of zero seconds. I did this so that if nothing is available from lane one, I can route the token back to the increment lane designation activity and check subsequent lanes for available items. This will make it so we aren't forced to pull from lane one first; whatever lane has something available will be pulled instead.
This is where the Wait for Event comes in; if all the lanes are empty, and there is a wait time of zero before attempting to re-pull from a new lane, the token gets into an infinite loop which halts the model. So The Wait for Event right after the Puller Source is there to prevent that by only permitting the Puller to look at the List if there is something to potentially Pull.
I also added two activities after the Synchronize. I create a label that stores the number of entries on the list (IE. checks if the List has items ready to be pulled on the feeder lanes). If there List has entries to be pulled we route the puller back to the pull activity to find something to pull, if the List is empty it goes back to the Wit for Event until something shows up in one of the feeder lanes.
8 People are following this question.
