Configuration

Chapter 48
48.1 Functions
48.2 Function Blocks
48.3 User Defined Function Blocks
48.4 Nesting of Function Blocks
48.5 Function Block Diagrams
48.6 Comments
48.7 Compliance

Traditionally, configuration is associated with con- for industrial process measurement and control
tinuous control functions, as described in Chap- systems. A more detailed explanation of this is
ter 44 and depicted in Figure 44.1 for an ana- given in another text by Lewis (2001).
logue control loop. However, configuration is not
restricted to continuous functions: function blocks
are commonly used for handling the logic associ-
ated with discrete signals, as described in Chap-
48.1 Functions
ter 46, and are increasingly being used for simple A function is a software element which, when used
sequencing applications. with a given set of inputs, produces a single value
Configuration is the process by which pre- as a result. Functions can be used in any of the
defined routines, usually referred to as function five languages of IEC 61131. Figure 48.1 depicts
blocks, are strung together to perform some over- the function for finding the average of two real
all function using some configuration tool. Thus, variables.
as explained in Chapter 41, configuring a control
scheme consists of creating instances of function TEMP 1 avg
blocks from generic types in a library, and linking TMEAN
them together in the order required by the appli- TEMP 2
cation. Each function block relates to a block of
data in the database which requires values to be
Fig. 48.1 Function for averaging two real variables
specified for a variety of parameters.
This chapter explains functions and function
Its functionality is defined in structured text as
blocks, as per the IEC 61131 (Part 3) standard,
follows:
and the creation of function block diagrams. In
particular, it gives an insight into their underly- function AVG: real
ing functionality which is all too easy to lose sight var_input
of with the use of configurators. For a more de- INPUT1, INPUT2: real;
tailed explanation, the reader is referred to the text end_var
by Lewis (1998). There is a further standard, IEC AVG:=(INPUT1+INPUT2)/2;
61499, which concerns the use of function blocks end_function
 346 48 Configuration

This function may then be invoked to calculate the Its structured text equivalent is as follows in Pro-
mean, say of two temperatures, by a statement of gram 48.1:
the form:
Program 48.1. Structured text equivalent of Figure 48.3
TMEAN:=AVG(TEMP1, TEMP2)
type
Functions may be strung together to realise a more A1, A2, SUM, X1: real;
complex function. For example, the same average CALC, DONE: bool;
could be computed from add and divide functions, ADD_47: add;
as depicted in Figure 48.2. SQRT_47: sqrt;
end_type
TEMP 1 add
div if CALC then
TEMP 2 TMEAN
ADD_47.EN:=1;
SUM:=A1+A2;
ADD_47.ENO:=1;
end_if;
2.0
if ADD_47.ENO then
Fig. 48.2 Alternative functions for averaging SQRT_47.EN:=1;
X1:=SQRT(SUM);
There are many standard functions defined in
SQRT_47.ENO:=1;
IEC 61131 for converting data types, arithmetic,
end_if;
trigonometric and boolean operations,variable se-
if SQRT_47.ENO then
lection and comparison, bit and character string
DONE:=1;
manipulation, and for handling the date and time.
end_if;
The intent is that the functions are overloaded
which means that, as far as is practicable, each
function can handle a variety of data types.
When a function is used in either a ladder di- 48.2 Function Blocks
agram or a function block diagram, it is possible Function blocks are different from functions in
to control when the function executes by means of that they are not restricted to a single output and
a special input EN and output ENO. If EN is set can retain values between executions. The integral
true the function executes and when successfully function block, for example, is depicted in Fig-
completed ENO is set true. By chaining the ENO of ure 48.4.
one function to the EN of the next, it is possible to
control the order of execution of the functions and integral
to ensure that the result of a chain of functions is BOOL run q BOOL
valid. An example of this is depicted in Figure 48.3
BOOL r1 xout REAL
which shows two functions in the rung of a ladder
diagram. REAL xin
REAL x0
ADD-47 SQRT-47
CALC DONE TIME cycle
add sqrt
en eno en eno
A1
A2 SUM X1 Fig. 48.4 The integral function block

Its structured text equivalent is as follows in Pro-

Fig. 48.3 Use of EN and ENO for controlling order of execution gram 48.2:
 48.2 Function Blocks 347

Program 48.2. Structured text equivalent of the integral func- • Integration could be suspended and waiting to
tion block be continued, or
• It could have finished integrating and be waiting
function_block INTEGRAL
to be reset.
var_input
RUN: bool; (* Integrate=1, Hold=0 *) The accuracy of the numerical integration is crit-
R1: bool; (* Reset*) ically dependent upon the value of the input CY-
XIN: real; (* Input signal *) CLE time being equal to the sampling period cor-
X0: real; (* Initial value *) responding to the frequency at which the function
CYCLE: time; (* Sampling time equiv to block is executed. This is an implementation is-
integration step length *) sue, normally resolved at task level. It is implicit
end_var in function block diagrams and sequential func-
var_output tion charts, but is not necessarily so with ladder
Q: bool; (* Not reset=1*) diagrams whose cycle time is usually variable.
XOUT: real; (* Integrator output *) An instance of this function block can then
end_var be declared, or instantiated, within any program
Q := not R1; where an integration is required, as follows:
if R1 then
var
XOUT := X0;
FIT47_TOT: INTEGRAL
elsif RUN then
end_var
XOUT := XOUT+XIN * time_to_real(CYCLE);
end_if The instance is thereafter referred to within the
end_function_block program by name. However, to be executed, the in-
puts and outputs of the instance need to be related
The functionality of this integral function block is to those of the function block. An example of a
indicated by the annotated comments. In essence, statement for doing such is as follows:
the following algorithm is used for numerical inte-
FIT47_TOT (RUN:=FLG47_1, R1:=FLG47_2,
gration:
XIN:=FIT47, X0:=ZERO,

j
FLG47_3:=Q, F47TOT:=XOUT);
x0 (j) = x0 (0) + x1 (i).t
i=0
When an instance of a function block is executed
it is said to have been invoked. Those variables
The first half of the function block is taken up with explicitly declared as parameters of the function
type statements for input and output variables.The block when it is invoked must have been defined
reset flag R1 is used to initialise integration. If R1 is elsewhere, and the names of the remaining vari-
on (true) then the output flag Q is off (false) indi- ables are assumed to be the same in the function
cating that integration is not occurring and XOUT block as in the calling program.
is set to X0, the initial value for integration. Other- The integral function block’s functionality was
wise, R1 is off and Q is on, indicating that integra- articulated in structured text for convenience. It
tion is occurring and, provided that RUN is on too, could have been done in terms of functions, or in-
summation of the input XIN with respect to time deed any of the other IEC 61131 languages and
CYCLE occurs. mixtures thereof, but the explanation would have
If R1 and RUN are both off (false), as deter- been more cumbersome.
mined by the external logic, then the integrator is The standard currently defines a small number
idle and its status is ambiguous: of fairly basic function blocks such as bistables,
• It could have been reset and waiting to start in- edge detectors, counters, timers, real-time clock,
tegration, or ramp, hysteresis, I and D actions, PID control and
 348 48 Configuration

ratio. It can be anticipated that a variety of other DOT1:=0;

function blocks, such as cascade and lead/lag, will if LT ge LMAX then
be incorporated through extensions to the stan- MES:=‘$n LEVEL TOO HIGH $r’
dard and that system suppliers will provide li- elsif WT le WMIN then
braries of function blocks. MES:=‘$n WEIGHT TOO LOW $r’
else
DOT2:=1;
DOT3:=1;
48.3 User Defined Function WTBEG:=WT;

Blocks DOT4:=1;
repeat
Function blocks can be user defined. For example, WTDIF:=WTBEG-WT
a function block for charging based upon the se- until WTDIF ge WTREQ
quence of Figure 29.2 could be defined, as depicted end_repeat
in Figure 48.5. DOT4:=0;
DOT2:=0;
charge TC.SP:=TDES;
lt dot1 TC.AUTO:=1;
lmax dot2 end_if
end_function_block
wt dot3 bool
real
wmin dot4 An instance of this function block could then be
wreq tc.auto declared within a program, for each identical ar-
tdes tc.sp real rangement of charge and process vessel.
mes string

48.4 Nesting of Function

Fig. 48.5 User defined function block for charging sequence
Blocks
The structural text equivalent, adapted from Pro-
Function blocks may be nested in the sense that
gram 29.1, is as follows in Program 48.3:
one function block may be defined in terms of
others. The PID function block, for example, is de-
Program 48.3. Structured text equivalent of charging sequence
picted in Figure 48.6.
function_block CHARGE Assume that this function block is equivalent
var_input to the PID controller of Equation 23.6:
LT, WT: real;
⎛ ⎞
LMAX, TDES, WMIN, WREQ: real; t
1 de
end_var 0 = b ± KC ⎝e + e.dt + TD ⎠
var_output TR dt
0
DOT1, DOT2, DOT3, DOT4: bool; ⎛ ⎛ ⎞ ⎞
t
TC: pid; 1 ⎝ TR de
MES: string;
= ±KC ⎝e + .b + e.dt⎠ + TD ⎠
TR K C dt
end_var 0
⎛ ⎛ 0 ⎞ ⎞
var  t
1 de
WTBEG, WTDIF: real; ≡ ±KC ⎝e + ⎝ e.dt + e.dt⎠ + TD ⎠
end_var TR dt
−∞ 0
 48.5 Function Block Diagrams 349

PID 48.5 Function Block Diagrams

bool auto Function block diagrams (FBD) are used to express
pv xout real the behaviour of functions and function blocks in
terms of the flow of signals between them.They de-
sp
pict the multiple connections between the various
x0 elements involved in realising control schemes. An
real
kp insight into the scope of these interconnections is
tr provided by Figure 48.7 which is a relatively sim-
ple FBD. It is usual for control schemes to consist
td
of several function blocks as was seen, for exam-
time cycle ple, in Chapter 44 in which AIN, FIL, PID and AOT
function blocks were configured. Clearly an FBD
Fig. 48.6 The PID function block
depicting in detail all the interconnections for this
would be extensive.
Its functionality may be explained utilising inte- The IEC 61131 standard defines graphical for-
gral and derivative function blocks as depicted in mats for depicting the elements and signals, and
function block diagram form in Figure 48.7. recommends conventions for layout. For example,
The standard,IEC 61499,currently being devel- inputs should occur on the left and outputs on the
oped, addresses the issues relating to hierarchical right hand side of a FBD and, in general, signal
models of nested function blocks. flow should be from left to right. Signals may be

KC X OP

BIAS –..

–
SP
IP
+
integral
AUTO run q
r1 xout
–..
xin
X x0
cycle

TR

derivative
run q
xin xout
CYCLE cycle
X

TD
Fig. 48.7 Functionality of PID function block
 350 48 Configuration

fed back, right to left, from outputs of one block cal. It will enable instances of function blocks to
to inputs of another. This feed back may be either be created and “dragged” into place on a function
explicit or by means of connectors. block diagram. Connections have to be established
The elements on FBDs should be arranged so explicitly by “wiring” them together. The princi-
as to enable the principal signals to be traced read- pal outcome of the subsequent compilation pro-
ily. A good configurator enables the elements and cess is to automatically establish the underlying
their connections to be dragged across the FBD datablocks.
and positioned such that the crossing of signals
and changes of direction are minimised. There is
no limit on the size or complexity of a FBD al-
though, in practice, there are physical constraints 48.7 Compliance
imposed by the resolution of the screen and system
One of the principal driving forces behind develop-
dependent constraints on the number of function
ment of the IEC 61131 standard was the portability
blocks per configuration.
of application software from one system to another.
The order of execution of functions and func-
There is a huge potential benefit to end-users in
tion blocks is implicit from the their positions in
terms of re-usability through the modularity of de-
the FBD.When a function block is executed,its out-
sign encouraged by the standard. To this end an in-
puts are updated: it follows that, in general, signals
dependent compliance testing institute, PLCopen,
propagate from left to right.However,the order can
has been established. PLCopen’s purpose is to test
be made explicit by chaining of the EN and ENO
system’s languages, tools, etc. against IEC 61131-3
signals, as discussed. The order of execution is not
and to establish the extent to which they are com-
always obvious in FBDs with feedback paths and
pliant with the constructs, functionality, etc. of the
can lead to subtle variations in behaviour between
standard. There are different levels of compliance
systems.
and certification identifies those aspects of a sys-
tem that are not compliant. Note the deliberate use
of the word “compliance” and the distinction be-
tween compliance and accordance. Systems which
48.6 Comments are claimed to be in accordance with the standard
From a users point of view, configuration of a con- do not necessarily comply with it.
trol scheme is fairly straightforward. Invariably Application software, which may be created in
there is a configuration tool which guides the user any of the five IEC 61131 languages, or mixtures
with prompts,options and default settings through thereof, ultimately results in files. These files are
the processes of instantiating function blocks and created, or subsequently operated upon, by tools
then parameterising them. However, the feel of such as configurators, graphical editors, compil-
the tool will vary substantially from one system to ers, etc. A fairly fundamental constraint on full
another. compliance are the interfaces between the various
Typically, the configurator of a DCS will provide, tools, for which a common file exchange format
for each function block instance, a template based is required. Thus, for portability of programs de-
display of the corresponding datablock type. The veloped in the graphical languages, i.e., function
user is then prompted for values to be entered into block diagrams (FBD), ladder logic and sequential
the slots, as depicted in Chapter 45. Apart from function charts (SFC), the source code must be in
type testing and memory allocation, the principal one of the textual languages. Noting that applica-
outcome of the subsequent compilation process is tion software must eventually be cross compiled
to automatically establish the connections between into the assembly language of the target machine,
the function blocks. rather than into instruction lists (IL), the de-facto
In contrast to this, the configurator of a SCADA source code for file exchange is structured text.
or PLC based system is more likely to be graphi-