Exit
Exit: where an item can permanently leave a model
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
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
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
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)
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
Throw Exit
Throw exits are for advanced users. 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.
Before sending an Item through this exit you need to supply some details about where it is to be placed.
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.
Throwing to a Process Delay
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.
Throwing to a Portal
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.
Throwing into to a Rail Network
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.
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.
Refer to Editing Object Properties for information about editing properties common to all objects.
Exit Articles
- Portal Exit
- Portal Entry
- Hiding Portal Entries and Portal Exits
- Naming Portal Entries and Portal Exits
- Throw Exit
- Exit Limit Count
- Exit Operation Mode
- Exit Stop Options
- Exit Stop Actions