JOURNAL OF APPLIED

COMPUTER SCIENCE
Vol. 16. No 1(2008), pp. 49-67

Programming controllers in Structured Text

language of IEC 61131-3 standard
Dariusz Rzo ca, Jan Sadolewski, Andrzej Stec
Zbigniew wider, Bartosz Trybus, Leszek Trybus
Rzeszw University of Technology
Division of Computer Science and Control
ul. W.Pola 2, 35-959 Rzeszw, Poland
email: {drzonca, janeks, astec, swiderzb,
btrybus, ltrybus}@prz-rzeszow.pl
Abstract. Programming industrial controllers by means of Control
Program Developer (CPDev) package* in IEC 61131-3 Structured Text
(ST) language is presented. The package involves ST compiler that
generates an universal code executed on different platforms by Java-like
virtual machines. Operation of compiler components, i.e. scanner, parser
and code generator is presented in details. Virtual machine executes
universal code using hardware allocation map for particular platform. The
CPDev package is open in terms of software and hardware, what means
that the user can create libraries, and hardware designers can program
external interfaces. First application for programming a small distributed
control-and-measurement system from LUMEL Zielona Gra is described.

1. Introduction
General purpose of IEC 61131-3 standard introduced in 1998 was to
improve quality of software for programmable controllers. Now the standard is
also a Polish law (PN-EN 61131-3). The IEC (number will be dropped for
brevity) defines five programming languages, namely LD, IL, FBD, ST and
SFC, allowing the user to choose one suitable for particular application,
corresponding to his expertise. Instruction list IL and Structured Text ST are text
languages, whereas Ladder Diagram LD, Function Block Diagram FBD and
Sequential Function Chart SFC are graphical ones (SFC is not an independent
* Developed under MNiSzW grant no. R02 058 03.

50

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

language, since it requires components written in the other languages).

Relatively simple languages LD and IL are used for small applications. FBD, ST
and SFC are appropriate for medium-scale and large applications. John and
Tiegelkamp's and Kasprzyk's books [1,2] are good sources to learn IEC
programming.
ST is a high level language originated from Pascal, Ada and C, especially
suitable for complicated algorithms. Equivalent code for a program written in
any of the other four languages can be developed in ST, but not vice versa.
Hence most of engineering packages use ST as a default language for
programming user function blocks. Due to such reasons, ST has been selected
as a base language for software package for programming control-andmeasurement devices and small distributed systems, being developed by the
authors under the sponsorship of Ministry of Science and Higher Education. The
package called CPDev (Control Program Developer) is written in C# at
Microsoft .NET Framework 2.0 [3]. Initial information has been presented in [4]
and [5] at the recent Real Time Systems conference. Here we describe CPDev in
more details, paying particular attention to compilation and explaining how the
compiled code is executed on different hardware platforms.
The paper is organized as follows. Basic facts on programming in ST, i.e.
data types, Program Organization Units (POUs) and an example of a function
block code are presented in Sec. 2. Next section includes structure of CPDev,
user interface, standard functions and libraries. The user can create his own
POUs and libraries. Components of ST compiler, i.e. scanner, parser and
code generator, are described in Sec. 4 together with classes of related
objects. Section 5 presents the example of ST program compilation for
standard up-counter, beginning from source code up to binary, universal code
executed by Java-like virtual machine. Realization of the virtual machine,
followed by first application of CPDev for programming distributed mini-system
from LUMEL Zielona Gra, is described in Sec. 6.

2. Programming in Structured Text

2.1. Data types
Data types, literals (constants) and variables are common components of the
five IEC languages. Variable names are typical, although there is no distinction
between capital and small characters. The standard defines twenty elementary
data types listed in Table 1 together with memory sizes and ranges (left part).
BOOL, INT, REAL and TIME are most common. FALSE, 13, -4.1415 and
T#1m25s are examples of corresponding constants.

Programming controllers in Structured Text language of IEC 61131-3 standard

51

Table 1. Elementary data types of IEC 61131-3 standard

Type

Size (range)

Type

Size

SINT

1B (-128 .. 127)

BOOL

1B (0, 1)

INT

2B (-32768 .. 32767)

BYTE

1B

DINT

4B (-231 .. 231 1)

WORD

2B

DWORD

4B

LWORD

8B

2B (0 .. 65535)

TIME

4B

UDINT 4B (0 .. 232 1)

DATE

4B

TIME_OF_DAY

4B

LINT

63

63

8B (-2 .. 2 1)

USINT 1B (0 .. 255)
UINT

64

ULINT 8B (0 .. 2 1)
REAL

4B, IEEE-754 format

LREAL 8B, IEEE-754 format

DATE_AND_TIME 8B
STRING

Variable length

The standard defines three levels for accessing variables, i.e. LOCAL,
GLOBAL and ACCESS. LOCALs are available in the program, function block or
function. GLOBALs can be used in the whole project, but programs, blocks or
functions must declare them as EXTERNAL. ACCESS variables exchange data
between different systems.

2.2. POU units

Well structured software consists of programs, function blocks and
functions, i.e. Program Organization Units (POUs). Function blocks, designed
for reuse in different parts of the program, are of crucial importance. A block
involves inputs, outputs and memory for data from previous executions. The IEC
defines small set of standard blocks listed further in Sec 3.2. Three of them are
shown in Fig. 1.
Programs written in ST begin with declarations of variables and instances of
function blocks placed between VAR and END_VAR keywords. The declarations
are followed by list of instructions. The instructions involve expressions which,
when evaluated, yield result in one of defined data types, i.e. elementary
(Table 1) or derived, such as alias, array or structure. The following operators are
available (in descending priority): parenthesis, function evaluation, negation,
power, arithmetic operators, Boolean operators.

52

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

Fig. 1. Examples of IEC 61131-3 standard function blocks with time diagrams:
SR flip-flop, TON on-delay timer, CTU up-counter

ST language provides five types of instructions:

assignment := (Pascal symbol),
selection IF, CASE,
loop FOR, WHILE, REPEAT,
Table 2. ST source code for the CTU standard up-counter
FUNCTION_BLOCK CTU
VAR_INPUT
CU : BOOL;
RESET : BOOL;
PV : INT;
END_VAR
VAR_OUTPUT
Q : BOOL;
CV : INT;
END_VAR
VAR
CUp : BOOL := FALSE;
END_VAR
IF RESET THEN
CV := 0;
ELSE
IF (CU AND NOT CUp) THEN
IF (CV < PV) THEN
CV := CV + 1;
END_IF
END_IF
END_IF
Q := CV >= PV;
CUp := CU;
END_FUNCTION_BLOCK

(* CTU up-counter *)
(* count up *)
(* reset *)
(* preset value *)
(* signaling output *)
(* current value *)
(* previous CU input *)
(* if reset *)
(* if rising edge at CU input *)

(* Q := TRUE, if CV >= PV *)
(* previous value of CU *)

Programming controllers in Structured Text language of IEC 61131-3 standard

53

control RETURN, EXIT, END,

function block call (invocation).
Table 2 presents source code of the up-counter CTU from Fig. 1. Rising edge
at the input CU (Count Up) increments the output CV (Current Value). When CV
reaches PV (Preset Value), the output Q is set to TRUE. R (Reset) clears the
counter.
Suppose an instance of the CTU counter has been declared by
COUNTER:CTU. The following instructions implement the block call and use its
outputs:
COUNTER (CU:=INCREASE, R:=CLEAR, PV:=UPPER_LIMIT);
FULL:=COUNTER.Q;
HOW_MANY:=COUNTER.CV;

3. CPDev package
3.1. Internal structure
The CPDev package consists of three programs executed by PC and one by
the controller. The PC programs are as follows:
CPDev compiler of ST language,
CPSim simulator,
CPCon configurer of hardware resources.
The programs exchange data through files in appropriate formats. The
CPDev compiler (the same name as the package) generates universal code
executed by virtual machine (VM) run by the controller. The VM operates as an
interpreter. The universal code is a list of primitive instructions of the VM
language called VMASM assembler. VMASM is not related to any particular
processor, however it is close to typical assemblers. The VMASM and virtual
machine are described in Secs. 4, 5 and 6.
Fig. 2 presents relation between CPDev, CPSim and CPCon. Separation of
the package into logic and hardware layers simplifies implementation at
different platforms. The ST source program is compiled into universal
executable code at the logic layer. The compiler employs ST syntax rules, list of
VMASM instructions and POUs from libraries. Besides the universal code the
compiler generates some information for debugging and simulation. The
addresses of directly represented variables [1,2], declared in ST by AT keyword,
are relative addresses (called local here). They are sufficient for the CPSim
simulator but not sufficient for the target platform.

54

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

Logic
layer

ST language
syntax

Libraries

VMASM assembler

Compiler
CPDev

ST source code

Universal
executable code

Debugger
information

Error list

Simulator
CPSim

Target
platform
Configurer
of hardware resources
CPCon

I/O interface
specification

Hardware
layer

Hardware
allocation map

Communication
Interface specification

Fig. 2. Structure of Control Program Developer

Configuration of hardware resources at the lower layer involves memory,

input/output (I/O) and communication interfaces. Specifications define memory
types and sizes, numbers and types of I/Os and communication channels,
validity flags, etc. Allocation of hardware resources has the form of a map that
assigns local addresses to physical ones. Virtual machine at the target platform,
given the universal code and the map, is able to execute calculations.

3.2. User interface

Main window of CPDev user interface is shown in Fig. 3. The window
consists of three areas:
tree of project structure, on the left,
program in ST language, center,
message list, bottom.
Tree of the MOVE_UNIT project shown in the figure involves POU with the
program PRG_MOVE_UNIT, eight global variables from START to NUMBER,
task TSK_MOVE_UNIT, and two function blocks TP and CTU from the standard
library IEC_61131.

Programming controllers in Structured Text language of IEC 61131-3 standard

55

Fig. 3. User interface in CPDev package

The program PRG_MOVE_UNIT is written according to ST language rules

[1,2]. The first part declares local variables Count, sTime, dTime, and
instances of the function blocks CYCLES:CTU and PAUSE_TIME:TP.
Declarations of global variables are in the second part, and instructions of the
program in the third one. The instructions will not be discussed here. We merely
explain that following START, every 2 seconds the value TRUE appears at one
of consecutive outputs OUT0 to OUT3 (moving unit). The variable Count
indicates which output has the unit. The signal PAUSE generated by the
PAUSE_TIME block stops the movement for 10 seconds. The output NUMBER
of the counter CYCLES indicates number of turns (loops) of the moving unit.
RESET clears all variables and blocks.
Global variables and tasks are defined in CPDev using separate windows
(not shown here). According to IEC the variables can be assigned CONSTANT
and RETAIN attributes, and relative local addresses (by AT keyword). A task can
be executed once, cyclically with a given period, or as soon as the previous

56

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

execution is completed. There is no limit on the number of programs assigned to

a task, however a program can be assigned only once.

3.3. Functions and function blocks

The CPDev package provides most of the standard functions defined in IEC.
Six groups of them followed by examples are listed below:
type conversions: INT_TO_REAL, TIME_TO_DINT, TRUNC,
numerical functions: ADD, SUB, MUL, DIV, SQRT, ABS, LN,
Boolean and bit shift functions: AND, OR, NOT, SHL, ROR,
selection and comparison functions: SEL, MAX, LIMIT, MUX, GE, EQ,
LT,
character string functions: LEN, LEFT, CONCAT, INSERT,
functions of time data types: ADD, SUB, MUL, DIV (IEC standard uses
the same names as for numerical functions).
Variables of any numerical type, i.e. INT, DINT, UINT and REAL (called
ANY_NUM in IEC) can be arguments in most of relevant functions.
Two libraries are available in CPDev so far:
IEC_61131 standard library,
Basic_blocks library with simple blocks supplementing the
standard.
Table 3 lists the blocks from the first library (source program for CTU has
been presented in Table 2). The second library involves fairly simple blocks
similar to the ones available in multifunction instruments and small
programmable automation controllers (PACs).
Table 3. Blocks from IEC_61131 standard library

Bistable elements
flip-flop
flip-flop
semaphore
Counters
up
down
up-down

RS
SR
SEMA
CTU
CTD
CTUD

Edge detectors
rising
falling
Timers
pulse
on-delay
off-delay
real time clock

R_TRIG
F_TRIG
TP
TON
TOF
RTC

Programming controllers in Structured Text language of IEC 61131-3 standard

57

4. Compiler components
4.1. Scanner, parser and code generator
The task of the compiler is to convert XML source file with the project in ST
language into a file with universal executable code in binary format. General
diagram of the compiler operation involving scanner, parser and code generator
is shown in Fig. 4.

Fig. 4. Operation of the CPDev compiler

The scanner (lexical analyser) analyses character stream from the ST source
file and decomposes it into lexical units, i.e. tokens. The tokens are classified
into categories. Most important categories are listed in Table 4. The tokens with
categories are collected on a list passed to the parser.
Table 4. Token categories recognized by the scanner

Category

Example

Category

Example

identifier

PRG_MOVE_UNIT

integer constant

50

keyword

FUNCTION

operator

typed constant

DINT#1722211

delimiter

comment

(* reset *)

directive

(*$READ*)

real constant

18.32

white space

string constant

'Temperature: '

invalid character

The parser operates according to top-down scheme with syntax directed

translation [5]. By employing the ST syntax the parser recognizes consecutive
token constructions from the scanner list. White spaces and comments are
dropped. When correct construction is recognized the parser replaces it by a set
of mnemonic instructions of the VMASM assembler. To do so, the parser
employs built in elementary data types (Table 1) and list of VMASM
instructions. Examples of these instructions are presented in Table 5.

58

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

Table 5. VMASM assembler instructions of the virtual machine

Instruction Meaning

ST oper. Instruction Meaning

ADD

Addition

OR

Logical or

SUB

Subtraction

XOR

Logical xor

MUL

Multiplication

NOT

Binary negation

DIV

Division

MCD

Constant initialization

NEG

Negation

MEMCP

Memory copy

EXPT

Power

**

SHL/SHR

Shift left/right

GT

Greater

>

ROL/ROR

Rotate left/right

LT

Less

<

JMP

Unconditional jump

GE

Greater or equal

>=

JZ

LE

Less or equal

<=

JNZ

EQ

Equal

JR

Relative jump

NE

Not equal

<>

JRN

CONCAT

String concatenation +

JRZ

Conditional relative
jumps

AND

Logical and

RETURN

Return from a function

&

Conditional jumps

Some translations require introduction of auxiliary variables and labels (see

Sec. 5.2). Derived data types and POUs from libraries (functions, function
blocks and programs) are also parsed. The mnemonic code is written in a
special text format. The code can be consolidated with other mnemonic codes.
In the third step the code generator converts the consolidated mnemonic
code into universal executable code in binary format. Mnemonics of the
VMASM instructions, names of the variables and labels are replaced by
corresponding digital identifiers. To do so, the generator employs a Library
Configuration File (LCF) with the identifiers of the instructions, numbers and
types of the operands, and information how the operands are acquired (operator
identifier may be an index to variable or a direct value). Each implementation of
the virtual machine is defined by specific LCF configuration file.
Besides binary file with the executable code (*.xcp extension) the
compiler generates a text file (*.dcp) with mnemonic code, some additional
information for CPSim simulator (variable names, etc.) and compilation report.

Programming controllers in Structured Text language of IEC 61131-3 standard

59

4.2. Parser and code generator classes

Basic elements of the compiler are defined as classes in C# language [3,6].
Each token selected by the scanner becomes an object of corresponding class.
The classes inherit from an abstract STIdentifier class. During compilation,
object identifiers are collected on appropriate lists. So there is a list of global
identifiers and lists of local identifiers for functions, function blocks and
programs (POUs). Predicates are applied to find identifiers on the lists, so
cumbersome creation of hash tables is avoided. The identifiers on the lists are
verified with respect to uniqueness. If two identical ones are detected, the
compilation is stopped and error reported. Hiding a global identifier by local one
produces a warning message in compilation report (lower area in Fig. 3).

Fig. 5. Classes of object representation of ST tokens

Virtual machine instructions passed from the parser to code generator

involve mnemonics and operand lists. Each instruction is stored as an object of
VMInstruction class. The operand list is an object of VMOperand class
being a field in VMInstruction. The use of lists at all stages of the
compilation eliminates problems encountered with fixed-size tables.

60

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

5. Compilation of the CTU counter

5.1. Block definition, declarations
Compilation steps will now be presented in details using the example of the
CTU counter (Table 2). So suppose that after merging all items of the project, i.e.
global variables, POUs, tasks and libraries, the ST code of the CTU counter
(repeated in Fig. 6) is going to be compiled.

Fig. 6. Compilation process-scanning and compilation

As indicated before, in the first step the scanner decomposes input character
stream into tokens, and classifies them into categories. Here the first token is
FUNCTION_BLOCK from keyword category (Table 4). Hence the next token
CTU is treated as a new identifier of STFunctionBlock class and registered
on the list of global identifiers. The following token VAR_INPUT is a keyword
that begins declaration clause. ST language requires declaration clauses to be
finished by END_VAR. Interpretation of all clauses beginning with VAR, so
VAR_INPUT, VAR_OUTPUT and VAR proceeds according to lexical diagram of
Fig. 7. Taking into account the types (BOOL and INT here), the parser
determines memory sizes for the variables declared. The sizes will be used by
the code generator to resolve addresses (Sec. 5.3).

Programming controllers in Structured Text language of IEC 61131-3 standard

61

Fig. 7. Lexical diagram of the VAR declaration clause

5.2. Instruction compilation, instance initialization

If the next token does not match any declaration clause, compilation of the
code implementing the operation begins. The ST body is compiled first,
followed by generation of the instance, i.e. assignment of initial values to
variables and initialization of other functions and blocks, if used by this block.
Here the body begins with the keyword IF of the conditional instruction. This
translates into the line 009 in Fig. 6, with the conditional jump dependent on the
identifier RESET. If RESET is FALSE (ELSE clause), JZ jumps to the label
:?CTUIF?B00E0 below. We explain that the names of auxiliary variables and
labels generated automatically during compilation of conditional instructions,
loops and complicated expressions are indicated by question marks? This makes
them different from the names in ST (without question marks).
The MEMCP instruction in the line 010 copies two bytes (#0200) to the
variable CV from the auxiliary variable ?LVAR?T00E1 that stores 0 (see
below). Unconditional JMP in the line 011 jumps to the label
:?CTUIF?E00E? completing the IF instruction. The lines 013 and 014
evaluate the Boolean expression CU AND NOT CUp from the second IF. NOT
is executed first, as required by priority [1,2]. The line 018 evaluates
CV:=CV+1 from the third IF, with ?LVAR?T00EC storing 1. Two assignment
instructions below the last END_IF (middle of Fig. 6) translate into the lines
020 and 021. The function GE replaces the operator >=. RETURN completes
compilation of the body.
Now the compiler initializes the instance of the block. Corresponding code
shown in the lines 001 to 007 contains the MCD instructions (Table 5) for
initialization of output, local and auxiliary variables by constant values, namely:
Boolean variables Q, CUp initialized by FALSE (#00),
integer variable CV initialized by 0 (#0000),
auxiliary integer variables ?LVAR?T001, ?LVAR?T00EC initialized by
0 and 1 (#0100), respectively.

62

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

As seen, two byte variables are in the Little Endian form. Similarly as
before, RETURN completes the initialization section.

5.3. Binary code

In the third step the final executable code for the virtual machine is created.
To do so, the compiler consolidates the codes of all modules and translates the
overall mnemonic code into binary form by replacing:
instruction mnemonics with corresponding digital identifiers,
variable names by addresses (local) in the data memory,
label names by code addresses (absolute or relative).
Digital identifiers of mnemonics are provided by the LCF configuration file
mentioned before. A portion of this file with definition of the GE instruction
(line 020 before) is shown in Fig. 8 (lower left part). The identifier 1102
assigned to the vmcode attribute appears at the address 006F in the binary
code.

Fig. 8. Compilation process code generation and output files

Local addresses of variables are resolved using the sizes determined by the
scanner at the beginning (Sec. 5.1). The first address is 0000. In our example
the variables CU, RESET, PV, Q, CV and CUp are consecutively declared
(Fig. 6). BOOL occupies one byte and INT two. So the variables are at the
addresses 0000, 0001, 0002, 0004, 0005 and 0007, respectively. The

Programming controllers in Structured Text language of IEC 61131-3 standard

63

addresses of Q, CV and PV are seen at 006F and 0073 in the binary code
(Fig. 8, Little Endian).
As mentioned before, the LCF configuration file is created independently for
each virtual machine. So in one case the mnemonic GE can be replaced by 1102
and in another one by something else. Diversification of the vmcode attributes
is the way to optimize the code for particular processors. Besides, by using
<deny-type> elements of the LCF file (TYPES section) one can restrict the
number of available data types. This provides flexibility of the CPDev package.
By applying <deny-type>, the number of data types for SMC controller
mentioned in the next section has been restricted to ten. So by means of the LCF
files one can create dedicated compilers for particular applications.

6. Realization of virtual machine

6.1. Virtual machine
Deployment of executable software at the target platform is illustrated in
Fig. 9. Binary files with the universal code and hardware allocation map from
the CPCon configurer (Sec. 3.1) are downloaded into the controller, to be
processed by virtual machine. Main features of the processing are characterized
below.

Fig. 9. Deployment of executable software in the controller

Virtual machine is an automaton operating according to Fig. 10. The task

consists of programs executed consecutively. The binary code involves digital
identifiers of the instructions and addresses of operands (Fig. 8, middle). The
machine, similarly as a real processor, maintains program counter with the
address of instruction to be executed, and base address of the data area with
operands (specified for each POU). Given the instruction address, the machine
fetches the identifier, decodes it, fetches the operands, and executes the

64

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

instruction. Stack emulation and update of the base addresses permit multiple,
concurrent calls of functions and function blocks.

Fig. 10. Operation of the virtual machine

Allocation of software to memory segments is shown in Fig. 11a. The

instructions are in the code segment (read only). Data segment contains global,
local and auxiliary variables, some of them with constant values (Sec. 5.2). The
data segment can be accessed directly or indirectly by special registers (virtual).
The machine's internal memory holds code of the interpreter, stacks and
registers. There is no way of accessing internal memory from the program level.
As shown in Fig. 11b, the virtual machine consists of a few software
modules to simplify implementation on different platforms. The universal
modules remain unchanged (if one neglects compilation of the source code for a
given processor). The platform dependent modules must be rewritten or
modified (but without changing procedure calls, see below). For instance, the
module Time&Clock is associated with particular hardware, as it employs time
interrupts to handle TIME data. DATE_AND_TIME data require real-time clock
(RTC) on board. The multitasking module is optional, since it employs
mechanisms of the host operating system. In such environment the tasks create
private copies of global variables to avoid conflicts (so-called process image
mechanism).

Programming controllers in Structured Text language of IEC 61131-3 standard

65

Fig. 11. Virtual machine: a) memory organization, b) software modules

The universal part of the virtual machine has been written in industry
standard ANSI C, so it can be directly applied to different processors. As
indicated before, the number of data types and the way in which the machine
instructions are executed are defined by the LCF configuration file. A set of
general specifications has been developed in CPDev for handling processor
components (interrupt system, RTC) and external interfaces (I/O,
communications). The specifications are in the form of prototypes of
corresponding procedures (names, types of inputs and returned outputs). The
prototypes do not depend on processor and hardware solutions.
The file with the prototypes (*.h) is compiled together with the universal
modules of the virtual machine. The contents (bodies) of the specification
procedures can be prepared elsewhere and, as a binary file (e.g. *.obj),
consolidated with the compiled universal modules. This gives the complete code
of the virtual machine for the given platform.
We stress that the contents of the procedures, dependent on the processor and
hardware solutions, may be written by controller designers themselves. This
makes the CPDev package open also in the hardware sense.

7. Distributed mini-system with SMC controller

An SMC controller (Fig. 12a) introduced recently by LUMEL Zielona Gra [8]
is the first control-and-measurement device programmed by the CPDev
package. SMC has two RS-485 and RS-232/485 serial ports and USB
interface, but does not have inputs and outputs of its own. Therefore it is

66

D. Rzo ca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus

used as a central module in distributed mini-systems for control and

monitoring of small technological processes. Example of such system is
shown in Fig. 12b. Modbus RTU protocol handles communications [9].
a)

b)
S MC

RS485

RS485

RS232

SMC

RS485

Fig. 12. a) SMC programmable controller;

b) distributed control-and-measurement system from LUMEL Zielona Gra

Of twenty data types available in CPDev (Table 1), the SMC implements
ten, namely BOOL, INT, DINT, UINT, REAL, WORD, DWORD, STRING, TIME
and DATE_AND_TIME. Since SMC does not carry I/Os on board, the CPCon
configurer configures communications only.
The SMC controller is equipped with 8-bit AVR ATmega 128
microcontroller [10]. This is a modern RISC microprocessor able to execute
most of instructions in a single clock cycle, with separate buses for program and
data memories. The universal modules of the virtual machine, i.e. VMASM
assembler interpreter, stack emulator and data type handler (Fig. 11b) have been
compiled by avr-gcc compiler from WinAVR package [11]. Hardware dependent
software, i.e. interrupts, RTC and communication interfaces have been written
by engineers from LUMEL and sent to the authors in binary format.
Consolidation has produced a virtual machine which, written into SMC flash
memory, executes ST programs compiled by CPDev package and downloaded
from PC.
Another machine for ADuC841 microcontroller (MCS-51 core) has been
also developed. The machine for PC is a part of CPSim simulator.

Programming controllers in Structured Text language of IEC 61131-3 standard

67

8. Conclusions
The CPDev package for programming controllers and other control-andmeasurement devices in the ST language of IEC 61131-3 standard has been
presented. The package is universal, since the compiled code can be executed on
different platforms. However, the execution must be carried out by virtual
machines dedicated for particular processors.
Operation of the CPDev compiler involving scanner, parser and code
generator has been explained by means of a program for CTU counter. The
compiler produces universal executable code which, together with hardware
allocation map, is downloaded into the controller and executed by the virtual
machine. The machine is configured by means of LCF Library Configuration
File which enables selection of data types and some form of code optimization.
The CPDev package is open in terms of both software and hardware. The
user can create libraries with POUs. Hardware designers can program external
interfaces (drivers). Distributed mini-system from LUMEL is the first
application of the package.

References
[1] John K.H., Tiegelkamp M.: IEC 61131-3: Programming Industrial Automation
Systems. Berlin Heidelberg, Springer-Verlag, 2001.
[2] Kasprzyk J.: Programming Industrial Controllers, WNT, Warsaw, 2006 (in Polish).
[3] C# Language Specification
http://msdn2.microsoft.com/enus/vcsharp/aa336809.aspx
[4] Rzo ca D., Sadolewski J., Trybus B.: IEC 61131-3 standard ST compiler into
universal executable code. In: Real-Time Systems. Methods and Applications, WK,
Warsaw, 189-198, 2007 (in Polish).
[5] Stec A., wider Z., Trybus L.: Functional characteristic of the prototype system for
embedded systems programming. In: Real-Time Systems. Methods and
Applications, WK, Warsaw, 179-188, 2007 (in Polish).
[6] Cooper K., Torczon L.: Engineering a Compiler. Morgan Kaufmann, San Francisco,
2003.
[7] Appel A., Palsberg J.: Modern compiler implementation in Java. Second edition.
Cambridge University Press, 2002.
[8] LUMEL Ltd., Zielona Gra http://www.lumel.pl
[9] Modicon MODBUS Protocol Reference Guide. MODICON, Inc., Industrial
Automation Systems, Massachusetts, 1996.
http://www.modbus.org/docs/PI_MBUS_300.pdf
[10] ATmega 128 Datasheet. Atmel, 2007.
http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf
[11] WinAVR Development Tools for the Atmel AVR. http://winavr.sourceforge.net/
[12] ADuc841 Datasheet. Analog Devices, 2003.
http://www.analog.com/UploadedFiles/Data_Sheets/
ADUC841_842_843.pdf