About Gating Options
About Selecting a Gating Option
Switches do not have any capacity, so an item cannot become blocked at a switch. Rather it will become blocked at the object upstream that is feeding the switch.
Some switches in your model may NEVER block an item. If so, you can take advantage of this and increase your model's run speed by setting the Gating Option so that it does not need to manage blocking of items.
Read further to better understand the issues behind Gating Option Choices.
When items move in Planimate® they look before they leap.
Before Planimate® can pass an item on from one capacity object to the next capacity object, it needs to test whether this can be done. This is called Lookahead, or ‘TestEnter’.
Between these capacity objects may lie logical objects.
Change objects can change attributes in the model and switches provide path-branching points in a flow.
The Lookahead process must examine all objects between the capacity objects.
If a change object contains a routine, the lookahead has to perform all the operations in that routine in case a value change occurs in an attribute that is involved later on in the lookahead - at a single condition switch for example.
After performing the lookahead, all the attributes affected by any operations must be reset to their earlier values, in case the item has found it is blocked.
When the item moves between the capacity objects, all those operations are performed once more. This can seem very inefficient, and it is not always necessary.
The Gating option “Switch Cannot Block Items” in the Switch Object menu is useful where you can safely assume that a switch will never block an item (i.e. items are routed and never held up by a switch with this option selected).
Selecting this option enables you to speed up your model runs.
This option enables a switch that will not ever be blocked to safely defer decision making until an item actually moves into it.
No lookahead is performed past the switch to determine whether its path are available - they are assumed to always be available.
However the trade-off for the speed increase is that the switch must be able to assume that it will never be blocked.
If a switch with the Switch Cannot Block Items option set finds itself unable to pass an item forward from itself, then the run will be stopped with an error message, since the model is doing something that the modeller indicated would not happen.
This protects against unexpected results if the routine before the switch was setting an attribute required by the switch - but because the routine is executed "Only During Move" and the switch requires the change during lookahead, the change would not be seen by the switch.
The modeller needs to think about how the switch is being used.
If it is acting to route an item, simply setting the switch to "Assume No Blocking" will avoid the new error message.
This enables the switch to defer its decision to when the item actually moves - but means the switch cannot act as a gate.
If the switch must act as a gate, then the preceeding routines must be executed in lookahead - so "Only During Move" must be turned off.
This in turn requires that the preceeding routines dont perform operations which cannot be performed during lookahead, like table operations. Otherwise the system will report errors. The solution is then to split the "movement" and "lookahead" activities into separate routines.
If you intend that your switch may potentially be blocked at any time during a model run, then you should set the Gating option to “Switch Can Block Items”.