Exit: Difference between revisions

From Planimate Knowledge Base
Jump to navigation Jump to search
m (Created)
 
mNo edit summary
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
Exit: where an item can permanently leave a model  
== Exit: where an item can permanently leave a model ==
 
<onlyinclude>[[Image:Exit Palette Icon.jpg]]


Items leave a model via an Exit object.  
Items leave a model via an Exit object.  


They can be classified as “Logical Only”, and thus do not have capacity. Items that move into an exit permanently disappear from a model.  
Items that move into an exit will permanently disappear from a model and cannot be recalled.  


Exit States
However Exits can also be used to send Items to other locations, via broadcasting or throwing.</onlyinclude> <br>


Idle The exit is always idle.  
Exits can be classified as “Logical Only”. They do not have capacity.  


Items are never blocked from entering an exit.
== Exit States<br>  ==


<br> Exits have four modes, all of which are configured from Object Edit View
'''Idle&nbsp;&nbsp; '''The exit is always idle.


Normal Exit
Items are never blocked from entering an exit.


        This mode is very simple. The item arrives at an exit and disappears from the model space.
<br>


Thus the exit represents a boundary point for the system being modelled.
== Exit Modes  ==


<br>
Exits have four modes, all of which are configured from Object Edit View


  Broadcast Exit
=== Normal Exit<br> ===


    This mode enables you to ‘Broadcast’ a message across the entire model hierarchy.  
[[Image:Exit Normal.jpg]]<br>


When an item passes into a Broadcast Exit, the broadcast is generated. Any Broadcast Entries tuned in to receive that particular broadcast will produce an item just like the one that caused the Broadcast (as long as that item class has a path leaving the BC Entry).  
This mode is very simple. <br>


After you select a broadcast, the name of the exit will be changed to the name of that broadcast. If the same broadcast is assigned to more than one broadcast entry, numbers will be added to ensure the exit object has a unique name.  
The item arrives at an exit and disappears from the model space.<br>


Wormhole Exit
Thus the exit represents a boundary point for the system being modelled.


      This mode allows you to ‘cheat the system’. Normally you cannot send an item along a path from one subsystem to a distant subsystem without having to respect the hierarchy of subsystems in the model. However with the combination of the Wormhole Exit and the Wormhole Entry, you can pass an item from one subsystem to another directly. This is useful, sometimes.
=== Broadcast Exit<br>  ===


A wormhole entry-exit pairing is always one to one. Items passing through wormhole-space are able to be blocked.  
[[Image:Exit Broadcast Icon.jpg]]&nbsp;&nbsp;&nbsp; <br>


<br>  
This mode enables you to ‘Broadcast’ a message across the entire model hierarchy.<br>  


Throw Exit (Place Item into Object)
When an item passes into a Broadcast Exit, the broadcast is generated. <br>


        This is an advanced and little-used exit mode. It is only available to exits located within an Application Panel.  
Any Broadcast Entries tuned in to receive that particular broadcast will produce an item just like the one that caused the Broadcast (as long as that item class has a path leaving the BC Entry). <br>


This mode works by reading an item system attribute (s.Item Location) that specifies the name of the Object the item is to be ‘thrown’ to. Objects being thrown to must be included in the _Model Objects list.  
After you select a broadcast, the name of the exit will be changed to the name of that broadcast. <br>


More Details about Throw Exit.  
If the same broadcast is assigned to more than one broadcast entry, numbers will be added to ensure the exit object has a unique name.  


<br>  
=== Wormhole Exit<br> ===


Exit Options
[[Image:Exit Wormhole Icon.jpg]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>


An exit can be configured to pause or halt the model run if an item passes into it, delivering a message onto the screen. In this way they may be useful as ‘Alerts’ or 'Error Traps' to ensure that improper model behaviour is detected and identified.  
This mode allows you to ‘cheat the system’. <br>


Refer to Standard Exit Options.  
Normally you cannot send an item along a path from one subsystem to a distant subsystem without having to respect the hierarchy of subsystems in the model. <br>


<br> Exits should not be confused with Portal Exits which transport an item back to a Portal in the screen above the subsystem.  
However with the combination of the Wormhole Exit and the [[Wormhole_Entry|Wormhole Entry]], you can pass an item from one subsystem to another directly. This is useful, sometimes.<br>


<br> Standard Exit Options The Object Edit Menu for an Exit has the following options specific to all Modes:
A wormhole entry-exit pairing is always one to one. <br>  


Item Count
Items passing through wormhole-space are able to be blocked.


Enables User Definable Messages.  
Note that an unconnected wormhole exit gives an error rather than acting blocked.<br><br>


Configuring the Exit Object enables action to be taken when a certain number of items enter an Exit. The "Exit" object may be configured to take action when a certain number of items (specified by the stop count) enter it.
=== Throw Exit (Place Item into Object)<br>  ===


With a stop count of 1, the exit can act as an eror catcher (with a user definable message) or to just notify the user that a certain event has occurred (leaving the model paused so the user can examine the model, then continue the run).
{{Breakout|Throw Exit}}
<br>


A model builder can use this to warn of situations arising during a model run which break assumptions made in the model's construction. Error traps may thus be enabled.
== Exit Configuration Options<br>  ==


<br>
An exit can be configured to pause or halt the model run if an item passes into it, delivering a message onto the screen.


Action at Count
In this way they may be useful as ‘Alerts’ or 'Error Traps' to ensure that improper model behaviour is detected and identified. Refer to Standard Exit Options.


Enables selection of the following actions to be taken when the Item Count value is exceeded:
Exits should not be confused with Portal Exits which transport an item back to a Portal in the screen above the subsystem. <br><br>


  Action
== Standard Exit Options ==
Description
   


Continue
The Object Edit Menu for an Exit has the following options specific to all Modes:


  The run will continue if it was paused.
=== Item Count<br> ===


Pause
Enables User Definable Messages.


Shows message and model pauses.  
Configuring the Exit Object enables action to be taken when a certain number of items enter an Exit.  


Stop Current Run
The "Exit" object may be configured to take action when a certain number of items (specified by the stop count) enter it.


Stops run. For a multiple run, the next run is started.  
With a stop count of 1, the exit can act as an eror catcher (with a user definable message) or to just notify the user that a certain event has occurred (leaving the model paused so the user can examine the model, then continue the run).  


Stop All Runs
A model builder can use this to warn of situations arising during a model run which break assumptions made in the model's construction.


Terminates run and all other runs in a multiple run.  
Error traps may thus be enabled.<br>


Stop All Runs and Quit
=== Action at Count<br>  ===


Terminates run and all other runs in a multiple run and closes Planimate®.
Enables selection of the following actions to be taken when the Item Count value is exceeded:
 
Stop Current Run and Restart


Terminates run and starts a fresh run. This lets a run be restarted without having to have the Run Behaviour Settings option "Restart when model stops" on.
----


Stop All Runs, Save and Quit
'''Action'''<br>Description<br>


Terminates run and all other runs in a multiple run, saves the MDL file and closes Planimate®. This is useful for batch runs which modify tables in the models which you want to retain.
----


<br>  
<br>  


Message Text
;Continue


This enables a short message to be entered for display when a Stop Action occurs.  
:The run will continue if it was paused.


<br>
;Pause


Options
:Shows message and model pauses.


Here you can set three options for an Exit that has an Item Count greater than zero.
;Stop Current Run


Show Object’s Window
:Stops run. For a multiple run, the next run is started.


Switches screen to screen of exit.
;Stop All Runs


Display Message
:Terminates run and all other runs in a multiple run.


Shows message, when user OK's it, the run resumes.
;Stop All Runs and Quit


Include Name in Message
:Terminates run and all other runs in a multiple run and closes Planimate®.


Includes the Exit Object’s Name in front of the message
;Stop Current Run and Restart


Throw Exit
:Terminates run and starts a fresh run. This lets a run be restarted without having to have the Run Behaviour Settings option "Restart when model stops" on.


Throw exits are for advanced users.
;Stop All Runs, Save and Quit


You can distribute items from Application Panels into any other capacity object in your model, provided it has been exported to the _Model Objects List. This is done by sending the item into an Exit that has had the Place Item into Object option specified in it. This option is only available in an exit within an Application Panel.  
:Terminates run and all other runs in a multiple run, saves the MDL file and closes Planimate®. This is useful for batch runs which modify tables in the models which you want to retain.


Before sending an Item through this exit you need to supply some details about where it is to be placed.
<br>


This is done by setting the Item System Attribute called s.Item Location. This attribute will be the _Model Objects name of the object the item is to be thrown at. If there is no object, then an error will occur, so you will want to be sure to set a valid name. The s.item location reference has to be set in the change object immediately prior to the throw exit, otherwise it is lost. This is because each new object visited updates this variable - if objects appear between the setting of this attribute in code and the Throw Exit, the setting is updated and thus lost.
=== Message Text<br>  ===


Throwing to a Process Delay
This enables a short message to be entered for display when a Stop Action occurs.


If the target object involves some kind of process delay, then you will be likely to want to specify some details about how much longer it is to be within the object before it leaves. This is done by setting the Item System Attributes called s.Item Total Delay, and s.Item Delay Left. You need to set both of these values before throwing the item, to ensure that the system’s integrity is maintained.
=== Options<br>  ===


<br>
Here you can set three options for an Exit that has an Item Count greater than zero.


  Throwing to a Portal
==== Show Object’s Window ====


Some cases will require you to simply place an item in a specific location – usually a portal. However a portal has no capacity to speak of – other than by way of the objects within it. Planimate has a default system to support throwing items at portals. You need to place an queue into the portal, and provide it with the default name _!Catch. (Note that the name is hidden when you create it, due to the exclamation mark ahead of it.) All items thrown to the portal will land in this Queue, and can proceed from there on their way into the system.  
Switches screen to screen of exit.<br><br>


<br>
==== Display Message  ====


Throwing into to a Rail Network
Shows message, when user OK's it, the run resumes.<br><br>


If the target involves some sort of rail network activity, then you will need to supply even more information - the Route the item is on, and the route step it is currently on. This requires a fair bit of preparation, making use of table input data, to gain all possible information that will support searching for the correct route involved, establishing the location and the associated route step for the item’s movements, then applying the route and working out the time it has been on the rails, and how far it has to travel (in time) before arriving at the next location on the track.
==== Include Name in Message  ====


The item will be very likely to need further configuration to provide it with all the other attributes that give it its unique identity – all of these will either be read, or tupled from tables before it gets thrown.
Includes the Exit Object’s Name in front of the message<br><br>


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


<br>  
<br>  
Line 190: Line 179:
ordermethod=pagetouched
ordermethod=pagetouched
order=descending
order=descending
</dpl>
</dpl>  


[[Category:Object/Exit]]
[[Category:Object/Exit]]

Latest revision as of 15:42, 16 January 2009

Exit: where an item can permanently leave a model

Exit Palette Icon.jpg

Items leave a model via an Exit object.

Items that move into an exit will permanently disappear from a model and cannot be recalled.

However Exits can also be used to send Items to other locations, via broadcasting or throwing.

Exits can be classified as “Logical Only”. They do not have capacity.

Exit States

Idle   The exit is always idle.

Items are never blocked from entering an exit.


Exit Modes

Exits have four modes, all of which are configured from Object Edit View

Normal Exit

Exit Normal.jpg

This mode is very simple.

The item arrives at an exit and disappears from the model space.

Thus the exit represents a boundary point for the system being modelled.

Broadcast Exit

Exit Broadcast Icon.jpg   

This mode enables you to ‘Broadcast’ a message across the entire model hierarchy.

When an item passes into a Broadcast Exit, the broadcast is generated.

Any Broadcast Entries tuned in to receive that particular broadcast will produce an item just like the one that caused the Broadcast (as long as that item class has a path leaving the BC Entry).

After you select a broadcast, the name of the exit will be changed to the name of that broadcast.

If the same broadcast is assigned to more than one broadcast entry, numbers will be added to ensure the exit object has a unique name.

Wormhole Exit

Exit Wormhole Icon.jpg     

This mode allows you to ‘cheat the system’.

Normally you cannot send an item along a path from one subsystem to a distant subsystem without having to respect the hierarchy of subsystems in the model.

However with the combination of the Wormhole Exit and the Wormhole Entry, you can pass an item from one subsystem to another directly. This is useful, sometimes.

A wormhole entry-exit pairing is always one to one.

Items passing through wormhole-space are able to be blocked.

Note that an unconnected wormhole exit gives an error rather than acting blocked.

Throw Exit (Place Item into Object)

Exit Throw Icon.jpg

This is an advanced and little-used exit mode.

This Exit Mode is only available to exits located within an Application Panel.

This mode works by reading an item system attribute (s.Item Location) that specifies the name of the Object the item is to be ‘thrown’ to.

Objects being thrown to must be included in the _Model Objects list.

For full details refer to this page: Throw Exit


Exit Configuration Options

An exit can be configured to pause or halt the model run if an item passes into it, delivering a message onto the screen.

In this way they may be useful as ‘Alerts’ or 'Error Traps' to ensure that improper model behaviour is detected and identified. Refer to Standard Exit Options.

Exits should not be confused with Portal Exits which transport an item back to a Portal in the screen above the subsystem.

Standard Exit Options

The Object Edit Menu for an Exit has the following options specific to all Modes:

Item Count

Enables User Definable Messages.

Configuring the Exit Object enables action to be taken when a certain number of items enter an Exit.

The "Exit" object may be configured to take action when a certain number of items (specified by the stop count) enter it.

With a stop count of 1, the exit can act as an eror catcher (with a user definable message) or to just notify the user that a certain event has occurred (leaving the model paused so the user can examine the model, then continue the run).

A model builder can use this to warn of situations arising during a model run which break assumptions made in the model's construction.

Error traps may thus be enabled.

Action at Count

Enables selection of the following actions to be taken when the Item Count value is exceeded:


Action
Description



Continue
The run will continue if it was paused.
Pause
Shows message and model pauses.
Stop Current Run
Stops run. For a multiple run, the next run is started.
Stop All Runs
Terminates run and all other runs in a multiple run.
Stop All Runs and Quit
Terminates run and all other runs in a multiple run and closes Planimate®.
Stop Current Run and Restart
Terminates run and starts a fresh run. This lets a run be restarted without having to have the Run Behaviour Settings option "Restart when model stops" on.
Stop All Runs, Save and Quit
Terminates run and all other runs in a multiple run, saves the MDL file and closes Planimate®. This is useful for batch runs which modify tables in the models which you want to retain.


Message Text

This enables a short message to be entered for display when a Stop Action occurs.

Options

Here you can set three options for an Exit that has an Item Count greater than zero.

Show Object’s Window

Switches screen to screen of exit.

Display Message

Shows message, when user OK's it, the run resumes.

Include Name in Message

Includes the Exit Object’s Name in front of the message

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


Exit Articles



Exit Object Frequently Asked Questions