Working Logic of Dispatcher

I am trying to use dispatcher to assign tasksequences to the connected operators according to the task type and also the operator type. When I read the manual about the dispatcher, I am a little bit confused about how it works.

1. The manual says that "When a Dispatcher receives a task sequence, triggered by the dispatchtasksequence() command, it first calls its Pass To function." Does this mean the Pass To function is called only when the dispatcher receives a task sequence? I think at least when the connected operators change states (for example, from not-available to aviable), the Send To function should be reevaluated. Is that true?

2. The manual says that "The Dispatcher will then immediately pass the task sequence on to the object connected to that port. If the function returns a 0 instead of a port number, then the task will be queued up in the Dispatcher's task sequence queue." So if the Pass To function return a specific port, it will pass the tasksequence to the operator connected to that specific port, no matter that operator is busy or not?. The default (the pick list First Available) of Pass To functions always return 0. Does this mean the Dispatcher will always queue the new task (sounds not right...)? Then when the dispatcher actually pass the tasksequence to operators in the default case?

3. There is a OnResourceAvaiable trigger for Dispatcher. The manual only has one line of description: "This function is called when a downstream resource of a Dispatcher becomes available.". Does the downstream resource mean the operator connected to the dispatcher? When does the trigger fired? What is the trigger typically used for?

Thanks,
Alan

As soon as a Dispatcher receives a task sequence he will execute the passto. If the passto returns a non-zero value, then he will immediately pass it on, regardless of downstream availability. If the passto returns zero, then he will sort the ts in his queue using the queue strategy, then open his output ports and send the task sequence on when a downstream object becomes available.

The OnResourceAvailable trigger will fire:
1. When a downstream TE (a TE connected to the dispatcher's output ports) finishes a task sequence and doesn't have any more in his queue, so he will notify the dispatcher that he is available.
2. When a task sequence is first dispatched and the dispatcher's passto returns 0, and one or more of the downstream TE's is already available. The OnResourceAvailable will be fired for each TE that is available as long as the dispatcher's task sequence queue is not empty, meaning if output port 1 is available and the task sequence is sent on leaving the task sequence queue empty, then output port 2 will not be fired even if it's available.

I think the OnResourceAvailable trigger is probably what you want to use.

Note that if the OnResourceAvailable trigger returns 0, the Dispatcher will give the TE the first task sequence in its queue. If you return 1 in the OnResourceAvailable, then the dispatcher will do nothing, assuming that you do your own task sequence dispatching logic using movetasksequence(), dispatchtasksequence(), etc. Note that when the OnResourceAvailable fires, the dispatcher may or may not have a task sequence in its queue, so you'll need to take both scenarios into account.

If you plan on using the OnResourceAvailable trigger, there are changes scheduled for future releases that you should know about. First, the OnResourceAvailable will be expanded to fire on an individual TaskExecuter whenever that TE finishes a task sequence, so you can give the TE "go back home if you don't have anything left to do" type task sequences without having to connect it to a Dispatcher and use its OnResourceAvailable. Second, we plan on changing the timing for the Queue Strategy being fired. Right now, the ts queue is sorted when a task sequence is received. In a future release we will change this so that the queue will be sorted when a resource becomes available. This will not matter if you use the standard Queue Strategy of sorting by ts priority, but it will change if you use some custom queue strategy such as one that is based on the distance to a pick-up/drop-off point, or perhaps the age of the task sequence, etc. basically scenarios where the "importance" of that task sequence can change based on a given state of the model (I'm making a distinction here between the static priority value that is stored on that task sequence when it is created and the potentially dynamic "importance" value that is returned by the Queue Strategy field). In the future release, such strategies should work properly, whereas right now you have to write code explicitly to sort the queue on resource availability to get the queue strategy to work right.

Anthony,

Thanks for the answers. To summarize,

1. The PassTo function is NOT reevaluated when a downstream TE becomes available. If PassTo returns non zero, the tasksequence will not be queued in the dispatcher, but will immediately pass through that port to the downstream TE.

2. By default, a Dispatcher will always queue the new tasksequence. When a downstream object becomes available, the first tasksequence in the queue will be passed to that downstream object. This is the standard logic of a dispatcher.

3. OnResourceAvaiable will be fired whenever an object connected to the out ports of the dispatcher becomes available, and if the tasksequence queue of the dispatcher is not empty. Future release will give individual TE's their own OnResourceAvaiable trigger (now only Dispatcher has this trigger). The future release will also fire QueueStrategy when a donwstream TE becomes available (a better way!).

As you have pointed out, the current logic is hard to be changed to response to dynamic model state. The way to do it is to write logic in the OnResourceAvaiable trigger to pick the right tasksequence in the queue. But I have reconsidered my problem. The standard dispatcher is just a queue for tasksequences for a certain type of tasks. Thus, I can use multiple dispatchers, one for one task type. Then the standard logic of dispatcher does not need to be changed. And use dispatchtasksequence outside of the dispatcher to assign right tasks to right dispatchers. That way should make life easier.

Thanks,
Alan

To follow up on Alan's previous summary post, starting with Flexsim 4.3 released in March of 2008, the QueueStrategy of a Dispatcher is evaluated whenever downstream resources become available, and TaskExecuters were given their own OnResourceAvailable trigger that fires whenever the TE finishes a tasksequence.

It seems that when a broken ts is queued up, then it has higher priority than normal ts in the queue. Am I right?

"the QueueStrategy of a Dispatcher is evaluated whenever downstream resources become available"

In the QueueStrategy trigger of a Dispatcher, how to reference the downstream resource that triggers the QueueStrategy trigger ?

thanks

You would have to do it in the OnResourceAvailable trigger. You could set a label like, "AvailObject" on the dispatcher to the "resource" variable that you have available to you in that trigger. Then just reference that label in your code in the QueueStategy field.