How Planimate Moves Items
Every activity in a Planimate™ model is initiated by an event. Events are drawn from a time sorted event list, the Future Event Chain (FEC). Each event is processed to completion and may add to or reorder the other events in the FEC. Most importantly, the model must be in a valid state between events. That is, every item must be residing at an object with capacity and there must be no outstanding activities (apart from the events in the FEC).
A model can only be paused between events.
This page discusses the most important Planimate event, the Move event. It is important to remember that all the activity described below (for a given move) occurs within the context of one event - ie. it does not directly use the FEC but rather is triggered via an event drawn from it.
Moving An Item
Objects which generate or hold items eventually determine that an item should leave. For a multi-server, this is signalled via a completion event, scheduled to occur at the time the server delay is complete. The object initiates a handshake with objects following it to locate a viable target for the item to move to.
The first step is finding a target object which has capacity to accept the item. This phase is called TestEnter, and invokes a recursive lookahead of objects downstream of the object from which the item is leaving.
If a blockable switch is involved, things get much more interesting. Depending on its settings, the switch may have to explore multiple options, testing each one for viability, before reporting back to the object(s) and if successful, preceeding to direct the item to its decided destination.
Once the object which initiated the TestEnter determines that a target object can accept the item, the actual move takes place. The item now animates, following the path determined during the TestEnter phase until it reaches the target object. Remember, the target object is one which has capacity to hold the item.
The final step in the move process does not involve the item at all, but rather objects upstream of the object which just moved the item. Since a leaving item creates a space, the object may now be able to accept an item, which may have been previously refused because the object was at capacity. This is checked by exploring all paths upstream of the object, invoking an Unblock method for each. If an object upstream determines it can move an item, it will invoke its own Move process and the whole process will start over.
The lookahead process
As mentioned above, if during a lookahead a switch is encountered, the switch may be required to make a decision - which involves exploring the outgoing paths of the switch. If this decision is based on an attribute, the attribute needs to be read at lookahead time. If the attribute is set by a routine just before the switch, then that routine also needs to be evaluated in the lookahead - before the item actually moves.
This means that any change object routines ahead of a switch must be evaluated before the switch can be tested. Moreoever, all the attribute changes made must be undone, after all this is only a TestEnter phase and the original object may decide not to move the item, or the item may take another path because of another switch upstream.
Worse still - if the change object before the switch performs a time expensive operation such as a large search, a lot of time will be wasted re-evaluating the search during lookahead and again during the actual move. Fortunately there are some actions the modeller can take to reduce this overhead.
Switch Can/Cannot Block Items
This switch option enables the modeller to inform the switch on whether it will ever block an item.
Switches set to not block items can assume that whenever an item approaches them, there will always be somewhere for the item to go. This prevents the switch having to lookahead past itself - the switch does not need to explore its outgoing paths nor make a decision when a TestEnter is performed on it. It simply reports “proceed” to the object before it.
When the item reaches the switch, if its unable to find a viable destination, the switch will stop the model run with a model error - for some reason the capacity that the modeller expected in their flow logic is not there. So in addition to speeding up switch operation, using this option can also validate against unexpected blockages, which may go otherwise undetected.
This option cannot be used when a switch is expected to block or "hold up" an item, or when there is any possibility that a location downstream of the switch may be unable to accept the item.
Change Object Routine - Only During Move
Setting this option at a change object instructs it to only execute the routine when an item is actually moving through the change object, not during a lookahead exploration.
To improve performance, it can be turned on for all change objects except those that preceed an object which must decide whether to accept or block the item based on a calculation made by the change object.
For example, an attribute switch configured as "Can Block Items" requires that the attribute be evaluated and valid during lookahead. likewise a multiserver which is basing its capacity dynamically on an attribute will read this attribute during lookahead and hence require any routine just before it to be evaluated during lookahead.
A model’s run time may be significantly improved if complex routines are not unnecessarily evaluated during lookahead.
Things That Cannot Evaluate During Lookahead
Its important to know that Planimate cannot perform operations which require modifying multiple data in one routine line in lookahead,
for example inserting a row in a table, clearing a column or resiging a table cannot be performed during lookahead. Planimate will avoid the operation in lookahead and give a model stop error if any attempt to access data which might be incompletely calculated during lookahead.
The Only During Move routine operation enables one routine to contain both lookahead and "move only" code.
The Lookahead separator switch mode enables complex models involving tracks to look down separate flows during lookahead and item move,