I am attempting to create a solution, where Queue9 and Queue6 will be searched would be searched making sure the match is available in both queues before one object assumes the position at the combiner.
Thank you
How do I sort through two queues before a combiner searching for matching item types. Making sure that the matches are available in both queues before allowing one to take its position at the combiner?
FlexSim 16.1.1
@Justin Brozzo, did any of the answers below answer your question? If so, please accept one as your accepted answer by pressing the Accept link under the answer so that we'll know that "this case is closed".
If none of the Answers are what you are looking for, was any of them close? If so, could you add comments below that answer to help guide us to what you are looking for?
If you don't mind a bit of code, the attached model matchingitemtypes.fsm uses the Pull logic on the combiner to pull two matching itemtypes from Queue6 and Queue9. When an item enters either of the queue's, the Pull Requirement is called. The code will check the opposite queue to see if there is a matching itemtype. If it finds one, it stores off the itemtype on a label and then pulls the item. This then causes the combiner to call the Pull Requirement on all of the waiting items. We then use the matchedItemType label to find the item we matched previously.
Here's what the code looks like in the Combiner's Pull Requirement:
/**Matching Itemtypes*/
int matchedItemType = getlabel(current, "matchedItemType");
if (matchedItemType >= 0) {
//We previously matched an item so pull the matching itemtype from the other queue
if (getitemtype(item) == matchedItemType) {
setlabel(current, "matchedItemType", -1);
return 1;
}
return 0;
}
int type = getitemtype(item);
//Search the opposite queue for the same itemtype
int otherPort = port % 2 + 1; //Grab the other port rank so we look at the other queue
treenode queue = inobject(current, otherPort);
for (int i = 1; i <= content(queue); i++) {
if (getitemtype(rank(queue, i)) == type) {
//Found a matching itemtype, save the itemtype on a label
setlabel(current, "matchedItemType", type);
//Now pull the item that just entered the original queue
return 1;
}
}
//No matches, pull nothing
return 0;
Hi Justin,
This isn't the simplest thing to accomplish, but I created a sample model for a roundabout way to do this since the combiner really can't handle this kind of logic.
What I did is to first sort all flowitems that come through your first two queues by their itemtypes by sending each to a separate queue. Then the queue for each itemtype makes batches of two and sends the batch to one queue. This is the final queue before the combiner and has a max content of 2. This queue also makes batches of two. I made two connections from the final queue to the combiner so that it can join them. Even though it's not quite the same visually (and you'd have to add as many queues as you have itemtypes), it's probably the easiest way to perform this logic.
You will also want to set up the pull requirement in the final queue so that it doesn't always pull from the same queue. In this case I used the option "Round Robin If Available." Then a bit of code is necessary to make sure that the two flowitems are pulled from the same queue. Enter this in the OnEntry trigger of that queue:
if (content(current) == 1) {
for (int index = 1; index <= nrip(current); index++) {
if (port != index) {
closeoutput(inobject(current, index));
}
}
}
Then in the OnExit trigger of the same queue enter the following:
if (content(current) == 1) {
for (int index = 1; index <= nrip(current); index++) {
openoutput(inobject(current, index));
}
}
Without testing it, I think a global list would do it. The two queues push their items to the list and the pull requirement of the combiner pulls the matching itemtypes from the list. The global list contains a variable of the queue the items stay, if you don't want to evaluate this information out of the item's reference.
9 People are following this question.
