Dispatcher: Difference between revisions

From Planimate Knowledge Base
Jump to navigation Jump to search
m (Created)
 
mNo edit summary
Line 1: Line 1:
== Dispatcher: Dispatch Point for Items<br> ==
== Dispatcher: Dispatch Point for Items  ==


The Dispatcher is a wait station for Agents or Items, and can have multiple outgoing paths. Like a Queue, a Dispatcher has a maximum capacity, screen length and orientation.  
<onlyinclude>[[Image:Dispatcher_Palette_Icon.jpg]]
 
The Dispatcher is a wait station for Agents or Items, and can have multiple outgoing paths.  
 
Like a Queue, a Dispatcher has a maximum capacity, screen length and orientation.</onlyinclude>


A Dispatcher can be classified as “Logical with Capacity”, as they can hold items, and no time passes when they process items.  
A Dispatcher can be classified as “Logical with Capacity”, as they can hold items, and no time passes when they process items.  


It is used in situations where an Agent or an Item may be called upon by other objects, or in model logic in no particular order eg. a repairman servicing a group of machines, or a part which may be required by a range of assembly stations.  
It is used in situations where an Item may be called upon by other objects, or in model logic in no particular order eg. a repairman servicing a group of machines, or a part which may be required by a range of assembly stations.  
 
Any class of Item can wait in a Dispatcher, and can leave it at any time - unlike a First In First Out Queue. <br>


Any class of Agent or Item can wait in a Dispatcher, and can leave it at any time - unlike a First In First Out Queue. Agents or Items entering a Dispatcher wait there until they are required at a destination (ie. one of their outgoing paths will accept them). An Agent or Item immediately moves out from a Dispatcher if any of its paths lead either directly - or through a Switch - to a Multi-server, Queue, Splitter, Exit or another Dispatcher.  
Items entering a Dispatcher will wait there until they are allowed to proceed further <br>(ie. one of their outgoing paths will accept them). <br>
 
Unless it is blocked, a regular Item will immediately moves out from a Dispatcher if any of its paths lead either directly - or through a Switch - to a Multi-server, Queue, Splitter, Exit or another Dispatcher.  
 
A [[Carrier Item|Carrier Item]] may need to wait in a Dispatcher that has a path to a [[PickUp|PickUp Object]], until the PickUp Object has collected enough Items and requests the Carrier Item to enter it and take away some or all of the items it holds.<br>


== Dispatcher States  ==
== Dispatcher States  ==


The Dispatcher appears in outline like a queue but has a double line below. Agents or Items accumulate in Dispatchers as they wait for tasks. The icon for the Dispatcher does not change to represent different states.
The Dispatcher appears in outline like a queue but has a double line below. Agents or Items accumulate in Dispatchers as they wait for tasks. <br>


Idle No Agents or Items are at the Dispatcher.  
The icon for the Dispatcher Mode does not change to represent these different states.  


Wait At least 1 Agent or Item is at the Dispatcher.  
'''Idle''' No Agents or Items are at the Dispatcher.
 
'''Wait''' At least 1 Agent or Item is at the Dispatcher.  


<br>  
<br>  


== Use with Agent Pick-up Objects  ==
== Use with PickUp Objects  ==


When operating with Agents, Dispatchers can respond to Agent Pick-up Objects, holding the Agent until requested, then releasing the required Agent to perform a Pick-up of Items from that object. In such cases the outgoing path will often return the Agent (once a task is complete) to the Dispatcher so the Agent can wait for the next request. In this way an Agent can act as a transportation resource operating in a cyclic manner.  
When operating with Carrier Items, Dispatchers can respond to PickUp Objects, holding the Carrier Item until requested, then releasing it to perform a PickUp of Items from that object. <br>
 
In such cases the outgoing path will often return the Carrier Item (once its task is complete) to the Dispatcher so the Carrier Item can wait for the next request. <br>
 
In this way a Carrier Item can act as a transportation resource operating in a cyclic manner.  


== <br> Use with Switch  ==
== <br> Use with Switch  ==


Departures from a Dispatcher may be controlled by a Switch which is configured to release an item (or items), and direct the item along a particular path, when specific conditions are met. This Switch needs to be able to block items if it is to operate as a filter, holding some items back and latting others through.  
Departures from a Dispatcher may be controlled by a Switch which is configured to release an item (or items), and direct the item along a particular path, when specific conditions are met. <br>
 
This Switch needs to be able to block items if it is to operate as a filter, holding some items back and latting others through.  
 
 


== <br> Dispatcher Modes  ==
== Dispatcher Modes  ==


Dispatchers have a range of different modes, which make them a powerful object in your modelling. Some modes display an icon in their corner to clarify their use:  
Dispatchers have a range of different modes, which make them a powerful object in your modelling. Some modes display an icon in their corner to clarify their use:  
Line 33: Line 53:
=== Normal  ===
=== Normal  ===


Default Mode. Used in situations where an Agent or an Item may be called upon in no particular order by Agent Pick-up objects, or in model logic in combination with Switch Objects.  
Default Mode. <br>
 
Used in situations where an Item may be called upon in no particular order by PickUp objects, or in model logic in combination with Switch Objects.  


=== Send Message  ===
=== Send Message  ===


Used when you want to send an Item to another location in your model to be processed. In this Mode you nominate a Target Entry from a list of available Message Entries.  
[[Image:Dispatcher Icon Msg.jpg]]<br>


The Message Entry nominated need not be in the same subsystem.  
This Mode is used when you want to send an Item to another location in your model to be processed. <br>


This Mode is used when you want to send an Item to another location in your model to be processed. In this Mode you nominate a Target Entry from a list of available Message Entries. The Message Entry nominated need not be in the same subsystem. The Target option becomes available in the Object’s Menu when this Mode is selected.  
In this Mode you nominate a Target Entry from a list of available Message Entries. <br>
 
The Message Entry nominated need not be in the same subsystem. <br>
 
The Target option becomes available in the Object’s Menu when this Mode is selected.  


When an item enters this dispatcher, a "message" is sent to the nominated Entry, which then produces a "Message Item".  
When an item enters this dispatcher, a "message" is sent to the nominated Entry, which then produces a "Message Item".  
Line 47: Line 73:
This Message Item is identical to the original item except for its item ID.  
This Message Item is identical to the original item except for its item ID.  


It contains all of the attributes and values of the original item in the dispatcher. The “original item” is held by the Dispatcher until the "Message Item" is taken out through an Exit object, whereupon the original item is then free to leave the Dispatcher.  
It contains all of the attributes and values of the original item in the dispatcher. <br>
 
The “original item” is held by the Dispatcher until the "Message Item" is sent to an Exit object, whereupon the original item is then free to leave the Dispatcher.  


When the Message Item passes through the Exit, it passes back to the original item its characteristics, including Attributes, Trip details, Icon, and Class.  
When the Message Item passes through the Exit, it passes back to the original item its characteristics, including Attributes, Trip details, Icon, and Class.  


Many Dispatchers can call upon a single Message Entry. This enables you to centrally/remotely manage changes to any or all of an an item's Attributes; Icon; Route details; and even Class.  
Many Dispatchers can call upon a single Message Entry. <br>
 
This enables you to centrally/remotely manage changes to any or all of an an item's Attributes; Icon; Route details; and even Class.  


==== Treatment of Carried Items <br>  ====
==== Treatment of Carried Items <br>  ====


When Agents are sent as Message Items they carry their Items with them, and unless otherwise unloaded, they carry them back again when the Message Item “returns” to the original item waiting in the Dispatcher. If these items are delivered to an Agent Drop-off Object by the message-item agent, it will ‘return’ empty-handed back to the original agent, who carries on without those carried items. Similarly, a message-item agent can collect items, and upon its 'return', pass them across to the original agent who then sets off now carrying these items.
When Carrier Items are sent as Message Items they carry their Items with them, and unless otherwise unloaded, they carry them back again when the Message Item “returns” to the original item waiting in the Dispatcher. <br>
 
If these items are delivered to a DropOff Object by the message-carrier-item, it will ‘return’ empty-handed back to the original Carrier Item, who carries on without those carried items. <br>


You could use this feature to carry around a batch of items, then pass them over to a central processing location, where they are unloaded into a Tray, processed at this location (item attributes changed etc.), then collected again by the message-item agent, and then passed back to the original agent.  
Similarly, a message-carrier-item can collect items, and upon its 'return', pass them across to the original Carrier Item who then sets off now carrying these items.  


<br>  
You could use this feature to carry around a batch of items, then pass them over to a central processing location, where they are unloaded using a DropOff Object, processed at this location (item attributes changed etc.), then collected again by the message-carrier-item, and then passed back to the original Carrier Item.<br>  
 
==== Usage Notes and Limitations <br>  ====


==== Usage Limitations <br> ====
You can not pass information back to the original item if you destroy the Message Item in a Splitter. <br>  


You can not pass information back to the original item if you destroy the Message Item in an Assembler, Splitter. The original Item will be held in the Dispatcher forever if this happens.  
The original Item will be held in the Dispatcher forever if this happens.  


You cannot allow a Message Entry to be blocked. (Model complains when this occurs).  
You cannot allow a Message Entry to be blocked. (Model complains when this occurs).  
Line 73: Line 107:
=== Send Directed Message  ===
=== Send Directed Message  ===


Used when you want to direct a message to a alternative message entries. You get to specify the Target Object in this case using an Attribute, which means the Target may be variable.  
[[Image:Dispatcher Icon Directed Msg.jpg]]
 
This mode is similar to the Send Message Mode, except that you can direct a message to a alternative message entries.  
 
In this Mode you nominate a Target Message Entry Object using an Attribute reference, which means the Target may be varied, depending on the value of the Attribute, which is of course changeable during a model run.
 
The Target option becomes available in the Object’s Menu when this Mode is selected. <br>


This mode is similar to the Send Message Mode, except that you can direct a message to a alternative message entries. In this Mode you nominate a Target Message Entry Object using an Attribute reference, which means the Target may be varied, depending on the value of the Attribute, which is of course changeable during a model run.  
When the item enters this dispatcher, the value of the attribute being referenced will resolve to an object from the _Model Objects System Label List. <br>


The Target option becomes available in the Object’s Menu when this Mode is selected. When the item enters this dispatcher, the value of the attribute being referenced will resolve to an object from the _Model Objects System Label List. The object type needs to be either an Entry in Message Entry mode, or a Portal.  
The object type needs to be either an Entry in Message Entry mode, or a Portal.  


If you direct a message to a portal there are two ways of receiving the message.  
If you direct a message to a portal there are two ways of receiving the message.  
Line 83: Line 123:
1. The Portal must contain a message entry called _!message.  
1. The Portal must contain a message entry called _!message.  


2. You need to specify a preferred name for the Message Entry, and ensure there is a Message Entry with that name in the Portals the item is directed to. This can be set using the Message Entry Preferred Name option which becomes available in the Object’s Menu when this Mode is selected.<br>  
2. You need to specify a preferred name for the Message Entry, and ensure there is a Message Entry with that name in the Portals the item is directed to. <br>
 
This can be set using the Message Entry Preferred Name option which becomes available in the Object’s Menu when this Mode is selected.<br>  


==== Resolving the Directed Message Target <br>  ====
==== Resolving the Directed Message Target <br>  ====
Line 100: Line 142:
This enables  
This enables  


#&nbsp; Many message types to be directed at a portal and then individually handled within via separate entries. <br>  
#Many message types to be directed at a portal and then individually handled within via separate entries. <br>  
#&nbsp; Message handling to be encapsulated in a hidden portal (must be called _!message) or use the Handles Parent Messages/Broadcasts Option, rather than having to have message entries/flows right at the top portal, which may be visible to end users. <br>
#Message handling to be encapsulated in a hidden portal (must be called _!message) or use the Handles Parent Messages/Broadcasts Option, rather than having to have message entries/flows right at the top portal, which may be visible to end users. <br>


<br>  
<br>  
Line 107: Line 149:
==== Message Dispatcher event order <br>  ====
==== Message Dispatcher event order <br>  ====


If a message item triggered any broadcasts AND the message item did not enter and leave in the same thread (ie: any capacity in the message item thread) then when the message item went into its exit, it was possible that the broadcasts would be processed before the original item tried to leave the dispatcher. For this case, priority is given to moving the original item out of the dispatcher before any broadcast events are processed.  
If a message item triggered any broadcasts AND the message item did not enter and leave in the same thread (ie: any capacity in the message item thread) then when the message item went into its exit, it was possible that the broadcasts would be processed before the original item tried to leave the dispatcher. <br>
 
For this case, priority is given to moving the original item out of the dispatcher before any broadcast events are processed.  


<br>  
<br>  


=== Directed Message for Carried Items  ===
=== Directed Message for Carried Items  ===
[[Image:Dispatcher Icon Directed Msg.jpg]]


In this mode a dispatcher will send a message for every item that entering item is carrying.  
In this mode a dispatcher will send a message for every item that entering item is carrying.  


This enables processing of statistics, inspection of carried items etc. to be performed without the overhead of dropping off all the carried items then picking them all up again using Agent Drop-off and Pickup Objects.<br>  
This enables processing of statistics, inspection of carried items etc. to be performed without the overhead of dropping off all the carried items then picking them all up again using DropOff and PickUp Objects. <br>  


Note that if the dispatcher contains more than one item, performance will be reduced according to the number of carried items by the items in the dispatcher. <br>  
Note that if the dispatcher contains more than one item, performance will be reduced according to the number of carried items by the items in the dispatcher. <br>  
Line 123: Line 169:
=== Send Scoped Broadcast  ===
=== Send Scoped Broadcast  ===


This mode enables a dispatcher to send a specific broadcast to a hierarchy of subsystems. The top is specified using a portal in the object list. Unlike a change object broadcast, the broadcast is sent immediately, whilst the item waits in the dispatcher. The item only leaves the dispatcher once all listening entries have produced their broadcast items and they have flowed as far as they can before encountering capacity.  
[[Image:Dispatcher Icon Scoped BC.jpg]]


Refer to Send Scoped Broadcast for more details.  
This mode enables a dispatcher to send a specific broadcast to a hierarchy of subsystems. <br>


This mode enables a Dispatcher to send a specific broadcast to a hierarchy of subsystems. The broadcast is scoped to the subsystem under the object specified by the Target, which can be an Attribute reference, making the location variable. The top of the scope must resolve to a Portal that has been included in the _Model Objects System Label List.
The top of the hierarchy is specified by using an Attribute that resolves to a Portal that has been included in the _Model Objects System Label List.<br>
 
The broadcast is scoped to the subsystem under the object specified by the Target, which can be an Attribute reference, making the location variable. <br>


If an index of 0 is used, the broadcast is sent globally. However if possible use a scope to make your model scalable.  
If an index of 0 is used, the broadcast is sent globally. However if possible use a scope to make your model scalable.  


Unlike a Change object broadcast, the broadcast is sent immediately, whilst the item waits in the dispatcher. The item only leaves the dispatcher once all listening entries have produced their broadcast items and they have flowed as far as they can before encountering capacity.
Unlike a Change object broadcast, the broadcast is sent immediately, whilst the item waits in the dispatcher. <br>


<br>
The item only leaves the dispatcher once all listening entries have produced their broadcast items and they have flowed as far as they can before encountering capacity.


==== Wait for Items to Exit Option <br>  ====
==== Wait for Items to Exit Option <br>  ====


This option instructs the Dispatcher to hold on to the Item sending the broadcast until all broadcast items enter an Exit object. Normally, the item waits at the dispatcher only until the initial thread from each broadcast entry completes (items reach a point of capacity). This option is useful when you want to guarantee that all broadcasts have been completely processed before the item leaves the dispatcher, even if the processing of the broadcast takes non zero time or involves activities beyond a single thread (eg: pauseable zero delays, other broadcasts).  
This option instructs the Dispatcher to hold on to the Item sending the broadcast until all broadcast items enter an Exit object. <br>
 
Normally, the item waits at the dispatcher only until the initial thread from each broadcast entry completes (items reach a point of capacity). <br>
 
This option is useful when you want to guarantee that all broadcasts have been completely processed before the item leaves the dispatcher, even if the processing of the broadcast takes non zero time or involves activities beyond a single thread (eg: pauseable zero delays, other broadcasts).  


A modeller can now be assured that all listeners for a broadcast have received and had a chance to process it without having to put an explicit delay in the originating items path.<br>  
A modeller can now be assured that all listeners for a broadcast have received and had a chance to process it without having to put an explicit delay in the originating items path.<br>  
<br>
=== Send Dynamic Broadcast  ===
In this mode a dispatcher sends a broadcast to a scope set by a reference, as for the normal broadcast.
Unlike the normal broadcast, the type of broadcast sent is determined dynamically by another reference.
This reference should be set to an attribute which has a valid broadcast label index, to identify which broadcast type to send.
Modellers should use this mode only where absolutely necessary as PL will not identify the dispatcher as a broadcast source since the type of broadcast sent is indeterminate at edit time.
It can make a model difficult to understand and debug.
Document your intent when using it.


<br>  
<br>  
Line 145: Line 213:
=== Wait For Specific Release  ===
=== Wait For Specific Release  ===


In this mode Dispatchers can be set to hold items until there is a message sent to have a specific Item Released. Items entering the dispatcher wait there until the routine operation "Release Item" is used to release them from the dispatcher.  
[[Image:Dispatcher Icon Specific Release.jpg]]
 
In this mode Dispatchers can be set to hold items until there is a message sent to have a specific Item Released. <br>
 
Items entering the dispatcher wait there until the routine operation "Release Item" is used to release them from the dispatcher.  


The "Release Item" routine operation takes 2 parameters, Item Index and Scope Panel.  
The "Release Item" routine operation takes 2 parameters, Item Index and Scope Panel.  
Line 165: Line 237:
=== Restart Engine/Continue  ===
=== Restart Engine/Continue  ===


Dispatchers in this mode restart the model engine whilst retaining the item within them. ALL OTHER ITEMS in the model are deleted - the run is stopping and restarting at time = 0, but the item at the dispatcher "survives" the restart and can continue through its flow.  
This mode is only made available for Dispatchers located within an Application Panel.<br>
 
Dispatchers in this mode restart the model engine whilst retaining the item within them. <br>
 
ALL OTHER ITEMS in the model are deleted - the run is stopping and restarting at time = 0, but the item at the dispatcher "survives" the restart and can continue through its flow.
 
To enable the dynamic object mode, the Dispatcher "Enable Edit Command Table" option must be selected. <br>
 
This option is only available once the dispatcher is in "Restart Engine/Continue" mode.  


To enable the dynamic object mode, the Dispatcher "Enable Edit Command Table" option must be selected. This option is only available once the dispatcher is in "Restart Engine/Continue" mode.  
To enable the dynamic object mode with a Restart Engine/Continue Dispatcher, this mode causes another Option to appear in the Object Edit Menu called Table. <br>


To enable the dynamic object mode with a Restart Engine/Continue Dispatcher, this mode causes another Option to appear in the Object Edit Menu called Table. Here you can make a reference to a table that will be used for the generation and manipulation of Objects. The instruction in this table are read and carried out upon restarting after the Model Run has stopped.  
Here you can make a reference to a table that will be used for the generation and manipulation of Objects. <br>
 
The instruction in this table are read and carried out upon restarting after the Model Run has stopped.  


<br>  
<br>  
Line 179: Line 261:
*Direction
*Direction


Sets the direction in which Agents or Items will queue up. (Left to Right, Right to Left, Up to Down or Down to Up).  
Sets the direction in which Items will queue up. (Left to Right, Right to Left, Up to Down or Down to Up).  


*Capacity
*Capacity
Line 187: Line 269:
*Screen Length
*Screen Length


Sets the number of Agents or Items shown on the screen, others are indicated by a number, as for a queue.  
Sets the number of Items shown on the screen, others are indicated by a number, as for a queue.  


<br>  
<br>  
Line 193: Line 275:
== Dispatcher Options  ==
== Dispatcher Options  ==


The Following options are available - some only in specific modes:  
The following options are available for Dispatchers - some only in specific modes:  


=== Show Overflow  ===
=== Show Overflow  ===


This option displays the overflow box when the number of items in the dispatcher exceeds the screen display length. The box displays the number of extra items not visible. The full occupancy value of a dispatcher is thus the sum of this overflow figure, and the number of visible items.  
This option displays the overflow box when the number of items in the dispatcher exceeds the screen display length.  
 
The box displays the number of extra items not visible.  
 
The full occupancy value of a dispatcher is thus the sum of this overflow figure, and the number of visible items.  


If this Option is not selected, the number of Non-Visible items is not displayed.  
If this Option is not selected, the number of Non-Visible items is not displayed.  
Line 207: Line 293:
=== Dont Copy Back Message Item  ===
=== Dont Copy Back Message Item  ===


For Send Message and Send Directed Message Dispatchers.  
''For Send Message and Send Directed Message Dispatchers.''


When this is selected, the attributes/carried items of a destroyed message item are NOT copied back to the original item when it leaves the dispatcher.  
When this is selected, the attributes/carried items of a destroyed message item are NOT copied back to the original item when it leaves the dispatcher.  
Line 213: Line 299:
=== Wait for items to exit  ===
=== Wait for items to exit  ===


This option is for Send Scoped Broadcast dispatchers only.  
''This option is for Send Scoped Broadcast dispatchers only.''


Turned on, the item sending the broadcast waits in the dispatcher until all broadcast items enter an exit. Normally, the item waits at the dispatcher only until the initial thread from each broadcast entry completes (items reach a point of capacity).  
Turned on, the item sending the broadcast waits in the dispatcher until all broadcast items enter an exit. Normally, the item waits at the dispatcher only until the initial thread from each broadcast entry completes (items reach a point of capacity).  
Line 252: Line 338:
<br>  
<br>  


<br>
<br>  


[[Category:Object/Dispatcher]]
[[Category:Object/Dispatcher]]

Revision as of 14:06, 23 January 2009

Dispatcher: Dispatch Point for Items

Dispatcher Palette Icon.jpg

The Dispatcher is a wait station for Agents or Items, and can have multiple outgoing paths.

Like a Queue, a Dispatcher has a maximum capacity, screen length and orientation.

A Dispatcher can be classified as “Logical with Capacity”, as they can hold items, and no time passes when they process items.

It is used in situations where an Item may be called upon by other objects, or in model logic in no particular order eg. a repairman servicing a group of machines, or a part which may be required by a range of assembly stations.

Any class of Item can wait in a Dispatcher, and can leave it at any time - unlike a First In First Out Queue.

Items entering a Dispatcher will wait there until they are allowed to proceed further
(ie. one of their outgoing paths will accept them).

Unless it is blocked, a regular Item will immediately moves out from a Dispatcher if any of its paths lead either directly - or through a Switch - to a Multi-server, Queue, Splitter, Exit or another Dispatcher.

A Carrier Item may need to wait in a Dispatcher that has a path to a PickUp Object, until the PickUp Object has collected enough Items and requests the Carrier Item to enter it and take away some or all of the items it holds.

Dispatcher States

The Dispatcher appears in outline like a queue but has a double line below. Agents or Items accumulate in Dispatchers as they wait for tasks.

The icon for the Dispatcher Mode does not change to represent these different states.

Idle No Agents or Items are at the Dispatcher.

Wait At least 1 Agent or Item is at the Dispatcher.


Use with PickUp Objects

When operating with Carrier Items, Dispatchers can respond to PickUp Objects, holding the Carrier Item until requested, then releasing it to perform a PickUp of Items from that object.

In such cases the outgoing path will often return the Carrier Item (once its task is complete) to the Dispatcher so the Carrier Item can wait for the next request.

In this way a Carrier Item can act as a transportation resource operating in a cyclic manner.


Use with Switch

Departures from a Dispatcher may be controlled by a Switch which is configured to release an item (or items), and direct the item along a particular path, when specific conditions are met.

This Switch needs to be able to block items if it is to operate as a filter, holding some items back and latting others through.


Dispatcher Modes

Dispatchers have a range of different modes, which make them a powerful object in your modelling. Some modes display an icon in their corner to clarify their use:

Normal

Default Mode.

Used in situations where an Item may be called upon in no particular order by PickUp objects, or in model logic in combination with Switch Objects.

Send Message

Dispatcher Icon Msg.jpg

This Mode is used when you want to send an Item to another location in your model to be processed.

In this Mode you nominate a Target Entry from a list of available Message Entries.

The Message Entry nominated need not be in the same subsystem.

The Target option becomes available in the Object’s Menu when this Mode is selected.

When an item enters this dispatcher, a "message" is sent to the nominated Entry, which then produces a "Message Item".

This Message Item is identical to the original item except for its item ID.

It contains all of the attributes and values of the original item in the dispatcher.

The “original item” is held by the Dispatcher until the "Message Item" is sent to an Exit object, whereupon the original item is then free to leave the Dispatcher.

When the Message Item passes through the Exit, it passes back to the original item its characteristics, including Attributes, Trip details, Icon, and Class.

Many Dispatchers can call upon a single Message Entry.

This enables you to centrally/remotely manage changes to any or all of an an item's Attributes; Icon; Route details; and even Class.

Treatment of Carried Items

When Carrier Items are sent as Message Items they carry their Items with them, and unless otherwise unloaded, they carry them back again when the Message Item “returns” to the original item waiting in the Dispatcher.

If these items are delivered to a DropOff Object by the message-carrier-item, it will ‘return’ empty-handed back to the original Carrier Item, who carries on without those carried items.

Similarly, a message-carrier-item can collect items, and upon its 'return', pass them across to the original Carrier Item who then sets off now carrying these items.

You could use this feature to carry around a batch of items, then pass them over to a central processing location, where they are unloaded using a DropOff Object, processed at this location (item attributes changed etc.), then collected again by the message-carrier-item, and then passed back to the original Carrier Item.

Usage Notes and Limitations

You can not pass information back to the original item if you destroy the Message Item in a Splitter.

The original Item will be held in the Dispatcher forever if this happens.

You cannot allow a Message Entry to be blocked. (Model complains when this occurs).

Double clicking on a Send Message dispatcher flashes box around the Target Message Entry to assist in locating it.


Send Directed Message

Dispatcher Icon Directed Msg.jpg

This mode is similar to the Send Message Mode, except that you can direct a message to a alternative message entries.

In this Mode you nominate a Target Message Entry Object using an Attribute reference, which means the Target may be varied, depending on the value of the Attribute, which is of course changeable during a model run.

The Target option becomes available in the Object’s Menu when this Mode is selected.

When the item enters this dispatcher, the value of the attribute being referenced will resolve to an object from the _Model Objects System Label List.

The object type needs to be either an Entry in Message Entry mode, or a Portal.

If you direct a message to a portal there are two ways of receiving the message.

1. The Portal must contain a message entry called _!message.

2. You need to specify a preferred name for the Message Entry, and ensure there is a Message Entry with that name in the Portals the item is directed to.

This can be set using the Message Entry Preferred Name option which becomes available in the Object’s Menu when this Mode is selected.

Resolving the Directed Message Target

A dispatcher or Routine line sending a message to a portal will look in the following manner to attempt to find a suitable Message Entry:

  • In the Portal’s subsystem using the Message Entry Preferred Name.
  • In a Portal with the option “Handles Parent Messages/Broadcasts, using the Message Entry Preferred Name.
  • In the Portal’s subsystem looking for a Message Entry with the same name as the sending dispatcher/change object.
  • In a Portal with the option “Handles Parent Messages/Broadcasts, using the same name as the sending dispatcher/change object..
  • In the Portal’s subsystem looking for a Message Entry using the default entry name (_!message).
  • In a Portal with the option “Handles Parent Messages/Broadcasts, using the default entry name (_!message).


This enables

  1. Many message types to be directed at a portal and then individually handled within via separate entries.
  2. Message handling to be encapsulated in a hidden portal (must be called _!message) or use the Handles Parent Messages/Broadcasts Option, rather than having to have message entries/flows right at the top portal, which may be visible to end users.


Message Dispatcher event order

If a message item triggered any broadcasts AND the message item did not enter and leave in the same thread (ie: any capacity in the message item thread) then when the message item went into its exit, it was possible that the broadcasts would be processed before the original item tried to leave the dispatcher.

For this case, priority is given to moving the original item out of the dispatcher before any broadcast events are processed.


Directed Message for Carried Items

Dispatcher Icon Directed Msg.jpg

In this mode a dispatcher will send a message for every item that entering item is carrying.

This enables processing of statistics, inspection of carried items etc. to be performed without the overhead of dropping off all the carried items then picking them all up again using DropOff and PickUp Objects.

Note that if the dispatcher contains more than one item, performance will be reduced according to the number of carried items by the items in the dispatcher.


Send Scoped Broadcast

Dispatcher Icon Scoped BC.jpg

This mode enables a dispatcher to send a specific broadcast to a hierarchy of subsystems.

The top of the hierarchy is specified by using an Attribute that resolves to a Portal that has been included in the _Model Objects System Label List.

The broadcast is scoped to the subsystem under the object specified by the Target, which can be an Attribute reference, making the location variable.

If an index of 0 is used, the broadcast is sent globally. However if possible use a scope to make your model scalable.

Unlike a Change object broadcast, the broadcast is sent immediately, whilst the item waits in the dispatcher.

The item only leaves the dispatcher once all listening entries have produced their broadcast items and they have flowed as far as they can before encountering capacity.

Wait for Items to Exit Option

This option instructs the Dispatcher to hold on to the Item sending the broadcast until all broadcast items enter an Exit object.

Normally, the item waits at the dispatcher only until the initial thread from each broadcast entry completes (items reach a point of capacity).

This option is useful when you want to guarantee that all broadcasts have been completely processed before the item leaves the dispatcher, even if the processing of the broadcast takes non zero time or involves activities beyond a single thread (eg: pauseable zero delays, other broadcasts).

A modeller can now be assured that all listeners for a broadcast have received and had a chance to process it without having to put an explicit delay in the originating items path.


Send Dynamic Broadcast

In this mode a dispatcher sends a broadcast to a scope set by a reference, as for the normal broadcast.

Unlike the normal broadcast, the type of broadcast sent is determined dynamically by another reference.

This reference should be set to an attribute which has a valid broadcast label index, to identify which broadcast type to send.

Modellers should use this mode only where absolutely necessary as PL will not identify the dispatcher as a broadcast source since the type of broadcast sent is indeterminate at edit time.

It can make a model difficult to understand and debug.

Document your intent when using it.


Wait For Specific Release

Dispatcher Icon Specific Release.jpg

In this mode Dispatchers can be set to hold items until there is a message sent to have a specific Item Released.

Items entering the dispatcher wait there until the routine operation "Release Item" is used to release them from the dispatcher.

The "Release Item" routine operation takes 2 parameters, Item Index and Scope Panel.

  • Item Index

The Item ID of the item you want released from the dispatcher

  • Scope Panel

If non-zero, this specifies a dynamic panel which will define the dynamic scope under which the release will work.

If zero, the release will work for any dispatcher in the model. Using this value cuts down the search space in looking for dispatchers to release the selected item from.

The operation sets a target attribute to 1 if the item was found and released, otherwise it sets the target to 0, so you can learn whether the item was found or not.


Restart Engine/Continue

This mode is only made available for Dispatchers located within an Application Panel.

Dispatchers in this mode restart the model engine whilst retaining the item within them.

ALL OTHER ITEMS in the model are deleted - the run is stopping and restarting at time = 0, but the item at the dispatcher "survives" the restart and can continue through its flow.

To enable the dynamic object mode, the Dispatcher "Enable Edit Command Table" option must be selected.

This option is only available once the dispatcher is in "Restart Engine/Continue" mode.

To enable the dynamic object mode with a Restart Engine/Continue Dispatcher, this mode causes another Option to appear in the Object Edit Menu called Table.

Here you can make a reference to a table that will be used for the generation and manipulation of Objects.

The instruction in this table are read and carried out upon restarting after the Model Run has stopped.


Dispatcher Object Editing

The following Object Editing options are available in all Modes:

  • Direction

Sets the direction in which Items will queue up. (Left to Right, Right to Left, Up to Down or Down to Up).

  • Capacity

Sets the Item holding capacity of the dispatcher.

  • Screen Length

Sets the number of Items shown on the screen, others are indicated by a number, as for a queue.


Dispatcher Options

The following options are available for Dispatchers - some only in specific modes:

Show Overflow

This option displays the overflow box when the number of items in the dispatcher exceeds the screen display length.

The box displays the number of extra items not visible.

The full occupancy value of a dispatcher is thus the sum of this overflow figure, and the number of visible items.

If this Option is not selected, the number of Non-Visible items is not displayed.

Show BC/message icon during run

You can choose to have the little icons in the bottom left of the Message and Broadcast Dispatchers display during a run.

Dont Copy Back Message Item

For Send Message and Send Directed Message Dispatchers.

When this is selected, the attributes/carried items of a destroyed message item are NOT copied back to the original item when it leaves the dispatcher.

Wait for items to exit

This option is for Send Scoped Broadcast dispatchers only.

Turned on, the item sending the broadcast waits in the dispatcher until all broadcast items enter an exit. Normally, the item waits at the dispatcher only until the initial thread from each broadcast entry completes (items reach a point of capacity).

Enable Edit Command Table

To enable the dynamic object mode with a Restart Engine/Continue Dispatcher, this mode causes an option called Table, to appear in the Object Edit Menu.

Here you can make a reference to a table that will be used for the generation and manipulation of Objects.

The instruction in this table are read and carried out upon restarting after the Model Run has stopped.


Refer to Editing Object Properties for information about editing properties common to all objects.


Dispatcher Articles



Dispatcher Object Frequently Asked Questions