IEC61131-3 may sound like a complex specification, but in
practical use it comes down to just a few concepts that promote good
programming techniques and code reusability.
The most fundamental of IEC concepts is program execution
behavior. Each controller or PLC in an automation system is called a resource,
and each resource executes one or more tasks. Multiple tasks may be updated at
different update rates. The IEC code in each task is further divided into
Program Organization Units (POUs), which are executed within the task in the
order specified. The POU may exist as a program type and run in the associated
task. Alternatively, it may be a mathematical function type POU or a Function
Block type of POU, both of which run when used within the program type of POU.
Much like the familiar programming subroutine, customized
functions and function blocks allow the programmer to wrap up a particular
piece of code for easy organization, for reuse, for protection of intellectual
property, and/or for revision control.
Click here for larger image.
|
Variables and Data Types
The terminology and mechanics of variables, data types
and literals is defined in IEC61131-3 - and these definitions must be followed.
The character set is limited to alphanumeric and the underscore
with no spaces or special characters allowed. Programmers must therefore get
used to working with variables with names like "FeedSpeed" or "Feed_Speed."
Capital letters are preserved for display purposes, but capitalization
differences are ignored in program execution.
Most programmers are likely to find a new set of standard terms
to get used to in IEC61131-3. Besides the previously mentioned acronym POU, a
constant hard-coded value is called a literal. A variable with one bit of
information is called a BOOL. And when there's a decimal point, it's called a
REAL or LREAL data type.
This data type terminology
manifests itself in both literals and variables. A literal, hard-coded value of
"5" is expressed in the code with a data type prefix such as LREAL#5.0, INT#5,
WORD#5, or TIME#5s.
This provides a visible
double-check for the programmer to avoid unintentional mixing of data types.
The same holds true with variables.
A variable is assigned a data
type, and the initial value associated with that variable must match the data
type. So if a variable is named "FeedSpeed" and is given the data type LREAL,
then it can have an initial value of 5.0, but not 5 or 5s.
Often in programming, the
output of one part of the code is in one data type, and it must be used in
another part of the code as another data type. For example, an input value may
be received from an HMI as a WORD#5, to be written to the variable "FeedSpeed,"
with the LREAL data type. This requires a data conversion step.
IEC61131-3 good programming
practice insists that any conversion step not be hidden from view, so the
programmer must specifically define the conversion step. Fortunately, data type
conversion function blocks between any two combinations of the 20 standard data
types are provided so that data type conversion can be tightly
controlled.
Multiple Programming Languages
IEC uses and combines five of the most common programming
languages: Ladder Diagram (LD), Structured Text (ST), Function Block Diagram
(FBD), Instruction List (IL) and Sequential Function Chart (SFC).
The programmer decides the best language for a particular POU
based on personal preference and on the purpose of that particular POU. A
function block POU written in one language can be used within another POU of a
different language.
For example, a complex
mathematical formula may be best programmed using the ST language. I/O logic is
usually more easily programmed in LD, while FBD may be best for a motion
control sequence. SFC is effective to control the states of the machine. Under
the IEC61131-3 standard, the strengths of each language can be used simultaneously.
High-Level Programming
IEC61131-3 goes beyond fundamental programming techniques
- defining several high-level programming concepts such as Enumerated Types,
Arrays and Data Structures.
Enumerated Types give a name to a number so that when a numerical
selection is required, the name can be used in its place. This makes the code
more intelligible and aids in troubleshooting.
For example, the PLCopen function block MC_MoveAbsolute includes
a direction input so that rotary machines can locate the position in four
different ways, including "shortest_way." Instead of assigning the direction
input to 0, 1, 2, or 3, the "shortest_way" text can be used.
Arrays are familiar to many programmers and allow a large amount
of data to be accessed by indexing the address within the array. The data
structure is a critical programming tool for wrapping up an assembly of
different types of data into one variable.
One example of the usefulness
of data structures can be found in Yaskawa's PLCopen Toolbox user library for the
MP2000iec series controllers. Each axis in a system will typically have the
same data associated with it such as a jog speed, run speed, position,
parameters, etc.
Traditionally, the programmer must create separate variables for
each of these axis-specific pieces of data, a tedious task. But with
IEC61131-3, it's possible to define a data structure that contains all of the
axis-specific data once and for all, creating a type of template.
The programmer then creates a single variable (FeedAxis) for the
axis and chooses this new structure as the data type (Axis Struct). This
provides the equivalent result to having created tens or even hundreds of
variables all at once.
The data can be accessed as if it were a variable using the dot
notation such as FeedAxis.JogSpeed or FeedAxis.Prm. Additional variables with
this same data structure can be defined for the other axes in the system,
quickly creating an orderly and consistent definition of variables associated
with each axis.
The IEC61131-3 standard provides a host of benefits to
programmers of PLCs and controllers for integrating mechatronic applications.
Although it takes some time up front to learn specific terminology and
techniques, overall efficiency is increased. The resulting programs can then be
used and interpreted by others familiar with the standard, creating common
ground for other programmers and for maintenance and operations personnel.
Matt
Pelletier is senior product training engineer at Yaskawa America Inc.
Click
here
for more information.
Tweet This
3 
