Implementation of function blocks
Topics:
Ensure online change capability
The ability for online change is an important fundamental feature of PLC applications. A PLC program can be changed in various ways by means of online change without being stopped in the cyclic sequence. Often program code is changed in the implementation part, for which individual variables are also added in the declaration part.
Implement function blocks in such a way that instances are not affected in their functionality if they are moved in memory as a result of an online change.
For details refer to chapter Execution of an online change in the TwinCAT 3 PLC documentation
Uniform interface with one-time asynchronous processing
In addition to the naming conventions for variables and the order of text blocks for variable declarations, a uniform interface facilitates the use of function blocks.
For function blocks whose body call handles asynchronous and one-time ADS processing, you should use the following interface. If it is not an ADS communication, the parameter sNetId
is omitted.
Processing starts on the rising edge of the input bExecute
. This is only possible if the function block is not bBusy
. Input parameters should not be changed by the user during an ongoing processing. This also ensures that the results of the processing (outputs) match the specified parameters (inputs).
When the processing is finished, bBusy := FALSE
is set. At the latest now you have to set all output parameters. The user thus has the possibility of reacting to bBusy = FALSE
and evaluating the outputs as a result.
FUNCTION_BLOCK FB_Sample
VAR_INPUT
bExecute : BOOL;
... : ...; // optional inputs
... : ...; // optional inputs
tTimeout : TIME := DEFAULT_ADS_TIMEOUT; // ADS communication timeout
sNetId : T_AmsNetId := ''; // keep empty '' for the local device
END_VAR
VAR_OUTPUT
bBusy : BOOL;
bError : BOOL;
hrErrorCode : HRESULT;
... : ...; // optional outputs
... : ...; // optional outputs
END_VAR
Uniform interface with continuous asynchronous processing
In addition to the naming conventions for variables and the order of text blocks for variable declarations, a uniform interface facilitates the use of function blocks.
For function blocks whose body call handles asynchronous and continuous ADS processing, use the following interface. If it is not an ADS communication, the parameter sNetId
is omitted.
Processing starts on the rising edge of bEnable
. The function block operates as long as bEnable
is set. Resetting bEnable
does not necessarily result in the immediate termination of all processing due to the asynchronous processing. This is displayed by means of bBusy = FALSE
. While bEnable
is set, changed input parameters can be processed.
The output bValid
indicates the successful processing and the validity of optional output parameters.
The output bError
indicates an error that has occurred. More detailed information is provided by the error code at output hrErrorCode
. Because bError
can be set at any time during continuous processing and is often only present for one cycle, the user should query this output permanently.
FUNCTION_BLOCK FB_Sample
VAR_INPUT
bEnable : BOOL;
... : ...; // optional inputs
... : ...; // optional inputs
tTimeout : TIME := DEFAULT_ADS_TIMEOUT; // ADS communication timeout
sNetId : T_AmsNetId := ''; // keep empty '' for the local device
END_VAR
VAR_OUTPUT
bValid : BOOL;
bBusy : BOOL;
bError : BOOL;
hrErrorCode : HRESULT;
... : ...; // optional outputs
... : ...; // optional outputs
END_VAR
Use all parameters of a function block internally
All parameters of a function block should also be used internally.
Negative sample:
FUNCTION FB_Sample_neg
VAR_INPUT
nA : INT; // Variable a in term y = a*a
nB : INT; // NON COMPLIANT: nB will not be used
END_VAR
VAR_OUTPUT
nY : INT;
END_VAR
nY := nA * nA;
Positive sample:
FUNCTION FB_Sample_pos // COMPLIANT: no unused parameter
VAR_INPUT
nA : INT; // Variable a in term y = a*a
END_VAR
VAR_OUTPUT
nY : INT;
END_VAR
nY := nA * nA;
Grouping of parameters as a structure
If you have to specify many parameters in the function block, it is a good idea to group them in one or more structures. For example, configuration parameters can be well separated visually from control parameters.
See also: