www bzfxw com BRITISH STANDARD BS EN 61131 5 2001 IEC 61131 5 2000 Programmable controllers — Part 5 Communications The European Standard EN 61131 5 2001 has the status of a British Standard ICS 17 20[.]
PC network communication model
A programmable controller provides specific application functions to the control system and can also request functions from other controllers, facilitating effective communication within the system.
IEC 61131 are based on a communication subsystem that can report communication errors to the signal processing function of the PC (see 5.2).
The diagram depicts a communication network featuring three devices that act as clients, requesting functions from PC 2 The two emphasized PCs are relevant to this section of IEC 61131.
Other-end system which talks to PC
From a communication perspective, both the 'supervisory controller' and the 'other-end system communicating with the PC' demonstrate identical behavior towards a PC communication server, as they both send requests to it.
A PC may use its client function to communicate with any device if it behaves like a PC.
PC functional model
A PC consists of several functions (see figure 3) For a PC within the scope of this part of
IEC 61131, at least one communication function is present.
The following diagram is taken from IEC 61131-1, figure 1 It is designed to illustrate some of the subsystems of a typical PC.
Communication functions Power supply function
MAN-MACHINE INTERFACE functions debugging, and testing functions Programming,
PROGRAM storage functions APPLICATION functions
INTERFACE functions to sensors and actuators
Figure 3 – Programmable controller functional model
The programming and debugging tool (PADT) is an essential function of the PC system, typically operating externally to the PC It interacts with the PC through its communications function, facilitating effective programming and debugging processes.
The Interface Function to Sensors and Actuators can have I/O which are local or remote to the
Main Processing Unit (see 5.3 for the hardware model) The Interface Function to Sensors and
Actuators possess two key attributes for each Application Program that outline the PC's role in monitoring and controlling the machine or process The input attribute can indicate that inputs supplied to the Application Program are derived from sensors or that these inputs are maintained in their current state.
The output attribute has the following states: ã the actuators are being controlled by the Application Program, ã the actuators are being held in the current state.
PC hardware model
The following figure shows the PC hardware model It shows the modules that make up a PC.
A PC subsystem consists of one or more modules The following figure corresponds to figure
B.1 of IEC 61131-1 and figure 1 of IEC 61131-2.
Memory(ies) and processing unit(s)
Figure 4 – Programmable controller hardware model
Software model
Figure 5 shows the PC software model defined in IEC 61131-3, figure 1 It illustrates the basic high-level language elements of the PC programming languages and their interrelationships.
The elements defined in IEC 61131-3 include programmed components such as programs and function blocks, along with configuration elements like configurations, resources, tasks, global variables, and access paths These components facilitate the installation of programmable controller programs within programmable controller systems.
A configuration, as defined in IEC 61131-1, represents the language element associated with a programmable controller system It encompasses one or more resources, which correspond to signal processing functions and interfaces for man-machine, sensors, and actuators Each resource can contain multiple programs that operate under the management of zero or more tasks, while a program may include various function blocks or other defined language elements.
Configurations and resources can be started and stopped via the "operator interface",
"programming, testing, and monitoring", or "operating system" functions defined in
IEC 61131-1 The mechanisms for the starting and stopping of configurations and resources via communication services are defined in this part of IEC 61131.
The "communication function" defined in IEC 61131-1 allows for the loading or deletion of programs, resources, global variables, access paths, and their associated privileges and configurations This process ensures that loading or deleting a configuration or resource is equivalent to handling all the elements it encompasses.
Access paths and their corresponding access privileges allow to access variables of a PC via
Execution control path Variable access paths
NOTE 1 This figure is illustrative only The graphical representation is not normative.
NOTE 2 In a configuration with a single resource, the resource need not be explicitly represented.
This clause outlines the status information of a PC and details the services it offers to the control system through the communication subsystem Additionally, it specifies how the PC application program can utilize the communication subsystem to engage with other devices.
PC subsystems and their status
PC summary status
The PC provides the following summary status information.
1 Health GOOD All subsystems in the PC indicate a GOOD health condition
2 WARNING At least one subsystem indicates a WARNING health condition and no sub- system indicates a BAD health condition
3 BAD At least one subsystem indicates a BAD health condition
4 Running If TRUE, this attribute indicates if at least one part of the user application has been loaded and is under control of the PC
The "Local Control" attribute, when set to TRUE, signifies that local override control is currently active This activation may restrict the ability to manage a PC and its subsystems remotely, often linked to the presence of a local key switch.
This attribute, when set to TRUE, allows the PC to alter the physical state of all outputs during application program execution or other processes Conversely, if it is not TRUE, some outputs may remain unaffected, although their logical state could still change This functionality is primarily utilized for testing and modifying application programs on the PC.
This attribute, when set to TRUE, allows the PC to access the physical state of all inputs during application program execution or other methods If it is not TRUE, access to the physical state of certain inputs is restricted This functionality is primarily utilized for testing and modifying application programs, enabling the simulation of inputs.
The "Forced If TRUE" attribute indicates that at least one I/O point linked to the PC has been forced When an input is forced, the application program receives a value specified by the PADT rather than the actual value from the machine or process Similarly, when an output is forced, the machine or process gets the value defined by the PADT instead of the value produced by the application program's execution Additionally, when a variable is forced, the application program utilizes the value specified by the PADT instead of the value generated during normal program execution.
If TRUE, this attribute indicates that the Processing Unit has at least one user application present
10 I/O subsystem If TRUE, this attribute indicates "WARNING" or "BAD" which is caused by an I/O subsystem
If TRUE, this attribute indicates "WARNING" or "BAD" which is caused by a processing unit subsystem
If TRUE, this attribute indicates "WARNING" or "BAD" which is caused by a power supply subsystem
If TRUE, this attribute indicates "WARNING" or "BAD" which is caused by a memory subsystem
14 Communication subsystem If TRUE, this attribute indicates "WARNING" or "BAD" which is caused by a communication subsystem
If TRUE, this attribute indicates "WARNING" or "BAD" which is caused by an implementer specified subsystem
I/O subsystem
The PC provides the following status information of its I/O subsystem.
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
The "No outputs disabled" attribute, when set to TRUE, allows the PC to alter the physical state of all outputs linked to the specified I/O subsystem during application program execution or other processes If it is not set to TRUE, some outputs may remain unaffected, although their logical state could still change This feature is commonly utilized for testing and modifying application programs on the PC.
This attribute, when set to TRUE, allows the PC to access the physical state of all inputs linked to the specified I/O subsystem during application program execution or other methods If it is not TRUE, access to the physical state of certain inputs is restricted This functionality is primarily utilized for testing and modifying application programs, enabling the simulation of inputs.
The "6 I/O forced" attribute, when set to TRUE, signifies that at least one I/O point linked to the subsystem has been forced In the case of a forced input, the application program will utilize the value defined by the PADT rather than the actual value from the machine or process Conversely, for a forced output, the machine or process will receive the value specified by the PADT instead of the value produced by the application program's execution.
NOTE The definition of "major fault" and "minor fault" shall be provided by the implementer.
Processing unit
The PC provides the following status information of its processing unit.
Table 4 – Status of processing unit
Health This attribute identifies the health of the processing unit The implementer shall specify the conditions when GOOD, WARNING or BAD are valid
4 Running If TRUE, this attribute indicates if at least one part of the user application has been loaded and is under control of the processing unit
The "Local Control" attribute, when set to TRUE, signifies that local override control is enabled This activation may restrict the network's ability to manage the processing unit, often associated with the use of a local key switch.
The "No outputs disabled" attribute, when set to TRUE, allows the processing unit to alter the physical state of all its outputs during application program execution or other methods If it is not TRUE, some outputs may remain unaffected, although their logical state could still change This feature is commonly utilized for testing and modifying application programs within the processing unit.
This attribute, when set to TRUE, allows the processing unit to access the physical state of all inputs available during application program execution Conversely, if it is not TRUE, access to the physical state of certain inputs is restricted This functionality is particularly useful for testing and modifying application programs, as it enables the simulation of inputs.
If TRUE, this attribute indicates that the Processing Unit has at least one User Application present
9 Forced If TRUE, this attribute indicates that at least one variable associated with this Processing
Unit has been forced When a variable is forced, the application program will use the value specified by the PADT instead of that generated by the normal program execution.
Power supply subsystem
The PC can provide status information about any of the power supply subsystems; see figure 6 for the assumed configuration of a PC power supply The requirements on power supplies of
PC systems and their behavior is described in IEC 61131-1 and IEC 61131-2.
Power supply power supply Redundant
Figure 6 – Programmable controller power supply
Table 5 – Status of power supply
1 Health GOOD indicates that there have been no problems detected in the power supply to prevent it from remaining operable for an indefinite time
2 WARNING indicates that a problem has been detected in the power supply which may cause to become inoperable in a limited time
3 BAD indicates that the power supply is not operable
4 In use If TRUE, this attribute indicates that the power supply subsystem is in use, i.e it supplies power to the PC
If TRUE, this attribute indicates that the mains are supplying power within the range specified for the power supply
6 Mains low If TRUE, this attribute indicates that the mains are not supplying power within the range specified for the power supply
If TRUE, this attribute indicates that the battery is supplying power within the range specified for the power supply
8 Battery low If TRUE, this attribute indicates that the battery is not able to supply power within the range specified for the power supply
If TRUE, this attribute indicates that a protection device within the power supply has removed a portion of the power to the PC
Memory subsystem
The PC provides the following status information of its memory subsystem.
1 Health GOOD No errors have been found in the memory associated with this subsystem
2 WARNING At least one correctable error has been detected and no uncorrectable errors have been detected
3 BAD At least one uncorrectable error has been detected
The "Protected" attribute, when set to TRUE, signifies that the memory within this subsystem is safeguarded against modifications This protection ensures that the application program stored in this memory cannot be altered.
1) This attribute models a logical state not physical characteristics of the subsystem If some portions of the memory are protected and some are not, these shall be reported as multiple subsystems.
Communication subsystem
The PC provides the following status information of its communication subsystem.
Table 7 – Status of communication subsystem
1 Health GOOD indicates that either no errors or an acceptable number of recoverable errors has occurred
2 WARNING indicates that more than an acceptable number of recoverable errors has occurred
3 BAD indicates that the communication subsystem is not able to communicate with all devices as intended
The "In use" attribute, when set to TRUE, signifies that the communication subsystem is actively functioning For instance, in an MMS communication interface, this indicates that at least one application association has been established If FALSE, the implementer must clarify the meaning of this attribute.
5 Local error If TRUE, this attribute indicates that there are some errors, internal to the communi- cation subsystem, that inhibit operation
6 Remote error If TRUE, this attribute indicates that there are some errors, at devices being communi- cated with, that inhibit operation
NOTE 1 The communication subsystem reporting its state may not be able to report its own bad state in the way defined in this clause But, within a PC system, several independent communication subsystems may operate, and all of them may provide status information.
NOTE 2 It is intended that the implementer specific information will provide additional information about each particular interface ISO network interfaces also provide additional information via network management functions.
Implementer specific subsystems
Other subsystems of a PC system shall be modelled as implementer specific subsystems.
Some examples of these subsystems are: a) PID controller; b) motion controller; c) other auxiliary processors.
Table 8 – Status of implementer specific subsystem
1 Health GOOD indicates that there have been no errors detected in this subsystem
2 WARNING indicates that a minor fault has been detected in this subsystem
3 BAD indicates that a major fault has been detected in this subsystem
NOTE The definition of "major fault" and "minor fault" shall be provided by the implementer.
Presentation of status information
The status information will be displayed through variables that have a specified access path in the configuration of the PC application, or it will be shown as a variable directly to a remote communication partner.
Table 9 – Presentation of status information
No Presentation of status information
1 PC summary status as variable with pre-defined access path P_PCSTATE
2 PC summary status as variable with direct representation %S
3 PC summary status and status of all subsystems as variable with pre-defined access path P_PCSTATUS
4 Status information of each subsystem as a set of variables with direct representation %SC
5 Type of each subsystem as a set of variables with direct representation %SU
6 Name of each subsystem as a set of variables with direct representation %SN
7 State of each subsystem as a set of variables with direct representation %SS
8 Implementer specific status of each subsystem as a set of variables with direct representation %SI
If the PC summary status shall be presented in a variable, it shall have the access path
The P_PCSTATE variable, defined in the configuration declaration, is of type WORD and holds the PC summary status, starting from item number 1 at the least significant bit and progressing upwards.
The PC summary status will be represented as a variable, denoted as %S, and will be of type WORD This representation will include the PC summary status starting from item number 1 at the least significant bit and moving upwards.
To present the complete status information as a variable, the access path P_PCSTATUS must be pre-defined in the configuration section, and this variable should be structured accordingly.
SUBSYSTEM : (SUMMARY, IO, PU, POWER, MEMORY, COMMUNICATION,
NAME : STRING[];
SPECIFIC : ARRAY[0 p_BIT] OF BOOL;
Figure 7 – Type description of status information
The first element of the array, designated as 0, will hold the summary status of the PC, while subsequent elements will represent the status of individual subsystems Each subsystem element will include the type of the PC or subsystem.
The website www.bzfxw.com will include the name of the PC or subsystem, with the implementer defining the maximum allowable length for name strings, referred to as Max_Name_Len Additionally, the STATE sub-element will provide state information for the PC or subsystem in the form of an array.
The implementer must define the number of elements in the array P_PCSTATUS, referred to as p_NOS, along with the supported subsystem types Additionally, the semantic meaning of the values in the STATE sub-element for the specific subsystem must be specified, along with the size of the SPECIFIC sub-element, denoted as p_BIT, and its corresponding semantic meaning.
The status of each subsystem is represented by a variable denoted as %SC, where ranges from 0, indicating the PC summary status, to the total number of subsystems p_NOS This variable shares the same internal representation as the corresponding structure type illustrated in the referenced figure.
Additionally there may be a set of variables with direct representation %SU, %SN,
The variables %SS and %SI represent the status of the PC summary and subsystems, where ranges from 0 to the total number of subsystems, p_NOS These variables maintain the same internal representation as the sub-elements of the specified structure type Specifically, %SU corresponds to one of these sub-elements.
SUBSYSTEM, %SN to the sub-element NAME, %SS to the sub-element STATE, and
%SI to the sub-element SPECIFIC.
Application specific functions
Device verification
This function enables other devices to assess whether the PC can fulfill its role within the automated system The PC can relay its own status and that of its subsystems, which encompasses health and state information Devices can either request this status from the PC or receive unsolicited status reports initiated by the PC through the communication interface For detailed definitions of health and state information, refer to section 6.1.
PC system and of its subsystems.
Data acquisition
Data in a PC is represented as variables sourced from various origins, each carrying distinct meanings Clients can access this data through several methods: (a) Polled access allows clients to read one or more variable values based on conditions they set, with the PC controlling which variables are network-accessible; (b) Programmed access involves the PC supplying data to the client according to conditions defined by the PC's application program; and (c) Configured access enables clients to set up the communications interface to initiate data transfers from the PC.
In a communication system, the types of variables visible to the PC include those with direct representation and others that utilize access paths, as defined in IEC 61131-3.
When directly accessible variables are available for communication, they should utilize direct representation as their identifiers The PC server, which owns these variables, can interpret these identifiers through a defined algorithm set by the implementer.
Directly represented variables can be utilized like standard variables in application programming Additionally, a symbolic name can be assigned to these variables using the AT construct during their declaration, as outlined in IEC 61131-3.
In a typical PC, there are thousands of variables that require direct representation, making it impractical to store the names and addresses of all these variables in an object dictionary.
The PC system may restrict access to variables with direct representation The conditions
(size, location, etc.) under which each data type supported by the PC can be uninterruptedly accessed shall be specified by the implementer.
1 Variables with direct representation are accessible
2 Access paths on configuration level
3 Access paths on program level
4 Means to restrict access to variables with direct representation
5 Conditions for uninterruptible access to variables
Control
A PC may support two methods of control: parametric and interlocked.
Parametric control involves directing a PC's operation by assigning values to its variables This operational change is influenced by the application program or other local mechanisms.
Access to variables is managed by the PC that contains them, allowing only those with the READ_WRITE qualifier in the access path declaration to be accessible over the network for parametric control.
Interlocked control involves the client requesting the server to perform an application operation and subsequently notifying the client of the outcome This service encompasses two key elements: the synchronization between the client and server, and the data exchange that occurs between them.
In interlocked control, data exchange takes place at synchronization points within the application program, enabling the functionality of a remote procedure call between different application programs This process is visually represented in the timeline depicted in figure 8.
Sends data Ready to receive data
Server Ready to receive data
Receives data Performs requested application Sends response data
Ready to receive data again Time
The PC utilizes interlocked control through the SEND (client) and RCV (server) function blocks, while other devices can replicate this functionality using alternative methods to access the PC's communication capabilities.
1 Variables with direct representation are accessible
2 Access paths on configuration level
3 Access paths on program level
4 Means to restrict access to variables with direct representation
5 Conditions for uninterruptible access to variables
Synchronization between user applications
User applications often require a synchronization service to manage the execution of tasks For instance, one application may need to initiate another only after completing a specific algorithm This synchronization is facilitated by the interlocked control mechanism.
Alarm reporting
The PC is capable of sending alarm notifications to a client when specific conditions are met, allowing the client to acknowledge these alarms Unlike standard data acquisition, the PC retains the status of an alarm until the client acknowledges it Additionally, the PC can generate a summary of any unacknowledged alarms upon the client's request.
3 Generate summary of unacknowledged alarms
Application program execution and I/O control
Execution of a PC Application Program is managed by the Application Program Execution function (see 5.2) PC Application Programs can be started and stopped PC Application
Programs can be started either from an initial state or from the state they were in at the time they were stopped.
The PC application program in a PC system consists of one configuration and zero, one or more resources (see IEC 61131-3) Configurations and resources may be started and stopped.
The resources are started and stopped when the configuration is started and stopped and they can be started or stopped independently of the configuration.
The Interface Function to Actuators in a running Application Program can utilize values provided by the program or maintain a predefined state This state is determined when the Application Program's state is modified.
The outputs can be configured to either implementer-defined states, maintain their current state, reset to zero, or adjust specific outputs to user-defined states (on or off), while leaving unspecified outputs in their last state, using a mechanism determined by the implementer, such as tables or PC procedures.
The Interface Function to Sensors in a running Application Program can either deliver real-time data from the sensors or utilize previously provided values The input state is determined when the state of the Application Program is modified.
Table 14 – Startable and stoppable units
No Startable and stoppable unit
The I/O (inputs and outputs) associated with a running resource shall either be controlled by the program or held in a known state, which is determined when the resource is started.
Resources can be initiated from either a cold restart using START, which begins from an initial state, or a warm restart using RESUME, which resumes from the last stopped state Additionally, the desired output state can be defined during the stopping process.
The state of the I/O can be set to the following values when a configuration or resource is started or stopped:
Value of I/O State Meaning Set by
Controlled actuators are managed by the application program or its specific segment that is initiated The interface function provides inputs to this application program segment from sensors and actuators.
Actuators remain in their current state when not controlled by the application program or its initiating segment Meanwhile, sensors provide data to the application program through the interface function connecting sensors and actuators.
Actuators remain in their current state as they are not controlled by the application program or the specific segment of the program that is being initiated or halted Similarly, sensors are not provided to the application program or the relevant section being activated, resulting in them also being held in their current state.
In the implementer state, actuators remain in a predetermined state set by the implementer, as they are not controlled by the application program, which is currently halted Consequently, the application program's inactivity leads to an unspecified state for the Sensor Interface.
Zero outputs Actuators are not being controlled by the application program or the part of the application program being stopped, they are held in the zero state.
The application program is not running, therefore the state of the Sensor Interface is not specified.
User -specified actuators remain in a user-defined state when the application program is halted or not controlling them As the application program is not operational, the state of the Sensor Interface remains unspecified.
NOTE The communication subsystem should not be depended upon as a replacement for hardwired emergency stop switches Normal safety practices should be followed.
Table 17 – Execution and I/O control features
1 Receive requests to start a startable and stoppable unit
2 Receive requests to stop a startable and stoppable unit
3 Receive requests to resume a startable and stoppable unit
Application program transfer
The application program transfer utilizes the storage functions of a PC to enable clients to upload or download the contents of programmable memory for archiving or verification This process allows for restoring the PC to a known state and ensures a safe environment before any modifications to the programmable memory Additionally, it facilitates a secure restart once the application program transfer is complete.
The program transfer is usually initiated by a non-PC device and encompasses several key services: uploading for archiving, uploading for verification, downloading to restore a previously known good system, and downloading an offline developed system.
The portions of the programmable memory which can be uploaded or downloaded are given in table 18.
NOTE A load unit contains the variable P_DDATE, their value is the date of the last modification of the load unit.
5 Access paths on configuration level
6 Access paths on program level
7 Load units contain the variable P_DDATE
The implementer shall specify if other language elements, for example, function types or function block types are loadable and the conditions and restrictions for downloading and uploading these.
IEC 61131 outlines the procedures for uploading and downloading data on an entire PC, a subsystem, or a specific portion of a subsystem Prior to initiating a download, the entire PC or the designated portion must be explicitly halted During the download process, the system being updated will be unavailable for any other operations until the download is fully completed.
The implementer shall specify what other clients can do with a PC when one client is downloading it.
Table 19 – Application program transfer features
1 Receive requests to download a loadable unit
2 Receive requests to upload a loadable unit
Connection management
Connection Management facilitates the installation, maintenance, and termination of communication links with remote partners Multiple requests to interact with a device can utilize the same connection However, not all communication subsystems necessitate connections, such as in point-to-point communication scenarios.
Connections are controlled explicitly by the application program using the CONNECT function block or are provided by the communication subsystem if and when needed.
3 Using one connection for multiple requests
Overview of the communication function blocks
Device verification
The STATUS and USTATUS function blocks enable the PC to gather status information from other devices, ensuring that it can assess whether these devices are capable of fulfilling their intended roles within the automated system.
Data acquisition
Data from various devices can be represented as variables, which may have diverse meanings and sources The PC can access this data through two primary methods using communication function blocks: polled and programmed In the polled method, the PC employs the READ function block to retrieve one or more variable values based on conditions set by the application program, with access potentially controlled by the source device Conversely, in the programmed method, data is sent to the PC at specific times or conditions determined by the other device, utilizing the URCV function block for data provision and the USEND function block for sending unsolicited data to other devices.
The conditions (size, location, etc.) under which each data type supported by the other device can be uninterruptedly accessed is determined by the other device.
Control
Two methods of control shall be supported by PCs: parametric and interlocked.
Parametric control involves directing the operation of a device by writing values to its internal variables A PC manages access to these variables and utilizes the WRITE function block to execute this action from the application program.
Interlocked control involves a client requesting a server to perform an application operation and subsequently notifying the client of the outcome In this process, the PC utilizes the SEND function block for the client role and the RCV function block for the server role.
Alarm reporting
The PC is capable of sending alarm notifications to a client when specific conditions are met, allowing the client to acknowledge these alarms The application program utilizes the ALARM and NOTIFY function blocks to create both acknowledged and unacknowledged alarms.
Connection management
The PC application program uses the CONNECT function block to manage connections.
Device verification
The numbers given in the above table shall be used to state compliance to these communication function blocks (CFB).
The STATUS and USTATUS function blocks enable the PC to gather status information from other devices, ensuring that it can assess whether these devices are capable of fulfilling their intended roles within the automated system.
Data from various devices can be represented as variables, which may have diverse meanings and sources The PC can access this data through two primary methods using communication function blocks: polled and programmed In the polled method, the PC employs the READ function block to retrieve one or more variable values based on conditions set by the application program, with access potentially controlled by the source device Conversely, in the programmed method, data is sent to the PC at specific times or conditions determined by the other device, utilizing the URCV function block for data provision and the USEND function block for sending unsolicited data to other devices.
The conditions (size, location, etc.) under which each data type supported by the other device can be uninterruptedly accessed is determined by the other device.
Two methods of control shall be supported by PCs: parametric and interlocked.
Parametric control involves directing the operation of a device by writing values to its internal variables A PC manages access to these variables and utilizes the WRITE function block to execute this action from its application program.
Interlocked control involves a client requesting a server to perform an application operation and subsequently notifying the client of the outcome In this process, the PC utilizes the SEND function block for the client role and the RCV function block for the server role.
The PC is capable of sending alarm notifications to a client when specific conditions are met, allowing the client to acknowledge these alarms The application program utilizes the ALARM and NOTIFY function blocks to create both acknowledged and unacknowledged alarms.
The PC application program uses the CONNECT function block to manage connections.
7.2 Semantic of communication FB parameters
Communication function blocks utilize a standardized semantic for their inputs and outputs The definitions of these inputs and outputs are outlined below Additionally, certain communication function blocks feature unique input or output parameters, which are detailed in their respective descriptions.
Table 22 – Semantic of communication FB parameters
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
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 ID input value in a communication function block instance is crucial for managing communication with a remote partner, as it holds or references essential information This information may vary based on the specific implementation and the communication subsystem utilized.
The R_ID input serves to identify the specific instance of the communication function block at the remote partner, particularly when the PC communication function is supported by a matching 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.
| REMOTE_VAR | SCOPES -| SCOPE | - VAR_ADDR STRING -| SC_ID |
FUNCTION REMOTE_VAR (* Generate remote variable address *) : VAR_ADDR; (* Data which may be used at *) (* VAR_i inputs of the READ and *) (* WRITE function blocks *)
VAR_INPUT SCOPE : INT; (* Scope of the variable *) SC_ID : STRING; (* Identifier of the name scope *) NAME : STRING; (* Name of the variable *)
NOTE The input SUB can be of type STRING, or ANY_INT.
SCOPE is an integer which identifies the name scopes of the programming languages of IEC 61131-3, the communication system, or the implementer supports as scope of a remote variable.
Table 23 – Values of the SCOPE parameter
Name scope of IEC 61131-3 Value
Reserved for name scopes specific to communication subsystems 10 99
When a variable's SCOPE necessitates an identifier, the SC_ID provides that identifier The NAME field specifies the name of the remote variable If the SUB variable is of string type, its value is treated as a sub-element name; if SUB is an ANY_INT, it is interpreted as an index An empty string for SUB indicates that the entire variable is being referenced.
The output data type of the function is defined by the implementer The function's result can be assigned to the VAR_i inputs of the READ and WRITE function blocks or stored in a variable of the same data type Additionally, the REMOTE_VAR function may be limited to generating valid values specifically for the VAR_i parameters of the READ and WRITE function blocks.
The communication subsystem may include additional functions tailored to specific addressing schemes, resulting in outputs of the VAR_ADDR type These functions are detailed in the mapping annexes of IEC 61131.
All parameters of communication function blocks are mandatory, with the exception of the extensible parameters SD_i, RD_i, and VAR_i, which depend on the function block type It is not necessary for SD_i or RD_i parameters to share the same data type when multiple SD_i parameters are utilized within a single function block instance or across different instances The implementer must define the number of supported SD_i, RD_i, and VAR_i parameters for each invocation of a communication function block.
Additionally, he shall describe if there are restrictions with the use of these parameters, for example data type or size of the actual parameters.
When a communication function block requires compatible data types, the compatibility check will always succeed if the same IEC 61131-3 data types are utilized on both the client and server PCs Furthermore, specific compatibility rules related to the communication subsystem may also be established.
The outputs begin at system zero, with NDR, DONE, and ERROR pulses remaining true until the next instance invocation Each communication function block follows a specific structure that is not depicted in the state diagrams of those blocks.
Communication function block described in the following sections
Figure 10 – Principle of status signalling
If a communication error of an instance of a communication function block is detected by the
PC system or by the algorithm of the communication function block, the ERROR and the
STATUS output of the function block instance are set The ERROR output remains true during the time between two invocations of this instance (see figure 11).
Communication function block: errors detected -| -| -| -| -
Figure 11 – Timing diagram of the ERROR and STATUS outputs
The NDR, DONE, ERROR, and STATUS outputs must be updated to new values synchronously with the instance invocations of the communication function blocks, regardless of any errors that may occur during the process.
The following values for the STATUS output of the various function blocks have been defined. Not all values are used by all function blocks.
Table 24 – Value and interpretation of the STATUS output
1 Error of lower layers, no communication possible
2 Other negative response from remote communication partner
3 R_ID does not exist in the communication channel
7 Remote communication partner in wrong state
8 Access denied to remote object
9 Receiver overrun (user data are new)
10 Access to local object rejected
11 Requested service exceeds local resources
–1 Instance of this function is busy and cannot provide additional services at this time
< –1 or > 20 Codes less than –1 or greater than 20 are to be specified by the implementer
Programmed data acquisition
USEND/URCV function blocks
The PC communication function programmed data acquisition uses the USEND and the URCV function blocks.
Corresponding instances of one USEND and one URCV function block provide one instance of the PC function programmed data acquisition.
The USEND instance transmits data to the URCV instance, which processes it using its application program Upon request, the USEND instance retrieves data from its SD_i inputs and sends it to the corresponding URCV instance, overwriting any previously received data The URCV instance then relays this data to the application program through its RD_i outputs whenever requested Additionally, the URCV instance notifies the application program of any newly received data, ensuring timely updates A data flow diagram is provided to illustrate this process.
USEND function block data flow
Figure 20 – Programmed data acquisition data flow
The SD_i and RD_i parameters are designed to be extensible, with a minimum requirement of having the SD_1 input at the FB USEND and the RD_1 output at the FB URCV It is essential that the number and data types of the SD_i inputs for the USEND instance align with the RD_i outputs of the corresponding URCV instance to ensure compatibility.
A USEND instance transmits data to a corresponding URCV instance when the ID parameter points to the same communication channel and the R_ID parameters are equal within that channel.
If a communication system offers channels for one-to-many or one-to-all connections, these function blocks can be utilized to program a data acquisition function that allows data to be collected from a single communication partner and distributed to multiple recipients.
If an error occurred, the ERROR output pulses one cycle to indicate an error and the STATUS output contains the error code.
| USEND | BOOL -> REQ DONE | - BOOL COMM_CHANNEL -| ID ERROR | - BOOL STRING -| R_ID STATUS | - INT ANY -| SD_1 |
FUNCTION_BLOCK USEND (* Programmed data acquisition *) VAR_INPUT (* requester *)
REQ : BOOL R_EDGE; (* Request to send *)
ID : COMM_CHANNEL;(* Communication channel *) R_ID : STRING; (* Remote function block *) SD_1 : ANY; (* User data to send *) : (* extensible and any type *) SD_n : ANY;
VAR_OUTPUT DONE : BOOL; (* Function performed *) ERROR : BOOL; (* New non-zero STATUS received *) STATUS: INT; (* Last detected status *)
| URCV | BOOL -| EN_R NDR | - BOOL COMM_CHANNEL -| ID ERROR | - BOOL STRING -| R_ID STATUS | - INT | RD_1 | - ANY | : | : | RD_n | - ANY + -+
FUNCTION_BLOCK URCV (* Programmed data acquisition *) VAR_INPUT (* receiver *)
EN_R : BOOL; (* Enable to receive data *)
ID : COMM_CHANNEL;(* Communication channel *) R_ID : STRING; (* Remote function block *) END_VAR
VAR_OUTPUT NDR : BOOL; (* New user data received *) ERROR : BOOL; (* New non-zero STATUS received *) STATUS: INT; (* Last detected status *)
VAR_IN_OUT RD_1 : ANY; (* Received user data *) : (* extensible and any type *) RD_n : ANY;
TIMING RELATIONSHIPS: t1 > t0 t2 = t0 + tAD + tX (Accept delay and transmit time) t3 = t2 + tNC (Time to next invocation)
Event identification begins with the request to send at USEND.REQ, followed by the requester resetting the USEND.REQ input The requester's USEND.SD inputs are then transmitted to the receiver's URCV.RD outputs, marking the completion of the transmission at time t2, when the receiver's URCV.RD contains the received send data Finally, the process concludes with the next invocation of this function block instance at time t3.
Figure 23 – Timing diagram of USEND and URCV function blocks
The state diagram shown in figure 24 describes the algorithm of the USEND function block.
Tables 31 and 32 describe the transitions of this state diagram and the actions to be performed within the states and the settings of the USEND function block outputs.
Figure 24 – State diagram of USEND function block Table 31 – Transitions of the USEND state diagram
2 At raising edge of REQ input
3 Communication system indicates "Sent to Remote
4 Communication system indicates "Cannot Send to
Remote Communication Partner" or other communication problems detected
5 After next invocation of this instance
Table 32 – Action table for USEND state diagram
State Actions DONE c ERROR c STATUS
TRYING Send data given at the SD_i inputs to remote communication partner
- indicates "unchanged" FB outputs. a INIT is the cold start state. b The error code is placed in the status output. c See figure 10.
The state diagram illustrated in Figure 25 outlines the algorithm for the URCV function block, while Tables 33 and 34 detail the transitions within this diagram, including the actions to be executed in each state and the configurations for the outputs of the URCV function block.
Figure 25 – State diagram of URCV function block
Table 33 – Transitions of URCV state diagrams
4 Data received from remote communication partner
6 Data types of SD_i of USEND and RD_i of URCV match
7 Data types of SD_i of USEND and RD_i of URCV do not match
8 After next invocation of this instance
Table 34 – Action table of URCV state diagram
State Actions NDR c ERROR c STATUS RD_1 RD n
INIT a Initialize outputs 0 0 0 System null
CHECKING Verify data type match - - - -
HAVE_DATA Deposit data 1 0 0, 9 New data
- indicates "unchanged" FB outputs. a INIT is the cold start state. b The error code is placed in the status output. c See figure 10.
BSEND / BRCV Function Blocks
Corresponding instances of one BSEND and one BRCV function block provide one instance of the PC function programmed data acquisition.
The BSEND instance transmits data to the BRCV instance for processing by its application program Upon request, the BSEND instance retrieves data from its SD_1 input and sends it to the appropriate BRCV instance, overwriting any previously received data.
The BRCV instance passes the received data to the application program via its RD_1 output.
This occurs when the application program requests its BSEND instance to send data The
BRCV instance passes newly received data when it has finished its previous request and gets new data It informs the application program when new data have arrived.
The SD_1 input of the BSEND instance and the RD_1 output of the BRCV instance shall both be of data type ANY and are interpreted as a sequence of bytes.
The representation of data in the controller varies based on implementation, and communication partners must reach an agreement on the interpretation of any data types other than byte arrays This requirement can limit the interoperability of programs utilizing these communication function blocks.
The BSEND instance transmits a number of bytes from the data provided at the SD_1 input, corresponding to the value specified at the LEN input If the LEN input is set to 0, the entire variable from the SD_1 input will be sent The RD_1 output is designed to store the transmitted data, while the LEN output of the BRCV instance reflects the count of bytes received in the RD_1 output An error will be indicated if any issues arise during this process.
– either the value at the LEN input of the BSEND instance is greater than the total length in bytes of the variable connected to the SD_1 input,
If the total length in bytes of the received data exceeds the total length in bytes of the variable linked to the RD_1 output of the BRCV instance, it indicates a discrepancy in data handling.
The data transfer phase of the BSEND instance initiates with a rising edge at the REQ input and concludes when either the DONE or ERROR output is set to 1 The DONE output will remain at 1 for one cycle after the entire block of data has been successfully transmitted During this phase, access to the variable containing the data to be sent may be restricted by the implementer Additionally, the RD_1 output of the BRCV instance is valid when the NDR output equals 1.
A BSEND instance transmits data to a corresponding BRCV instance when both the ID parameter references the same communication channel and the R_ID parameters are equal within that channel's scope.
Data transfer will be terminated upon detection of a rising edge at the R input of the BSEND instance When this cancellation occurs, the ERROR and STATUS outputs of the BRCV instance will be activated, particularly if the RD_1 and LEN outputs are undefined.
If an error occurred, the ERROR output pulses one cycle to indicate an error and the STATUS output contains the error code.
| BSEND | BOOL -> REQ DONE | - BOOL BOOL -> R ERROR | - BOOL COMM_CHANNEL -| ID STATUS | - INT STRING -| R_ID |
ANY_INT -| LEN | ANY -| SD_1 | + -+
FUNCTION_BLOCK BSEND (* Programmed data acquisition *) VAR_INPUT (* requester *)
REQ : BOOL R_EDGE; (* Request to send *)
ID : COMM_CHANNEL;(* Communication channel *) R_ID : STRING; (* Remote function block *) LEN : ANY_INT; (* Bytes to send *)
SD_1 : ANY; (* User data to send *) END_VAR
VAR_OUTPUT DONE : BOOL; (* Function performed *) ERROR : BOOL; (* New non-zero STATUS received *) STATUS: INT; (* Last detected status *)
| BRCV | BOOL -| EN_R NDR | - BOOL COMM_CHANNEL -| ID ERROR | - BOOL STRING -| R_ID STATUS | - INT | LEN | - ANY_INT | RD_1 | - ANY + -+
FUNCTION_BLOCK BRCV (* Programmed data acquisition *) VAR_INPUT (* receiver *)
EN_R : BOOL; (* Enable to receive data *)
ID : COMM_CHANNEL;(* Communication channel *) R_ID : STRING; (* Remote function block *) END_VAR
VAR_OUTPUT NDR : BOOL; (* New user data received *) ERROR : BOOL; (* New non-zero STATUS received *) STATUS: INT; (* Last detected status *)
LEN : ANY_INT; (* Count of received bytes *) END_VAR
VAR_IN_OUT RD_1 : ANY; (* Received user data *) END_VAR
In timing relationships, the sequence of events is defined as follows: \( t1 \) occurs after \( t0 \), while \( t2 \) is calculated as \( t0 + tAD + tX \), where \( tAD \) represents the accept delay and \( tX \) denotes the transmit time The confirmation transmit time is represented by \( t3 = t2 + tCF \), and the time to the next invocation is given by \( t4 = t3 + tNC1 \) and \( t5 = t2 + tNC2 \) For event identification, \( t0 \) marks the request to send at BSEND.REQ, followed by \( t1 \) when the requester resets the BSEND.REQ input The time interval from \( t0 \) to \( t2 \) indicates that the requester's BSEND.SD inputs are sent to the receiver's BRCV.RD outputs, with \( t2 \) signifying the completion of data transmission and the receiver's BRCV.RD containing the received data \( t3 \) represents the last confirmation received by the requester, while \( t4 \) and \( t5 \) indicate the next invocations of this function block instance.
Figure 28 – Timing diagram of BSEND and BRCV function blocks
The state diagram in Figure 29 illustrates the algorithm for the BSEND function block, while Tables 35 and 36 detail the transitions within this diagram, outlining the actions to be executed in each state and the configurations for the outputs of the BSEND function block.
Figure 29 – State diagram of BSEND function block Table 35 – Transitions of the BSEND state diagram
2 At raising edge of REQ input
3 Positive confirmation received and more data to send
4 Negative confirmation received or communication problems detected
5 At raising edge of R input
6 Positive confirmation received and no more data to send
8 After next invocation of this instance
Table 36 – Action table for BSEND state diagram
State Actions DONE c ERROR c STATUS
SEND_FIRST Send first block of data given at the
SD_1 input to remote communication partner, send a maximum of LEN bytes in total
SEND_NEXT Send next block of data given at the
SD_1 input to remote communication partner, send a maximum of LEN bytes in total
CANCEL Stop the data transfer - - -
- indicates "unchanged" FB outputs. a INIT is the cold start state. b The error code is placed in the status output. c See figure 10.
The state diagram in Figure 30 illustrates the algorithm for the BRCV function block, while Tables 37 and 38 detail the transitions within this diagram, outlining the actions to be executed in each state and the configurations for the outputs of the BRCV function block.
Table 37 – Transitions of BRCV state diagrams
4 Data received from remote communication partner
5 More data follows is true
6 More data follows is false
9 Indication received to cancel data transfer
10 After next invocation of this instance
Table 38 – Action table of BRCV state diagram
State Actions NDR c ERROR c STATUS RD_1, LEN
INIT a Initialize outputs 0 0 0 System null
RESP_NEG Send negative response
RECEIVING Verify data can be stored and store at the given index
RESP_MORE Send positive response - - - -
RESP_LAST Send positive response - - - -
HAVE_IT Deposit data 1 0 0 New data
The article discusses the cold start state indicated by "INIT" and highlights that error codes are included in the status output It references figure 10 for further clarification Additionally, it notes that new data can be placed in the RD_1 output if the STATUS output is set to –1.