Μ

Edouard Tisserant, Laurent Bessard, and Mário de Sousa

An Open Source IEC 61131-3 Integrated Development

Environment
Abstract—The IEC 61131-3 standard defines a common not discuss.
framework for programming PLCs (Programmable Logic Additionally, and just like any other programming
Controllers), which includes the complete definition of four
language, learning and becoming proficient with these
programming languages and a state machine definition
language. Industrial PLC vendors are slowly offering support programming languages requires that the student practice
for this standard, however small inconsistencies remain extensively program development and therefore learn from
between their implementations, transferring programs his/her mistakes and errors. Expensive licensing deals from
between vendors is almost impossible due to different file existing vendors makes it cost prohibitive to allow students
formats, and licenses are generally too expensive to allow to install an IEC 61131-3 programming environment on
students do install these commercial solutions on their own
computers.
their own personal computers. Practice is therefore limited
To this end, the authors have developed an Integrated to the few workstations that may be made available to the
Development Environment (IDE) for the IEC 61131-3 students and located on the school campus.
framework, which is being offered to the general public under The authors therefore embarked on the project of
the GNU Public License (GPL). The IDE consists of a developing and IDE for the IEC 61131-3 standard that may
Graphical User Interface (GUI) and a backend compiler. be used freely and without restrictions by anybody who so
Using the GUI the user may develop programs in any of the wishes. In order to foment the dissemination and take
four programming languages, as well as the state machine
definition language. The backend compiler is used to convert advantage of any help that third parties may wish to
these programs into equivalent C++ programs which may provide, the code has been made publicly available under
later be compiled and executed on various platforms. the GPL. The project has two main requirements, namely:
– strict adherence to the IEC 61131-3 standard
I.INTRODUCTION – cross platform support

T HE proliferation of PLCs (Programmable Logical

Controllers) used in an industrial setting is indicative
of their usefulness. These have evolved with the times, to
A.Outline
This paper describes the implementation of an IEC
61131-3 integrated development environment. After this
the point that many modern top of the range PLCs are first section which introduces the paper, section 2 gives a
actually full fledged computers in disguise, executing necessarily brief overview of the IEC 61131-3 standard.
modern operating systems. The hardware inside many Section 3 describes the graphical user interface of the IDE
vendor's PLCs has a tendency to become similar to PCs and its implementation, and section 4 describes the IL and
(Personal Computers) in order to take advantage of ST compiler that comprises the backend. We conclude in
economies of scale. section 5 with a few comments on the IEC 61131-3
On the other hand, the diversity of the programming standard itself, and point to directions to which we may
languages used between different vendors, along with their draw our attention in future work.
increased complexity, has led to larger learning times for
the programmer when switching between PLC. To this end, II.IEC 61131-3 OVERVIEW
the IEC (International Electrotechnical Commission), an
international standards body, has approved a collection of The IEC 61131 standard [1] is a general framework, that
standards with the intention of creating a common user tries to establish the rules to which all PLCs should adhere
experience when configuring and programming industrial to, encompassing mechanical, electrical, and logical
controllers. One of the components of this standard, aspects. The third part, IEC 61131-3, deals with the
namely the IEC 61131-3 [1], defines how the user may programming aspect of the industrial controllers, defining
program the PLCs, and includes a programming framework the logical programming blocks and the programming
and several programming languages. languages.
Nevertheless, even though both the hardware and the There are three variations of top level programming
software aspect of differing vendor PLCs are becoming blocks: functions, function block types, and program types.
similar, the vendors are still able to lock users into their Functions have similar semantics to those in traditional
line of products using several techniques which we shall functional languages, and directly return a single output
value. However, besides one or more input values
M
anuscript received January 24, 2007. (equivalent to variables passed as values), the function may
Mário de Sousa is with the Electrical Engineering Department,
University of Porto, 4200 465 Porto, Portugal, (phone: +351 22 508 1815; also have parameters used as outputs (equivalent to passing
fax: +351 22 508 1443; e-mail: msousa@fe.up.pt). variables as references), or as input and output
Edouard Tisserant and Laurent Bessard are with TBI SARL - Lolitech, simultaneously. Function semantics state that they are
88100 Saint-Dié-des-Vosges, France (phone: +33 (0)3 29 52 95 67; e-mail:
edouard.tisserant@lolitech.fr, laurent.bessard@lolitech.fr). idempotent, i.e. all invocations of the same function with
the same input values should always yield exactly the same
result, whatever the state of the rest of the system,
including the time at which the function is executed.
Function block types are similar to classes in object
oriented languages, with the limitation of having a single
public member function. Function blocks are instantiated
as variables, each with their own copy of the function block
state. The default function of a function block does not
directly return any value, but, like functions, may have
parameters to pass data as input, output or bidirectional.
Since the function block has only a single function, calling Fig. 1. General aspect of the Graphical User Interface
this function is commonly referred to as 'calling the
function block'. Likewise, this function's parameters are interface variables, as well as all internal variables (Fig. 1).
often referred to as the function block parameters. Each POU may be further programed in any of the IEC
Since a function must be idem-potent, it can neither 61131-3 languages, using the appropriate language editor
instantiate nor call a function block instance. It may, on the right pane of the IDE. The definition of the POU
however, read the current values of the output or interface, as well as all internal variables is made through a
bidirectional parameters of a function block. Note that the graphical window interface (Fig. 2).
function block instance must be passed to the function as A.The PLCOpen editor
an input parameter, as a function may not instantiate a The GUI lets users program with the five languages
function block instance. defined by IEC 61131-3 standard :
Program types are very similar to function blocks, with – Sequential Function Chart (SFC)
the exception that these may only be instantiated inside a – Function Block Diagram (FBD)
configuration, and not inside other functions, function – Ladder Diagram (LD)
block types or program types. – Structured Text (ST, equivalent to C/C++)
A configuration is the program organization unit with – Instruction List (IL, equivalent to assembler)
the highest abstraction level. It does not contain executable The graphical editor is strongly linked to PLCOpen
code, but rather instantiates programs and/or function specification [2]. This specification defines an XML
blocks, creates and configures tasks, and assigns the grammar describing the five IEC 61131-3 languages. All
programs and/or function blocks to tasks. Tasks are similar automation programs written in this environment are saved
to processes in common operating systems, and may have into XML files, according to this grammar. It is then
periodic execution or execute upon the occurrence of the possible to exchange projects with other IEC 61131-3
rising edge of a specified Boolean variable. editors that conform with the PLCOpen standard.
The three types of programming blocks may be The graphical editor is written with python, and uses the
programmed in one of two textual languages (IL - python binding to wxWidgets. The use of these two
Instruction Language; ST - Structured Text), or two technologies allows the code to be portable between
graphical languages (LD - Ladder; FBD - Function Block different platforms, including Windows and Linux.
Diagram).
The standard also defines a graphical language for
specifying state machines (SFC – Sequential Function
Chart), mostly based on Grafcet, that may also be used in
programming function blocks or programs. Since a state
machine implies the maintenance of state, SFCs may not be
used to program functions because these must be idem-
potent. It should be noted that without reverting to the other
languages it is not possible to write a complete program
using only an SFC chart, which is why the authors hesitate
to refer to SFC as a programming language.

III.THE GRAPHICAL USER INTERFACE

The user interacts with the IEC integrated development
environment through a graphical interface. This graphical
interface lets the user create a project consisting of several Fig. 2. The graphical for interface and variable definition
IEC 61131-3 program organization blocks (POUs). These
POUs are listed in a tree view on the left pane of the IDE. All program editors follow the MVC (Model-View-
Each POU in the tree may be expanded to show its Controller) paradigm. The object classes used by the first
component (i.e. the Model) are dynamically generated from
the official scheme (.xsd) defined in the PLCOpen
specification. Incorporating future changes of the
PLCOpen specifications into the model component of the
editor may therefore be automated.
The SFC, FBD and LD graphical editors allow the user
to insert and delete programming elements in such a way as
not to permit the user to introduce illegal layout. These
programs are therefore always in a correct, although
possibly incomplete, state.
The SFC editor (Fig. 3) provides a toolbox with which to
insert initial steps, steps, transitions, and transition
convergences or divergences. The insertion of these
elements (except an initial step) must always be referenced Fig. 3. The SFC editor
to a previously existing element of the SFC. For example,
to insert a transition the user must first select the step to
which it will be associated. Likewise, to insert a step the
user must first select a transition or another step. In the
case a step is selected, the editor automatically inserts a
transition between the steps.
The LD editor (Fig. 4) follows the same philosophy. The
creation of a new rung implies the insertion of an output
relay. The rung is always in a consistent state, only Fig. 4. The LD editor
allowing the user to introduce new elements in such a way
as to produce another valid state.
The textual language editors, IL (Fig. 5) and ST (Fig. 6),
include syntax highlighting of the code, and
autocompletion of keywords and variable names. Simple
syntax errors are highlighted, nevertheless (and unlike the
graphical editors), the code may be saved with the syntax
and/or semantic errors inside.
B.Conversion of Graphical Languages
A module is responsible to translate PLCOpen graphical
language (FBD and LD) into ST. This part is integrated
into the graphical editor, but may be used independently. Fig. 5. The IL editor
The reverse value propagation algorithm is used to convert
these graphical languages into ST.
Conversion is also conditioned by optional debug mode,
that adds necessary information in generated code. This
information will then be used at runtime to ensure status
feedback for users.
Graphical SFC programs, on the other hand, may be
converted to the textual syntax used to express SFC
programs. This textual syntax, although not commonly
used, has been normalized in IEC 61131-3. As with the
textual ST and IL languages, it will be up to the backend
compiler to compile SFC programs expressed using the Fig. 6. The ST editor
textual syntax into the equivalent C++ program.
and XML grammar for describing vector graphics. The
C.Human Machine Interface Creation Tool main idea is to let users "draw" their HMI with any
The authors intend to continue the development of the standard SVG drawing software such as Inkscape, and
project in several fronts. One these will be the integration select graphical elements that will participate in the
of a tool (which the authors intend to call SVGUI) to allow interaction with the automation program.
the user/programmer to define graphical interfaces to the The interaction will be made through the use of wxSVG,
automation control program. This will be based on the which is a SVG renderer using wxWidgets graphical
"SVG" (Scalable Vector Graphics) open W3C standard, library. The particularity of wxSVG is that it loads an SVG
file into a "living" object tree in memory, allowing "live" A.Lexical Analyser
access to the graphical elements. The lexical analyser was implemented using the flex
A "widgets" library (e.g: buttons, scrollbars, textareas, utility that generates lexical analysers from a configuration
checkboxes,...) will have to be developed that uses wxSVG file. The configuration file includes the extended
graphical elements for representation and interaction. As an expression definitions of the language's tokens.
example a rectangle drawn under Inkscape can be defined This stage is the most straightforward, but nevertheless
as a button and when clicked, change form and colour, and still has its difficulties. The main issue is the definition of
move around the screen. the EOL token (used in the IL language), and defined by
In SVGUI, appearance is completely independent of the standard as “normally consisting of the 'paragraph
code. It is possible to change GUI appearance without any separator' character defined as hexadecimal code 2029 by
source code change. This permits the graphical creation to ISO/IEC 10646 “. This statement seems to leave to the
be entrusted to a graphical designer (i.e. non-programmer) implementors the final choice of which character should
and the interaction to a programmer. This aspect is actually represent the EOL token. It is our intention to allow the
very difficult to find on the majority of GUI toolkits. programs to be written using existing text editors that
The link between SVG graphical elements (rectangles, generate ASCII text. However, the suggested character is
circles, ...) and widgets (buttons, textarea, ...) is done not an ASCII character, and we were therefore forced to
through a simple XML file, that declares which graphical choose another character to represent the EOL token. The
elements participate with which widget. Widgets have their 'newline' (ASCII 10hex) character seemed to be the most
own names and specific variables. All the widgets used will natural.
automatically generate a corresponding Function Block This choice, although seemingly obvious, complicates
that may be used by the automation program. Each matters since the newline character is considered
function block instance will correspond to a single widget whitespace in the standard. This means that the lexical
instance, and each pin to a variable. analyser may only generate EOL tokens while parsing IL
Using this architecture, SVGUI will be a library written statements, and ignore it otherwise. Our solution was to
in C++. Development of some "bindings" for other implement a state machine in the lexical analyser, with a
languages should be rather straightforward. very limited knowledge of the syntax, that tracks whether
IL statements are currently being parsed, and therefore
IV.THE BACKEND COMPILER parsers the newline character as the EOL token, instead of
The backend portion of the IDE consists of a compiler the normal whitespace.
that converts IL, ST and SFC programs into equivalent However, the state machine got more complex when we
C++ programs. This compiler executes in four plus one decided to allow our compiler to automatically detect
stages: lexical analyser, syntax parser, semantics analyser, whether it was parsing IL, ST or SFC, the reason for which
code generator, and binary code generator. is explained later.
The lexical parser analyses the source code and breaks it B.Syntax Parser
up into lexical tokens, removing on the way all comments
and white-spaces between the tokens. The syntax parser The syntax parser was implemented using the GNU
groups the tokens into syntax constructs, and builds an bison utility. This program generates a syntax parser from
equivalent internal abstract syntax data structure. The the syntax definition of the language being parsed.
semantic analyser walks through the abstract syntax and Although it too may have seemed straightforward at first,
determines whether all semantic rules have been obeyed. many issues had to be overcome, of which we shall
The code generator, based on the abstract syntax once mention only a few.
again, produces the final equivalent code. As the IL and ST languages share a very large common
This architecture allows us to easily write a new code syntax related to the declaration of types, functions,
generator for whatever output language desired, without variables, etc., we decided to write a single parser that
having to rewrite all the lexical, syntactic and semantic would handle both languages simultaneously. It was this
parsers. At the moment we have merely implemented a choice that led to the more complex state machine in the
C++ code generator. The last stage of the overall compiler lexical parser, which has already been mentioned.
will generate the final executable from the code generated A few conflicts were found in the syntax definition given
from the previous stage. In our case we are currently using in the standard. These were mostly due to the existence of
the gcc compiler to generate the final executable. more than one route for reducing several constructs. All of
Our abstract syntax tree has been implemented as a tree these conflicts were easily resolved, as the expected
of objects that follow the visitor design pattern [3]. This semantics of either route were identical.
enables us to easily add or remove stages to our Other more thorny issues were related to the fact that the
architecture without having to edit the abstract syntax tree language requires more than one look ahead token to be
classes themselves. Possible additions to the architecture correctly parsed, whereas the bison utility generates a
include a code optimization stage. parser that uses a single look ahead token. We worked
around this issue by reducing to temporary constructs until parameter. This was done in order to allow the loading (LD
the look ahead token that would break the deadlock was operator of the IL language) of FB instances, which
available. Only then was the temporary construct changed requires that the FB instance be copied onto a default
to the correct final construct. This of course resulted in a accumulator type variable, that must be able to store many
much more confusing configuration file for the bison different data types. This accumulator variable is therefore
utility, and less maintainable code. implemented as a C++ union.
We also found that the syntax does not contain sufficient The resulting C++ code is practically self-contained and
redundancy to allow it to be successfully parsed without self-referencing, which allows it to be completely portable
the help of a symbol table that keeps track of the type of to any platform with a C++ compiler. The single instance
construct to which an identifier (name) refers to. The that makes the code platform dependent is how a
syntax parser therefore makes use of two symbol tables, configuration is mapped to C++.
one for the global references (function names, data type Due to time constraints, and in order to maintain
names, ...), and another for variables declared within program portability, complete mapping of configuration
functions, programs or function blocks. The syntax parser constructs has not yet been implemented. Currently a single
adds entries to these tables when an identifier is declared. task running a single program instance is supported. This
Subsequently, when the lexical parser comes across an single program may however call as many FB or functions
identifier, it will first look it up in these tables to verify if it that may be necessary.
has been previously declared. Before any parsing
commences, the global table is initialised with the names of V.CONCLUSIONS
all the default functions and functions blocks defined in the We believe that the editor and compiler are already
standard. usable in both an academic and industrial environment. We
The use of the symbol tables results in many semantic expect to put it to the test in the next academic year.
checks being inherently performed by the syntax parser. Nevertheless, some work still remains to be done. Future
For e.g., a variable name may only be used if it has been work will involve writing the semantic checker, and
previously declared. Type checking, for e.g., is defining a runtime to allow the full syntax of
nevertheless not performed, and is left to the semantic configurations, for at least one platform. Work on the
checker. SVGUI platform to support graphical user interfaces has
C.The Semantic Checker already started.
Due to a lack of time and resources, the semantic
checker has not yet been implemented. Although extremely REFERENCES
important for the correct functioning of the overall [1] IEC, “IEC 61131-3, 2nd Ed. Programmable Controllers – Programming
Languages”, International Electrotechnical Comission, 2003
compiler, we felt that this part could be left for a later [2] PLCopen Technical Committee 6, “XML Formats for IEC 61131-3,
stage. This is mainly due to the fact that our first code Ver 1.0”, April 2005
generator creates C++ source code, which is then compiled [3] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, “Design
Patterns”, Addison-Wesley, 1997, IEBN 0-201-63361-2
by the gcc compiler. Many semantic errors in the ST or IL
source code will also result in semantic errors in the C++
source code, which will be caught by the gcc compiler.
Some semantic errors, such as calling a function block
from within a function, will nevertheless not get caught.
This is of course not a desirable scenario for a fully
functioning compiler, as the user does not get any feedback
as to the location of the error in the ST or IL source code. It
is therefore our intention to complete the semantic checker
as soon as possible.
D.The C++ Code Generator
IL and ST code transcription to C++ is rather
straightforward as many of the constructs used in ST and
IL are also available in C++. Data types not supported
directly by C++, such as time of day, were implemented as
specific C++ classes, with overloaded operators.
Contrary to what might be expected, the FB and program
type constructs are both mapped onto a C++ structure data
type that contains all internal and interface variables for the
FB or program, and an accompanying function that takes
an instance of the referred data structure as its single