Configure a Bypass for an Interlock
- Last UpdatedJul 13, 2023
- 3 minute read
You can configure an Interlocks so that it can be bypassed. This means an operator can manually override an interlock, making a locked process available to start.
A bypass is implemented at runtime via the Interlock tab on the Information Zone. For further instructions, see Information Zone.
To configure a bypass for an interlock
A bypass is configured via the equipment reference that defines the relationship between the two pieces of equipment (see Configure Interlocks).
To enable a bypass, complete the following Custom properties:
-
Custom 1 — BypassStatus - enter the name of the tag that controls the bypass status for the interlock.
-
Custom 2 — BypassCommand - enter the name of the tag that when written to will bypass an interlock.
-
Custom 3 — RemoveBypassCommand - enter the name of the tag that when written to will remove a bypass for an interlock.
-
Custom 4 — EnableBypass/Reset - enter the name of a tag to disable the bypass command. If this tag exists, then the bypass and reset commands will be enabled if the value of this tag is 1.
You need to have variable tags for the bypass states for the referenced equipment. For example, for Motor1 you would configure four variable tags, one for each bypass state:

Note: If custom field 4 is empty, and any of the remaining fields are completed, then the "Reset" and "Bypass" commands will be enabled. Otherwise, if the four custom fields are complete, then the "Reset" and "Bypass" commands will be disabled unless the tag specified in this field is 1.
Bypass permissions
The ability to initiate a bypassed depends on the privileges defined for the piece of equipment that changes state in response to an interlock trigger.
The function GetPrivEx is used to retrieve the privilege of the interlocked piece of equipment. If the privilege level assigned to the current user does not match the privilege level of the interlocked equipment, the options to bypass and remove a bypass will not be available.
SOE event journal limitations
Bypassing an interlock adds an event to the sequence of events (SOE) journal. The event message uses the following format:
<Cluster>.<Equipment>.<Item> @(INTERLOCK BYPASSED:)<Reason>
The length of the message field in the SOE is 254 characters. If <Cluster>.<Equipment>.<Item> has more than 160 characters, it will be truncated from the beginning.
For example, if the name of a piece of equipment is "Cluster1.Equip1…..Equip10.Item" (which contains 167 characters), the name will be truncated to "1.Equip1…..Equip10.Item".
The truncated equipment name needs to be globally unique, otherwise the bypass information will not display in the remove bypass form. A hardware alarm "Named object already exists" will also be raised.
The length of the reason an operator can specify depends on equipment name and the localized string of "INTERLOCK BYPASSED:". For example, if the equipment name is 80 characters long and the localized string of "INTERLOCK BYPASSED:" is 20 characters long, the operator can type 153 characters as the reason for the bypass. If the operator types more than 153 characters, the text will be truncated from the end.
Similarly, removing an interlock bypass adds an event to the SOE journal. The message of the event is in the following format:
<Cluster>.<Equipment>.<Item> @(INTERLOCK BYPASS REMOVED:)<Reason>
Again, if <Cluster>.<Equipment>.<Item> has more than 160 characters, it will be truncated from the beginning.
The length of the reason provided for removing a bypass depends on the equipment name and the localized string of "INTERLOCK BYPASS REMOVED:". For example, if the equipment name is 80 characters long and the localized string of "INTERLOCK BYPASS REMOVED:" is 26 characters long, a user can type 147 characters as the bypass reason. If the
user types more than 148 characters, the text will be truncated from the end.