Release Only When Operator(s) Ready

Hi,
This is probably a simple problem but I haven't been able to find any related solutions in the manual or forum.

Model Description: A queue outputs items to 3 processors and, if all the processors are full, to another queue which delays the items. The processors require operators to process, the number of operators dependent on the itemtype and assigned using a global table and the following code:
setvarnum(current, "nrofprocessoperators", gettablenum(tablename,row,col));
The delay queue holds an item for a set amount of time before attempting to send it to an open processor once more. If all processors are full again, the item is sent to a sink.

Here is a picture of the model:


My dilemma is that I would like the queue not to release an item unless enough operators are available to process it. Currently, items are moved to the processor and can wait until the required number of operators are available to process it. I've tried the Pull option on the processors with no success. I considered requiring an operator to transport an item and then carry on with a tasksequence but wouldn't that disrupt the table assigning multiple operators? Is there are way to close the ports which output to processors until the "nrofprocessoperators" variable is less than or equal to the number of idle operators?

Thanks so much for any suggestions you might have, it is greatly appreciated!

Kellen

Hello Kellen,

my first idea is, give the number of operators you need a new utilize task in their actual tasksequence as further task. Otherwise dispatch a new utilize tasksequence with high priority explicitly to them. If all needed Operators are in the utilize task let the processor free those operators and then pick them by releasing the item.
Have a look in the pick operators function: Multilple Teams Number of Dispatchers.
To prevent that the freed operators do something else let the pick task be of the preempting type: preempt only with the highest actual priority of all tasksequences.

It is really advanced stuff

It isn't tested on a real model.

Jörg

Thanks Jörg, I'll give that a try

Kellen,

Did you find a solution to your problem?

Brandon

Originally Posted by Brandon Peterson

Did you find a solution to your problem?

Nope. I tried a couple things with no luck and set the problem aside for a few days.

Kellen,

First, you can check to see if an operator is available by checking for an active task sequence.

if(objectexists(gettasksequence(centerobject(current, 1), 0)))
{
  //Operator has TS
}else{
  //Operator has no TS
}

You could also try checking to see if its state is IDLE but you run the risk there that it may still have a task sequence for some reason (say it was given a delay task with a state == IDLE).

if(getstatenum(centerobject(current, 1)) == STATE_IDLE)
{
  //Operator has TS
}else{
  //Operator has no TS
}

Using one of these two methods you could loop through the operators to find the total number available.

Second, you will need to find a way of securing the other operators so that you don't have two items that each need two operators both thinking that they can go to a processor at the same time when there are only three operators available. You could do this this a coordinated task sequence that moves the item to the processor and then utilizes all the operators required. You can then use the freeoperators() command in the Process Finish trigger to release the operators from the coordinated task sequence. You will want to make sure that you use sync tasks to insure that all of the operators have traveled to the processor before you unload the item into the processor. This will make sure that you don't have people in transit when you start the work on the item.

I hope that this helps,
Brandon