Implementig Conwip Control

Hi,

I got a simple production line like this:

Source => JobQueue => Queue1 => Processor1 => Queue2 => Processor2 => Queue3 => Processor3 => Queue4 => Processor4 => Queue5 => Processor5 => Sink


And I want to use CONWIP to control the WIP of this production line.


I set two global variables:

1. MaxWIP (Experimenter Variable)
2. CurrentWIP (Initial = 0)

The JobQueue has an infinite maxcontent and should every job that comes.

The acutal production line starts with Queue1 and ends with Processor5. Therefor I set these objects to a group.

Now I don't know exactly how to control the flow from JobQueue to Queue1.

First approach

• onentrytrigger job queue:
  • if (CurrentWIP<=MaxWIP)
    {
    openinput(outobject(current,1);
    }
    else
    {
    closeinput(outobject(current,1);
    }
• onentrytrigger Queue1:
  • CurrentWIP = CurrentWIP+1;
• onexittrigger Processor5:
  • CurrentWIP = CurrentWIP-1;

Doesn't work properly, the CurrentWIP is far more than MaxWIP (in that case 9).

Second approach:

• onentrytrigger Queue1:
  • if (CurrentWIP<= MaxWIP)
    {
    openoutput(inobject(current, 1));
    CurrentWIP= CurrentWIP+1;
    }
    else
    {
    closeoutput(inobject(current, 1));
    }
• onexittrigger Processor5:
  • CurrentWIP = CurrentWIP-1;

Doesn't work at all. Nothing exits the Job Queue.

Thanks for your help!

Congshi

If you're not using transport to move the items from the JobQueue then the exit of the JobQueue can just be:

WIP++;
if (WIP>=WIPlimit)
closeoutput(current);


And on the entry to the sink:

WIP--;
openoutput(JobQueue);

If you know that the items leave JobQueue on port one, then this is a solution with transport.

On the SendTo of the JobQueue:

if (WIP<WIPlimit){
WIP++;
return 0;
}

return -1 ;

And then on the sink entry:

WIP--;
for (int n=1;n<=content(JobQueue);n++){

if (getnodenum(first(itemtype(rank(JobQueue,n))))==FRSTATE_INQUEUE){

releaseitem(rank(JobQueue,n),1);
WIP++;

break;
}

}

Thanks,

this solution is great because it is so simple ;-)

Sorry,

but I got still two questions left:

What is

itemtype and FRSTATE_INQUEUE?

And, in which case it is better to use

- the send to funtion: only send (return 0) if WIP is lower than WIPlimit, otherwise return -1 (== closeoutput)
- the onexit trigger function: closeoutput if WIP reachs or exceed WIPlimit

to control the flow out of the JobQueue?

Thanks!

Thanks!

The itemtype node of the item has underneath it another node (rank 1) which is used to flag whether it's scheduled to move out already - I'm just using that to see which ones are new items to be released, rather than ones that are are already released and just waiting to be moved.

If you plan to use transport to move items from the jobqueue, the first (simple) method will not work.

There are commands to access all the information under the itemtype node. For this case, you should be using getitemstate()

if(getitemstate(rank(JobQueue,n))==FRSTATE_INQUEUE)

In a previous post it is said that:
You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers!
http://www.flexsim.com/community/for...+code#post1877

You suggested to use the closeoutput(current) command. Could it be problematic?

There is a difference between opening and closing special ports and to open or close the output and the input in general.

Jörg

Originally Posted by Congshi Wang

In a previous post it is said that:
You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers!
http://www.flexsim.com/community/for...+code#post1877

You suggested to use the closeoutput(current) command. Could it be problematic?

Opening ports using openinput() or openoutput() in an OnExit or OnEntry triger can be problematic. If you have problems with your model because you are using these commands, put them into a delayed message in 0 time instead. These commands are problematic in certain situations. If you are unsure whether it is going to work correctly or you just want to be safe, don't use them in OnEntry or OnExit. Presumably, Jason tested his code and it worked fine. If it didn't work properly, he would have put the code into a delayed message. If you modify his code and it no longer works properly, you should put the code into a delayed message.

From the command documentation on openoutput():
"It is advised that modelers never use this command in any field other than the OnMessage field which has been triggered with the senddelayedmessage() command, because commands which open ports often spawn several other activities that shouldn't be performed during transitional events."