Dr. Ken Ryan is a PLCopen board member and an instructor in the
Center for Automation and Motion Control at Alexandria Technical
College. He is the founder and director of the Manufacturing Automation
Research Laboratory and directs the Automation Systems Integration
program at the center.
The ‘lowest’ level of program organization unit it the function.
A function is a software object which when invoked and supplied with a
unique set of input variables will return a single value with the same
name and of the same data type as those of the function. The sine qua
non of a function is the behavior that returns the same value anytime
the same input values are supplied. The best example of a function is
the ADD function. Any time I supply 2 and 2 to the ADD function inputs I
will receive a 4 as the return value. Since there is no other solution
for 2+2 then there is no need to store information about the previous
invocation of the ADD function (no instantiation) and thus no need for
internal memory.
This is the first in a series of articles focused on writing code
using the IEC 61131-3 programming standard. The first few articles will
focus on orientation to the architecture of the standard and the data
typing conventions. After covering these, this series will explore code
writing for a diverse field of application situations.
THE IEC 61131-3 SOFTWARE MODEL
Figure 1
The IEC 61131-3 standard has a hierarchal approach to programming
structure. The software model in Figure 1 depicts the block diagram on
this structure. Let’s decompose this structure from the top down.
Configuration:
At the top level of the software structure for any control application is the configuration.
This is the “configuration” or the control architecture of the software
defining the function of a particular PLC in a specific application.
This PLC may have many processors and may be one of several used in an
overall application such as a processing plant. We generally discuss one
configuration as encompassing only one PLC but with PC-based control
this may be extended to include one PC that may have the capability of
several PLCs. A configuration may need to communicate with other
configurations in the overall process using defined interfaces which
provide access paths for communication functions. These must be formally
specified using standard language elements.
Resource:
Beneath each configuration reside one or more resources. The resource supplies the support for program execution. This is defined by the standard as:
‘A resource corresponds to a “signal processing function” and
its “man-machine interface” and “sensor and actuator interface”
functions (if any) as defined in IEC 61131-3’.
An IEC program cannot execute unless loaded on a resource. A
resource may be a runtime application existing in a controller that may
exist in a PLC or on a PC. In fact, in many integrated development
environments today, the runtime system can be used to simulate control
program execution for development and debug purposes. In most cases a
single configuration will contain a single resource but the standard
provides for multiple resources in a single configuration. Figure 1
shows 2 resources under one configuration.
Task:
Tasks are the execution control mechanism for the
resource. There may be no specifically defined task or multiple tasks
defined for any given resource. If no task is declared the runtime
software needs to have a specific program it recognizes for default
execution. As you can see from Figure 1 tasks are able to call programs
and function blocks. However, some implementations of the IEC 61131-3
standard limit tasks to calling programs only and not function blocks.
Tasks have 3 attributes:
1. Name
2. Type – Continuous, Cyclic or Event-based
3. Priority – 0 = Highest priority
The next article in this series will focus exclusively on tasks and
their configuration and associations to programs and function blocks.
For now we will continue our decomposition of the software model.
Program Organization Units:
The lower three levels of the software model are referred to collectively as Program Organization Units (POUs).
-
Programs
-
Function Blocks
-
Functions
Programs:
A program, when used as a noun, refers to a software object that
can incorporate or ‘invoke’ a number of function blocks or functions to
perform the signal processing necessary to accomplish partial or
complete control of a machine or process by a programmable controller
system. This is usually done through the linking of several function
blocks and the exchange of data through software connections created
using variables. Instances (copies of a program can only be created at
the resource level. Programs can read and write I/O data using global
and directly represented variables. Programs can invoke and exchange
data with other programs using resource-level global variables. Programs
can exchange data with programs in other configurations using
communication function blocks and via access paths.
Function Blocks:
The real workhorses of this hierarchal software structure are the function blocks.
It is common to link function blocks both vertically (one function
block extends another) or horizontally (one function block invokes
another) in order to create a well structured control architecture.
Function Blocks encapsulate both the data (as internal variables and the
input and output variable that interface the function blocks to other
software objects) and an encoded algorithm that determines the value of
internal and output variables based on the current value of input and
internal variables. The key differentiator between function blocks and
functions is the retention of values in memory which is unique to
function blocks and not an attribute of functions. Since a function
block can have a defined state by virtue of its memory, its class
description can be copied (instantiated) multiple times. One of the
simplest examples of a function block is a timer. Once the class object
“timer” is described multiple copies of the class can be instantiated
(timer1, timer2, timer3… etc.) each having a unique state based on the
value of its variables.
Functions:
Access paths:
The method provided for exchange of data between different configurations is that of access paths.
Access paths supply a named variable that through which a configuration
can transfer data values to/from other remote configurations. The
standard does not define the lower layer protocol to be used for this
transfer but rather defines the creation of a construct (‘container’) in
which the data can travel.
Global Variable:
Finally we come to the variables which are declared to be “visible” to all members of a specific level on the hierarchy. If a global variable
is declared at the program level then all programs, function blocks and
functions that are members of this program have access to this data. We
say that the data is within their scope. Likewise, a global variable
declared at the resource level will be available to ALL programs located
on this resource.
Source:-http://www.automation.com/library/articles-white-papers/programmable-control-plc-pac/coder146s-corner-plcopen-standards-architecture--data-typing
