Intro4u2u

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):

 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:

a)         GOOD - If TRUE, the PLC (or the specified subsystem) has not detected any problems which would prohibit it from performing the intended function;

b)         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;

c)         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.

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):

       Table 3 - Overview of the communication function blocks