Portal Entry
Portal Entry: Entries for items into Subsystems
When an Item enters a Portal, it needs a place to appear in the subsystem inside the portal. The portal entry is where the item will appear.
A Portal Entry is created automatically for every sub system screen, which in turn is created when a Portal object is added to a model.
The Portal Entry is much like a normal Entry, but instead creating new items, it introduces items that enter the portal object into the sub system screen it is on.
Portal Exits are for items leaving Subsystems.
All subsystems must have at least one Portal Entry and one Portal Exit.
No interaction editing is necessary for Portal Entries and Portal Exits.
Portal Entry States
Idle Portal Entries always appear as idle.
They can however have different icons selected for them.
Portal Entry Object Editing
The following object menu options are available in a Portal Entry.
Menu Item
Description
Up To Portal
Enables the user to switch the screen display "up" to the Sub-system screen containing the Portal Object that owns the current subsystem.
Attributes
Attributes can be added to a Portal.
Click on the Attributes option brings up a list of Attribute names for editing, or enables you to name a new attribute. This option is also at the Portal Exit and the Portal itself.
Tables
Tables can be added to a Portal.
Click on the Tables option to bring up a list of Table names for editing, or enables you to name a new table. This option is also at the Portal Exit and the Portal itself
Panels
You can add View Panels to a subsystem.
View Panels are screens where you display information only. Neither items nor objects are shown in a View Panel. They only show views of data like attributes, tables, graphs, and paint objects (buttons, images etc).
Panels are owned by Portals, and are copied with the portal as part of its hierarchy when you copy and paste a portal.
This option is also available at the Portal itself and the Object Edit Screen Background Menu.
You can view a list of the Shared Routines resident at this subsystem level.
This option is also available at the Portal itself and under Panel, in the menu bar.
Labels
You can add Label Lists to a Portal. These Label Lists are “Scoped” which means they are visible only to items and code within the portal’s scope (i.e. its branch of the model hierarchy).
As with attributes and tables, scoped label lists with the same name as lists higher in the hierarchy will "obscure" those higher up. This option is also available at the Portal itself.
Classes
This option is also at the Portal Exit and the Portal itself.
Connect To
This option lets you connect select from a list of objects the one you want to assign to this Portal Entry.
Items entering the Portal from this object will now appear always at this Portal Entry.
When you assign an object to a Portal Entry, its name appears above the Portal Entry.
Note that an outside object with a leading underscore in its name will not be displayed. Only one Portal Entry should be set to "Any".
Add Alternate Entry
Places a new Portal Entry on the screen for you to use.
Each can be assigned as the link to a specific object outside the subsystem, using the "Connect To" menu option.
A Portal Entry not specifically linked to an object (ie. linked to "Any") receives those items that have not been directed to a specific Portal Entry.
Naming Portal Entries and Portal Exits
Each Portal Entry and Portal Exit can be named independently.
However if you rename the owning Portal (the Object containing this subsystem), then all of the Portal Entires and Exits are automatically renamed according to a special renaming/numbering system.
All links to specific named objects are retained if you copy and paste the subsystem.
This enables you to perform Ctrl-Pastes, without having to re-assign the Entries and Exits.
If a specified object is not linked, or not present when the portal with multi entries is pasted, then the system will complain about:
- Being unable to form a link, when there is no object of that name present, or
- The absence of a link, (either Path or Track) where the object is present.
Hiding Portal Entries and Portal Exits
The Portal’s Object Edit Menu Options dialog contains an option called “Hide P-Entry/P-Exit”.
When selected, this option disables and hides the sub-system Entry and Exit.
The sub-system entry and exit icons become blank and do not respond to clicking.
To re-enable the sub-system entry and exit, unselect the "Hide P-Entry/P-Exit" option in the Portal Object Edit Options Menu.
Multiple Portal Entries and Portal Exits
Multiple Portal Entries and Exits enable items to enter from the left, and depart to the right, and at the same time enter from the right and depart to the left, and enter from the top and depart to the bottom, and so on. This also makes logical constructs easier to build and follow.
You can create as many alternate Portal Entry Objects, and Portal Exit Objects in a Subsystem as you wish.
Multiple Portal Entries and Exits also enable the following:
- a) Direct control over incoming flows from specific objects located outside a Subsystem.
- b) Direct control over outgoing flows to specific objects located outside a Subsystem.
- c) An different approach to handling item flows into a subsystem
- You don’t have to use switches to direct an item when its path into the subsystem depends upon the object from which it came into the subsystem.
- d) An alternative approach to handling item flows out from a subsystem.
- You don’t have to place switches immediately outside a Portal to direct an item when its path away from a Portal depends upon how it was processed inside the Subsystem. This switching is now done within the Portal, and the Portal Exit chosen determines the path branch taken outside the Portal as the item leaves.
- e) Improved handling of challenging train control logic, and capacity management issues across subsystems.
- f) the chance to construct a more congruent representation of incoming, outgoing and crossover schematics within subsystems.
Connecting to External Objects
A link created between a Specific Object and a Specific Portal Entry applies to ALL ITEM CLASSES' with a path from the Object to the Portal.
All items, regardless of Class, leaving the Specified Object and entering the Portal, will arrive at the Specified Portal Entry. As usual, you can have different paths for the different classes leaving the specified portal entry.
A link created between a Specific Portal Exit and a Specific Object applies to ALL ITEM CLASSES' leading to this Portal Exit. All items, regardless of Class, passing through this Exit, will go to the Specified Object.
The software doesn't complain if 2 Portal Entries are assigned to the same object. Only the earliest created (NOT earliest assigned to the object) Portal Entry will accept items. (2 exits can point to the same object - this makes sense).
The software currently provides no warnings if an object connected to the Portal is "left out" of the specifications, and there is no Portal Entry in the subsystem with the assignment of "Any". This object will simply become, and remain blocked. You cannot leave the earliest-created Portal Entry with an unconnected flow, even if all other Portal Entries are connected, and set to receive items from any object.
Connecting to Track Objects
You can connect Portal Entries and Exits to Track Objects.
To properly connect up a Track object and enable bi-directional travel, you need to assign both a Portal Entry, and a Portal Exit to it. This will enable two way flow.
If your track is only uni-directional, then you need only assign an Entry or Exit, depending on the Track's direction.
Note that if you connect a Portal Entry/Exit to a Double Track Object, then you will get traffic coming in from either of the two individual tracks, (Portal Entry) or departing on to either of the two individual tracks (Portal Exit).
You may get more flexibility options by using two single tracks, rather than one double track - this will become clearer with further testing.
Ctrl-Paste Issues
Ctrl-Pasting of Subsystems assigned specific connections in a track network will probably give link warnings since the connections made are so specific to each subsystem, and a great deal of re-connection maintenance will be required if you think you will be making changes that you will have to replicate many times if the subsystem flow structure must change for some reason.
Either use Ctrl-Paste only on single objects inside the subsystem, or build logic into Portals within the Portal linked into the network infrastructure, (if you think that flow editing may be required as the model progresses).