While functions

I have a model that has four processors and multiple itemtypes

One itemtype "Item 1" in particular will essentially take up space on each processor

and it cannot start if the other processors are occupied and any subsequent items, excluding those of the same type, have to wait.

I was thinking I could use a "while" loop that only allows the processors to accept items from a queue if an "Item 1" is not waiting in an effort to empty the four proccessors.

Then I wanted to use another while loop to keep the other itemtypes off of the processors until "Item 1" was finished.

Where do I need to write the code for the loops, and if anyone has any suggestions for code I could use it would be greatly appreciated.

Xavier,

If you were to write a while loop to finish this it would most likely cause an infinite loop or a case where nothing more happened after the first event. This is because Flexsim works with events and as such needs to be coded in events and not as if it where a normal program.

To stop other processors from recieving material once a processor has recieved an item type 1 you can put code in the OnEntry trigger of each processor. The code will need to have an if statement that checks for item type 1 and if true then closes the input ports of the other processors. To allow the other processors to recieve material after the item type 1 has left you will need code on the OnExit trigger of each processor. Again, the code will check for item type 1 and if true then it will open the ports of the other processors.

Now, to get the processor with item type 1 to wait until the others are empty. In the OnEntry trigger or each processor you will need to check for content in each or the other processors as you close their input ports. If there is content then you can call stopobject on the current processor with item type 1. To resume the the current object you will need an else statement added onto the if that we put in the OnExit trigger of the processors. The else statement will fire if the item type is != 1 and will check to see if one of the other processors has and item of type 1 and if so then it will need to check to see if the other processors are empty. If they are then it will call resumeobject on the processor with the item type 1.

So you will need to use some if statements, for loops, and the following comands:

content()
stopobject()
resumeobject()
openinput()
closeinput()

Good Luck,
Brandon

Hello,

I want to create a while-loop in a queue which will be triggered on message and has the objective of releasing all items which fulfill a condition.
I wrote the code but it seems like it's working only for the first item in the queue and ignores others.

What could be the problem?

treenode current = ownerobject(c);
int horizon = 150;
int noofitems = content(current);
int index = 1;
while(index<=noofitems)
{
 if(getlabelnum(rank(current,index),"ReleaseDate")<=time()+horizon)
{
releaseitem(rank(current,index),1);
}
index=index+1;
}

Thanks.

Hello Yasemin,

the first step is to have a look at your code:

In this case you wrote, everytime you release an item you loose one in the row.. i.e. index = 150 then item 150 will be released, this cause that the next item decrease his rank from 151 to 150.. so your code didnt recognize it.

The next issue, maybe the releaseitem - command is not the right command in this case, maybe the moveobject command will be better.

Hope this helps you a little bit..

Regards
Tobias

Thank you Tobias, I think you're right about the logic of the code.
But I'm not sure that I got your point in suggesting the "moveobject" command. Wouldn't it cause the same error to happen in the code? Or do you have another reasoning for suggesting it? Because I've tried that command also and the model acted exactly the same as it did when using the other one.

My second issue was caused by the Documentation..

"releaseitem - This command should only be used if the flowitem is in a BasicFR object and the flowitem has not been released already, or if it is any FixedResource and has been held with holditem()."

But maybe its no problem..

Tobias, thanks for the explanation. I've read the documentation also, still I couldn't understand the exact difference between the two commands, but they seem to be giving the same results in my model.
I think I should work on the code to get over the problem.

Yasemin,

In the flow tab of the queue you can select "Do Not Release Item" and then it would be OK to release the flowitem the way you are doing so.

I personally wouldn't use a while loop here. They are too easy to get wrong and you have to manage the count yourself. It would be easier for you to have used a for loop: for(index = 1; index <= noofitems; index++)

One problem with your loop is that you are going in the wrong direction; meaning that you should have a for loop that looks like this: for(index = noofitems; index > 0; index--) The reason for this is that when you release the item it is possible that it will immediately leave the queue before you continue on with the loop. This means that when you started the loop you expected to have 10 items but after the first release you only have 9. This causes two problems, first, you will try to look at items that don't exist. Second, you will skip objects. This happens when you release an item (say rank 1) and it leaves the queue then the next itteration of the loop will look at the object ranked +1 (rank 2); however when the first object left the next object became that rank (2 became 1 and 3 became2, etc.). So you will loop through the items 1, 3, 5 instead of 1, 2, 3, 4, 5.

So I would try a for loop that goes in reverse order first and see if you are still having a problem.

If you have to go in order from low to high (1 to content) then try the for loop below (I picked this one up from looking at some of AJ's code):
for(treenode tobj = first(current); objectexists(tobj); tobj = next(tobj))

Good Luck,
Brandon

Thanks to Brandon I have abandoned while functions for my current model but I still have not gotten my model to run as I need it to. Thanks for everyones help.

I have four processors accepting two itemtypes. When one of the itemtypes enters a processor it checks to see if there are any of the other itemtype on the other processors, if there is, it stops itself.

{
if ((getitemtype(item)) == (3))
{
if(
        (
            (content(centerobject(current,1)) == 0) ||
            (getitemtype(first(centerobject(current,1))) == 3)
        ) 
&&
        (
                (content(centerobject(current,2)) == 0) ||
                (getitemtype(first(centerobject(current,2))) == 3)
    )      
    &&
    (
        (content(centerobject(current,3)) == 0) ||
        (getitemtype(first(centerobject(current,3))) == 3)
    )
)
{colorlime(item);}
else
{stopobject(current,1);}
}
else{coloryellow(item);}
}

The colorcolor code are simply visual cues for me to check how if everthing is working.

The resumeobject command is in the on message trigger of the processor.

and the message is sent from neighboring on exit triggers

/**Custom Code*/
treenode item = parnode(1);
treenode current = ownerobject(c);
int port = parval(2);
{
if (getitemtype(first(centerobject(current,1))) == 3)
{senddelayedmessage(centerobject(current,1),.1,current);}
}
{
if (getitemtype(first(centerobject(current,2))) == 3)
{senddelayedmessage(centerobject(current,2),.1,current);}
}
{
if (getitemtype(first(centerobject(current,3))) == 3)
{senddelayedmessage(centerobject(current,3),.1,current);}
}

the stopobject trigger seems to be working but any Item that gets stopped never resumes visually(I have visual tools displaying the state and I can see that the processors move to Idle and back to Setup but nothing moves). It sits on the processor simply for its process time + setup time not moving then immediately moves to the next downstream object. It has not taken into account the time it was stopped.


also for an "on exit" trigger has the exiting flow item left the object when the trigger happens? if not, how delayed a message would I need to guarantee that the trigger fires properly and is not affected by the next flowitem to enter the processor. I have tried this code with delay time 0 and .1

Each processor has the same code and are centrally connected to the other processors on ports 1,2 and 3.

The following information may be extraneous
Process time is based on the division of two labels on the item
There is also a create and initialize label code on each on entry and exit trigger.
There is also a setup time asking if the itemtype has changed.

Thanks again for any and all assistance

Xavier,

Here is a model that should do what you want. There are a number of issues that you should be aware of.

First, use resumeinput and stopinput instead of closeinput and openinput. The reason for this is as follows: assume that you have an itemtype 1 tat is leaving the processor and it calls open inputs on the first of the other three processors. That processor in turn gets an itemtype 1 and calls closeinput on the other three processors. Now the code gets back to your loop where you call openinput on the other two processors, essentially undoing the closeinput from the first processor you opened. Stopinput and resumeinput will keep this from happening.

Second, send a delayed message to resume the input of the other processors. If you don't then it is possible that one of the other processors will get an itemtype 1 and will count the current processor as already having a flowitem. This happens because the OnExit trigger fires before the item leaves the processor. A delayed message will allow the current item to leave before we resume the other objects. There are other ways to deal with this situation, like checks with if statements but I wanted to keep it a little more simple.

Good Luck,
Brandon

Brandon, thank you very much for the explanatory answer.
I tried your code and -needless to say that- it works without any problem.

Brandon

I went back over both of our models and they seem to be having the same problem.

the items are being stopped correctly which means any code that stops an item or closes a port is working properly, but

when the item should resume, it does not and it finishes its process at the time its process would have finished if it had never been stopped which is too soon.

Xavier,

The problem that we were having is due to the fact that the stopobject command works by delaying all of the events on an object. However, there weren't anyevents on the Processors when we were calling stopobject because the OnEntry trigger fires before the Setup Time or Process Time triggers fire and create a new event. So, after we were calling stopobject the same stream of code (same event) executed the Setup Time trigger which returned 0 an then the Process Time trigger that created the new event as normal.

I moved the stopobject code to the message trigger and fired a delayed message on entry and the problem was solved.

I included a new model (same name) that has the fix.

Good Luck,
Brandon