CD_WantMore
CD_WantMore
CD_WantMore
CD_WantMore
CD_WantMore

IEC 61131-3: By the Numbers

April 6, 2008
The Intent of Program Organizational Units (POUs) Is to Reduce Differences Between Suppliers, So A Timer Is A Timer, Regardless of Who Provides It
By Jeremy Pollard, CET

IEC 61131-3 was first used for PC-based control programming in the ’90s. PLCs had their own vendor-developed programming platforms.

CEI-IEC1131-3 was published by the IEC in 1993, but it began as a new work item of Technical Committee 75 in 1978. After 15 years, the 207-page document delivered the reader into a world of standards jargon and nomenclature. The major PLC vendors from Europe and North America initiated and supported the standard.

The intent of the standard, renamed in 1997, and its six parts is to normalize PLC and control systems and their programming by standardizing functionality such as program entry, instruction visualization, data types and syntax.

Included in the general requirements section are the software, communication—external as well as internal instruction and variable parameter passing—and programming models.

The software model introduces the concepts of configurations such as a PLC; resources like CPUs; tasks such as executable software; variables like storage; and communication paths. An IEC-based hardware “client” could run multiple tasks within a single configuration, or in fact have multiple configurations.

The communication model specifies how data is passed to different tasks or configurations or within the same task. Global variables are introduced.

The programming model is tied in very closely with concept of common elements, which provide for use of common data types, variable declaration and data formats such as dates and times. Program organizational units (POUs) also are common elements.

To read Jeremy Pollard's multiple-part saga on IEC 61131 and other related articles, 
visit our IEC 61131 resource page
POUs were developed to reduce the often implied meanings of instructions and blocks. There are three types of POUs defined in the standard.

The program POU is the program. Nothing new here. The function_block POU is a program block with inputs and outputs used for tasks such as timers and counters. The function POU lets various program elements extend the instruction set of the configuration.

The intent of these POUs is to reduce the differences between suppliers so a timer is a timer, regardless of who provides it.

The standard defines data types, such as Boolean and integer. The standard also defines the use and format of derived data types and functions. These derived functions and data types must conform to the previously mentioned standard data types.

The programming model extends a PLC-type programming environment with three languages and two graphical representation languages.

Ladder Logic is most used in discrete applications and is the most widely coded language in automation today. This language mainly was supported by the North American PLC vendors.

Some European PLCs were built with Instruction List, a very rudimentary assembler-type language. Statement List is the third language, which is Pascal-like. Various vendors supported a scripting language that was normalized into ST.

The graphical languages are Sequential Function Chart (derived from Grafcet [French]) and Function Block. These are graphical representations of processes and have underlying code that is written in one of the three languages, or in fact, an alternate language such as C++.

The standard defines the abstraction between the IEC model and the PLC/control hardware by using device tags and not addresses. Similar to programming in a high-level language such as Visual Basic, it allows the programmer to define a memory point, not by address, but by a descriptive name. The standard defines the characters you can use in the description. The outside world is tied into the model based on the hardware you use.

The desired effect of the standard is to reduce the user’s learning curve between vendors, and this standard was developed to meet that need, even as early as 1978.

Next up, we’ll discuss what IEC 61131 isn’t.