INTERFACE / END_INTERFACE
Definition
An INTERFACE declares a contract: a set of method
signatures (and optionally property signatures) without any
bodies. Any FUNCTION_BLOCK that IMPLEMENTS the interface
must provide a body for every interface method with an exactly
matching signature.
Interfaces are the IEC 61131-3 mechanism for polymorphism by contract: a variable typed as the interface can hold any FB instance that implements the interface, and a call through the interface variable dispatches to the concrete FB’s method at run time.
Syntax
INTERFACE <interface_name> [EXTENDS <base_interface>, <base_interface>, ...]
METHOD <method_name> [: <return_type>]
<var_blocks_no_body>
END_METHOD
...
END_INTERFACE
- Interface extension is multiple (
EXTENDS A, B, C) — the third edition allows an interface to extend several base interfaces. (FUNCTION_BLOCKEXTENDSis single-only; see EXTENDS.) - The method declarations carry signatures only — no
statement-list, no
VARblock beyond the parameter blocks. - Properties (
PROPERTY <name> : <type>withGET/SETbodies omitted) may appear inside an interface.
Example (roadmap — not yet compilable)
INTERFACE IAccount
METHOD Deposit
VAR_INPUT
amount : LREAL;
END_VAR
END_METHOD
METHOD Withdraw : BOOL
VAR_INPUT
amount : LREAL;
END_VAR
END_METHOD
METHOD GetBalance : LREAL
END_METHOD
END_INTERFACE
FUNCTION_BLOCK BankAccount IMPLEMENTS IAccount
VAR
balance : LREAL := 0.0;
END_VAR
METHOD PUBLIC OVERRIDE Deposit
VAR_INPUT
amount : LREAL;
END_VAR
balance := balance + amount;
END_METHOD
METHOD PUBLIC OVERRIDE Withdraw : BOOL
VAR_INPUT
amount : LREAL;
END_VAR
IF balance >= amount THEN
balance := balance - amount;
Withdraw := TRUE;
ELSE
Withdraw := FALSE;
END_IF;
END_METHOD
METHOD PUBLIC OVERRIDE GetBalance : LREAL
GetBalance := balance;
END_METHOD
END_FUNCTION_BLOCK
(* Caller uses the interface type — accepts any IAccount: *)
VAR
acc : BankAccount;
iAcc : REFERENCE TO IAccount;
END_VAR
iAcc REF= acc;
iAcc.Deposit(amount := 100.0);
Semantics
- An interface declaration is not instantiable on its own — there is no storage layout, no constructor. It only fixes the contract that implementers must satisfy.
- A variable of an interface type must be a reference —
IEC 61131-3 declares
REFERENCE TO <interface>. The reference is assigned withREF=to a concrete FB instance. - Method calls through the interface reference dispatch dynamically: the runtime picks the concrete FB’s method body. This is the IEC 61131-3 equivalent of a C++ virtual call or a Java interface method.
- Interface extension is subtype-compatible: a reference typed as the base interface can hold an instance whose FB implements the derived interface (Liskov substitution).
- Empty interfaces (no methods) are legal — they serve as marker interfaces that flag a capability without prescribing a call shape. Pattern is rare in PLC code.
IEC reference
IEC 61131-3 third edition (2013), clause 6.5.4 —
“Interfaces”. The keywords INTERFACE, END_INTERFACE are
reserved. EXTENDS is documented under the same clause when
used between interfaces; the single-inheritance variant for
FUNCTION_BLOCKs is clause 6.5.5.
matiec conformance
❌ Not supported. No INTERFACE production exists in matiec’s grammar; the parser stops at the first INTERFACE token. As with METHOD, the only matiec-compatible path is to refactor away from interface-based polymorphism entirely. Switching to the C++-codegen target (roadmap) is the supported upgrade path.
ForgeIEC notes
- Reference types in interfaces: the IEC 61131-3 reference
syntax
REFERENCE TO IAccountplusREF=for assignment is its own sub-feature (see theREFERENCE/REF_TO/REF=/NULLfuture page). The tree-sitter-st parser needs both INTERFACE and REFERENCE tokens before end-to-end interface usage compiles. - C++ codegen mapping: the roadmap maps an INTERFACE to a
C++ abstract base class with pure virtual methods (
virtual bool Withdraw(LREAL amount) = 0;).IMPLEMENTSbecomes public inheritance. Multiple-interface extension uses C++ multiple inheritance with abstract bases — which is safe because interfaces carry no state. - Editor display: the planned Library-Help-Panel will surface interfaces under their own tree-node so that an FB picker can show “FBs that implement IAccount” alongside the FB itself.
See also
- METHOD — method declarations inside an interface vs inside an implementing FB.
- EXTENDS — FUNCTION_BLOCK inheritance, which is the other half of OO polymorphism.
- IMPLEMENTS — the FB-side keyword that signs the contract.