Subroutines

Subroutines are similar in form to tasks except that they only execute when called from a task. As with tasks all variables defined in a subroutine are global, i.e. they can be read and written in any other task or subroutine within the program.

Note:

User-defined function blocks (UDFBs) should be used in preference to subroutines. UDFBs provide better encapsulation of data and better modularity. Also, subroutines cannot be placed into a library.

Subroutine names have the following format:

The first character must be an alphabetic character.
Subsequent characters must be alphanumeric characters or an underscore (_).
The name must not contain two consecutive unserscore characters.
The final character in the name must be a colon (:).

As with tasks, subroutines can contain any mix of DPL code, QLD and LD/ FB diagrams. The code can read or write variables, parameters and PLC registers. The following is an example of a subroutine:

Note:

It is possible to enter a section into the DPL editor which looks like subroutine and has a name that does not end in a colon. However it will not be possible to call the section from a task because the DPL syntax for calling a subroutine requires that the subroutine name has a colon at the end. For more information, see Subroutine Call.

To aid debugging, it is possible to monitor the values of parameters and variables in tasks when online and communicating with a target. However it is not possible to set a breakpoint in a subroutine.

Subroutines only execute when they are called from a task or another subroutine. The following is an example of a task calling a subroutine.

User-Defined Function Blocks (udfBs)

User Defined Function Blocks (UDFBs) provide a powerful alternative to subroutines and assist greatly in creating structured DPL programs.

Unlike tasks and subroutines, UDFBs are self-contained units (i.e. encapsulated). This means that any variable used in a UDFB is local to the UDFB and cannot be modified inadvertently by other tasks, subroutines or UDFBs in the user program.

The values of any variables used in a UDFB persist between calls (although they are lost when a power down or option module reset occurs).

A program can create multiple instances of a UDFB. Each instance will have its own set of variables.

The only interface between a UDFB and the remainder of the DPL program is via its input and output arguments. A UDFB cannot access the global DPL variables in the DPL program or variables in other UDFBs. UDFBs can access drive parameters and PLC registers (as can tasks and subroutines).

Note:

The DPL compiler for the SM-Applications and SM-Applications Lite targets allows distributable binary libraries of UDFBs to be created. If a function block is being created for inclusion in a library it is recommended that the use of drive parameters and PLC registers is minimised since it will reduce the portability of the UDFB to other applications.

UDFB names have the following format:

The first character must be an underscore _.
The next character must be an alphabetic character.
Subsequent characters must be alphanumeric characters or an underscore (_).
The name must not contain two consecutive underscore characters.

A UDFB has three parts as shown below:

The declaration section defines the input and output arguments of the UDFB. The initialisation section and body section contain the executable code for the UDFB. For more information, see:

UDFB Input and Output Arguments
UDFB Code Sections

It is possible to monitor the values of parameters in UDFBs when online and communicating with a target. However it is not possible to set a breakpoint in a subroutine or to monitor the values of variables inside function blocks.

UDFBs only execute when they are called from a task, a subroutine or another UDFB. The following is an example of a task calling a UDFB. The example also shows the creation of multiple instances of a UDFB.

UDFBs can be called in any supported language - DPL, QLD or LD/ FB.