C 61131-5 Providing User Oriented Communication

Within the full set of the international IEC 61131 standard, part 5 deals with communication. As such it is approved as Standard in 2000, and is available at IEC or at the local representations (adres info). This part 5 describes the way PLCs can communicate to each other. A PLC as used in the context of IEC 61131 may be a real controller or a SoftPLC or any device which supports the programming languages of IEC 61131-3 and the communication defined in IEC 61131-5. This means from PLC-to-PLC, to HMI, Plant control, and even robots and CNC’s. Even it can provide communication to intelligent devices via a fieldbus. However, it does not include distributed control or communication to simple I/O devices via a sensor / actuator level bus or fieldbus. The IEC 61131-5 describes the communication services from the point of view of the programmer and/or user. As such it is a application program interface for PLC communication. For this it provides communication services in the form of functions combined with the concepts and elements of the IEC 61131-3 programming languages. This means also that it lies on top of the ISO/OSI stack. Otherwise stated, it lies on top of the layer 7 – application layer. As such it really provides services to the users – they do not have to write the code by themselves, nor to worry about how it is done. This matches the high user friendliness of the IEC 61131-3 Function Blocks. IEC 61131-5 does not describe a communication bus-system – it defines independent services at a higher level, which can be used in existing communication networks and systems. Pre-requisite for these systems is that they support connections, access to variables and message services, as well as the loading of large data sets. Also, this standard contains the mapping onto ISO/IEC 9506-1/2 (MMS, Manufacturing Message Specification, as a result of the MAP, Manufacturing Automation Protocol, initiative of General Motors in the 1980’s.) and onto ISO/IEC 9506-5 (PLC Companion Standard). Other communication systems based on other standards or de-facto standards may be used as communication subsystems for IEC 61131-5 too. Example of these are EN 50170 (Profibus FMS), and EN 50170 – 3 (Sub MMS), which is currently under definition. Data Consistency Within IEC 61131-5 data consistency is guaranteed. Nevertheless inconsistencies can occur when the application program is interrupted by a higher priority task, for instance an alarm function. If this function changes the data under communication, an inconsistent set can be created. In this case the user has to take measures to guarantee that the data areas used to send or receive the data values shall not be used during the time that the function blocks are busy. If one transfers larger sets of data at once with the function blocks BSEND / BRCV, one has to be aware of the effect on the reaction time of the system. One way is to divide the large set into smaller units, as part of the application program. For user, like application programmers, the combination of IEC 61131-3 and –5 is of course the most natural. Connections In IEC 61131-5, the communication itself is done via communication connection. These take care that Client and Server can find each other and understand each other, or change the role of client and server. The data are transmitted between instances of the IEC 61131-5 function block. The user does not have to worry about how: it is contained in the function blocks, and normally hidden. In the application program, the sending function block has a variable set of inputs with the data to be sent (SD_i). Via the communication system these data set is send to the corresponding receiving side, and made available to the other application program via the outputs (RD_i). Of course both data-types of SD-i and RD_i have to match. Please note that the implementation of flexible number of inputs and outputs at run time (expandable FBs) is very difficult, and will not be seen often in praxis – fixed length is preferred by the supplier. With this set, not only 1-to-1 connections, but also 1-to-n connections multi-cast) as well as 1-to-all connections (broadcast) can be supported (if the communication system can support it). With these last two, the Publisher-Subscriber model is supported, besides the standard Client-Server model. Connection can be made within a system, for instance between different CPU’s in one PLC, or between different tasks on a SoftPLC, or between different PLC applications. All communication service of IEC 61131-5 need connections. In most cases these are constructed and maintained in an implicit way, meaning that no coding in the application program has to be done for this. This is what is meant with the functionality lying above level 7, application layer, of the OSI/ISO stack. Figure 1: - Programmable Controller – Communication Model (subset) Figure 2: Programmable Controller hardware model IEC 61131-5 has defined an extensive set of status information on the hardware itself. This means that for the user this part is covered by the standard itself, and needs no additional coding. The hardware model (conform IEC 61131-1 and –2) identifies seven entities (units, modules or subsystems) per PLC. These entities which are can present status information are (see figure 2): No. Status presenting entities 1 PLC (as a whole) 2 I/O subsystem (includes I/O modules and other intelligent I/O devices) 3 Processing unit 4 Power supply subsystem 5 Memory subsystem 6 Communication subsystem 7 Implementer specific subsystems The status is intended to provide information about the controller including its hardware and firmware subsystems, not considering configuration information. It is not intended to provide information about the controlled process nor the PLC application program. The status data contains information concerning the state and the health of the PLC and its subsystems. There are two concepts used in this part of IEC 61131 related to status: health and state. The "health" of a PLC or its subsystems is specified by returning one and only one of the three possible values. The semantics associated with each value is specified below. They are, in order of decreasing health: GOOD - If TRUE, the PLC (or the specified subsystem) has not detected any problems which would prohibit it from performing the intended function; WARNING - If TRUE, the PLC (or the specified subsystem) has not detected any problems which would prohibit it from performing the intended function, but it has detected at least one problem which could place some limits on its abilities. The limit may be time, performance, etc; BAD - If TRUE, the PLC (or the specified subsystem) has detected at least one problem which could prohibit it from performing the intended function. Each of the status information can also have implementer specified attributes. For instance, for the I/O subsystems the following summary status information has been defined (Table 1). Similar sets have been defined for the PLC, the status of the processing units, power supply, memory, communication subsystem, and implementer specific subsystems. This covers all entities, and takes this part out of the hands of the users. Also, the representation of the status information is defined. No. Item Description 1 Health GOOD indicates that there have been no errors detected in this I/O subsystem 2 WARNING indicates that a minor fault has been detected in the I/O subsystem. An example of a minor fault is the occurrence of recoverable errors in the communication with a remote I/O station 3 BAD indicates that a major fault has been detected in the I/O subsystem. An example of a major fault is losing communication with a remote I/O station 4 No outputs disabled If TRUE, this attribute indicates that the PC can change the physical state of all outputs associated with the specified I/O subsystem as a result of application program execution or other means. If not TRUE, the physical state of some of the outputs is not affected (logical state may be affected). This is typically used in the testing and modifying of application programs in the PC 5 No inputs disabled If TRUE, this attribute indicates that the PC can access the physical state of all inputs associated with the specified I/O subsystem as a result of application program execution or other means. If not TRUE, the physical state some inputs cannot be accessed. This is typically used in the testing and modifying of application programs where the inputs can be simulated 6 I/O forced If TRUE, this attribute indicates that at least one I/O point associated with this subsystem has been forced. When an Input is forced, the application program will receive the value specified by the PADT instead of the actual value from the machine or process. When an output is forced, the machine or process will receive the value specified by the PADT instead of the value generated by execution of the application program Table 1: Status of the I/O Subsystem In addition, the functions which a PLC provides to a control system using the communication subsystem have been defined. This means a complete set for the communication function: device verification, data acquisition, control, synchronization between user applications, alarm reporting, connection management, program execution and I/O control, and application program transfer. This means that the features are defined, and the function blocks (except for the last two) are available. Programmable Controller Function Blocks If you have reached this point, you noticed that the IEC 61131-5 standard does not only cover some communication functions or function blocks. But of course, they are defined too. And they are well defined all function blocks include timing diagram, state diagram and the corresponding transitions. The following FBs are defined (Table 3): Application specific functions Name of communication function block or function Addressing of remote variables REMOTE_VAR (function) Device verification STATUS, USTATUS Polled data acquisition READ, Programmed data acquisition USEND, URCV, BSEND, BRCV Parametric control WRITE, Interlocked control SEND, RCV Programmed alarm report NOTIFY, ALARM Connection management CONNECT Table 3 - Overview of the communication function blocks Most of them are clear, but others need some additional information: Device verification: FBs STATUS and USTATUS A PC can request a remote communication partner to send back to it its status information using the STATUS function block. A PC can itself enable to receive status information of a remote communication partner using the USTATUS function block. Programmed data acquisition: FB USEND / URCV and BSEND / BRCV For the programmed data acquisition, there are two pairs of FBs defined. The difference between these pairs of function blocks lies in the way they operate. The FB pair USEND / URCV transmits a set of variables between a pair of instances of USEND/URCV or between one instance of USEND and many instances of URCV. In the application program, USEND has a variable set of inputs with the data to be sent (SD_i). Via the communication system these data set is send to the corresponding URCV, and made available to the other application program via the outputs (RD_i) of URCV. Of course both datatypes of SD-i and RD_i have to match. BSEND/BRCV are used for the transmission of a data buffer, with length as specified in the application program. The number of bytes to be transferred can dynamically be set via one input parameter. This makes this function block flexible in its usage. The communication system may use segmented transfer to transmit larger amounts of data. The user does not take care of that: segmentation is hidden inside the function block or the communication system. Of course the user has to take care of the data consistency, he shall not use the data buffers during the function blocks are busy. Parametric control: FB WRITE; Polled Data Acquisition: FB READ This combination to read and write data are used in 1-to-1 connections only. The application program requests if and when the data shall be read or written. Two kinds of variables in the PLC may be used with READ and WRITE: 1. Directly represented Variables with direct representation 2. Other variables which have Access paths (See IEC 61131‑3 for the definition of access paths) If the directly represented variables are accessible these variables shall use the direct representation as an identifier. The PLC which own the variables can interpret the identifier using an implementer defined algorithm. The PC system may restrict access to variables with direct representation. Interlocked control: FBs SEND and RCV The SEND instance requests the RCV instance to execute an application operation and to inform the SEND instance of the result of the operation. This has two aspects, the synchronization of the application program of the SEND and RCV instances and the exchange of information between them. This function can be used to have the effect of a remote procedure call from one application program to another. Programmed alarm report: FBs NOTIFY and ALARM A PC can be programmed using the ALARM function block to report an alarm message with an acknowledgement capability. Or, it can be programmed using the NOTIFY function block to report an alarm message without an acknowledgement capability. Connection management: CONNECT Connections are controlled explicitly by the application program using the CONNECT function block or are provided by the communication subsystem if and when needed. This communication function block allows to establish a connection between the calling communication partner and the remote communication partner. The remote communication partner is identified using its name. A communication channel to the remote communication partner is defined. The remote communication partner shall decide whether or not to establish the connection. Consistent semantic of the Function Blocks Now concerning the function blocks, first of all the semantics are defined, meaning that they all use a common semantics to their inputs and outputs as far as possible (see Table 2). Parameter name Data type of the parameter Interpretation EN_R BOOL Enabled to receive data REQ/RESP BOOL Perform function on raising edge ID COMM_CHANNEL Identification of the communication channel R_ID STRING Identification of the remote FB inside the channel SD_i ANY User data to send VAR_i STRING or data type of the output of the function REMOTE_VAR Identification of a variable of the remote communication partner DONE BOOL Requested function performed (good and valid) NDR BOOL New user data received (good and valid) ERROR BOOL New non-zero status received STATUS INT Last detected status (error or good) RD_i ANY Last received user data Table 2: Semantic of communication FB parameters Additional information to table 2: The ID input references the communication channel used by the instance of the communication function block, i.e. it determines the remote communication partner. The ID input is of COMM_CHANNEL type which shall be implementer defined. The R_ID input is used to identify the corresponding instance of the communication function block at the remote partner, if the PLC communication function is provided by a corresponding pair of function block instances. One instance of a communication function block shall use the same communication channel and communicate to the same corresponding remote function block instance throughout its whole lifetime. The variables to be read or written are identified using the VAR_i inputs of the READ and WRITE function blocks. The actual parameter is typically a string which contains the name of the remote variable. Additionally the VAR_i parameter may also have an implementer defined data type named VAR_ADDR. A function REMOTE_VAR is defined to generate the access information for nested variables. An example with timer in Function Block Diagram: The Future IEC 61131-5 combines communication over different networks with a common user interface. By hiding much of the complexity, it provides an easy to use and neutral interface. With currently many different communication solutions and systems, IEC 61131-5 can help to harmonize this wide variety at the software level. This brings the user many advantages, very much like IEC 61131-3 programming languages did and does. At the moment only a limited number of suppliers support this part of IEC 61131. Partly this is because the standard became available as an official standard only recently. Since IEC 61131-5 can cooperate with many different networks, implementations can be done in parallel, providing a standard communication to the user a across different networks. For instance, lying on top of TCP/IP based networks. The same is valid for OPC, OLE for Process Control. This uses ActiveX and DCOM objects and methods for reading and writing of process variables. At the next level, additional functions have to be defined. IEC 61131-5 certainly can help here to create efficient communications to the PLC world. The overall effect of IEC 61131-5 is still unclear. Although it provides a solid basis, the number of implementations has to increase dramatically. User demands certainly will play a role here. This article may push the use of IEC 61131-5. For user, like application programmers, the combination of IEC 61131-3 and –5 is of course the most natural. Further reading: PNO publication - PROFIBUS Communication and Proxy Function Blocks according to IEC 61131-3, check http://www.profibus.com/downloads.html

Introduction into IEC 61131- 4 User Guidelines

Scope

This Technical report (TR) IEC 61131-4 is to introduce the end-users of PLC to the IEC 61131 standard, and to assist the end-users in selection and specifying their equipment requirements according to the IEC61131standard.

This TR has as its main audience the PLC users. As depicted in Figure 1 the users consist of System integrators and End-users. The Vendor of PLC is required by the IEC 61131 standard to furnish appropriate product information to the user. The user needs to supply applications requirement and specifications to the vendor in order to receive suitable products and services from the vendor. The object of this TR then is to assist in this communication, especially from the end-user's perspective. Accordingly, this TR does not detail all the requirements of each and every part of IEC 61131 standard, such as conformance tests. The user should refer to the individual parts of the standard when needed.

The International Standard IEC61131 applies to programmable controllers (PLC) and their associated peripherals. PLCs and their associated peripherals are considered as components of a control system. Therefore, this standard does not deal with the automated system in which the programmable controller system is but one component. However, when applying this User guidelines an overall system architecture evaluation is recommended.

Since PLCs are component devices, overall automated system safety is beyond the scope of this standard.

Introduction into IEC 61131-3 Programming Languages

Scope

This Part specifies syntax and semantics of programming languages for programmable controllers as defined in Part 1 of this Standard.
The functions of program entry, testing, monitoring, operating system, etc., are specified in Part 1 of this Standard.

Overview and general requirements

This part of IEC 61131 specifies the syntax and semantics of a unified suite of programming languages for programmable controllers (PCs). These consist of two textual languages, IL (Instruction List) and ST (Structured Text), and two graphical languages, LD (Ladder Diagram) and FBD (Function Block Diagram). Sequential Function Chart (SFC) elements are defined for structuring the internal organization of programmable controller programs and function blocks. Also, configuration elements are defined which support the installation of programmable controller programs into programmable controller systems. In addition, features are defined which facilitate communication among programmable controllers and other components of automated systems. The programming language elements defined in this part may be used in an interactive programming environment. The specification of such environments is beyond the scope of this part; however, such an environment shall be capable of producing textual or graphic program documentation in the formats specified in this part. The material in this part is arranged in "bottom-up" fashion, that is, simpler language elements are presented first, in order to minimize forward references in the text. The remainder of this subclause provides an overview of the material presented in this part and incorporates some general requirements.


Figure 3 - Combination of programmable controller language elements LD - Ladder Diagram (4.2) FBD - Function Block Diagram (4.3) IL - Instruction List (3.2) ST - Structured Text (3.3) OTHERS - Other programming languages (1.4.3)

Introduction into IEC 61131-2 Equipment Requirements and Tests

Scope

1. This International Standard specifies requirements and related tests for programmable controllers (PLC) and their associated peripherals {e.g., programming and debugging tools (PADTs), human-machine interfaces (HMIs), etc.} which have as their intended use the control and command of machines and industrial processes.
   
2. PLCs and their associated peripherals are intended to be used in an industrial environment and may be provided as open or enclosed equipment. If a PLC or its associated peripherals are intended for use in other environments, then the specific requirements, standards and installation practices for those other environments must be additionally applied to the PLC and its associated peripherals.
   
3. This standard also applies to any products performing the function of PLCs and/or their associated peripherals.
4. Equipment covered in this standard is intended for use in overvoltage category II (IEC 60664-1) in low voltage installations, where the rated mains supply voltage does not exceed AC 1000Vr.m.s. (50/60 Hz), or DC 1500V. {If PLCs or their associated peripherals are applied in overvoltage category III installations, then additional analysis will be required to determine the suitability of the equipment for those applications.}
   
5. This standard does not deal with the functional safety or other aspects of the overall automated system. PLCs, their application program and their associated peripherals are considered as components of a control system.
   
6. Since PLCs are component devices, safety considerations for the overall automated system including installation and application are beyond the scope of this standard. However, PLC safety as related to electric shock and fire hazards, electrical interference immunity and error detecting of the PLC-system operation (such as the use of parity checking, self-testing diagnostics, etc.), are addressed. Refer to IEC 60364 or applicable national/local regulations for electrical installation and guidelines.
   

Object of the Standard

The purposes of this standard are:

• To establish the definitions and identify the principal characteristics relevant to the selection and application of PLCs and their associated
  peripherals;
• To specify the minimum requirements for functional, electrical, mechanical, environmental and construction characteristics, service conditions, safety, EMC, user programming and tests applicable to PLCs and the associated peripherals
  

Object of This Part

This part specifies:

1. service, storage and transportation requirements for PLCs and their associated peripherals;
2. functional requirements for PLCs and their associated;
3. EMC requirements for PLCs and their associated peripherals;
4. safety requirements for PLCs and their associated;
5. information that the manufacturer is required to supply;
6. test methods and procedures that are to be used for the verification of compliance of PLCs and their associated peripherals with the requirements.

The tests are type tests or production routine tests, and not tests related to the ways PLC systems are applied.

Introduction into IEC 61131-1 General Information

Scope

The International Standard IEC 61131 applies to programmable controllers (PLC) and their associated peripherals such as programming and debugging tools (PADTs), Human-machine interfaces (HMIs), etc. which have as their intended use the control and command of machines and industrial processes.

PLCs and their associated peripherals are intended to be used in an industrial environment and may be provided as open or enclosed equipment. If a PLC or its associated peripherals are intended for use in other environments, then the specific requirements, standards and installation practices for those other environments must be additionally applied to the PLC and its associated peripherals.

The functionality of a programmable controller can be performed as well on a specific hardware and software platform as on a general-purpose computer or a personal computer with industrial environment features. This standard applies to any products performing the function of PLCs and/or their associated peripherals. This standard does not deal with the functional safety or other aspects of the overall automated system. PLCs, their application program and their associated peripherals are considered as components of a control system.

Since PLCs are component devices, safety considerations for the overall automated system including installation and application are beyond the scope of this standard. However, PLC safety as related to electric shock and fire hazards, electrical interference immunity and error detecting of the PLC-system operation (such as the use of parity checking, self-testing diagnostics, etc.), are addressed. Refer to IEC 60364 or applicable national/local regulations for electrical installation and guidelines.

This part of IEC 61131 gives the definitions of terms used in this standard. It identifies the principal functional characteristics of programmable controller systems.

WHAT ARE THE DIFFERENCES BETWEEN ZELIO LOGIC AND TWIDO HARDWARE?

WHAT ARE THE DIFFERENCES BETWEEN

ZELIO LOGIC AND TWIDO HARDWARE?

Function Blocks for Motion Control Version 2.0 Released (Merge of Part 1 and 2)

Introduction

Part 1, the Basic document (version 1.0) was originally published in November 2001, a specification of an independent library of function blocks for motion control. It included motion functionality for single axes and multiple axes, several administrative tasks, as well as a state diagram. This specification provides the user a standard command set and structure independent of the underlying architecture. This structure can be used on many platforms and architectures. In this way one can decide which architecture will be used at a later stage of the development cycle. Advantages for the machine builder are, amongst others, lower costs for supporting the different platforms and the freedom to develop application software in a more independent way, without limiting the productivity of the machine. In addition to those benefits, system maintenance is easier and the education period is shorter. This is a major step forward, and is more and more accepted by both users as well as suppliers. With so many implementations, as well as the first applications, inconsistencies were found in the first specification, as well as additional features to be added. This resulted in an update of the basic document; version 1.1, which was released in April 2005 and implemented in over 30 products.
Part 2, Extensions is an addition to the basic document and should not be seen as a stand alone document. For example, part 2 adds information to the state diagram, but only the added transitions are shown in this document, containing additional function blocks. 
In 2007 we started a new phase in PLCopen Motion Control – the update of the basic specification, known as Part 1 – Basics, and Part 2 - Extensions. With multiple implementations and many applications running, more and more feedback came in at PLCopen for items to be clarified or changed, as well as additions. All these comments were merged in 2 new documents: a “Corrigendum” for the clarifications and changes, and an “Addendum” for the additions. (Note: these documents at the current stage are only open for PLCopen members). This resulted in the decision to merge Part 1 and Part 2 into one document in order to provide a better overview of these basics. This document is now released Version 2.0

Definition of the state machine

The following diagram normatively defines the behavior of the axis at a high level. This diagram is useful to build a more complicated profile or to treat exceptions within a program. (In real implementations there may be additional states at a lower level defined).
The axis is always in one of the defined state (see diagram). Any motion command is a transition that changes the state of the axis and, as a consequence, modifies the way the current motion is computed.

There are eight states defined as shown in the picture below:

  A normal procedure would start in Disabled. In this state the power can be switched on per axis (via the command Power, see above) which transfers the relevant axis to the state Standstill. From there one can access the Homing state (via the issue of the command Home per axis), which after normal completion returns to Stand Still. From here one can transfer an axis to either Discrete Motion or Continuous Motion. From these states a coupling to a master axis can be realized for instance via issuing MC_GearIn. The resulting state for the slave axis is then Synchronized Motion. Issuing a single axis move command will bring the axis back to either Discrete or Continuous Motion. Via the state Stopping one can return to StandStill. ErrorStop is a state the axis transfers to in case of an error. Via a (manual) Reset command one can return to StandStill, from which the machine can be moved to an operational state again. Please note that the States define the functionality of the Function Blocks.

Function Blocks Definitions

A. Axis Ref

The reference to an axis is done via the derived datatype AXIS_REF. This datatype is supplied by all manufacturers. It provides the interface towards the motor / drive itself. The technicalities of the real interface are hidden within the structure and function block itself. In this way, different architectures, from centralized to distributed and networked systems, looks the same to the user while giving access to all relevant parameters.

B. AxisRef as Var_In_Out

The Axis_Ref is used as Var_In_Out, represented as an input and an output connected by a horizontal line in a graphical representation of a Function Block. The variables used within Axis_Ref, acting both as input and output parameters, can be modified within the Function Block as well as receive values from external variables. However they are stored externally to the FB, making copying of the structure unnecessary.
As an example of how this could operate: imagine a Program containing several function blocks, all linked after each other (left-to-right) and all referring to the same axis via Axis_Ref. The first FB reads the latest values in Axes_Ref, and might update some of these values before it finishes its execution. Then the next FB is started and reads the updated values within Axes_Ref, so uses the latest values. And these values are internally coupled to the motor itself. Again, the control architecture can be quite different across systems.
One can use this reference to define one or more virtual axes, in that sense that it exists as a datastructure but is not coupled to a physical drive and/or motor.

The Function Blocks for single axis Motion Control

There are motion related and administrative function blocks defined in both part 1 and 2. The first movement function block is shown here in some more detail:

FB-Name	MC_MoveAbsolute
This function block commands a controlled motion at a specified absolute position.

Graphical representation:  

		MC_MoveAbsolute
AXIS_REF		Axis		Axis		AXIS_REF
BOOL		Execute		Done		BOOL
REAL		Position		Busy		BOOL
REAL		Velocity		Active		BOOL
REAL		Acceleration		CommandAborted		BOOL
REAL		Deceleration		Error		BOOL
REAL		Jerk		ErrorID		WORD
MC_Direction		Direction
MC_BufferMode		BufferMode

The other single axis Function Blocks as defined in part 1 and 2 are listed here below in short-form:

• MC_MoveRelative - moves the axis a specified distance relative to the actual position at the time of the execution. 
• MC_MoveAdditive - for a specified relative distance additional to the original commanded position in the discrete motion state. In the Continuous Motion the specified relative distance is added to the actual position at the time of the execution.
• MC_MoveSuperimposed - for a specified relative distance additional to an existing motion. The existing Motion is not interrupted, but is superimposed by the additional motion. 
• MC_MoveVelocity - for a never ending controlled motion at a specified velocity.
• MC_MoveContinuous - commands a controlled motion of a specified relative distance ending with the specified velocity.  
• MC_TorqueControl - continuously exerts a torque or force of the specified magnitude, approached using a defined ramp, and sets the InTorque output if the torque level is reached.
• MC_SetPosition - shifts the coordinate system of an axis by manipulating both the set-point position as well as the actual position of an axis with the same value without any movement caused.
• MC_SetOverride - sets the values of override for the whole axis and all functions that are working on that axis.  
• MC_TouchProbe - is used to record an axis position at a trigger event.
• MC_AbortTrigger - is used to abort function blocks which are connected to trigger events (e.g. MC_TouchProbe).
• MC_DigitalCamSwitch - provides the analogy to switches on a motor shaft: it commands a group of discrete output bits to switch in analogy to a set of mechanical cam controlled switches connected to an axis. Forward and backward movements are allowed.  
• MC_Home - commands the axis to perform the «search home» sequence. The details of this sequence are manufacturer dependent and can be set by axis’ parameters, as well as the function blocks as defined in Part 5 – Homing sequences.  
• MC_Stop - commands a controlled motion stop and transfers the axis to the state “Stopping”. It aborts any ongoing function block execution. With the Done output set, the state is transferred to the StandStill. While the axis is in state Stopping, no other FB can perform any motion on the same axis.  
• MC_Halt - commands a controlled motion stop. It aborts any ongoing function block execution. The axis is moved to the state “DiscreteMotion“, until the velocity is zero. With the Done output set, the state is transferred to StandStill.  
• MC_Power - switches the power stage on or off.
• MC_ReadStatus - returns in detail the status of the axis with respect to the motion currently in progress.  
• MC_ReadAxisError - Indicates errors not relating to the function blocks.
• MC_Reset -makes the transition from the state ErrorStop to StandStill by resetting all internal axis-related errors and clearing pending commands.
• MC_ReadParameter & MC_ReadBoolParameter - Returns the value of a vendor specific parameter.  
• MC_WriteParameter & MC_WriteBoolParameter - Modifies the value of a vendor specific parameter.
• MC_ReadActualPosition - returns the actual position.
• MC_ReadDigitalInput - provides the value of the digital input as referenced by INPUT_REF.  
• MC_ReadDigitalOutput - - provides the value of the digital output as referenced by OUTPUT_REF.  
• MC_WriteDigitalOutput - writes a value to the output referenced by the argument “Output”once.
• MC_ReadActualVelocity - returns the value of the actual velocity as long as enabled.
• MC_ReadActualTorque - returns the value of the actual torque as long as enabled.  
• MC_PositionProfile - commands a time-position locked motion profile.
• MC_VelocityProfile - commands a time-velocity locked motion profile.
• MC_AccelerationProfile - commands a time-acceleration locked motion profile.
   

Common set of multi-axes Function Blocks

For multi-axes, coordinated movements, a small set is defined. This set will be extended by additional application specific libraries. The current defined Function Blocks are:

• CamTableSelect - selects the CAM tables by setting the pointers to the relevant tables.
• CamIn - engages the CAM.
• CamOut - disengages the Slave from the Master axis immediately.
• GearIn - commands a ratio between the velocity of the slave and master axis.
• GearOut - disengages the Slave from the Master axis.
• MC_GearInPos - commands a gear ratio between the position of the slave and master axes from the synchronization point onwards.

A. Aborting, merging, and blending

Multiple function blocks have an input to set the different operating modes, combined with an output for signalling this. With this input, the FB can either work in a ‘Non-buffered mode’ (default behavior) or in a ‘Buffered mode’. The difference between those modes is when they should start their action:

• A command in a non-buffered mode acts immediately, even if this interrupts another motion
• A command in a buffered mode waits till the current FB is done (signaled via the corresponding output or via in-position, or in-velocity or similar outputs).

The following modes have been identified:

• Aborting - Default mode without buffering. The next FB aborts an ongoing motion and the command is affecting the axis immediately;
• Buffered - The next FB is affecting the axis as soon as the previous movement is ‘Done’. There is no blending;
• BlendingLow - The next FB is controlling the axis after the previous FB has finished (equal to buffered), but the axis may not stop between the movements. The velocity is blended with the lowest velocity of both commands (1 and 2) at the first end-position (1);
• BlendingPrevious - blending with the velocity of FB 1 at end-position of FB 1;
• BlendingNext - blending with velocity of FB 2 at end-position of FB1;
• BlendingHigh - blending with highest velocity of FB 1 and FB 2 at end-position of FB1.

An example

The following example is an example of a simple drilling unit:



We use Sequential Function Chart here to describe the different step for this drilling example.  
Step 1: Initialization, for instance at power up.
Step 2: Move forward to drilling position and start driller turning: in this way it will be fully operational         before the position is reached; then check if both actions are completed.
Step 3: Drill the hole.
Step 4: After Drilling the hole we have to wait for the step-chain sequence to finish dwelling the hole free of any stuff which might have stuck in the hole.
Step 5: Move driller back to starting position and shut the spindle off. Combining the finishing of moving backwards and stopping the spindle we signal the step-chain to start over.

Representation of the drilling example in SFC

The corresponding timing diagram for the movement is depending on the selected mode. For example:


Timing diagram for drilling - aborting mode  

Timing diagram for drilling - blending mode

IEC 1131 or 61131 : status of the Standard

What about this '6' in IEC 1131 ?

The International Electrotechnical Commission, IEC, is a world wide standardization body. Nearly all countries over the world have their own, national standardization bodies. In Germany for instance this is the Deutsche Elektrotechnischen Kommission, DKE. These commissions have agreed to accept the IEC approved and published standards. At local publication, often after translation, the standard was published under a local number. This local number often had no match to the number of the IEC published standard. For a standardization body this looked awkward. To harmonize this, they searched for a world wide numbering system that was available to use. This is where the famous '6' came in. And so IEC 61131-3 became IEC 61131-3, without any changes to the standard itself. Moreover, during the current transition phase, you have to order the IEC 6-1131 standard to get a publication that clearly has on its front cover 'IEC 61131-3'. As this might be confusing to non-insiders, we decided to wait for a new edition of the standard to migrate to the new number. In this way it is coupled to change.

A New Edition?

The international standard "IEC 61131-3" was released in 1993 and, since its adoption, has become widely accepted by the international user and vendor community. Today, it is, as such, the worldwide recognized standard for programming and configuring industrial control devices.

There are, however, several reasons why the standard must be revised: First of all, since 1993 a great deal of practical experience has been gained in which a number of inconsistencies and contradictions have been detected. In order to remedy this, many users of the standard proposed revisions and enhancements. These can be found in the Addendum and in the Corrigendum as belonging to the standard.

In addition, the demands on industrial control systems and their engineering environments have considerably changed over the years, where the most important item is the migration of large centralized control systems towards distributed systems.

This is the reason why IEC 1131 is now being revised in three stages, each summarized below:

1. "Corrigendum": correction of hard errors and non-compliances.
2. "Amendment": more consistent structuring of the standard accompanied by additional implementation of features required in everyday controls situations.
   
3. Harmonization between IEC 61131-3 and distributed systems standards like IEC 61499.

In the course of this, the major goal to maintain upward compatibility for all amendments. This means, a control program which complies with the previous standard is also expected to comply with the new standard without conflicts.

Current state

The new edition of the standard has been published as International Standard in 2003. This new version includes the "Corrigendum" and "Amendments".

The third proposed stage is in a much less mature development stage. This planned harmonization work can lead to a third edition of the standard.

To keep them alive, standards are always subject to change and undergo evolutionary changes in regard to technology advancements and market needs. On the other hand, the essentials of a standard must be established on a solid and long-lasting basis. For this reason, caution must always be applied to all exercised amendments: The investments of the industrial end users and hardware and software control vendors are always expected to be the primary concern. The approach described here represents an appropriate compromise to this concern.

Gray Backgrounds for DCS Operating Displays ?

 In a control room environment, operating displays serve an important role in supporting operator situation awareness and executing actions to prevent and respond to abnormal plant situations. Operator situation awareness involves orienting one’s self to several factors: 

• The presence and location of a disturbance;
• Comprehending the nature of the underlying plant conditions;
• Projecting the impact of the disturbance into the immediate future; and
• Analyzing all these to determine the appropriate course of action. 

The operator display design directly impacts the speed and accuracy of an operator performing these abnormal situation management activities.

The recent evolution of distributed control systems (DCS) to PC-based computer platforms has been accompanied by a significant change in capabilities to present data and information to operators. In particular, the ability to render those first-generation color schematic displays has evolved from the limited use of eight colors with full and half intensity to potentially millions of colors with the ability to manipulate combinations of saturation, hue, and intensity levels. 

The early DCS schematic displays were implemented with these limited color options on black background screens. Moreover, because of the limited colors available, the same color was often used to visually code different data types or status information. For example, the color red might be used to communicate a valve is closed, a pump is stopped, a process parameter is in alarm, and a process line is transferring oxygen.  

From pneumatic panels to CRTs

In parallel to the shift in DCS display technology, the use of black background on CRT screens created an unexpected impact on control room lighting. This unexpected result was in part due to the curvature of the CRT screen itself and in part the phenomena of creating a mirror out of the CRT glass with the extreme contrasts of light on each side of that glass. The result was excessive glare, and the response in almost all control rooms was a migration from bright, well-lit control rooms (with pneumatic control panels) to dark, dimly lit control rooms with multiple CRT based console workstations.

In the mid-90s, the Abnormal Situation Management (ASM) Consortium began studying factors that impacted the ability of operators to prevent and respond to abnormal situations in the plant. One of the conclusions at the time was that the present-day technology supports operators more effectively during steady-state operations than during upset operations. Operator schematic display design was one factor that was identified as needing improvement to support effective operator situation awareness and performance. Consequently, the ASM Consortium began researching human factors in operator display design to identify effective practices based on plant implementations as well as human factors research in academia and other industries. 

This research resulted in the ASM Guidelines publication of the Effective Operator Display Design, and one of the 16 guideline areas was on the effective use of color in operator displays. Within this guideline area there are eight guidelines on the use of color, one of which is the choice of color for display backgrounds. The color-specific ASM guidelines are intended to aid the display designer in selecting a color scheme that enhances the overall operator performance in the control room environment, not how to design an “attractive” display. The color scheme guidelines were created with the understanding that this work context places specific demands on the operator that are not present in contexts such as an office, public facility, or home. For example, operators must maintain continuous alertness over long shifts and monitor for infrequent events that may occur at unknown times. In this context, it is vital the display captures the operator’s attention—particularly when the vigilance performance decrement has been demonstrated across multiple industries for monotonous, low frequency events—when critical data is changing. 

Why gray?

Subsequently, the recommended design practice of using light gray backgrounds on DCS operating displays emerged as a result of several interacting design objectives. A few of these design objectives are:

• Directing the operator’s attention to the most critical information with the least possibility for confusion, slow response, or errors in detection or interpretation;
• Addressing concerns with respect to individuals who might have color vision deficiencies; and
• Reducing glare so ambient light levels are high enough to support both visual acuity for non-display tasks (e.g., reading paper copy) and also biological clock adjustments for the appropriate day or night shift.

To understand the factors that influence design decisions on use of color in operator displays, it is important to understand some basic principles of human sensation and perception. To enhance situation awareness, visual coding techniques are used to draw the operator’s attention to the most critical data and information through enhancing the salience of the associated display elements. An object is more salient than another object if it “stands out,” or grabs one’s attention. In terms of the display design then, this object appears to be in the foreground of the display relative to other objects. 

Manipulating visual attributes

The visual attributes that the designer can manipulate to create different degrees of salience include movement, form, and color. Luminance and color contrast depend on the brightness and color attributes to define the visual distinctiveness of a symbol or object from its immediate background. A minimum level of luminance contrast is necessary for legibility. Manipulating degrees of luminance contrast is effective for managing the viewer’s attention. The most safety-critical or urgent information should stand out the most in the display foreground whereas static and less important data, or information that provides context, such as vessels or display background, should blend more to the background. For operator situation awareness, it’s important to emphasize abnormal states, off-normal conditions, and dynamic data. When the designer is using color to manipulate salience, it is important that the color is used discriminately to code a specific meaning. If red means critical alarm state, then it should not also mean a pump is off (which might be its normal state). Nondiscriminate coding requires the viewer to use additional mental effort and time to exhaustively scan similar colored objects in an operating display and evaluate what the red means in each instantiation on display objects.

To maximize the ability to manipulate salience, the designer needs to consider how the background color supports both effective luminance and color contrast. From a luminance contrast perspective, the designer could choose a white, black, or gray background. A white or black background will provide maximum luminance contrast with dark or light text or objects. Research has shown that the ability to see detail (i.e., visual acuity) is better for dark text on white backgrounds. From a color contrast perspective, the use of a light grayscale background enables the use of a broader range of foreground color choices for manipulating salience than a light colored background such as tan, green, or blue, particularly when one considers the impact on individuals with color vision deficiencies. With a non-gray colored background, certain regions of the foreground color palette fall into the same color spectrum as the background color, reducing the color contrast for normal color-vision individuals and increasing the likelihood of confusion or mistakes for individuals with color vision deficiencies. 

 Why not white or black?

So why not use a white background display instead of gray? One reason is that the background display color in combination with the ambient light level of the control room can impact the probability of eye strain and fatigue as well as visual acuity. When someone is looking at a bright display in a dark room or a dark display in a bright room, the eyes have to make an adaption to the change in luminance as they move about the room and at the displays. With the successive viewing of light and dark sources over the period of a 12-hour shift, operators may experience eye strain and fatigue.

From the operators’ perspective, the background luminance of their displays will be the main determinant of their eye adaptation level. Hence, keeping the contrast between ambient lighting in the control room and background display luminance to a minimum can improve eye comfort. In addition, visual acuity has been demonstrated to be better when the surrounding or ambient luminance is equal to the display luminance. Hence, the recommendation of a light display background is coupled to the recommendation for high ambient lighting in the control room. 

A key consideration for deciding on ambient control room light levels is their impact on operator alertness. Low alertness levels are shown to reduce operator performance. Long work shifts (typically 12 hours) coupled with a rotating shift schedule presents significant challenges to operators in maintaining an effective alertness level due to the impact on their biological clock. Working in a dark control room exacerbates the challenge of maintaining alertness because it causes a physiological reaction that facilitates sleeping. Hence, bright, well-lit control rooms can improve operator alertness levels and subsequent performance.

In conclusion, the combination of design factors that impact operator situation awareness, alertness, eye strain, and fatigue led to the general recommendation to use a light-colored background on operating displays in a well-lit control room. Secondly, for a broader choice of colors that provide an effective contrast against the display background color, most operator display designers end up choosing gray as the background color as opposed to tan, green, or blue. In the end, the ASM Consortium recommends gray backgrounds due to the positive impact on operator performance rather than on operator preference for aesthetically pleasing colored displays. Moreover, the ASM Consortium does NOT recommend only using grayscale in display design but to use an effective color scheme to establish the relative importance of information and subsequently communicate distinctive meaning at a glance.  However, display designers must realize that color usage is only one of several considerations when designing an effective operator display. The ASM Consortium guidelines provide a comprehensive set of recommendations for ensuring the operator display maximizes human performance when dealing with abnormal situations.

Additional reading:

Bullemer, P.T., Reising, D.C., Burns, C., Hajdukiewicz, J., and Andrzejewski, J. (2008). Effective operator display design. ASM Consortium Guidelines Book. Minneapolis, MN: ASM Consortium.

Arend, L., Logan, A., and Havin, G. (2011). Using color in information displays graphics. NASA Ames Research Center, http://colorusage.arc.nasa.gov.

Panel on Impact of Video Viewing on Vision of Workers. (1983). Video Displays, Work, and Vision. Washington, DC: National Academic Press.

Bus terminals for use in extreme climates

The ET Bus Terminals from Beckhoff Automation extend the temperature range for selected standard Bus Terminals and Couplers, reportedly making them ideal for outdoor applications such as solar power plants.

Beckhoff Automation Extended Temperature (ET) Bus Terminals extends the operating temperature range for selected standard Bus Terminals and Couplers to between -4 and 140°F. The storage temperature range of the ET Bus Terminals is specified as -40 to 185°F. 

With the broadened operating temperature range for selected standard Bus Terminals and Couplers, the ET Terminals are ideal for "outdoor applications," according to Beckhoff Automation. Typical fields of use include alternative energy systems such as wind, solar or tidal power plants, which in many cases operate under extreme climatic conditions. 

The I/O terminals selected for the extended temperature range cover the most common areas of application and a wide range of signal types, according to Beckhoff Automation. The Beckhoff CX5000 series Embedded PCs with direct I/O connection and low-heat dissipation are designed for the extended temperature range. When paired with the new ET Bus Terminals, this represents a complete controller and I/O solution for extreme environments. 

Via Beckhoff’s K-bus technology, the new ET Bus Terminals are compatible with the entire Bus Terminal product range and can function with more than 15 fieldbus networks and protocols.