The S7-1200 offers several types of communication between CPUs and programming devices, HMIs, and other CPUs.
PROFINET
PROFINET is used for exchanging data through the user program with other communications partners through Ethernet:
In the S7-1200, PROFINET supports 16 IO devices with a maximum of 256 submodules
S7 communication
User Datagram Protocol (UDP) protocol
ISO on TCP (RFC 1006)
Transport Control Protocol (TCP)
PROFINET IO controller
As an IO controller using PROFINET IO, the CPU communicates with up to 16 PN devices on the local PN network or through a PN/PN coupler (link). Refer to PROFIBUS and PROFINET International, PI for more information.
PROFIBUS
PROFIBUS is used for exchanging data through the user program with other communications partners through the PROFIBUS network:
In the S7-1200, PROFIBUS allows 3 independent PROFIBUS DP Masters, supporting 32 slaves per DP master, with a maximum of 512 modules per DP master.
With CM 1242-5, the CPU operates as a PROFIBUS DP slave.
With CM 1243-5, the CPU operates as a PROFIBUS DP master class1.
PROFIBUS DP Slaves, PROFIBUS DP Masters, and AS-i and PROFINET are separate communications networks that do not limit each other.
AS-i
The S7-1200 CM 1243-2 AS-i Master allows the attachment of an AS-i network to an S7-1200 CPU.
CPU-to-CPU S7 communication
You can create a communication connection to a partner station and use the GET and PUT instructions to communicate with S7 CPUs.
TeleService communication
In TeleService, an engineering station on which STEP 7 is installed communicates via the cellular network and the Internet with a SIMATIC S7-1200 station with a CP 1243-7 LTE. The connection runs via a telecontrol server that serves as an intermediary and is connected to the Internet.
IO‑Link
The S7‑1200 SM 1278 4xIO‑Link Master enables IO‑Link devices to connect to an S7-1200 CPU.
Network security
Avoiding security risks from physical network attacks
If an attacker can physically access your networks, the attacker can possibly read and write data.
For example, I/O exchange through PROFIBUS, PROFINET, AS-i, or other I/O bus, GET/PUT, T-Block, and communication modules (CMs) have no security features. You must protect these forms of communication by limiting physical access. If an attacker can physically access your networks using these forms of communication, the attacker can possibly read and write data.
If you fail to protect these forms of communication, death or severe personal injury can result.
For security information and recommendations, see the "Operational Guidelines" white paper on the Siemens Industrial Cybersecurity Web site.
S7‑1200 CPUs implement secure communication between PLCs and the TIA Portal, SIMATIC Automation Tool, and HMIs. This implementation uses the industry standard TLS 1.3 (Transport Layer Security) protocol. The S7‑1200 CPU has provided secure communication enhancements since V4.0. To maintain compatibility with older devices and clients, legacy communication still exists. You have the choice whether to use secure or legacy communication. Siemens strongly recommends secure communication for clients and devices that support it.
Advantages of secure communication
Use secure communication to achieve the following objectives:
Confidentiality: The data is secret and cannot by read by eavesdroppers.
Integrity: The message that reaches the recipient is the same message, unchanged, that the sender sent. The message has not been altered on the way.
End point authentication: The end point communication partner is exactly who it claims to be and the party who is to be reached. The identity of the partner is verified.
Today, networked industrial machinery and control systems with sensitive data are at high risk and consequently pose high security requirements for data exchange.
Protection through firewall, VPN connection, or a security module, was common in the past and remains common. In addition to physical security, however, using secure communications to transfer data to external communication partners in encrypted form is becoming necessary.
The CPU uses X.509 certificates to provide secure communication between the CPU and clients. Clients such as STEP 7 and the SIMATIC Automation Tool might require that you trust the certificate that is in the CPU. Be aware of the certificate you download to a CPU so that you can trust it when prompted.
Considerations when using secure communication
Be aware of the following concerns regarding secure communication:
Communication speeds can be slower with secure communication compared to legacy communication.
Secure PG/PC and HMI communication requires TIA Portal and V4.x S7-1200 CPUs.
The secure communication capabilities depend on several factors:
Actual firmware version of the physical CPU
Configured firmware version of the CPU in the STEP 7 project
The following table illustrates supported communication for a S7‑1200 CPU with V4.x firmware:
Device configuration of the CPU in the STEP 7 project | Client versions | |||
|---|---|---|---|---|
TIA Portal >= V17 / SIMATIC Automation Tool >= V4.0 SP3 | TIA Portal < V17 / SIMATIC Automation Tool < V4.0 SP3 | HMI >= V171 | HMI < V17 | |
Firmware version configured in the STEP 7 project: V4.x Configuration setting: "Only permit secure PG/PC and HMI communication" selected | Secure | No connection | Secure | No connection |
Firmware version configured in the STEP 7 project: V4.x Configuration setting: "Only permit secure PG/PC and HMI communication" deselected | Secure by default, legacy configurable | Legacy | Secure | Legacy |
Firmware version configured in the STEP 7 project: V4.x | Legacy | |||
No project | Secure or legacy | Legacy | Not applicable | |
1 Not applicable for HMIs with S7 communication
You must configure the firmware version of the CPU in the STEP 7 project to be V4.x to use TLS 1.3. The CPU uses TLS 1.2 if the configured firmware version in the project is prior to V4.5.
Configuring secure or legacy communication
You configure the security features of your CPU in the device configuration of the CPU in the TIA Portal under Protection & Security. The TIA Portal dialogs provide access to the TIA Portal Information System to guide you through the configuration process. To simplify configuration, TIA Portal and higher provides a Security Wizard to guide you through your security choices.
TIA Portal defaults to secure PG/PC and HMI communication; however, for commissioning reasons you can force the TIA Portal to use legacy PG/PC communications by selecting "Use only legacy PG/PC communication" from the Online menu.
Additional information
You can find additional details about the implementation of secure communication in the TIA Portal Information System. In particular, additional information about certificates is in the following TIA Portal Information System topics:
Confidentiality through encryption
Managing certificates with STEP 7
Examples for the management of certificates
Authenticity and integrity through signatures
This is an overview of the supported protocols and ports used for communication over PN/IE interfaces. The specified ports are the standard port numbers that the S7-1200 PLC uses. Many communication protocols and implementations enable you to use other port numbers. The following tables show different layers, protocols, and ports used in the S7-1200 PLC.
Port(s) | Direction | Protocol | Application | Description | Default setting/notes |
|---|---|---|---|---|---|
25 | Outbound | TCP | SMTP | SMTP is used for sending e-mails. | Default: Deactivated. Can be enabled via TMAIL_C instruction in the STEP 7 program. |
80 | Inbound | TCP | HTTP | HTTP is used for communication with the CPU-internal webserver. | Default: Deactivated. Can be enabled in the CPU properties. Requirement: Web server in the CPU properties is enabled. |
102 | Inbound/ Outbound | TCP | ISO-on-TCP | ISO-on-TCP (according to RFC 1006). The S7 protocol users ISO-on-TCP according to RFC 1006 for PG/HMI communication with TIA Portal. | Default: Activated. This function cannot be deactivated. |
123 | Outbound | UDP | NTP | NTP is used for synchronization of the CPU system time with the time of an NTP server. | Default: Deactivated. Can be enabled in the CPU properties. |
161 | Inbound | UDP | SNMP | SNMP is used for reading and setting network management data (SNMP managed Objects) by the SNMP Manager. | Default: Deactivated. Can be enabled via data record in the user program, CPU properties, and as write-protected in the CPU properties. |
443 | Inbound | TCP | HTTPS | HTTPS is used for secure communication with the CPU-internal web server over TLS. | Default: Deactivated. Can be enabled in the CPU properties. Requirement: Web server in the CPU properties is enabled. |
465, 587 | Outbound | TCP | SMTPS | SMTPS is used for sending e-mails over secure connections. | Default: Deactivated. Can be enabled via TMAIL_C instruction in the STEP 7 program. |
502 | Inbound/ Outbound | TCP | Modbus | Modbus/TCP is used by MB_CLIENT/MB_SERVER instructions in the user program. | Default: Deactivated. Can be activated via Modbus instructions in the STEP 7 program. |
4840 | Inbound | TCP | OPC UA | Communication standard ranging from the enterprise level to the field level. | Default: Deactivated. Server and client function can be enabled in the CPU properties. Client access can be configured in the STEP 7 program. |
6514, 514 | Outbound | TCP (6514) UDP (514) | Syslog Client | The Syslog client of the CPU is used for transferring syslog messages to a server. | Default: Deactivated. Can be enabled in the CPU properties. You can configure the forwarding of syslog messages to a syslog server in the CPU properties. The collection of system logging events within a CPU cannot be disabled. Port 6514 is the default value for Syslog servers in STEP 7. Port 514 is the standard port for UDP Syslog servers, but it is not the default value even if you select UDP in the STEP 7 project configuration. |
34964 | Inbound/ Outbound | UDP | PROFINET Context Manager | The PROFINET Context Manager provides an endpoint mapper in order to establish an application relation (PROFINET AR). | Default: Enabled (UDP port open). This function cannot be deactivated. |
Port Range | Direction | Protocol | Application | Description |
|---|---|---|---|---|
1-1999 | Varies | TCP/UDP | OUC | Port range can be used to limited extent, excluding already used ports. |
2000-5000 | Varies | TCP/UDP | OUC | Recommended port range for OUC |
5001-49151 | Varies | TCP/UDP | OUC | Port range can be used to limited extent, excluding already used ports. |
49152-65535 | Outbound | TCP/UDP | Varies | Dynamic port area used for active connection end point if the application does not determine the local port number. |
Protocol | Direction | Ethertype | Description |
|---|---|---|---|
PROFINET DCP | Inbound/Outbound | 0x8892 | DCP is used by PROFINET to discover PROFINET devices and provide basic settings. DCP uses the special multicast MAC addresses: 01-0E-CF-00-00-00 and 01-0E-CF-00-00-01. |
LLDP | Outbound | 0x88CC | LLDP is used by PROFINET to discover and manage neighbor relationships between PROFINET devices. LLDP uses the special multicast MAC address: 01-80-C2-00-00-0E. |
PROFINET IO | Inbound/Outbound | 0x8892 | The PROFINET IO frames are used to transmit IO data cyclically between PROFINET IO controller and IO devices via Ethernet. |
ICMP | Inbound | 0x0800 | Internet Control Message Protocol is used for diagnostic or control purposes. |
MRP | Inbound/Outbound | 0x88E3 | Media Redundancy Protocol enables control of redundant transmission paths in a ring topology. MRP uses the special multicast MAC addresses: 01:15:4E:00:00:01 and 01:15:4E:00:00:02 |
Overview of communication services
The CPU supports the following communication services:
Communication service | Functionality | Using PROFIBUS DP | Using Ethernet | |
|---|---|---|---|---|
CM 1243-5 DP master module | CM 1242-5 DP slave module | |||
PG communication | Commissioning, testing, diagnostics | Yes | No | Yes |
HMI communication | Operator control and monitoring | Yes | No | Yes |
S7 communication | Data exchange using configured connections | Yes | No | Yes |
Routing of PG functions | For example, testing and diagnostics beyond network boundaries | No | No | No |
PROFIBUS DP | Data exchange between master and slave | Yes | Yes | No |
PROFINET IO | Data exchange between I/O controllers and I/O devices | No | No | Yes |
Web server | Diagnostics | No | No | Yes |
SNMP 1 (Simple Network Management Protocol) | Standard protocol for network diagnostics and parameterization | No | No | Yes |
S7 routing | Using routing tables, communication partners can communicate with each device even though the devices are on different S7 subnets. | No | No | Yes |
Open communication over TCP/IP | Data exchange over Industrial Ethernet with TCP/IP protocol (with loadable FBs) | No | No | Yes |
Open communication over ISO on TCP | Data exchange over Industrial Ethernet with ISO on TCP protocol (with loadable FBs) | No | No | Yes |
Open communication over UDP | Data exchange over Industrial Ethernet with UDP protocol (with loadable FBs) | No | No | Yes |
OPC UA Server | Data exchange over Industrial Ethernet with OPC UA clients | No | No | Yes2 |
1 The CPU supports SNMP V1 without TRAPs.
2 OPC UA is only supported using the CPU's integrated Ethernet port.
Available connections
The CPU supports the following number of maximum simultaneous, asynchronous communication connections for PROFINET and PROFIBUS. The maximum number of connection resources allocated to each category are fixed; you cannot change these values. However, you can configure the "Free available connections" to increase the number of any category as required by your application.
Some connection types have a fixed number of reserved resources (sometimes called guaranteed). This means that the CPU is guaranteed to support up to the number of reserved resources for the connection type. For example, at least 12 HMI connections can be made to the CPU simultaneously. Additional connections beyond the number of reserved resources can be made for a connection type, but those connections resources must come from the "dynamic" resources pool.
The dynamic resources (sometimes called Free) are a collection of resources that can be used for any connection type. These resources are used by connections that do not have any reserved resources (such as OPC UA) or by connections that have used up all of their reserved resources.
S7-1200 CPUs have 34 dynamic resources.
The total number of S7-1200 communication connections does not increase when you add CM/CP modules.
OPC UA connections
OPC UA connections consume resources from the dynamic resources. Ensure that you have enough available connections for your application.
Based upon the allocated connection resources, the following number of connections per device are available:
Type | Reserved | Maximum1 |
|---|---|---|
Programming terminal (PG) communication | 4 | 4 |
Human Machine Interface (HMI) communication | 12 | 18 |
S7 communication | 8 | 14 |
Open User communication | 8 | 14 |
Web communication | 2 | 30 |
OPC UA Client/Server communication | 0 | 10 |
Other communication | 0 | - |
1 Since the dynamic connections are shared, it is not possible to max out all connections simultaneously.
For an example, the CPU has four available PG connection resources. Depending on the current PG functions in use, the PG might actually use one, two, three, or four of its available connection resources. You can always use one PG.
Another example is the number of HMIs, as shown in the figure below. HMIs have 12 available connection resources. Depending on what HMI type or model that you have and the HMI functions that you use, each HMI might actually use one, two, or three of its available connection resources. Given the number of available connection resources being used, it might be possible to use more than four HMIs at one time. However, you are always guaranteed at least four HMIs. An HMI can use its available connection resources (one each for a total of three) for the following functions:
Reading
Writing
Alarming plus diagnostics
This is only an example. The actual number of connections used can vary by HMI type and version.
Example | HMI 1 | HMI 2 | HMI 3 | HMI 4 | HMI 5 | Total connection resources available |
|---|---|---|---|---|---|---|
Connection resources used | 2 | 2 | 2 | 3 | 3 | 12 |
Web server connections: The CPU provides connections for multiple web browsers. The number of browsers that the CPU can simultaneously support depends upon how many connections a given web browser requests/utilizes and the number of dynamic connection resources available in the CPU.
The Open User Communications, S7 connection, HMI, programming device, OPC UA, and Web server communication connections may utilize multiple connection resources based upon the features currently being used.
Secure communication services require certificates with certain security parameters.
You can create or select these certificates from the following areas in the TIA Portal "General" tab of the CPU "Properties" window:
"Web server > Security": Use for the generation and assignment of Web server certificates, which can be either hardware generated or software downloaded.
"Protection & Security > Connection mechanisms": Use for the generation or assignment of PLC communication or Secure PG/PC and HMI communication certificates.
"Protection & Security > Certificate manager": Use for the generation or assignment of all types of certificates. The default setting for the creation of certificates is TLS certificates for Secure Open User Communication (Secure OUC).
"OPC UA > Server > Security": Use for the generation or assignment of OPC UA server certificates.
For more information on generating and assigning certificates, refer to the STEP 7 Information System.
Recommended certificate parameters for all security-enabled communication services:
Certificate Parameters | Communication services | ||||
|---|---|---|---|---|---|
Encryption method | Encryption parameter | ||||
EC | prime256v1 | Supported | Supported | Supported | Unsupported |
EC | secp384r1 | Supported | Supported | Supported | Unsupported |
RSA | 2048 | Supported | Supported | Supported | Supported |
You can use certificate parameter RSA 4096 with a significantly increased minimum scan cycle that allocates at least 60% of the scan cycle load to communication.
Although you can select unsupported certificate parameters from the "Certificate manager," only use the recommended certificate parameters listed in the table above.
Using an unlisted certificate parameter might cause communication problems or cause the communication service to be inoperable.
The CPU can communicate with the following devices:
Other CPUs
Programming devices
HMI devices
Non-Siemens devices using standard TCP communications protocols
Example connections are as follows:
Programming device connected to the CPU
HMI connected to the CPU
A CPU connected to another CPU
Ethernet switching
The CPU 1211C, 1212C, and 1214C have a single Ethernet port and do not include a integrated Ethernet Switch. A direct connection between a programming device or HMI and a CPU does not require an Ethernet switch. However, a network with more than two CPUs or HMI devices requires an Ethernet switch.
The CPU 1215C and the CPU 1217C have a built-in 2-port Ethernet switch. You can have a network with a CPU 1215C and two other S7-1200 CPUs.
① | CPU 1215C |
You can also use the rack-mounted CSM1277 4-port Ethernet switch for connecting multiple CPUs and HMI devices.
② | CSM1277 Ethernet switch |
Use the "Network view" of Device configuration to create the network connections between the devices in your project.
Select "Network view" to display the devices to be connected.
Select the "Connections" tab and choose your connection type from the dropdown menu.
Select the port on one device and drag the connection to the port on the second device.
Release the mouse button to create the network connection.
After creating the network connection, use the "Properties" tab of the inspector window to configure the parameters of the network.
A Local / Partner (remote) connection defines a logical assignment of two communication partners to establish communication services. A connection defines the following:
Communication partners involved (One active, one passive)
Type of connection (for example, a PLC, HMI, or device connection)
Connection path
Communication partners execute the instructions to set up and establish the communication connection. You use parameters to specify the active and passive communication end point partners. After the connection is set up and established, it is automatically maintained and monitored by the CPU.
If the connection is terminated (for example, due to a line break), the active partner attempts to re-establish the configured connection. You do not have to execute the communication instruction again.
Connection paths
After inserting a TSEND_C, TRCV_C or TCON instruction into the user program, the inspector window displays the properties of the connection whenever you have selected any part of the instruction. Specify the communication parameters in the "Configuration" tab of the "Properties" for the communication instruction.
TCP, ISO-on-TCP, and UDP | Connection properties |
|---|---|
For the TCP, ISO-on-TCP, and UDP Ethernet protocols, use the "Properties" of the instruction (TSEND_C, TRCV_C, or TCON) to configure the "Local/Partner" connections. The illustration shows the "Connection properties" of the "Configuration tab" for an ISO-on-TCP connection. |
When you configure the connection properties for one CPU, STEP 7 allows you either to select a specific connection DB in the partner CPU (if one exists), or to create the connection DB for the partner CPU. The partner CPU must already have been created for the project and cannot be an "unspecified" CPU.
You must still insert a TSEND_C, TRCV_C or TCON instruction into the user program of the partner CPU. When you insert the instruction, select the connection DB that was created by the configuration.
S7 communication (GET and PUT) | Connection properties |
|---|---|
For S7 communication, use the "Devices & networks" editor of the network to configure the Local/Partner connections. You can click the "Highlighted: Connection" button to access the "Properties". The "General" tab provides several properties:
| |
Refer to "Protocols" in the "PROFINET" section or to "Creating an S7 connection" in the "S7 communication" section for more information and a list of available communication instructions.
Parameter | Definition | |
|---|---|---|
Address | Assigned IP addresses | |
General | End point | Name assigned to the partner (receiving) CPU |
Interface | Name assigned to the interfaces | |
Subnet | Name assigned to the subnets | |
Interface type | S7 communication only: Type of interface | |
Connection type | Type of Ethernet protocol | |
Connection ID | ID number | |
Connection data | Local and Partner CPU data storage location | |
Establish active connection | Radio button to select Local or Partner CPU as the active connection | |
Address details | End point | S7 communication only: Name assigned to the partner (receiving) CPU |
Rack/slot | S7 communication only: Rack and slot location | |
Connection resource | S7 communication only: Component of the TSAP used when configuring an S7 connection with an S7-300 or S7-400 CPU | |
Port (decimal): | TCP and UPD: Partner CPU port in decimal format | |
TSAP 1 and Subnet ID: | ISO on TCP (RFC 1006) and S7 communication: Local and partner CPU TSAPs in ASCII and hexadecimal formats | |
1 When configuring a connection with an S7-1200 CPU for ISO-on-TCP, use only ASCII characters in the TSAP extension for the passive communication partners.
Transport Service Access Points (TSAPs)
Using TSAPs, ISO on TCP protocol and S7 communication allows multiple connections to a single IP address. TSAPs uniquely identify these communication end point connections to an IP address.
In the "Address Details" section of the Connection Parameters dialog, you define the TSAPs to be used. The TSAP of a connection in the CPU is entered in the "Local TSAP" field. The TSAP assigned for the connection in your partner CPU is entered under the "Partner TSAP" field.
Port Numbers
With TCP and UDP protocols, the connection parameter configuration of the Local (active) connection CPU must specify the remote IP address and port number of the Partner (passive) connection CPU.
In the "Address Details" section of the Connection Parameters dialog, you define the ports to be used. The port of a connection in the CPU is entered in the "Local Port" field. The port assigned for the connection in your partner CPU is entered under the "Partner Port" field.
If the network interface of your programming device connects to a local area network (LAN) with multiple subnets, both the programming device and the CPU must be on the same subnet. You assign the subnet as a combination of the IP address and subnet mask for the device. See your local network administrator for help.
The Network ID of a Class C IP address is the first three octets of the IP address. The network ID of 211.154.184.16, for example, is 211.154.184. This network ID uniquely identifies your IP network. The subnet mask normally has a value of 255.255.255.0. Because your computer is on a plant LAN, however, the subnet mask might have various values, for example, 255.255.254.0, to set up unique subnets. The subnet mask, when combined with the device IP address in a logical AND operation, defines the boundaries of an IP subnet.
You must assign unique IP addresses to all devices on your subnet.
Unauthorized access to a CPU
Users with CPU full access or full access (incl. fail-safe) privileges have privileges to read and write PLC variables. Regardless of the access level for the CPU, Web server or OPC UA users can have privileges to modify PLC data and execute functions. Unauthorized access to the CPU can disrupt process operation.
Siemens recommends that you observe the following security practices:
Enable Access control under "Protection & Security > Access control".
Do not enable the "Anonymous" user.
Use strong passwords, as defined in STEP 7.
Enable the setting "Only allow secure PG/PC and HMI communication" under "Protection & Security > Connection mechanisms".
Use a secure Virtual Private Network (VPN) to connect to the S7-1200 PLC from a location outside your protected network.
Enable access to the Web server only with the HTTPS protocol.
Perform error-checking and range-checking on your variables in your program logic because Web server or OPC UA users can change PLC variables to invalid values.
For the OPC UA server: In your STEP 7 Device configuration, navigate to "Properties > OPC UA > Server > Security" and deselect "No security" in "Security policies available on the server for the secure channel".
Disruption of process operations can result in death, severe personal injury, and/or property damage.
A secondary network adapter card is useful when you do not want your CPU on your company LAN. During initial testing or commissioning tests, this arrangement is particularly useful.
Assigning or checking the IP address of your programming device
To assign or check your programming device's IP address, follow these steps:
Open the Control Panel.
Navigate to the "Network and Sharing Center".
Click the network interface connected to your CPU.
Click "Properties" to open the properties dialog.
In the properties dialog, select the checkbox for "Internet Protocol Version 4 (TCP/IPv4)".
Click the "Properties" button.
Select "Obtain an IP address automatically" or to enter a static IP address select "Use the following IP address".
If you selected "Use the following IP address", set the IP address and subnet mask:
Set the IP address to use the same Network ID and same subnet as the CPU. For example, if the CPU IP address is 192.168.0.1, you could set the IP address to 192.168.0.200.
Select a subnet mask of 255.255.255.0.
Leave the default gateway blank.
Consult your network administrator to help you set up a network configuration to allow you to connect to the S7-1200 G2 CPU.
You can check the MAC and IP addresses of your network interface in STEP 7 with the following menu selections:
In the "Project tree", expand "Online access".
Right-click the required network interface and select "Properties".
In the dialog, expand "Configurations", and select "Industrial Ethernet".
The dialog displays the MAC and IP addresses of the network interface.
You can assign an IP address to a network device online. This is particularly useful in an initial device configuration.
1. In the "Project tree," verify that the CPU does not have a configured IP address. Expand "Online access" > <Adapter card for the network in which the device is located and double-click "Update accessible devices". If STEP 7 displays a MAC address instead of an IP address, then no IP address has been assigned. | ||
2. Under the required accessible device, double-click "Online & diagnostics". |  | |
3. In the "Online & diagnostics" dialog, select "Functions" > "Assign IP address". |  | |
4. In the "IP address" field, enter your new IP address, and click the "Assign IP address" button. | ||
5. In the "Project tree," verify that STEP 7 has assigned your new IP address to the CPU. Double-click "Update accessible devices" to display the IP address that you configured. |
Configuring the PROFINET interface
To configure parameters for the PROFINET interface, select the green PROFINET interface on the CPU. The "Properties" tab in the inspector window displays the PROFINET port.
Configuring the IP address
Ethernet (MAC) address: In a PROFINET network, each device is assigned a Media Access Control address (MAC address) by the manufacturer for identification. A MAC address consists of six groups of two hexadecimal digits, separated by hyphens (-) or colons (:), in transmission order, (for example, 01-23-45-67-89-AB or 01:23:45:67:89:AB).
IP address: Each device must also have an Internet Protocol (IP) address. This address allows the device to deliver data on a more complex, routed network.
Each IP address is divided into four 8-bit segments and is expressed in a dotted, decimal format (for example, 211.154.184.16). The first part of the IP address is used for the Network ID (What network are you on?), and the second part of the address is for the Host ID (unique for each device on the network). An IP address of 192.168.x.y is a standard designation recognized as part of a private network that is not routed on the Internet.
Subnet mask: A subnet is a logical grouping of connected network devices. Nodes on a subnet tend to be located in close physical proximity to each other on a Local Area Network (LAN). A mask (known as the subnet mask or network mask) defines the boundaries of an IP subnet.
A subnet mask of 255.255.255.0 is generally suitable for a small local network. This means that all IP addresses on this network should have the same first three octets, and the various devices on this network are identified by the last octet (8-bit field). An example of this is to assign a subnet mask of 255.255.255.0 and an IP addresses of 192.168.2.0 through 192.168.2.255 to the devices on a small local network.
The only connection between different subnets is via a router. If subnets are used, an IP router must be employed.
IP router: Routers are the link between LANs. Using a router, a computer in a LAN can send messages to any other networks, which might have other LANs behind them. If the destination of the data is not within the LAN, the router forwards the data to another network or group of networks where it can be delivered to its destination.
Routers rely on IP addresses to deliver and receive data packets.
IP addresses properties: In the Properties window, select the "Ethernet addresses" configuration entry. STEP 7 displays the Ethernet address configuration dialog, which associates the software project with the IP address of the CPU that will receive that project.
Parameter | Description | |
|---|---|---|
Subnet | Name of the Subnet to which the device is connected. Click the "Add new subnet" button to create a new subnet. "Not connected" is the default. Two connection types are possible:
| |
IP protocol | IP address | Assigned IP address for the CPU |
Subnet mask | Assigned subnet mask | |
Use IP router | Click the checkbox to indicate the use of an IP router | |
Router address | Assigned IP address for the router, if applicable | |
All IP addresses are configured when you download the project. If the CPU does not have a pre-configured IP address, you must associate the project with the MAC address of the target device. If your CPU is connected to a router on a network, you must also enter the IP address of the router.
The "IP address is set directly at the device" radio button allows you to change the IP address online or by using the "T_CONFIG" instruction after the program is downloaded.
Downloading a hardware configuration with "IP address is set directly at the device"
After downloading a hardware configuration with the "IP address is set directly at the device" option enabled, it is not possible to transition the CPU operating mode from RUN to STOP or from STOP to RUN until you set an IP address. User equipment continues to run under these conditions and can result in unexpected equipment and process operations.
Ensure that your CPU IP address(es) are set before using the CPU in an actual automation environment. This can be done by using your STEP 7 programming package, the SIMATIC Automation Tool, or an attached HMI device in conjunction with the T_CONFIG instruction.
Unexpected equipment and process operations can cause death, severe personal injury, or property damage if proper precautions are not taken.
Condition in which PROFINET network might stop
When changing the IP address of a CPU online or from the user program, it is possible to create a condition in which the PROFINET network might stop. If the IP address of a CPU is changed to an IP address outside the subnet, the PROFINET network will lose communication, and all data exchange will stop. User equipment might be configured to keep running under these conditions. Loss of PROFINET communication can result in unexpected machine or process operations.
If an IP address must be changed manually, ensure that the new IP address lies within the subnet.
Unexpected machine or process operations can cause death, severe personal injury, or property damage if proper precautions are not taken.
Configuring the PROFINET port
By default, the CPU configures port(s) of the PROFINET interface for autonegotiation. For autonegotiation to function properly, you must configure both stations to autonegotiate. If one station has a fixed configuration (for example, full-duplex at 100 Mbps) and the other station is set to autonegotiate, then autonegotiation fails, resulting in half-duplex operation.
To overcome this limitation of autonegotiation, the S7-1200 provides an option to disable autonegotiation. When you disable autonegotiation, the S7-1200 is automatically configured for full-duplex operation at 100 Mbps.
You can set the transmission rate and duplex to a fixed value for each port:
Select Advanced options and the port you need to configure. Then, select Port options.
In the Connection, Transmission rate / duplex field, select one of the following:
Automatic: The CPU and the peer device determine the port’s transmission rate and duplex by autonegotiation.
TP 100 Mbps full-duplex: If you disable autonegotiation, the port operates at 100 Mbps full-duplex. If you enable autonegotiation, the port can operate at 100 Mbps full-duplex or another transmission rate / duplex that is autonegotiated between the CPU and the peer device. This places a message in the diagnostics buffer if "Monitor" is selected (see below).
Monitor: When you select this check box, a message is placed in the diagnostics buffer if any of the following occur at the port:
A link cannot be established at the port
An established link fails
You select "TP 100 Mbps full-duplex" as the Transmission rate / duplex, and the CPU establishes a link using autonegotiation with the negotiated transmission rate not equal to 100 Mbps or the negotiated duplex equal to half-duplex.
Enable autonegotiation: Once you set the Transmission rate / duplex field to full-duplex at 100 Mbps, you can then disable autonegotiation. Deselect the "Enable autonegotiation" check box to disable autonegotiation.
If you disable autonegotiation, the CPU and the peer device do not negotiate the port’s transmission rate and duplex.
After completing the configuration, download the project to the CPU. All IP addresses are configured when you download the project.
Assigning an IP address to a device online
The S7-1200 CPU does not have a pre-configured IP address. You must manually assign an IP address for the CPU:
To assign an IP address to a device online, refer to "Device configuration: Assigning an IP address to a CPU online" for this step-by-step procedure.
To assign an IP address in your project, you must configure the IP address in the Device configuration, save the configuration, and download it to the PLC. Refer to "Device configuration: Configuring an IP address for a CPU in your project" for more information.
Using the "Extended download to device" dialog to test for connected network devices
The S7-1200 CPU "Download to device" function and its "Extended download to device" dialog can show all accessible network devices and whether or not unique IP addresses have been assigned to all devices. To display all accessible and available devices with their assigned MAC or IP addresses, check the "Show all accessible devices" checkbox.
If the required network device is not in this list, communications to that device have been interrupted for some reason. The device and network must be investigated for hardware and/or configuration errors.
In PROFINET networking, a Media Access Control address (MAC address) is an identifier assigned to the network interface by the manufacturer for identification. A MAC address usually encodes the manufacturer's registered identification number.
The standard (IEEE 802.3) format for printing MAC addresses in human-friendly form is six groups of two hexadecimal digits, separated by hyphens (-) or colons (:), in transmission order, (for example, 01-23-45-67-89-ab or 01:23:45:67:89:ab).
Each CPU is loaded at the factory with a permanent, unique MAC address. You cannot change the MAC address of a CPU.
The MAC address is printed on the front, lower-left corner of the CPU. Note that you have to lift the lower door to see the MAC address information.
① | MAC address |
Initially, the CPU has no IP address, only a factory-installed MAC address. PROFINET communications requires that all devices be assigned a unique IP address.
Use the CPU "Download to device" function and the "Extended download to device" dialog to show all accessible network devices and ensure that unique IP addresses have been assigned to all devices. This dialog displays all accessible and available devices with their assigned MAC or IP addresses. MAC addresses are all-important in identifying devices that are missing the required unique IP address. |
The Network Time Protocol (NTP) is widely used to synchronize the clocks of computer systems to Internet time servers. In NTP mode, the CPU sends time-of-day queries at regular intervals (in the client mode) to the NTP server in the subnet (LAN). Based on the replies from the server, the most reliable and most accurate time is calculated and the time of day on the station is synchronized.
Risk of network attacks through Network Time Protocol (NTP) synchronization
If an attacker can access your networks through Network Time Protocol (NTP) synchronization, the attacker can possibly disrupt control of your process by shifting the CPU system time.
The S7‑1200 CPU disables the NTP client feature by default. When you enable the NTP feature, then only the IP addresses that you configure can act as NTP servers. You must configure the NTP feature to allow CPU system time corrections from remote servers.
The S7‑1200 CPU supports "time of day" interrupts and clock instructions that depend upon accurate CPU system time. If you configure NTP and accept time synchronization from a server, you must ensure that the server is a trusted source. Failure to do so can cause a security breach that allows an unknown user to disrupt control of your process by shifting the CPU system time.
Disruptions to process control can possibly cause death, severe injury, or property damage.
For security information and recommendations, see the "Operational Guidelines" white paper on the Siemens Industrial Cybersecurity Web site.
The advantage of this mode is that it allows the time to be synchronized across subnets.
You configure the IP addresses of up to four NTP servers. The update interval defines the interval between the time queries (in seconds). The value of the interval ranges between 10 seconds and one day.
In NTP mode, the servers generally transfer UTC (Universal Time Coordinated), which corresponds to GMT (Greenwich Mean Time).
In the Properties window of the CPU's device configuration, select the "Time synchronization" configuration entry. STEP 7 displays the Time synchronization configuration dialog:
The CPU receives all the IP addresses when you download the project.
Parameter | Definition |
|---|---|
Enable time synchronization via NTP server | Select the checkbox to enable time synchronization via NTP server. |
Server 1 | Assigned IP Address for network time server 1 |
Server 2 | Assigned IP Address for network time server 2 |
Server 3 | Assigned IP Address for network time server 3 |
Server 4 | Assigned IP Address for network time server 4 |
Time synchronization update interval | Interval value (sec) |
CPU synchronizes the modules of the device. | Select the checkbox to synchronize the CP clock with the CPU clock. |
PROFINET IO can extend the start-up time for your system (configurable time-out). More devices and slow devices impact the amount of time it takes to switch to RUN.
You can have a maximum of 16 PROFINET IO devices on your PROFINET network.
Each station (or IO device) starts up independently on start-up, and this affects the overall CPU start-up time. If you set the configurable time-out too low, there may not be a sufficient overall CPU start-up time for all stations to complete start-up. If this situation occurs, false station errors will result.
The default configurable time-out is 60,000 ms (1 minute). You can configure this in CPU Properties > Startup > Configuration time.
PROFINET device naming and addressing in STEP 7
All PROFINET devices must have a Device Name and an IP Address. Use STEP 7 to define the Device Names and to configure the IP addresses. Device names are downloaded to the IO devices using PROFINET DCP (Discovery and Configuration Protocol).
PROFINET address assignment at system start-up
The controller broadcasts the names of the devices to the network, and the devices respond with their MAC addresses. The controller then assigns an IP address to the device using PROFINET DCP protocol:
If the MAC address has a configured IP address, then the station performs start-up.
If the MAC address does not have a configured IP address, STEP 7 assigns the address that is configured in the project, and the station then performs start-up.
If there is a problem with this process, a station error occurs and no start-up takes place. This situation causes the configurable time-out value to be exceeded.
The integrated PROFINET port of the CPU supports multiple communications standards over an Ethernet network:
Protocol | Usage examples | Entering data in the receive area | Communication instructions | Addressing type |
|---|---|---|---|---|
TCP | CPU-to-CPU communication Transport of frames | Ad hoc mode | Only TRCV_C and TRCV | Assigns port numbers to the Local (active) and Partner (passive) devices |
Data reception with specified length | TSEND_C, TRCV_C, TCON, TDISCON, TSEND, and TRCV | |||
ISO on TCP | CPU-to-CPU communication Message fragmentation and re-assembly | Ad hoc mode | Only TRCV_C and TRCV | Assigns TSAPs to the Local (active) and Partner (passive) devices |
Protocol-controlled | TSEND_C, TRCV_C, TCON, TDISCON, TSEND, and TRCV | |||
UDP | CPU-to-CPU communication User program communications | User Datagram Protocol | TUSEND and TURCV | Assigns port numbers to the Local (active) and Partner (passive) devices, but is not a dedicated connection |
S7 communication | CPU-to-CPU communication Read/write data from/to a CPU | Data transmission and reception with specified length | GET and PUT | Assigns TSAPs to the Local (active) and Partner (passive) devices |
PROFINET IO | CPU-to-PROFINET IO device communication | Data transmission and reception with specified length | Built-in | Built-in |
Transport Control Protocol (TCP) is a standard protocol described by RFC 793: Transmission Control Protocol. The primary purpose of TCP is to provide reliable connection service between pairs of processes. This protocol has the following features:
An efficient communications protocol since it is closely tied to the hardware
Suitable for medium-sized to large data amounts (up to 8192 bytes)
Provides considerably more facilities for applications, notably error recovery, flow control, and reliability
A connection-oriented protocol
Can be used very flexibly with third-party systems which exclusively support TCP
Routing-capable
Only static data lengths are applicable.
Messages are acknowledged.
Applications are addressed using port numbers.
Most of the user application protocols, such as TELNET and FTP, use TCP.
Programming effort is required for data management due to the SEND / RECEIVE programming interface.
International Standards Organization (ISO) on Transport Control Protocol (TCP) (RFC 1006) (ISO on TCP) is a mechanism that enables ISO applications to be ported to the TCP/IP network. This protocol has the following features:
An efficient communications protocol closely tied to the hardware
Suitable for medium-sized to large data amounts (up to 8192 bytes)
In contrast to TCP, the messages feature an end-of-data identification and are message-oriented.
Routing-capable; can be used in WAN
Dynamic data lengths are possible.
Programming effort is required for data management due to the SEND / RECEIVE programming interface.
Using Transport Service Access Points (TSAPs), TCP protocol allows multiple connections to a single IP address (up to 64K connections). With RFC 1006, TSAPs uniquely identify these communication end point connections to an IP address.
Typically, TCP and ISO-on-TCP receive data packets of a specified length, ranging from 1 to 8192 bytes. However, the TRCV_C and TRCV communication instructions also provide an "ad hoc" communications mode that can receive data packets of a variable length from 1 to 1460 bytes.
If you store the data in an "optimized" DB (symbolic only), you can receive data only in arrays of Byte, Char, USInt, and SInt data types.
To configure the TRCV_C or TRCV instruction for ad hoc mode, set the ADHOC instruction input parameter.
If you do not call the TRCV_C or TRCV instruction in ad hoc mode frequently, you could receive more than one packet in one call. For example: If you were to receive five 100-byte packets with one call, TCP would deliver these five packets as one 500-byte packet, while ISO-on-TCP would restructure the packets into five 100-byte packets.
The CPU supports the protocols listed in the table below. For each protocol, the CPU assigns the address parameters, the respective communications layer as well as the communications role, and the communications direction.
This information makes it possible to match the security measures for protection of the automation system to the used protocols. Only the Ethernet or PROFINET networks have security measures.
The table below shows the different layers and protocols that the CPU uses:
Protocol | Port number | (2) Link layer(4) Transport layer | Function | Description |
|---|---|---|---|---|
PROFINET protocols | ||||
DCP (Discovery and Configuration Protocol) | Not relevant | (2) Ethernet II and IEEE 802.1Q and Ethertype 0x8892 (PROFINET) | Accessible devices PROFINET Discovery and configuration | PROFINET uses DCP to discover devices and provide basic settings. DCP uses the special multicast MAC address: 01-0E-CF-xx-xx-xx where xx-xx-xx = Organizationally Unique Identifier |
LLDP (Link Layer Discovery Protocol) | Not relevant | (2) Ethernet II and IEEE 802.1Q and Ethertype 0x88CC (PROFINET) | PROFINET Link Layer Discovery protocol | PROFINET uses LLDP to discover and manage neighbor relationships between PROFINET devices. LLDP uses the special multicast MAC address: 01-80-C2-00-00-0E |
When you insert the TSEND_C, TRCV_C or TCON PROFINET instructions into your user program, STEP 7 creates an instance DB to configure the communications channel (or connection) between the devices. Use the "Properties" of the instruction to configure the parameters for the connection. Among the parameters is the connection ID for that connection.
The connection ID must be unique for the CPU. Each connection that you create must have a different DB and connection ID.
Both the local CPU and the partner CPU can use the same connection ID number for the same connection, but the connection ID numbers are not required to match. The connection ID number is relevant only for the PROFINET instructions within the user program of the individual CPU.
You can use any number for the connection ID of the CPU. However, configuring the connection IDs sequentially from "1" provides an easy method for tracking the number of connections in use for a specific CPU.
Each TSEND_C, TRCV_C or TCON instruction in your user program creates a new connection. It is important to use the correct connection ID for each connection.
The following example shows the communication between two CPUs that utilize two separate connections for sending and receiving the data.
The TSEND_C instruction in CPU_1 links to the TRCV_C in CPU_2 over the first connection ("connection ID 1" on both CPU_1 and CPU_2).
The TRCV_C instruction in CPU_1 links to the TSEND_C in CPU_2 over the second connection ("connection ID 2" on both CPU_1 and CPU_2).
① | TSEND_C on CPU_1 creates a connection and assigns a connection ID to that connection (connection ID 1 for CPU_1). | |
② | TRCV_C on CPU_2 creates the connection for CPU_2 and assigns the connection ID (connection ID 1 for CPU_2). | |
③ | TRCV_C on CPU_1 creates a second connection for CPU_1 and assigns a different connection ID for that connection (connection ID 2 for CPU_1). | |
④ | TSEND_C on CPU_2 creates a second connection and assigns a different connection ID for that connection (connection ID 2 for CPU_2). |
The following example shows the communication between two CPUs that utilize 1 connection for both sending and receiving the data.
Each CPU uses a TCON instruction to configure the connection between the two CPUs.
The TSEND instruction in CPU_1 links to the TRCV instruction in CPU_2 by using the connection ID ("connection ID 1") that was configured by the TCON instruction in CPU_1. The TRCV instruction in CPU_2 links to the TSEND instruction in CPU_1 by using the connection ID ("connection ID 1") that was configured by the TCON instruction in CPU_2.
The TSEND instruction in CPU_2 links to the TRCV instruction in CPU_1 by using the connection ID ("connection ID 1") that was configured by the TCON instruction in CPU_2. The TRCV instruction in CPU_1 links to the TSEND instruction in CPU_2 by using the connection ID ("connection ID 1") that was configured by the TCON instruction in CPU_1.
① | TCON on CPU_1 creates a connection and assigns a connection ID for that connection on CPU_1 (ID=1). | |
② | TCON on CPU_2 creates a connection and assigns a connection ID for that connection on CPU_2 (ID=1). | |
③ | TSEND and TRCV on CPU_1 use the connection ID created by the TCON on CPU_1 (ID=1). TSEND and TRCV on CPU_2 use the connection ID created by the TCON on CPU_2 (ID=1). |
As shown in the following example, you can also use individual TSEND and TRCV instruction to communication over a connection created by a TSEND_C or TRCV_C instruction. The TSEND and TRCV instructions do not themselves create a new connection, so you must use the DB and connection ID that was created by a TSEND_C, TRCV_C or TCON instruction.
① | TSEND_C on CPU_1 creates a connection and assigns a connection ID to that connection (ID=1). | |
② | TRCV_C on CPU_2 creates a connection and assigns the connection ID to that connection on CPU_2 (ID=1). | |
③ | TSEND and TRCV on CPU_1 use the connection ID created by the TSEND_C on CPU_1 (ID=1). TSEND and TRCV on CPU_2 use the connection ID created by the TRCV_C on CPU_2 (ID=1). |
The TSEND_C, TRCV_C and TCON instructions require connection-related parameters to connect to the partner device. The TCON_Param structure assigns these parameters for the TCP, ISO-on-TCP, and UDP protocols. Use the "Configuration" tab of the "Properties" of the instruction to specify these parameters. If the "Configuration" tab is not accessible, provide the TCON_Param structure in the instruction parameters.
Use the TCON_QDN and TCON_QDN_SEC structure to configure the communication connections for TCP and UDP via the fully qualified domain name. Use the TCON_QDN_SEC structure to configure the communication connections for TCP via the fully qualified domain name with secure communication.
TCON_Param
Byte | Parameter and data type | Description | |
|---|---|---|---|
0 to 1 | block_length | UInt | Length: 64 bytes (fixed) |
2 to 3 | id | CONN_OUC (Word) | Reference to this connection: Range of values: 1 (default) to 4095. Specify the value of this parameter for the TSEND_C, TRCV_C or TCON instruction under ID. |
4 | connection_type | USInt | Connection type:
|
5 | active_est | Bool | ID for the type of connection:
|
6 | local_device_id | USInt | ID for the local PROFINET or Industrial Ethernet interface: 1 (default) |
7 | local_tsap_id_len | USInt | Length of parameter local_tsap_id used, in bytes; possible values:
|
8 | rem_subnet_id_len | USInt | This parameter is not used. |
9 | rem_staddr_len | USInt | Length of address of partner end point, in bytes:
|
10 | rem_tsap_id_len | USInt | Length of parameter rem_tsap_id used, in bytes; possible values:
|
11 | next_staddr_len | USInt | This parameter is not used. |
12 to 27 | local_tsap_id | Array [1..16] of Byte | Local address component of connection:
Note: Make sure that every value of local_tsap_id is unique within the CPU. |
28 to 33 | rem_subnet_id | Array [1..6] of USInt | This parameter is not used. |
34 to 39 | rem_staddr | Array [1..6] of USInt | TCP and ISO-on-TCP only: IP address of the partner end point. (Not relevant for passive connections.) For example, IP address 192.168.002.003 is stored in the following elements of the array: rem_staddr[1] = 192 rem_staddr[2] = 168 rem_staddr[3] = 002 rem_staddr[4] = 003 rem_staddr[5-6]= irrelevant |
40 to 55 | rem_tsap_id | Array [1..16] of Byte | Partner address component of connection
|
56 to 61 | next_staddr | Array [1..6] of Byte | This parameter is not used. |
62 to 63 | spare | Word | Reserved: W#16#0000 |
TCON_IP_V4
Byte | Parameter and data type | Description | |
|---|---|---|---|
0 to 1 | InterfaceId | HW_ANY | HW-identifier of the IE-interface submodule |
2 to 3 | ID | CONN_OUC (Word) | Reference to this connection: Range of values: 1 (default) to 4095. Specify the value of this parameter for the TSEND_C, TRCV_C, or TCON instruction under ID. |
4 | ConnectionType | Byte | Connection type:
|
5 | ActiveEstablished | Bool | Active/passive connection establishment:
|
V4 IP address | |||
6 | ADDR[1] | Byte | Octet 1 |
7 | ADDR[1] | Byte | Octet 2 |
8 | ADDR[1] | Byte | Octet 3 |
9 | ADDR[1] | Byte | Octet 4 |
10 to 11 | RemotePort | UInt | Remote UDP/TCP port number |
12 to 13 | LocalPort | UInt | Local UDP/TCP port number |
TCON_IP_V4_SEC
Byte | Parameter and data type | Description | |
|---|---|---|---|
0 to 15 | ConnPara | TCON_IP_v4 | SDT for the connection parameters Information about the interface_id:
|
16 | ActivateSecure‐Conn | Bool | Activation of Secure Communication for this connection If this parameter has the value FALSE (default), the subsequent security parameters are irrelevant, meaning that the connection is non-secure. You can set up a non-secure TCP or UDP connection in this case. |
17 | TLSServerReq‐ClientCert | Bool | Only for the server side: Request for an X.509-V3 certificate from the TLS client. FALSE (default) |
18 to 19 | ExtTLSCapabilities | Word |
|
20 to 23 | TLSServerCertRef | UDInt |
|
24 to 27 | TLSClientCertRef | UDInt |
|
The CONNECT connection parameter of the instance DBs for the TCON, TSEND_C, and TRCV_C instructions contains a reference to the data block used.
You can make non-secure TCP or UDP connections over IPv4.
You can also use SDT TCON_IP_V4_SEC for a non-secure TCP or UDP connection over IPv4.
TCON_IP_RFC
Byte | Parameter and data type | Description | |
|---|---|---|---|
0 to 1 | InterfaceId | HW_ANY | HW-identifier of the IE-interface submodule |
2 to 3 | ID | CONN_OUC (Word) | Reference to this connection: Range of values: 1 (default) to 4095. Specify the value of this parameter for the TSEND_C, TRCV_C, or TCON instruction under ID. |
4 | ConnectionType | Byte | Connection type:
|
5 | ActiveEstablished | Bool | Active/passive connection establishment:
|
6 to 7 | Spare | Not used | |
V4 IP address | |||
8 | ADDR[1] | Byte | Octet 1 |
9 | ADDR[1] | Byte | Octet 2 |
10 | ADDR[1] | Byte | Octet 3 |
11 | ADDR[1] | Byte | Octet 4 |
Remote transport selector | |||
12 to 13 | TSelLength | UInt | Length of TSelector |
14 to 45 | TSel | array [1..32] of Byte | Character array for TSAP name |
Local transport selector | |||
46 to 47 | TSelLength | UInt | Length of TSelector |
48 to 79 | TSel | array [1..32] of Byte | Character array for TSAP name |
TCON_QDN
Byte | Parameter and data type | Description | |
|---|---|---|---|
0 to 1 | InterfaceId | HW_ANY | S7-1200-CPUs as of firmware V4.x:
|
2 to 3 | ID | CONN_O UC | Reference to this connection (value range: 1 to 4095). Specify the value of this parameter for the TCON instruction under ID. |
4 | ConnectionType | BYTE | Connection type:
|
5 | ActiveEstablished | BOOL | Identifier for the type of connection establishment:
|
6 to 261 | RemoteQDN | Array of STRING [1..254] | Fully qualified domain name of the partner end point, which must finish with "." Please note that in a SIMATIC network, the name including the concluding dot must not exceed 254 characters. |
262 to 263 | RemotePort | UINT | Port address of the remote connection partner |
264 to 265 | LocalPort | UINT | Port address of the local connection partner |
TCON_QDN_SEC
Byte | Parameter and data type | Description | |
|---|---|---|---|
0 to 271 | ConnPara | TCON_QDN | Connection parameter |
272 | ActivateSecureConn | BOOL | Activation of secure communication for this connection. If this parameter has the value FALSE, the subsequent security parameters are irrelevant. You can set up a non-secure TCP or UDP connection in this case. |
273 | TLSServerReqClientCert | BOOL | Only for the server side: Request for an X.509-V3 certificate from the TLS client |
274 to 275 | ExtTLSCapabilities | WORD |
|
276 to 279 | TLSServerCertRef | UDINT |
|
280 to 283 | TLSClientCertRef | UDINT |
|
TLS is Transport Layer Security in the application layer of data communications. TLS increases security and privacy in communication between the S7‑1200 CPU and other devices. The TLS version depends on the S7‑1200 CPU firmware version and the version of the CPU in the Device Configuration of your STEP 7 project.
To find the CPU version in your STEP 7 project, follow these steps:
Click the CPU in the Device configuration.
View the General section of the Properties tab in the Inspector window.
Note the Firmware version in the Catalog information section.
To use the highest version of TLS, configure the CPU version in STEP 7 to be the actual firmware version of your CPU. The open user communication partner can then use the highest supported TLS version for maximum security.
TLS version support based on CPU and STEP 7 project firmware version
Firmware version configured in the STEP 7 project | Supported TLS version |
|---|---|
V4.5 - V4.7 | TLS 1.2, TLS 1.3 |
V4.3 - V4.4 | TLS 1.2 |
To use DNS, you must have at least one DNS server in your network, and you must configure at least one DNS server for the S7-1200 CPU.
You configure a DNS server using the following steps:
From the Device view for your S7-1200 CPU, navigate to "Properties > General".
Click on "DNS configuration" to display the configuration page.
In the Server list table, the first row under the DNS server addresses, click on "<Add new>" and enter the IP address of your DNS server.
In the TIA Portal, you can select the following Open User Communications connections (as shown below) for drawing to or from the S7-1200 or S7-1500 CPUs.
Iso-on-TCP connection
TCP connection
UDP connection
When you draw a line between devices, a connection is configured to compile and download to the device. This connection configuration allows the S7-1200 firmware to establish a connection with the partner when the CPU goes to RUN. There is no need to run a TCON instruction with a configured connection. Also, there is no need for a T_DISCON instruction for a configured connection.
To draw a line for these connections, both network interfaces for the CPU (or CP) should be on the same subnet. The TIA portal does not limit you from drawing a connection to devices on different networks. However, the TIA Portal will generate an error when compiling or downloading to the device.
You can now draw an OUC connection between the S7-1200 or S7-1500 CPUs, download the configuration, and automatically establish the connection between the CPUs (if the connection was physically possible).
Configuration options for configured OUC connections
You configure the following properties of the connection as shown below:
Connection ID
Name of the Connection
Which partner is the Active establishment
Port details in the property menu of the Network view by selecting a connection end
When you draw an OUC connection in the TIA Portal, a "Local ID" and "Partner ID" is assigned in the valid range for an OUC connection ID. You can change the value assigned in the connections table or in the Local ID. The value entered in each ID must be within the range defined by the TBlock instructions (See TSEND).
Assigned range for the connection ID
The assigned range for the connection ID is in the same range as allocated for an S7 connection. If an S7 Connection ID is supplied to a TSEND, it would result in an error from the instruction. The error will be 16#80A1 as there will be no OUC connection established.
In the "Special connection properties" menu, the "active connection establishment" field defines the device which sends connection messages out upon downloading of the configuration to the CPUs. If the "active connection establishment" checkbox is not checked, the downloaded device waits for connection messages from its partner. TIA portal automatically updates the partner when the "Active connection establishment" checkbox is clicked. Only one side of the connection can be set as active.
UDP connections
For UDP connections, the "active connection establishment" is not present.
The "address details" property menu shows configuration of the addresses that will be used for the communication of the connection for TCP and Iso-on-TCP types. When using TUSEND and TURCV on a UDP connection, the address for communication is overridden by a parameter on the instructions. Additionally, for Iso-on-TCP connection types, the TSAPs can be modified in the "address details" property menu as shown in the 2nd screen below.
Operation of existing TBlock instructions with configured connections
Once a connection is established, a configured connection operates in the same manner as a programmed connection. Other OUC instructions operate in the same manner as if operated on a programmed connection. Below is a description for OUC instructions and they operate with configured connections.
OUC instruction | Description with configured connection |
|---|---|
Must have a TCON_configured SDT passed to the Connect parameter. If a configured connection is used, then the ID field of the TCON_Configured should be set to the Configured Connection ID and the Connection Type field should be set to 254. When using a configured connection, the connection mechanism in the instruction should be skipped as the connection is already established. | |
Must have a TCON_Configured SDT passed to the Connect parameter. If a configured connection is used, then the ID field of the TCON_Configured should be set to the Configured Connection ID and the Connection Type field should be set to 254. When using a configured connection, the connection mechanism in the instruction should be skipped as the connection is already established. | |
Does not work with a configured connection | |
Gives an error (0x8085) if the Connection ID for a configured connection is provided because the connection is already open | |
Gives an error (0x80A3) | |
Gives an error (0x8085) TCONSettings cannot use configured connections. The TCONSettings write function returns an error. The TCONSettings read operation returns FALSE for the graceful shutdown option. | |
Operates the same | |
Operates the same | |
Operates the same | |
Operates the same | |
Operates the same. A disconnect occurs on the connection and a reconnect occurs. The SendBytes and Received bytes will be reset to 0. | |
Operates the same. The "Kind" field of the TDIAG_Status variant should indicate a configured connection. | |
Operates the same. (Not directly OUC protocol communication related.) | |
Must have a TCON_Configured SDT passed to the Connect parameter. If a configured connection is used, then the ID field of the TCON_Configured should be set to the Configured Connection ID and the Connection Type field should be set to 254. When using a configured connection, the connection mechanism in the instruction should be skipped as the connection is already established. | |
Must have a TCON_Configured SDT passed to the Connect parameter. If a configured connection is used, then the ID field of the TCON_Configured should be set to the Configured Connection ID and the Connection Type field should be set to 254. When using a configured connection, the connection mechanism in the instruction should be skipped as the connection is already established. |
The S7-1200 supports two sets of TSEND_C and TRCV_C instructions:
TSEND_C and TRCV_C instructions: These TSEND_C and TRCV_C instructions provide all of the functionality of the legacy instructions, plus the ability to use connection parameters with structures according to TCON_IP_V4, TCON_IP_V4_SEC, TCON_IP_RFC, TCON_QDN, and TCON_QDN_SEC.
Legacy TSEND_C and TRCV_C instructions: These TSEND_C and TRCV_C instructions existed prior to version V4.1 of the S7-1200 and only work with connection parameters with structures according to TCON_Param.
STEP 7 provides different versions of the TSEND_C and TRCV_C instructions. For information on instruction versions, refer to Use Instruction versions in the STEP 7 Information System.
The TSEND_C instruction combines the functions of the TCON, TDISCON and TSEND instructions. The TRCV_C instruction combines the functions of the TCON, TDISCON, and TRCV instructions. (Refer to "TCON, TDISCON, TSEND, AND TRCV" for more information on these instructions.)
The minimum size of data that you can transmit (TSEND_C) or receive (TRCV_C) is one byte; the maximum size is 8192 bytes. TSEND_C does not support the transmission of data from Boolean locations, and TRCV_C will not receive data into Boolean locations. For information on transferring data with these instructions, see the section on data consistency.
Initializing the communication parameters
After you insert the TSEND_C or TRCV_C instruction, use the "Properties" of the instruction to configure the communication parameters. As you enter the parameters for the communication partners in the inspector window, STEP 7 enters the corresponding data in the DB for the instruction.
If you want to use a multi-instance DB, you must configure the DB on both CPUs.
LAD / FBD | SCL | Description |
|---|---|---|
"TSEND_C_DB"( req:=_bool_in_, cont:=_bool_in_, len:=_uint_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, connect:=_struct_inout_, data:=_variant_inout_, com_rst:=_bool_inout_); | TSEND_C establishes a TCP or ISO on TCP communication connection to a partner station, sends data, and can terminate the connection. After the connection is set up and established, it is automatically maintained and monitored by the CPU. | |
"TRCV_C_DB"( en_r:=_bool_in_, cont:=_bool_in_, len:=_uint_in_, adhoc:=_bool_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, rcvd_len=>_uint_out_, connect:=_struct_inout_, data:=_variant_inout_, com_rst:=_bool_inout_); | TRCV_C establishes a TCP or ISO on TCP communication connection to a partner CPU, receives data, and can terminate the connection. After the connection is set up and established, it is automatically maintained and monitored by the CPU. |
1 STEP 7 automatically creates the DB when you insert the instruction.
Parameter and type | Data type | Description | |
|---|---|---|---|
REQ (TSEND_C) | IN | Bool | Starts the send job on a rising edge |
EN_R (TRCV_C) | IN | Bool | Receive enable |
CONT | IN | Bool | Controls the communication connection:
When sending data (TSEND_C) (rising edge at the REQ parameter) or receiving data (TRCV_C) (rising edge at the EN_R parameter), the CONT parameter must have the value TRUE in order to establish or maintain a connection. |
LEN | IN | UDInt | Optional parameter (hidden) Maximum number of bytes to be sent (TSEND_C) or received (TRCV_C) with the job. If you use purely symbolic values at the DATA parameter, the LEN parameter must have the value "0". |
ADHOC (TRCV_C) | IN | Bool | Optional parameter (hidden) Ad hoc mode request for connection type TCP. |
CONNECT | IN_OUT | Variant | Pointer to the connection description:
|
DATA | IN_OUT | Variant | Pointer to the send area containing:
|
ADDR | IN_OUT | Variant | Optional parameter (hidden) Pointer to the address of the recipient with the connection type UDP. The address information is mapped in the structure TADDR_Param ###. |
COM_RST | IN_OUT | Bool | Optional parameter (hidden) Restarts the instruction:
The COM_RST parameter is reset after evaluation by the TSEND_C or TRCV_C instruction and should not, therefore, be switched statically. |
DONE | OUT | Bool | Status parameter with the following values:
|
BUSY | OUT | Bool | Status parameter with the following values:
|
ERROR | OUT | Bool | Status parameters with the following values:
|
STATUS | OUT | Word | Status of instruction (see the ERROR and STATUS parameters description). |
RCVD_LEN (TRCV_C) | OUT | Int | Amount of data actually received (in bytes). |
The TSEND_C instruction requires a low-to-high transition at the REQ input parameter to start a send job. The BUSY parameter is then set to 1 during processing. Completion of the send job is indicated by either the DONE or ERROR parameters being set to 1 for one scan. During this time, any low-to-high transition at the REQ input parameter is ignored.
The default setting of the LEN parameter (LEN = 0) uses the DATA parameter to determine the length of the data being transmitted. It is recommended that the data transmitted by the TSEND_C instruction be the same size as the DATA parameter of the TRCV_C instruction.
If using the default setting of the LEN parameter and it is necessary to send the data in segments smaller than the DATA parameter size, the following applies. If the size of the data transmitted from TSEND_C does not equal the TRCV_C DATA parameter size, TRCV_C remains in a busy status (status code: 7006) until the overall size of the data transmitted from TSEND_C equals the TRCV_C DATA parameter size.
The TRCV_C DATA parameter buffer does not display the new data received until the data size equals the DATA parameter buffer size.
TSEND_C operations
The TSEND_C instruction is executed asynchronously and implements the following functions in sequence:
Setting up and establishing a communications connection:
TSEND_C sets up a communication connection and establishes this connection if a rising edge is detected at the REQ parameter and no communication connection is in place yet. Once the connection has been set up and established, it is automatically maintained and monitored by the CPU. The connection description specified at the CONNECT parameter is used to set up the communications connection.
An existing connection is terminated and the connection which has been set up is removed when the CPU goes into STOP mode. To set up and establish the connection again, you must execute TSEND_C again. For information on the number of possible communication connections, refer to the technical specifications for your CPU.
Sending data via an existing communications connection:
The send job is executed when a rising edge is detected at the REQ parameter. As described above, the communications connection is established first. You specify the send area with the DATA parameter. This includes the address and the length of the data to be sent. Do not use a data area with the data type BOOL or Array of BOOL at the DATA parameter. With the LEN parameter, you specify the maximum number of bytes sent with a send job. If using a symbolic name at the DATA parameter, the LEN parameter should have the value "0".
The data to be sent must not be edited until the send job is completed.
Terminating the communications connection:
The communications connection is terminated after the data has been sent if the CONT parameter had the value "0" at the time of the rising edge at the REQ parameter. Otherwise, the communications connection will be maintained.
If the send job executes successfully, the DONE parameter is set to "1". The communications connection may be terminated before this (see the above description of the dependency on the CONT parameter). Signal state "1" at the DONE parameter is not confirmation that the data sent has already been read by the communications partner.
TSEND_C is reset when the COM_RST parameter is set to "1". Data loss may occur if data is being transferred at this point.
The following scenarios are possible depending on the CONT parameter:
CONT = "0":
An existing communications connection is established.
CONT = "1" and a communications connection was established:
An existing communications connection is reset and established again.
CONT = "1" and no communications connection was established.
No communications connection is established.
The COM_RST parameter is reset following evaluation by the instruction T_SEND. To enable TSEND_C again after the execution (DONE = 1), call the instruction once with REQ = 0
TRCV_C operations
The TRCV_C instruction is executed asynchronously and implements the following functions in sequence:
Setting up and establishing a communications connection:
TRCV_C sets up a communication connection and establishes this connection if the EN_R parameter = "1" and there is no communication connection. Once the connection has been set up and established, it is automatically maintained and monitored by the CPU.
The connection description specified at the CONNECT parameter is used to set up the communications connection. The following connection types can be used:
TCON_Param structure for the TCP, ISO-on-TCP, and UDP protocols
TCP / UDP: Connection description via the structure TCON_IP_V4 at the parameter CONNECT
ISO-on-TCP: Connection description via the structure TCON_IP_RFC at the parameter CONNECT
TCP: Connection description using the structure TCON_IP_V4_SEC at the parameter CONNECT
TCP: Connection description using the structures TCON_QDN and TCON_QDN_SEC.
An existing connection is terminated and the connection which has been set up is removed when the CPU goes into STOP mode. To set up and establish the connection again, you must execute TRCV_C again with EN_R = "1".
If EN_R is set to "0" before the communications connection has been established, the connection will be established and remain in place even if CONT = "0". However, no data will be received (DONE will remain "0").
For information on the number of possible communication connections, please refer to the technical specifications for your CPU.
Receiving data via an existing communications connection:
Receipt of data is enabled when the EN_R parameter is set to the value "1". As described above, the communications connection is established first. The received data is entered in a receive area. You specify the length of the receive area either with the LEN parameter (if LEN <> 0) or with the length information of the DATA parameter (if LEN = 0), depending on the protocol variant being used. If you use purely symbolic values at the DATA parameter, the LEN parameter must have the value "0".
If EN_R is set to "0" before data is received for the first time, the communication connection will remain in place even if CONT = 0. However, no data will be received (DONE will remain "0").
Terminating the communications connection:
The communications connection is terminated after data has been received if the CONT parameter had the value "0" when connection established was started. Otherwise, the communications connection will be maintained.
If the receive job executes successfully, the DONE parameter is set to "1". The communications connection may be terminated before this (see the above description of the dependency on the CONT parameter).
TRCV_C is reset when the COM_RST parameter is set. If data is being received when it executes again, this can lead to a loss of data. The following scenarios are possible depending on the CONT parameter:
CONT = "0":
An existing communications connection is established.
CONT = "1" and a communications connection was established:
An existing communications connection is reset and established again.
CONT = "1" and no communications connection was established:
No communications connection is established.
The COM_RST parameter is reset following evaluation by the instruction TRCV_".
TRCV_C handles the same receive modes as the TRCV instruction. The following table shows how data is entered in the receive area:
Protocol variant | Availability of data in the receive area | Connection_type parameter of the connection description | LENparameter | RCVD_LENparameter |
|---|---|---|---|---|
TCP (Ad hoc mode) | The data is immediately available. | B#16#11 | Selected with the TRCV_C instruction ADHOC input | 1 to 1460 |
TCP (data receipt with specified length) | The data is available as soon as the data length specified at the LEN parameter has been fully received. | B#16#11 | 1 to 8192 | Identical to the value at the LEN parameter |
ISO on TCP (protocol-controlled data transfer) | The data is available as soon as the data length specified at the LEN parameter has been fully received. | B#16#12 | 1 to 8192 | Identical to the value at the LEN parameter |
Ad hoc mode
The "ad hoc mode" is only available with the TCP protocol variant. To configure the TRCV_C instruction for ad hoc mode, set the ADHOC instruction input parameter. The length of the receive area is defined by the pointer at the DATA parameter. The data length actually received is output at the RCVD_LEN parameter. A maximum of 1460 bytes can be received.
Importing of S7-300/400 STEP 7 projects containing "ad hoc mode" into the S7-1200
In S7-300/400 STEP 7 projects, "ad hoc mode" is selected by assigning "0" to the LEN parameter. In the S7-1200, you configure the TRCV_C instruction for ad hoc mode by setting the ADHOC instruction input parameter..
If you import an S7-300/400 STEP 7 project containing "ad hoc mode" into the S7-1200, you must change the LEN parameter to "65535".
TCP (data receipt with specified length)
You use the value of the LEN parameter to specify the length for the data receipt. The data specified at the DATA parameter is available in the receive area as soon as the length specified at the LEN parameter has been completely received.
ISO on TCP (protocol-controlled data transfer)
With the ISO on TCP protocol variant, data is transferred protocol-controlled. The receive area is defined by the LEN and DATA parameters.
BUSY, DONE, and ERROR parameters
Due to the asynchronous processing of TSEND_C, you must keep the data in the sender area consistent until the DONE parameter or the ERROR parameter assumes the value TRUE.
For TSEND_C, a TRUE state at the parameter DONE means that the data was sent successfully. It does not mean that the connection partner CPU actually read the receive buffer.
Due to the asynchronous processing of TRCV_C, the data in the receiver area are only consistent when parameter DONE = 1.
BUSY | DONE | ERROR | Description |
|---|---|---|---|
1 | 0 | 0 | The send job is being processed. |
0 | 1 | 0 | The send job was completed successfully. |
0 | 0 | 1 | The connection establishment or the send job was completed with an error. The cause of the error is specified in the STATUS parameter. |
0 | 0 | 0 | No new send job was assigned. |
You can check the status of the execution with the BUSY, DONE, ERROR, and STATUS parameters. The BUSY parameter indicates the processing status. With the DONE parameter, you can check whether or not a send job executed successfully. The ERROR parameter is set when errors occurred during execution of TSEND_C or TRCV_C. The error information is output at the STATUS parameter.
Error and Status parameters
ERROR | STATUS * (W#16#...) | Description |
|---|---|---|
0 | 0000 | Send (TSEND_C) or receive (TRCV_C) job executed without errors. |
0 | 0001 | Communication connection established. |
0 | 0003 | Communication connection closed. |
0 | 7000 | No active send job execution; no communications connection established. |
0 | 7001 |
|
0 | 7002 | Job executing (REQ irrelevant) |
0 | 7003 | The instruction is terminating the communications connection. |
0 | 7004 | Communications connection established and monitored; no send (TSEND_C) or receive (TRCV_C) job execution active. |
0 | 7005 | TSEND_C: Data transfer is in progress. |
0 | 7006 | TRCV_C: The instruction is receiving the data. |
1 | 8085 |
|
1 | 8086 | The ID parameter within the CONNECT parameter is outside the permitted range. |
1 | 8087 | Maximum number of connections reached; no additional connection possible. |
1 | 8088 | The value at the LEN parameter does not correspond to the receive area set at the DATA parameter. |
1 | 8089 |
|
1 | 8091 | Maximum nesting depth exceeded. |
1 | 809A | The CONNECT parameter points to a field that does not correspond to the length of the connection description. |
1 | 809B | The InterfaceId in the connection description does not correspond to the CPU or CP. |
1 | 80A1 |
|
1 | 80A2 | Local or remote port is being used by the system. Refer to "TCON and TDISCON instructions", "ERROR and STATUS condition codes" for further information. |
1 | 80A3 |
|
1 | 80A4 | IP address of the remote endpoint of the connection is invalid, which means it corresponds to the IP address of the local partner. |
1 | 80A7 | Communication error: You called the instruction with COM_RST = 1 before the send job was complete. |
1 | 80AA | Another block is establishing a connection using the same connection ID. Repeat the job with a new rising edge at the REQ parameter. |
1 | 80B3 |
|
1 | 80B4 | You have violated one or both of the following conditions for passive connection establishment (ActiveEstablished = FALSE) when using the ISO-on-TCP protocol variant (ConnectionType = B#16#12):
|
1 | 80B5 | Only passive connection establishment is permitted for connection type 13 = UDP. |
1 | 80B6 | Parameter assignment error in the ConnectionType parameter of the data block for connection description. |
1 | 80B7 |
|
1 | 80C3 |
|
1 | 80C4 | Temporary communication error:
|
1 | 80C5 |
|
1 | 80C6 | Network error:
|
1 | 8722 | Error in the CONNECT parameter: Invalid source area (area not declared in data block). |
1 | 873A | Error in the CONNECT parameter: Access to connection description is not possible (no access to data block). |
1 | 877F | Error in the CONNECT parameter: Internal error |
1 | 8822 | TSEND_C: DATA parameter: Invalid source area, the area does not exist in the DB. |
1 | 8824 | TSEND_C: DATA parameter: Area error in the VARIANT pointer. |
1 | 8832 | TSEND_C: DATA parameter: The DB number is too high. |
1 | 883A | TSEND_C: CONNECT parameter: Access to specified connection data not possible (for example, because the DB does not exist). |
1 | 887F | TSEND_C: DATA parameter: Internal error (for example, invalid VARIANT reference) |
1 | 893A | TSEND_C: DATA parameter: Access to send area not possible (for example, because the DB does not exist). |
1 | 8922 | TRCV_C: DATA parameter: Invalid target area; the area does not exist in the DB. |
1 | 8924 | TRCV_C: DATA parameter: Area error in the VARIANT pointer. |
1 | 8932 | TRCV_C: DATA parameter: The DB number is too high. |
1 | 893A | TRCV_C: CONNECT parameter: Access to specified connection data not possible (for example, because the DB does not exist). |
1 | 897F | TRCV_C: DATA parameter: Internal error (for example, invalid VARIANT reference). |
1 | 8A3A | TRCV_C: DATA parameter: No access to the data area (for example because the data block does not exist). |
* The error codes can be displayed as integer or hexadecimal values in the program editor. | ||
Error messages of the instructions TCON, TSEND, TRCV, and TDISCON
Internally, the TSEND_C instruction uses the TCON, TSEND, and TDISCON instructions; and the TRCV_C instruction uses the TCON, TRCV, and TDISCON instructions. Refer to "TCON, TDISCON, TSEND, AND TRCV" for more information on error messages of these instructions.
Connection Ethernet protocols
Every CPU has an integrated PROFINET port, which supports standard PROFINET communications. The TSEND_C and TRCV_C and TSEND and TRCV instructions all support the TCP and ISO on TCP Ethernet protocols.
Refer to "Device Configuration: Configuring the Local/Partner connection path" for more information.
Prior to the release of STEP 7 V13 SP1 and the S7-1200 V4.1 CPUs, the TSEND_C and TRCV_C instructions could only work with connection parameters with structures according to "TCON_Param". The general concepts apply to both sets of instructions. Refer to the individual legacy TSEND_C and TRCV_C instructions for programming information.
STEP 7 provides different versions of the TSEND_C and TRCV_C instructions. For information on instruction versions, refer to Use Instruction versions in the STEP 7 Information System.
The legacy TSEND_C instruction combines the functions of the legacy TCON, TDISCON and TSEND instructions. The TRCV_C instruction combines the functions of the TCON, TDISCON, and TRCV instructions. (Refer to "Legacy TCON, TDISCON, TSEND, and TRCV (TCP communication) instructions" for more information on these instructions.)
The minimum size of data that you can transmit (TSEND_C) or receive (TRCV_C) is one byte; the maximum size is 8192 bytes. TSEND_C does not support the transmission of data from Boolean locations, and TRCV_C will not receive data into Boolean locations. For information on transferring data with these instructions, see the section on data consistency.
Initializing the communication parameters
After you insert the TSEND_C or TRCV_C instruction, use the "Properties" of the instruction to configure the communication parameters. As you enter the parameters for the communication partners in the inspector window, STEP 7 enters the corresponding data in the DB for the instruction.
If you want to use a multi-instance DB, you must configure the DB on both CPUs.
LAD / FBD | SCL | Description |
|---|---|---|
"TSEND_C_DB"( req:=_bool_in_, cont:=_bool_in_, len:=_uint_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, connect:=_struct_inout_, data:=_variant_inout_, com_rst:=_bool_inout_); | TSEND_C establishes a TCP or ISO on TCP communication connection to a partner station, sends data, and can terminate the connection. After the connection is set up and established, it is automatically maintained and monitored by the CPU. | |
"TRCV_C_DB"( en_r:=_bool_in_, cont:=_bool_in_, len:=_uint_in_, adhoc:=_bool_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, rcvd_len=>_uint_out_, connect:=_struct_inout_, data:=_variant_inout_, com_rst:=_bool_inout_); | TRCV_C establishes a TCP or ISO on TCP communication connection to a partner CPU, receives data, and can terminate the connection. After the connection is set up and established, it is automatically maintained and monitored by the CPU. |
1 STEP 7 automatically creates the DB when you insert the instruction.
Parameter and type | Data type | Description | |
|---|---|---|---|
REQ (TSEND_C) | IN | Bool | REQ = 1 starts the TSEND_C send job on a rising edge with the connection described in CONNECT parameter. (CONT = 1 is also required to establish and maintain the communication connection. |
EN_R (TRCV_C) | IN | Bool | When EN_R = 1, TRCV_C is ready to receive. The receive job is processed. (CONT = 1 is also required to establish and maintain the communication connection.) |
CONT | IN | Bool | Controls the communication connection:
When sending data (TSEND_C) (rising edge at the REQ parameter), the CONT parameter must have the value TRUE in order to establish or maintain a connection. When receiving data (TRCV_C) (rising edge at the EN_R parameter), the CONT parameter must have the value TRUE in order to establish or maintain a connection. |
LEN | IN | UInt | Maximum number of bytes to be sent (TSEND_C) or received (TRCV_C):
|
CONNECT | IN_OUT | TCON_Param | Pointer to the connection description |
DATA | IN_OUT | Variant |
|
COM_RST | IN_OUT | Bool | Allows restart of the instruction:
|
DONE | OUT | Bool |
|
BUSY | OUT | Bool |
|
ERROR | OUT | Bool | Status parameters with the following values:
|
STATUS | OUT | Word | Status information including error information. (Refer to the "Error and Status Parameters" table below.) |
RCVD_LEN (TRCV_C) | OUT | Int | Amount of data actually received, in bytes |
The TSEND_C instruction requires a low-to-high transition at the REQ input parameter to start a send job. The BUSY parameter is then set to 1 during processing. Completion of the send job is indicated by either the DONE or ERROR parameters being set to 1 for one scan. During this time, any low-to-high transition at the REQ input parameter is ignored.
The default setting of the LEN parameter (LEN = 0) uses the DATA parameter to determine the length of the data being transmitted. It is recommended that the data transmitted by the TSEND_C instruction be the same size as the DATA parameter of the TRCV_C instruction.
If using the default setting of the LEN parameter and it is necessary to send the data in segments smaller than the DATA parameter size, the following applies. If the size of the data transmitted from TSEND_C does not equal the TRCV_C DATA parameter size, TRCV_C remains in a busy status (status code: 7006) until the overall size of the data transmitted from TSEND_C equals the TRCV_C DATA parameter size.
The TRCV_C DATA parameter buffer does not display the new data received until the data size equals the DATA parameter buffer size.
TSEND_C operations
The following functions describe the operation of the TSEND_C instruction:
To establish a connection, execute TSEND_C with CONT = 1.
After successful establishing of the connection, TSEND_C sets the DONE parameter for one cycle.
To terminate the communication connection, execute TSEND_C with CONT = 0. The connection will be aborted immediately. This also affects the receiving station. The connection will be closed there and data inside the receive buffer could be lost.
To send data over an established connection, execute TSEND_C with a rising edge on REQ. After a successful send operation, TSEND_C sets the DONE parameter for one cycle.
To establish a connection and send data, execute TSEND_C with CONT =1 and REQ = 1. After a successful send operation, TSEND_C sets the DONE parameter for one cycle.
TRCV_C operations
The following functions describe the operation of the TRCV_C instruction:
To establish a connection, execute TRCV_C with parameter CONT = 1.
To receive data, execute TRCV_C with parameter EN_R = 1. TRCV_C receives the data continuously when parameters EN_R = 1 and CONT = 1.
To terminate the connection, execute TRCV_C with parameter CONT = 0. The connection will be aborted immediately, and data could be lost.
TRCV_C handles the same receive modes as the TRCV instruction. The following table shows how data is entered in the receive area:
Protocol variant | Entering the data in the receive area | Parameter "connection_type" | Value of the LEN parameter | Value of the RCVD_LEN parameter (bytes) |
|---|---|---|---|---|
TCP | Ad hoc mode | B#16#11 | 65535 | 1 to 1460 |
TCP | Data reception with specified length | B#16#11 | 0 (recommended) or 1 to 8192, except 65535 | 1 to 8192 |
ISO on TCP | Ad hoc mode | B#16#12 | 65535 | 1 to 1460 |
ISO on TCP | Protocol-controlled | B#16#12 | 0 (recommended) or 1 to 8192, except 65535 | 1 to 8192 |
Ad hoc mode
The "ad hoc mode" exists with the TCP and ISO on TCP protocol variants. You set "ad hoc mode" by assigning "65535" to the LEN parameter. The receive area is identical to the area formed by DATA. The length of the received data will be output to the parameter RCVD_LEN.
If you store the data in an "optimized" DB (symbolic only), you can receive data only in arrays of Byte, Char, USInt, and SInt data types.
Importing of S7-300/400 STEP 7 projects containing "ad hoc mode" into the S7-1200
In S7-300/400 STEP 7 projects, "ad hoc mode" is selected by assigning "0" to the LEN parameter. In the S7-1200, you set "ad hoc mode" by assigning "65535" to the LEN parameter.
If you import an S7-300/400 STEP 7 project containing "ad hoc mode" into the S7-1200, you must change the LEN parameter to "65535".
Must keep the data in the sender area consistent until the DONE parameter or the ERROR parameter assumes the value TRUE
Due to the asynchronous processing of TSEND_C, you must keep the data in the sender area consistent until the DONE parameter or the ERROR parameter assumes the value TRUE.
For TSEND_C, a TRUE state at the parameter DONE means that the data was sent successfully. It does not mean that the connection partner CPU actually read the receive buffer.
Due to the asynchronous processing of TRCV_C, the data in the receiver area are only consistent when parameter DONE = 1.
BUSY | DONE | ERROR | Description |
|---|---|---|---|
TRUE | irrelevant | irrelevant | The job is being processed. |
FALSE | TRUE | FALSE | The job is successfully completed. |
FALSE | FALSE | TRUE | The job was ended with an error. The cause of the error can be found in the STATUS parameter. |
FALSE | FALSE | FALSE | A new job was not assigned. |
Error and Status parameters
ERROR | STATUS | Description |
|---|---|---|
0 | 0000 | Job executed without error |
0 | 7000 | No job processing active |
0 | 7001 | Start job processing, establishing connection, waiting for connection partner |
0 | 7002 | Data being sent or received |
0 | 7003 | Connection being terminated |
0 | 7004 | Connection established and monitored, no job processing active |
1 | 8085 | LEN parameter is greater than the largest permitted value. |
1 | 8086 | The CONNECT parameter is outside the permitted range. |
1 | 8087 | Maximum number of connections reached; no additional connection possible. |
1 | 8088 | LEN parameter is not valid for the memory area specified in DATA. |
1 | 8089 | The CONNECT parameter does not point to a data block. |
1 | 8091 | Maximum nesting depth exceeded. |
1 | 809A | The CONNECT parameter points to a field that does not match the length of the connection description. |
1 | 809B | The local_device_id in the connection description does not match the CPU. |
1 | 80A1 | Communications error:
|
1 | 80A3 | Attempt being made to terminate a nonexistent connection |
1 | 80A4 | IP address of the remote partner connection is invalid. For example, the remote partner IP address is the same as the local partner IP address. |
1 | 80A5 | Connection ID is already in use. |
1 | 80A7 | Communications error: You called TDISCON before TSEND_C was complete. |
1 | 80B2 | The CONNECT parameter points to a data block that is set to "Only store in load memory." |
1 | 80B3 | Inconsistent parameters:
|
1 | 80B4 | When using the ISO on TCP (connection_type = B#16#12) to establish a passive connection, condition code 80B4 alerts you that the TSAP entered did not conform to one of the following address requirements:
Valid ASCII characters are byte values from 20 to 7E (hexadecimal). |
1 | 80B7 | Data type and/or length of the transmitted data does not fit in the area in the partner CPU in which it is to be written. |
1 | 80C3 | All connection resources are in use. |
1 | 80C4 | Temporary communications error:
|
1 | 8722 | CONNECT parameter: Source area invalid: area does not exist in DB. |
1 | 873A | CONNECT parameter: Access to connection description is not possible (for example, DB not available) |
1 | 877F | CONNECT parameter: Internal error such as an invalid ANY reference |
1 | 893A | Parameter contains the number of a DB that is not loaded. |
Connection Ethernet protocols
Every CPU has an integrated PROFINET port, which supports standard PROFINET communications. The TSEND_C and TRCV_C and TSEND and TRCV instructions all support the TCP and ISO on TCP Ethernet protocols.
Refer to "Device Configuration: Configuring the Local/Partner connection path" for more information.
The S7-1200 supports two sets of TCON, TDISCON, TSEND, and TRCV instructions:
TCON, TDISCON, TSEND, and TRCV instructions: These TCON, TDISCON, TSEND, and TRCV instructions provide all of the functionality of the legacy instructions, plus the ability to use connection parameters with structures according to TCON_IP_V4, TCON_IP_V4_SEC, TCON_IP_RFC, TCON_QDN, and TCON_QDN_SEC.
Legacy TCON, TDISCON, TSEND, and TRCV instructions: These TCON, TDISCON, TSEND, and TRCV instructions existed prior to version V4.1 of the S7-1200 and only work with connection parameters with structures according to TCON_Param.
STEP 7 provides different versions of the TCON, TDISCON, TSEND, and TRCV instructions. For information on instruction versions, refer to Use Instruction versions in the STEP 7 Information System.
Ethernet communication using TCP and ISO on TCP protocols
TSEND_C and TRCV_C instructions
To help simplify the programming of PROFINET/Ethernet communication, the TSEND_C instruction and the TRCV_C instruction combine the functionality of the TCON, TDISCON. TSEND and TRCV instructions:
TSEND_C combines the TCON, TDISCON and TSEND instructions.
TRCV_C combines the TCON, TDISCON and TRCV instructions.
The following instructions control the communication process:
TCON establishes the TCP/IP connection between the client and server (CPU) PC.
TSEND and TRCV send and receive data.
TDISCON breaks the connection.
The minimum size of data that you can transmit (TSEND) or receive (TRCV) is one byte; the maximum size is 8192 bytes. TSEND does not support the transmission of data from Boolean locations, and TRCV will not receive data into Boolean locations. For information transferring data with these instructions, see the section on data consistency.
TCON, TDISCON, TSEND, and TRCV operate asynchronously, which means that the job processing extends over multiple instruction executions. For example, you start a job for setting up and establishing a connection by executing an instruction TCON with parameter REQ = 1. Then you use additional TCON executions to monitor the job progress and test for job completion with parameter DONE.
The following table shows the relationships between BUSY, DONE, and ERROR. Use the table to determine the current job status:
BUSY | DONE | ERROR | Description |
|---|---|---|---|
1 | 0 | 0 | The job is being processed. |
0 | 1 | 0 | The job successfully completed. |
0 | 0 | 1 | The job ended with an error. The cause of the error is output at the STATUS parameter. |
0 | 0 | 0 | No new job assigned. |
TCON and TDISCON
Initializing the communication parameters
After you insert the TCON instruction, use the "Properties" of the instruction to configure the communication parameters. As you enter the parameters for the communication partners in the inspector window, STEP 7 enters the corresponding data in the instance DB for the instruction.
If you want to use a multi-instance DB, you must configure the DB on both CPUs.
LAD / FBD | Description | |
|---|---|---|
"TCON_DB"( req:=_bool_in_, ID:=_undef_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, connect:=_struct_inout_); | TCP and ISO on TCP: TCON initiates a communications connection from the CPU to a communication partner. | |
 | "TDISCON_DB"( req:=_bool_in_, ID:=_word_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_); | TCP and ISO on TCP: TDISCON terminates a communications connection from the CPU to a communication partner. |
1 STEP 7 automatically creates the DB when you insert the instruction.
Parameter | Declaration | Data type | Description |
|---|---|---|---|
REQ | IN | Bool | Starts the job to establish the connection specified in the ID upon a rising edge. |
ID | IN | CONN_OUC (Word) | Reference to the assigned connection. Range of values: W#16#0001 to W#16#0FFF |
CONNECT (TCON) | IN_OUT | VARIANT | Pointer to the connection description:
|
DONE | OUT | Bool | Status parameter with the following values:
|
BUSY | OUT | Bool | Status parameter with the following values:
|
ERROR | OUT | Bool | Status parameter ERROR:
|
STATUS | OUT | Word | Status of the instruction |
Both communication partners execute the TCON instruction to set up and establish the communication connection. You use parameters to specify the active and passive communication end point partners. After the connection is set up and established, it is automatically maintained and monitored by the CPU.
If the connection is terminated due to a line break or due to the remote communications partner, for example, the active partner attempts to re-establish the configured connection. You do not have to execute TCON again.
An existing connection is terminated and the set-up connection is removed when the TDISCON instruction is executed or when the CPU has gone into STOP mode. To set up and re-establish the connection, you must execute TCON again.
ERROR | STATUS * (W#16#...) | Explanation |
|---|---|---|
0 | 0000 | Connection successfully established. |
0 | 7000 | No job processing active |
0 | 7001 | Start job execution; establish connection (TCON) or terminate connection (TDISCON). |
0 | 7002 | The instruction is establishing a connection (REQ irrelevant); establish connection (TCON) or terminate connection (TDISCON). |
1 | 8085 | TCON: Connection ID is in use. |
1 | 8086 | TCON: The ID parameter is outside the valid range. |
1 | 8087 | TCON: Maximum number of connections reached; no additional connection possible |
1 | 8089 | TCON: The CONNECT parameter does not point to a connection description, or the connection description was created manually. |
1 | 809A | TCON: The instruction does not support the structure at the CONNECT parameter, or the length is invalid. |
1 | 809B | TCON:
|
1 | 80A1 | TCON: For TCP/UDP: Connection or port is in use. |
1 | 80A2 | TCON: The system is using the local or remote port. Refer to "Common parameters for instructions", "Restricted TSAPs and port numbers for passive ISO and TCP communication" for further information. |
1 | 80A3 | TCON: A connection (TCON), created by the user program, is using the value at the ID parameter. The connection uses the identical ID and the same connection settings at the CONNECT parameter. |
1 | 80A4 | TCON: IP address of the remote endpoint of the connection is invalid, or it corresponds to the IP address of the local partner. |
1 | 80A7 | TCON: Communication error: You executed "TDISCON" before "TCON" had completed. |
1 | 80B3 | Inconsistent parameter assignment |
1 | 80B4 | TCON: Only with TCON_IP_RFC: One of the following occurred:
|
1 | 80B5 | TCON: The instruction permits only passive connection establishment for connection type 13 = UDP (Parameter ActiveEstablished of the structure TCON_xxx has the value TRUE). |
1 | 80B6 | TCON: Parameter assignment error in the ConnectionType parameter of the data block for connection description:
|
1 | 80B7 | TCON: With TCON_IP_V4, TCON_IP_V4_SEC, TCON_QDN, TCON_QDN_SEC:
TCON: With TCON_IP_RFC:
|
1 | 80B8 | TCON: ID parameter in the local connection description (structure at CONNECT parameter) and ID parameter of the instruction are different. |
1 | 80C3 | TCON: All connection resources are in use. |
1 | 80C4 | Temporary communication error:
|
1 | 80C5 | TCON: The remote partner did one of the following:
|
1 | 80C6 | TCON: The instruction cannot reach the remote partner (network error). |
1 | 80C7 | TCON: Execution timeout |
1 | 80C8 | TCON: A connection (TCON), created by the user program, is using the value at the ID parameter. The connection uses the identical ID, but different connection settings at the CONNECT parameter. |
1 | 80C9 | TCON: Validation of the remote partner failed. The remote partner that wants to establish the connection does not match the defined partner of the structure at the CONNECT parameter. |
1 | 80CE | TCON: The IP address of the local interface is 0.0.0.0. |
1 | 80E0 | TCON: The instruction received an unsuitable or poor message. |
1 | 80E1 | TCON: Error during the handshake. Possible causes:
|
1 | 80E2 | Certificate not supported / certificate invalid / no certificate Possible cause: For the module concerned, the CPU did not set the time-of-day or synchronize the module. Example: The default setting for the date of the module is 1/1/2012, and the CPU did not set the date during commissioning. The validity period of the certificate starts on 20 August 2016, and ends on 20 August 2024. In this case, the date of the module is outside the validity period of the certificate; the certificate is invalid for the module. |
1 | 80E3 | Certificate discarded. |
1 | 80E4 | No valid certification authority found. |
1 | 80E5 | Certificate expired. |
1 | 80E6 | Integrity errors in the Transport Layer Security Protocol |
1 | 80E7 | Not supported extension in X.509-V3 certificate |
1 | 80E9 | The instruction does not support a TLS server without a server certificate. |
1 | 80EA | The instruction does not support DTLS (UDP) protocol. |
1 | 80EB | A client cannot request a client certificate. |
1 | 80EC | The server cannot perform validation based on the subjectAlternateName (only clients can do this). |
1 | 80ED | TLSServerCertRef_m-ID invalid |
* The error codes in the program editor can be displayed as integer or hexadecimal values. | ||
TSEND and TRCV
When using PROFINET Open User communication, if you execute a TSEND instruction without a corresponding TRCV instruction executing on the remote device, then the TSEND instruction may reside indefinitely in a "Busy State", waiting for the TRCV instruction to receive the data. In this state, the TSEND instruction "Busy" output is set, and the "Status" output has a value of "0x7002". This condition may occur if you are transferring more than 4096 bytes of data. The issue is resolved at the next execution of the TRCV instruction.
LAD / FBD | SCL | Description |
|---|---|---|
"TSEND_DB"( req:=_bool_in_, ID:=_word_in_, len:=_udint_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, data:=_variant_inout_); | TCP and ISO on TCP: TSEND sends data through a communication connection from the CPU to a partner station. | |
"TRCV_DB"( en_r:=_bool_in_, ID:=_word_in_, len:=_udint_in_, adhoc:=_bool_in_, ndr=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, rcvd_len=>_udint_out_, data:=_variant_inout_); | TCP and ISO on TCP: TRCV receives data through a communication connection from a partner station to the CPU. |
1 STEP 7 automatically creates the DB when you insert the instruction.
Parameter and type | Data type | Description | |
|---|---|---|---|
REQ | IN | Bool | TSEND: Starts the send job on a rising edge. The data is transferred from the area specified by DATA and LEN. |
EN_R | IN | Bool | TRCV: Enables the CPU to receive; with EN_R = 1, the TRCV is ready to receive. The receive job is processed. |
ID | IN | CONN_OUC (Word) | Reference to the associated connection. ID must be identical to the associated parameter ID in the local connection description. Value range: W#16#0001 to W#16#0FFF |
LEN | IN | UDInt | Maximum number of bytes to be sent (TSEND) or received (TRCV):
|
ADHOC | IN | Bool | TRCV: Optional parameter (hidden) Ad hoc mode request for connection type TCP. |
DATA | IN_OUT | Variant | Pointer to send (TSEND) or receive (TRCV) data area; data area contains the address and length. The address refers to I memory, Q memory, M memory, or a DB. |
DONE | OUT | Bool | TSEND:
|
NDR | OUT | Bool | TRCV:
|
BUSY | OUT | Bool |
|
ERROR | OUT | Bool | ERROR = 1: Error occurred during processing. STATUS provides detailed information on the type of error |
STATUS | OUT | Word | Status information including error information. (Refer to the Error and Status condition codes in the table below.) |
RCVD_LEN | OUT | UDInt | TRCV: Amount of data actually received in bytes |
The TSEND instruction requires a low-to-high transition at the REQ input parameter to start a send job. The BUSY parameter is then set to 1 during processing. Completion of the send job is indicated by either the DONE or ERROR parameters being set to 1 for one scan. During this time, any low-to-high transition at the REQ input parameter is ignored.
TRCV Operations
The TRCV instruction writes the received data to a receive area that is specified by the following two variables:
Pointer to the start of the area
Length of the area or the value supplied at the LEN input if not 0
The default setting of the LEN parameter (LEN = 0) uses the DATA parameter to determine the length of the data being transmitted. It is recommended that the data transmitted by the TSEND instruction be the same size as the DATA parameter of the TRCV instruction.
If using the default setting of the LEN parameter and it is necessary to send the data in segments smaller than the DATA parameter size, the following applies. It is recommended to keep the EN_R bit high until the corresponding TSEND transfers the appropriate amount of data to fill the TRCV DATA parameter. If the size of the data transmitted from TSEND does not equal the TRCV DATA parameter size, TRCV remains in a busy status (status code: 7002) while the EN_R bit is high until the overall size of the data transmitted from TSEND equals the TRCV DATA parameter size. If the EN_R bit of TRCV is pulsed, it needs to be pulsed the same number of times as TSEND is executed to receive the data.
The TRCV DATA parameter buffer does not display the new data received until the data size equals the DATA parameter buffer size.
As soon as all the job data has been received, TRCV transfers it to the receive area and sets NDR to 1.
Protocol variant | Entering the data in the receive area | Parameter "connection_type" | Value of the LEN parameter | Value of the RCVD_LEN parameter (bytes) |
|---|---|---|---|---|
TCP | Ad hoc mode | B#16#11 | Selected with the TRCV instruction ADHOC input | 1 to 1460 |
TCP | Data reception with specified length | B#16#11 | 0 (recommended) or 1 to 8192, except 65535 | 1 to 8192 |
ISO on TCP | Ad hoc mode | B#16#12 | 65535 | 1 to 1460 |
ISO on TCP | protocol-controlled | B#16#12 | 0 (recommended) or 1 to 8192, except 65535 | 1 to 8192 |
Ad hoc mode
The "ad hoc mode" exists with the TCP and ISO on TCP protocol variants. To configure the TRCV instruction for ad hoc mode, set the ADHOC instruction input parameter. The receive area is identical to the area formed by DATA. The length of the received data will be output to the parameter RCVD_LEN. Immediately after receiving a block of data, TRCV enters the data in the receive area and sets NDR to 1.
If you store the data in an "optimized" DB (symbolic only), you can receive data only in arrays of Byte, Char, USInt, and SInt data types.
Importing of S7-300/400 STEP 7 projects containing "ad hoc mode" into the S7-1200
In S7-300/400 STEP 7 projects, "ad hoc mode" is selected by assigning "0" to the LEN parameter. In the S7-1200, you configure the TRCV instruction for ad hoc mode by setting the ADHOC instruction input parameter.
If you import an S7-300/400 STEP 7 project containing "ad hoc mode" into the S7-1200, you must change the LEN parameter to "65535".
ERROR | STATUS | Description |
|---|---|---|
0 | 0000 |
|
0 | 7000 |
|
0 | 7001 |
|
0 | 7002 |
|
1 | 8085 |
|
1 | 8086 | The ID parameter is not in the permitted address range. |
1 | 8088 | The LEN parameter is larger than the memory area specified in DATA. |
1 | 80A1 | Communications error:
|
1 | 80C3 | Internal lack of connection resources: A block with this ID is already being processed in a different priority class. |
1 | 80C4 | Temporary communications error:
|
Connection Ethernet protocols
Every CPU has an integrated PROFINET port, which supports standard PROFINET communications. The TSEND_C, TRCV_C, TSEND and TRCV instructions all support the TCP and ISO on TCP Ethernet protocols.
Refer to "Device Configuration: Configuring the Local/Partner connection path" for more information.
You can use the "TCONSettings" instruction to execute the following functions:
Request a connection ID for a new OUC connection
Request a connection ID for a new OUC connection and at the same time specify a property for this connection
Read a property of a prepared or an existing OUC connection
Write a property for a prepared or an existing OUC connection
You can read or write the following connection properties with the "TCONSettings" instruction:
How a TCP connection is terminated
The "TCONSettings" instruction is an asynchronous instruction. Processing extends over multiple calls. You start processing with a rising edge at the "REQ" parameter.
The parameters "Busy" and "Done" indicate the status of the job.
If an error occurs during execution, this is signaled by the parameters "Error" and "Status".
Parameters and type | Data type | Description | |
|---|---|---|---|
REQ | Input | Bool | Control parameter Request Activates the job on a positive edge. |
MODE | Input | USInt | Use the "Mode" parameter to select the information you want to read from your CPU:
|
DONE | Output | Bool | Status parameter with the following values:
|
BUSY | Output | Bool | Status parameter with the following values:
|
ERROR | Output | Bool | Status parameter with the following values:
|
STATUS | Output | Word | Return value or error information of the "TCONSettings" instruction. |
ID | InOut | CONN_OUC | Reference to the connection: Note: For MODE=0, ID is an output parameter, for MODE=1 and MODE=2 ID is an input parameter. |
OPTION | InOut | Variant | Pointer to the description of the connection property to be read or specified:
|
BUSY, DONE and ERROR parameters
You can check the status of the job with the BUSY, DONE, ERROR and STATUS parameters. The BUSY parameter indicates the processing status. With the DONE parameter, you can check whether or not a job executed successfully. The ERROR parameter is set if errors occur during the execution of "TCONSettings". The error information is output at the STATUS parameter.
The following table shows the relationship between the BUSY, DONE and ERROR parameters:
BUSY | DONE | ERROR | Description |
|---|---|---|---|
1 | 0 | 0 | The job is being processed. |
0 | 1 | 0 | The job was completed successfully. |
0 | 0 | 1 | The job ended with an error. The cause of the error is output at the STATUS parameter. |
0 | 0 | 0 | No new job was assigned. |
STATUS (W#16#...) | Explanation |
|---|---|
0000 | "TCONSettings" was completed without errors. |
7000 | No job processing active. |
7001 | Start of job execution |
7002 | Intermediate call (REQ irrelevant): |
8086 | ID is outside the permitted range. |
8087 | Maximum number of OUC connections reached; no additional connections possible. |
8089 | OPTION does not point to a valid data type or OPTION is empty. |
8090 | OPTION points to a connection property which must not be changed for the connection referenced by ID. |
8091 | Invalid value for MODE |
8092 | A value in the data block referenced by OPTION is not permitted. |
8093 | If MODE has the value 0, ID must also have the value 0. |
809A | OPTION points to a data type that is not permitted for "TCONSettings". |
80A3 | ID points to a non-existent communication endpoint. |
80B1 | The OPTION parameter was changed before the execution of "TCONSettings" was completed. It is not permitted to change OPTION while "TCONSettings" are being executed. |
80C3 | The maximum number of simultaneously active jobs has already been reached. |
Maximum number of simultaneously active jobs
The maximum number of simultaneously active jobs is identical to the maximum number of OUC connections of your CPU
Reserving a connection resource
Call TCONSettings with MODE=0. Assign the relevant parameters as follows:
Enter the value NULL at the ID parameter.
If you do not want to specify a property for the associated connection, leave the OPTION parameter empty.
If you want to specify a property for the associated connection, assign a valid value to the OPTION parameter.
After the DONE parameter of TCONSettings is TRUE, a connection ID for a new OUC connection is available at the ID parameter. If you specified a property in the OPTION parameter, the connection uses this property for the connection. The TCONSettings instruction uses an OUC connection resource for the ID and creates the corresponding diagnostic objects. The TCONSettings instruction has prepared the connection but external communication partners do not yet know about the connection.
You have not specified any details for the connection, neither the connection partner nor the protocol nor the interface nor the DB with the connection description.
Establishing the connection
TCONSettings does not establish a connection.
Establishing the associated connection
If you want to establish the corresponding connection after the successful execution of "TCONSettings", follow these steps:
Save the connection ID provided by "TCONSettings".
Call the instruction "TCON" with exactly this ID.
The number of available OUC connections does not change, because the TCONSettings instruction already consumed the connection.
Release the connection ID and the corresponding connection resource
If you want to release the connection ID provided by "TCONSettings" and the corresponding connection resource again, call the "TDISCON" instruction with exactly this ID.
CPU changes to STOP mode
When the CPU changes to STOP mode, all connection IDs provided by "TCONSettings" and the corresponding connection resources are released.
Reading a property of a prepared or an existing connection
You call "TCONSettings" with MODE=1. You assign the relevant parameters as follows:
At the ID parameter you specify the reference to the desired connection.
At the OPTION parameter you specify which connection property you want to read.
After the DONE parameter has assumed the value TRUE, the current values of the desired property are available in the data area specified by OPTION.
Specifying a property of a prepared or an existing connection
You call "TCONSettings" with MODE=2. You assign the relevant parameters as follows:
At the ID parameter you specify the reference to the connection to which you want to assign a property.
At the OPTION parameter you indicate which connection property you want to specify.
After the DONE parameter has assumed the value TRUE, the connection has been assigned the desired property.
Connections created by OUC and Modbus instructions
The instructions of the OUC library ending with "_C" and the instructions of the MODBUS-TCP library establish connections by calling the instruction "TCON" internally. You can change such connections with "TCONSettings" in the same way as connections that you have created by explicitly calling "TCON".
Connection properties that can generally be read and specified
The following connection properties can be read and specified with the "TCONSettings" instruction:
How a TCP connection is terminated.
Relation between the protocol or the interface and the actual readable or specifiable connection properties
Not every protocol or interface can read or specify all of the above connection properties. The following table shows which connection properties are possible for the individual protocols or interfaces.
Protocol / interface | Terminating a connection |
|---|---|
Programmed connection: | Yes |
Configured connection: | No 1) |
TCP | Yes |
UDP | No 3) |
ISO on TCP | No |
CPU interface | Yes |
CP interface | No |
Virtual CP interface | Yes |
1) You cannot call "TDISCON" for a configured connection. Therefore, there is no way to end the connection in an orderly manner. 2) UDP is connectionless at the protocol level, so no termination is necessary. | |
Conflicts in the specification of connection properties
Each predefinable connection property is only permitted for specific protocols or interfaces. Therefore, there may be conflicts between your specification of a connection property and the desired protocol or interface. In this case "TCONSettings" returns the value W#16#8090 at the STATUS parameter.
How can you terminate a TCP connection?
You can terminate an existing TCP connection in the following two ways:
With a TCP-Reset (default)
The connection is closed after the frame has been sent with the RST bit set in the header. The associated resources are immediately deleted and enabled. Remaining data is neither sent nor transferred to the user program.
With a TCP-Finish
If you have set TCP-Finish as the way of terminating a connection and then call the instruction "TDISCON", the connection is closed from the user's point of view after the termination of "TDISCON" with DONE=TRUE, i.e. the connection ID is available again. In the lower layers in the TCP/IP stack of the module, however, the resources are still assigned for some time, as are the diagnostic objects belonging to the connection.
If you remove many connections using TCP-Finish and reserve (with "TCONSettings") or establish (with "TCON") connections before the timer for enabling the resources expires, this can result in a resource bottleneck.
Conditions for a TCP-Finish
The following conditions must be met in order for you to terminate a connection in an orderly manner using a TCP-Finish:
The protocol used is TCP.
The associated interface is located on the CPU.
The reason for the termination of the connection is the call of the "TDISCON" instruction.
Terminating a TCP connection during transition to STOP
During the transition to STOP, a TCP connection is always terminated with a TCP-Reset.
SDT for connection termination: TCON_TCPTermination
The SDT for the connection termination has the following structure:
Parameters | Data type | Start value | Description |
|---|---|---|---|
GracefulShutdown | Bool | FALSE |
|
Prior to the release of STEP 7 V13 SP1 and the S7-1200 V4.1 CPUs, the TCON, TDISCON, TSEND, and TRCV instructions could only work with connection parameters with structures according to TCON_Param. The general concepts apply to both sets of instructions. Refer to the individual legacy TCON, TDISCON, TSEND, and TRCV instructions for programming information.
STEP 7 provides different versions of the TCON, TDISCON, TSEND, and TRCV instructions. For information on instruction versions, refer to Use Instruction versions in the STEP 7 Information System.
Ethernet communication using TCP and ISO on TCP protocols
TSEND_C and TRCV_C instructions
To help simplify the programming of PROFINET/Ethernet communication, the TSEND_C instruction and the TRCV_C instruction combine the functionality of the TCON, TDISCON. TSEND and TRCV instructions:
TSEND_C combines the TCON, TDISCON and TSEND instructions.
TRCV_C combines the TCON, TDISCON and TRCV instructions.
The following instructions control the communication process:
TCON establishes the TCP/IP connection between the client and server (CPU) PC.
TSEND and TRCV send and receive data.
TDISCON breaks the connection.
The minimum size of data that you can transmit (TSEND) or receive (TRCV) is one byte; the maximum size is 8192 bytes. TSEND does not support the transmission of data from Boolean locations, and TRCV will not receive data into Boolean locations. For information transferring data with these instructions, see the section on data consistency.
TCON, TDISCON, TSEND, and TRCV operate asynchronously, which means that the job processing extends over multiple instruction executions. For example, you start a job for setting up and establishing a connection by executing an instruction TCON with parameter REQ = 1. Then you use additional TCON executions to monitor the job progress and test for job completion with parameter DONE.
The following table shows the relationships between BUSY, DONE, and ERROR. Use the table to determine the current job status:
BUSY | DONE | ERROR | Description |
|---|---|---|---|
TRUE | irrelevant | irrelevant | The job is being processed. |
FALSE | TRUE | FALSE | The job successfully completed. |
FALSE | FALSE | TRUE | The job was ended with an error. The cause of the error can be found in the STATUS parameter. |
FALSE | FALSE | FALSE | A new job was not assigned. |
TCON and TDISCON
Initializing the communication parameters
After you insert the TCON instruction, use the "Properties" of the instruction to configure the communication parameters. As you enter the parameters for the communication partners in the inspector window, STEP 7 enters the corresponding data in the instance DB for the instruction.
If you want to use a multi-instance DB, you must configure the DB on both CPUs.
LAD / FBD | Description | |
|---|---|---|
"TCON_DB"( req:=_bool_in_, ID:=_undef_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, connect:=_struct_inout_); | TCP and ISO on TCP: TCON initiates a communications connection from the CPU to a communication partner. | |
| "TDISCON_DB"( req:=_bool_in_, ID:=_word_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_); | TCP and ISO on TCP: TDISCON terminates a communications connection from the CPU to a communication partner. |
1 STEP 7 automatically creates the DB when you insert the instruction.
Parameter and type | Data type | Description | |
|---|---|---|---|
REQ | IN | Bool | Control parameter REQ starts the job by establishing the connection specified by ID. The job starts at rising edge. |
ID | IN | CONN_OUC (Word) | Reference to the connection to be established (TCON) or terminated (TDISCON) to the remote partner, or between the user program and the communication layer of the operating system. The ID must be identical to the associated parameter ID in the local connection description. Value range: W#16#0001 to W#16#0FFF |
CONNECT (TCON) | IN_OUT | TCON_Param | Pointer to the connection description |
DONE | OUT | Bool |
|
BUSY | OUT | Bool |
|
ERROR | OUT | Bool | Status parameters with the following values:
|
STATUS | OUT | Word | Status information including error information. (Refer to the Error and Status condition codes in the table below.) |
Both communication partners execute the TCON instruction to set up and establish the communication connection. You use parameters to specify the active and passive communication end point partners. After the connection is set up and established, it is automatically maintained and monitored by the CPU.
If the connection is terminated due to a line break or due to the remote communications partner, for example, the active partner attempts to re-establish the configured connection. You do not have to execute TCON again.
An existing connection is terminated and the set-up connection is removed when the TDISCON instruction is executed or when the CPU has gone into STOP mode. To set up and re-establish the connection, you must execute TCON again.
ERROR | STATUS | Description |
|---|---|---|
0 | 0000 | Connection was established successfully. |
0 | 7000 | No job processing active |
0 | 7001 | Start job processing; establishing connection (TCON) or terminating connection (TDISCON) |
0 | 7002 | Follow-on call (REQ irrelevant); establishing connection (TCON) or terminating connection (TDISCON) |
1 | 8086 | The ID parameter is outside the permitted address range. |
1 | 8087 | TCON: Maximum number of connections reached; no additional connection possible. |
1 | 809B | TCON: The local_device_id in the connection description does not match the CPU. |
1 | 80A1 | TCON: Connection or port is already occupied by user. |
1 | 80A2 | TCON: Local or remote port is occupied by the system. |
1 | 80A3 | Attempt being made to re-establish an existing connection (TCON) or terminate a non-existent connection (TDISCON). |
1 | 80A4 | TCON: IP address of the remote connection end point is invalid; it matches the local partner IP address. |
1 | 80A5 | TCON: Connection ID is already in use. |
1 | 80A7 | TCON: Communications error: You executed a TDISCON before the TCON completed. The TDISCON must first completely terminate the connection referenced by the ID. |
1 | 80B2 | TCON: The CONNECT parameter points to a data block that was generated with the attribute "Only store in load memory". |
1 | 80B4 | TCON: When using the ISO on TCP (connection_type = B#16#12) to establish a passive connection, condition code 80B4 alerts you that the TSAP entered did not conform to one of the following address requirements:
Valid ASCII characters are byte values from 20 to 7E (hexadecimal). |
1 | 80B5 | TCON: Connection type "13 = UDP" permits only passive connection establishment. |
1 | 80B6 | TCON: Parameter assignment error in CONNECTION_TYPE parameter of the SDT TCON_Param. |
1 | 80B7 | TCON: Error in one of the following parameters of the data block for connection description:
Note: When operating TCON in TCP passive mode, the LOCAL_TSAP_ID_LEN must be "2" and the REM_TSAP_ID_LEN must be "0". |
1 | 80B8 | TCON: Parameter in the local connection description and Parameter ID are different. |
1 | 80C3 | TCON: All connection resources are in use. |
1 | 80C4 | Temporary communications error:
|
TSEND and TRCV
When using PROFINET Open User communication, if you execute a TSEND instruction without a corresponding TRCV instruction executing on the remote device, then the TSEND instruction may reside indefinitely in a "Busy State", waiting for the TRCV instruction to receive the data. In this state, the TSEND instruction "Busy" output is set, and the "Status" output has a value of "0x7002". This condition may occur if you are transferring more than 4096 bytes of data. The issue is resolved at the next execution of the TRCV instruction.
LAD / FBD | SCL | Description |
|---|---|---|
"TSEND_DB"( req:=_bool_in_, ID:=_word_in_, len:=_udint_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, data:=_variant_inout_); | TCP and ISO on TCP: TSEND sends data through a communication connection from the CPU to a partner station. | |
"TRCV_DB"( en_r:=_bool_in_, ID:=_word_in_, len:=_udint_in_, ndr=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, rcvd_len=>_udint_out_, data:=_variant_inout_); | TCP and ISO on TCP: TRCV receives data through a communication connection from a partner station to the CPU. |
1 STEP 7 automatically creates the DB when you insert the instruction.
Parameter and type | Data type | Description | |
|---|---|---|---|
REQ | IN | Bool | TSEND: Starts the send job on a rising edge. The data is transferred from the area specified by DATA and LEN. |
EN_R | IN | Bool | TRCV: Enables the CPU to receive; with EN_R = 1, the TRCV is ready to receive. The receive job is processed. |
ID | IN | CONN_OUC (Word) | Reference to the associated connection. ID must be identical to the associated parameter ID in the local connection description. Value range: W#16#0001 to W#16#0FFF |
LEN | IN | UInt | Maximum number of bytes to be sent (TSEND) or received (TRCV):
|
DATA | IN_OUT | Variant | Pointer to send (TSEND) or receive (TRCV) data area; data area contains the address and length. The address refers to I memory, Q memory, M memory, or a DB. |
DONE | OUT | Bool | TSEND:
|
NDR | OUT | Bool | TRCV:
|
BUSY | OUT | Bool |
|
ERROR | OUT | Bool | ERROR = 1: Error occurred during processing. STATUS provides detailed information on the type of error |
STATUS | OUT | Word | Status information including error information. (Refer to the Error and Status condition codes in the table below.) |
RCVD_LEN | OUT | Int | TRCV: Amount of data actually received in bytes |
The TSEND instruction requires a low-to-high transition at the REQ input parameter to start a send job. The BUSY parameter is then set to 1 during processing. Completion of the send job is indicated by either the DONE or ERROR parameters being set to 1 for one scan. During this time, any low-to-high transition at the REQ input parameter is ignored.
TRCV Operations
The TRCV instruction writes the received data to a receive area that is specified by the following two variables:
Pointer to the start of the area
Length of the area or the value supplied at the LEN input if not 0
The default setting of the LEN parameter (LEN = 0) uses the DATA parameter to determine the length of the data being transmitted. It is recommended that the data transmitted by the TSEND instruction be the same size as the DATA parameter of the TRCV instruction.
If using the default setting of the LEN parameter and it is necessary to send the data in segments smaller than the DATA parameter size, the following applies. It is recommended to keep the EN_R bit high until the corresponding TSEND transfers the appropriate amount of data to fill the TRCV DATA parameter. If the size of the data transmitted from TSEND does not equal the TRCV DATA parameter size, TRCV remains in a busy status (status code: 7002) while the EN_R bit is high until the overall size of the data transmitted from TSEND equals the TRCV DATA parameter size. If the EN_R bit of TRCV is pulsed, it needs to be pulsed the same number of times as TSEND is executed to receive the data.
The TRCV DATA parameter buffer does not display the new data received until the data size equals the DATA parameter buffer size.
As soon as all the job data has been received, TRCV transfers it to the receive area and sets NDR to 1.
Protocol variant | Entering the data in the receive area | Parameter "connection_type" | Value of the LEN parameter | Value of the RCVD_LEN parameter (bytes) |
|---|---|---|---|---|
TCP | Ad hoc mode | B#16#11 | 65535 | 1 to 1460 |
TCP | Data reception with specified length | B#16#11 | 0 (recommended) or 1 to 8192, except 65535 | 1 to 8192 |
ISO on TCP | Ad hoc mode | B#16#12 | 65535 | 1 to 1460 |
ISO on TCP | protocol-controlled | B#16#12 | 0 (recommended) or 1 to 8192, except 65535 | 1 to 8192 |
Ad hoc mode
The "ad hoc mode" exists with the TCP and ISO on TCP protocol variants. You set "ad hoc mode" by assigning "65535" to the LEN parameter. The receive area is identical to the area formed by DATA. The length of the received data will be output to the parameter RCVD_LEN. Immediately after receiving a block of data, TRCV enters the data in the receive area and sets NDR to 1.
If you store the data in an "optimized" DB (symbolic only), you can receive data only in arrays of Byte, Char, USInt, and SInt data types.
Importing of S7-300/400 STEP 7 projects containing "ad hoc mode" into the S7-1200
In S7-300/400 STEP 7 projects, "ad hoc mode" is selected by assigning "0" to the LEN parameter. In the S7-1200, you set "ad hoc mode" by assigning "65535" to the LEN parameter.
If you import an S7-300/400 STEP 7 project containing "ad hoc mode" into the S7-1200, you must change the LEN parameter to "65535".
TSEND and TRCV Error and Status condition codes
ERROR | STATUS | Description |
|---|---|---|
0 | 0000 |
|
0 | 7000 |
|
0 | 7001 |
|
0 | 7002 |
|
1 | 8085 |
|
1 | 8086 | The ID parameter is not in the permitted address range. |
1 | 8088 | The LEN parameter is larger than the memory area specified in DATA. |
1 | 80A1 | Communications error:
|
1 | 80C3 | Internal lack of resources: A block with this ID is already being processed in a different priority class. |
1 | 80C4 | Temporary communications error:
|
Connection Ethernet protocols
Every CPU has an integrated PROFINET port, which supports standard PROFINET communications. The TSEND_C, TRCV_C, TSEND and TRCV instructions all support the TCP and ISO on TCP Ethernet protocols.
Refer to "Device Configuration: Configuring the Local/Partner connection path" for more information.
The "T_RESET" instruction terminates and then re-establishes an existing connection:
LAD / FBD | SCL | Description |
|---|---|---|
 | "T_RESET_DB"( req:=_bool_in_, id:=_word_in_, done=>_bool_out_, error=>_bool_out_, status=>_word_out_); | Use the T_RESET instruction to terminate and then re-establish an existing connection. |
The local end points of the connection are retained. They are generated automatically:
If a connection has been configured and loaded to the CPU.
If a connection has been generated by the user program, for example, by calling the instruction "TCON".
The "T_RESET" instruction can be executed for all connection types regardless of whether the local interface of the CPU or the interface of a CM/CP was used for the connection. An exception to this is connections for data transfer in ad-hoc mode with TCP, as such connections cannot be referenced with a connection ID.
Once the instruction "T_RESET" has been called using the REQ parameter, the connection specified with the ID parameter is terminated and, if necessary, the data send and receive buffer cleared. Canceling the connection also cancels any data transfer in progress. There is therefore a risk of losing data if data transfer is in progress. The CPU defined as the active connection partner will then automatically attempt to restore the interrupted communication connection. You therefore do not need to call the "TCON" instruction to re-establish the communication connection.
The output parameters DONE, BUSY, and STATUS indicate the status of the job.
Data types for the parameters
The following table shows the parameters of the "T_RESET" instruction:
Parameter | Declaration | Data type | Memory area | Description |
|---|---|---|---|---|
REQ | Input | BOOL | I, Q, M, D, L, T, C or constant | Control parameter REQUEST starts the job for terminating the connection specified by ID. The job starts on a rising edge. |
ID | Input | CONN_OUC (WORD) | L, D or constant | Reference to the connection to the passive partner which is to be terminated. ID must be identical to the corresponding parameter ID in the local connection description. Range of values: W#16#0001 to W#16#0FFF |
DONE | Output | BOOL | I, Q, M, D, L | Status parameter DONE
|
BUSY | Output | BOOL | I, Q, M, D, L | Status parameter BUSY
|
ERROR | Output | BOOL | I, Q, M, D, L | Status parameter ERROR
|
STATUS | Output | WORD | I, Q, M, D, L | Status parameter STATUS Error information (see "STATUS parameter" table). |
STATUS parameter
Error bit | STATUS* (W#16#...) | Description |
|---|---|---|
0 | 0000 | No error. |
0 | 0001 | Connection has not been established. |
0 | 7001 | Connection termination launched. |
0 | 7002 | Connection being terminated. |
1 | 8081 | Unknown connection specified at the ID parameter. |
The "T_DIAG" instruction checks the status of a connection and reads further information on the local end point of this connection:
LAD / FBD | SCL | Description |
|---|---|---|
"T_DIAG_DB"( req:=_bool_in_, id:=_word_in_, done=>_bool_out_, error=>_bool_out_, status=>_dword_out_); | Use the T_DIAG instruction to check the status of a connection and read further information on the local end point of this connection. |
The "T_DIAG" instruction operates as follows:
The connection is referenced by the ID parameter. You can read both connection end points configured in the connection editor and programmed connection end points (e.g. with the "TCON" instruction).
Temporary connection end points (for example end points created when you connect to an engineering station) cannot be diagnosed, as no connection ID is generated in this process.
The connection information read is stored in a structure referenced by the RESULT parameter.
The output parameter STATUS indicates whether it was possible to read the connection information. The connection information in the structure at the RESULT parameter is only valid if the "T_DIAG" instruction has been completed with STATUS = W#16#0000 and ERROR = FALSE.
Connection information cannot be evaluated if an error occurs.
Possible connection information
The "TDiag_Status" structure can be used to read the connection information at the RESULT parameter. The TDiag_Status structure only contains the most important information about a connection end point (for example, the protocol used, the connection status, and the number of data bytes sent or received).
The structure and parameters of the TDiag_Status structure are described below (see the "TDIAG_Status structure" table).
Data types for the parameters
The following table shows the parameters of the "T_DIAG" instruction:
Parameter | Declaration | Data type | Memory area | Description |
|---|---|---|---|---|
REQ | Input | BOOL | I, Q, M, D, L, T, C or constant | Starts the instruction to check the connection specified in the ID parameter when there is a positive edge. |
ID | Input | CONN_OUC (WORD) | L, D or constant | Reference to the assigned connection. Range of values: W#16#0001 to W#16#0FFF |
RESULT | InOut | VARIANT | D | Pointer to the structure in which the connection information is stored. The structure TDiag_Status can be used at the RESULT parameter (for a description, see the "TDIAG_Status structure" table). |
DONE | Output | BOOL | I, Q, M, D, L | Status parameter:
|
BUSY | Output | BOOL | I, Q, M, D, L | Status parameter:
|
ERROR | Output | BOOL | I, Q, M, D, L | Status parameter:
|
STATUS | Output | WORD | I, Q, M, D, L | Status of the instruction |
Parameters BUSY, DONE, and ERROR
You can check the status of "T_DIAG" instruction execution with the BUSY, DONE, ERROR and STATUS parameters. The BUSY parameter indicates the processing status. You use the DONE parameter to check whether or not an instruction has been executed successfully. The ERROR parameter is set if errors occur during execution of "T_DIAG".
The following table shows the relationship between the BUSY, DONE, and ERROR parameters:
BUSY | DONE | ERROR | Description |
|---|---|---|---|
1 | - | - | The instruction is being processed. |
0 | 1 | 0 | The instruction has been executed successfully. The data in the structure referenced by RESULT are only valid if this is the case. |
0 | 0 | 1 | Instruction completed with an error. The cause of the error is output at the STATUS parameter. |
0 | 0 | 0 | No new instruction has been assigned. |
STATUS parameter
The following table shows the meaning of the values at the STATUS parameter:
Error bit | STATUS* (W#16#...) | Description |
|---|---|---|
0 | 0000 | The instruction "T_DIAG" has been executed successfully. The data in the structure referenced at the RESULT parameter can be evaluated. |
0 | 7000 | No instruction processing active. |
0 | 7001 | Instruction processing launched. |
0 | 7002 | Connection information is being read (REQ parameter irrelevant). |
1 | 8086 | The value at the ID parameter is outside the valid range (W#16#0001 ... W#16#0FFF). |
1 | 8089 | The RESULT parameter points to an invalid data type (structures TDIAG_Status and TDIAG_StatusExt only). |
1 | 80A3 | The ID parameter references a connection end point which does not exist. With programmed connections, this error can also occur after the "TDISCON" instruction is called. |
1 | 80B1 | The RESULT parameter was changed before the execution of T_DIAG was completed. A change of RESULT is not permitted during the execution of T_DIAG. |
1 | 80C4 | Internal error. Access to the connection end point is temporarily unavailable. |
TDIAG_Status Structure
The table below details the form of the TDIAG_Status structure. The value of each element is only valid if the instruction has been executed without errors. If an error occurs, the content of the parameters will not change:
Name | Data type | Description |
|---|---|---|
The following parameters are in the TDIAG_Status structure: | ||
InterfaceID | HW_ANY | Interface ID (LADDR) of the CPU or the CM/CP. |
ID | CONN_OUC | ID of the connection diagnosed. Following a successful call, the value of this element is identical to the parameter ID of the "T_DIAG" instruction. |
ConnectionType | BYTE | Protocol type used for connection:
|
ActiveEstablished | BOOL |
|
State | BYTE | Current status of the connection end point
|
Kind | BYTE | Mode of the connection end point:
|
SentBytes | UDINT | Number of data bytes sent. |
ReceivedBytes | UDINT | Number of data bytes received. |
You use the TMAIL_C instruction to send an email using the Ethernet interface of the S7-1200 CPU.
The TMAIL_C instruction has two functionalities:
Email over the CPU Interface
Email over a CP Interface
To use the TMAIL_C instruction, you must satisfy these prerequisites:
You have configured the hardware
The network infrastructure allows for a communication connection to the mail server
LAD / FBD | SCL | Description |
|---|---|---|
"TMAIL_C_DB"( req:=_bool_in_, to_s:=_string_in_, cc:=_string_in_, subject:=_string_in_, text:=_string_in_, attachment:=_variant_in_, attachment_name:=_string_in_, mail_addr_param:=_string_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_); | The TMAIL_C instruction sends an email using the Ethernet interface of the S7-1200 CPU. |
1 STEP 7 automatically creates the DB when you insert the instruction.
You define the content of the email and the connection data, using the following parameters:
Recipient addresses with the TO_S and CC parameters
Content of the email with the SUBJECT and TEXT parameters
Optional attachment using VARIANT pointers at the ATTACHMENT and ATTACHMENT_NAME parameters
Connection data, addressing and authentication for the mail server at the MAIL_ADDR_PARAM parameter
As of TMAIL_C version V6.0 or later and S7-1200 CPU firmware version V4.x, you can use the instruction TMAIL_C to send an email with secure communication over an integrated Ethernet port of your S7-1200 CPU. You define the data required for the sending process at the MAIL_ADDR_PARM parameter with the TMail_V4_SEC or TMail_QDN_SEC SDT.
You cannot send an SMS directly with the TMAIL_C instruction. Whether or not the mail server can forward an email as an SMS depends on your telecommunications provider.
Operation of the instruction
You start the sending of an email with an edge change from "0" to "1" for the REQ parameter.
The TMAIL_C instruction indicates the job status by the "BUSY", "DONE", "ERROR" and "STATUS" output parameters.
The TMAIL_C instruction works asynchronously, which means its execution extends over multiple calls. You must specify an instance when you call the instruction "TMAIL_C".
In the following cases, the connection to the mail server will be lost:
If the CPU switches to STOP while TMAIL_C instruction is active
If communication problems occur at the Industrial Ethernet bus
In this case, the transfer of the email will be interrupted and it will not reach its recipient.
The connection is also canceled after the instruction has successfully executed and sent the email.
Changing user programs
Change the parts of the user program that directly affect calls of TMAIL_C only when:
The CPU is in "STOP" mode.
No email is being sent (REQ = 0 and BUSY = 0).
This relates to deleting and replacing program blocks that contain TMAIL_C calls or calls for the instance of TMAIL_C.
Ignoring this restriction can tie up connection resources. The automation system can change to an undefined status with the TCP/IP communication functions via Industrial Ethernet.
Perform a warm or cold restart of the CPU after transferring changes.
Property damage can occur if the TCP/IP communication functions change to an undefined status.
Data consistency
The TO_S, CC, SUBJECT, TEXT, ATTACHMENT and MAIL_ADDR_PARAM parameters are applied by the TMAIL_C instruction while it is running, which means that they may only be changed after the job has been completed (BUSY = 0).
SMTP authentication
Authentication refers to a procedure for verifying identity, for example, with a password query.
If you are using the S7-1200 CPU interface, the instruction TMAIL_C supports the SMTP authentication procedure AUTH-LOGIN which is required by most mail servers. For information about the authentication procedure of your mail server, refer to your mail server manual or the Web site of your Internet service provider.
Before you can use the AUTH-LOGIN authentication procedure, the TMAIL_C instruction requires the user name with which it is to log on to the mail server. This user name corresponds to the user name with which you set up a mail account on your mail server. It is transferred via the UserName parameter to the structure at parameter MAIL_ADDR_PARAM.
If no user name is specified at the MAIL_ADDR_PARAM parameter, the AUTH-LOGIN authentication procedure is not used. The email is then sent without authentication.
To log on, the TMAIL_C instruction also requires the associated password. This password corresponds to the password you specified when you set up your mail account. It is transferred via the PassWord parameter to the structure at parameter MAIL_ADDR_PARAM.
Data types for the parameters
The following table shows the parameters of the TMAIL_C instruction:
Parameter | Declaration | Data type | Memory area | Description |
|---|---|---|---|---|
REQ | Input | BOOL | I, Q, M, D, L, T, C or constant | Control parameter REQUEST: Activates the sending of an email upon a rising edge. |
Input | STRING | D | Recipient addresses STRING with a maximum length of 180 characters (bytes). For the email address format, please see the example in the parameter description. | |
Input | STRING | D | CC recipient addresses (optional) STRING with a maximum length of 180 characters (bytes). Same email address format as for the TO_S parameter. If you assign an empty string here, the instruction does not send the email to a CC recipient. | |
SUBJECT | Input | STRING | D | Subject of the email STRING with a maximum length of 180 characters (bytes). |
TEXT | Input | STRING | D | Text of the email (optional) STRING with a maximum length of 180 characters (bytes). If you assign an empty string at this parameter, the instruction sends the email without text. |
ATTACHMENT | Input | VARIANT | D | Email attachment (optional) Reference to a char/byte/word/double word/string field (ArrayOfChar, ArrayOfByte, ArrayOfWord, ArrayOfDWord, or String) with a maximum length of 64 KB. Note: If you assign no value or an empty string to the ATTACHMENT parameter, the instruction sends the email without an attachment. |
ATTACHMENT_NAME | Input | VARIANT | D | Email attachment name (optional) Reference to a character string with a maximum length of 50 characters (bytes) to define the file name of the attachment. If an empty string is assigned at this parameter, the email attachment will be sent with the file name "attachment.bin". Using the AttachmentName parameter, you can assign the attachment name that appears when the communication partner receives the email. The TMail_FileReference SDT automatically uses the FileName parameter for the AttachmentName parameter. If using the TMail_FileReference SDT, the AttachmentName parameter does not apply. Leave it blank. If you enter data in the AttachmentName parameter when using the TMail_FileReference SDT, the TMAIL_C instruction produces an error. Refer to "Error condition codes, SFB_STATUS parameter of the instance DB" for further information. |
Input | VARIANT | D | Connection parameter and address of the email server To define the connection parameters, use the TMail_V4, TMail_FQDN, TMail_V4_SEC, or TMail_QDN_SEC SDT (see parameter description). | |
Output | BOOL | I, Q, M, D, L | Status parameter
| |
Output | BOOL | I, Q, M, D, L | Status parameter
| |
Output | BOOL | I, Q, M, D, L | Status parameter
| |
Output | WORD | I, Q, M, D, L | Status parameter Return value or error information of the TMAIL_C instruction (see parameter description). |
Optional parameters
The instruction sends the optional parameters CC, TEXT, and ATTACHMENT only if the corresponding parameters contain a string of length > 0.
At the MAIL_ADDR_PARAM parameter, you define the connection for sending the email and save the e-mail server address and login details.
The system data type (SDT) you use at the MAIL_ADDR_PARAM parameter depends on the format in which the email server is to be addressed:
SDT | Description | Interface support |
|---|---|---|
TMail_V4 | Addressing by IP address (IPv4) | CPU and CP |
TMail_V6 | Addressing by IP address (IPv6) | CP |
TMail_FQDN | Addressing by Fully Qualified Domain Name (FQDN) | CP |
TMail_V4_SEC | Secure addressing by IP address (IPv4) | CPU and CP |
TMail_V6_SEC | Secure addressing by IP address (IPv6) | CP |
TMail_QDN_SEC | Secure addressing by Fully Qualified Domain Name (FQDN) | CPU and CP |
TMail_V4: Addressing the mail server by IP address (IPv4)
Parameter | Data type | Description | ||
|---|---|---|---|---|
TMail_v4 | Struct | |||
InterfaceId | LADDR | Hardware identifier of the Ethernet interface | ||
ID | CONN_OUC | Connection ID | ||
ConnectionType | BYTE | Connection type. Select 16#20 as the connection type for IPv4. | ||
ActiveEstablished | BOOL | Active/passive connection establishment. The CPU is always the SMTP client. | ||
CertIndex | BYTE | =0: SMTP used (Simple Mail Transfer Protocol). SMTP must be used if the email is being sent via the interface of an S7‑1200 CPU. ≠0: SMTPS used to secure the connection (CP interface) | ||
WatchDogTime | TIME | Execution watchdog. Use this parameter to define the maximum execution time for the send operation. This value determines how long the TMAIL_C instruction can remain in execution before a timeout is reached and the TMAIL_C instruction execution is stopped. As of TMAIL_C version V6.0, a WatchDogTime value of zero is now allowed, which signals the TMAIL_C instruction to disable the timer during execution. You can still enter a non-zero value for the WatchDogTime to make execution of the TMAIL_C instruction more deterministic. Note: Connection establishment can take longer (approx. one minute) if the connection is slow. When you specify the WatchDogTime parameter, remember to allow for the time required to establish the connection. | ||
MailServerAddress | IP_v4 | IP address of the mail server. IPv4 in the following format: XXX.XXX.XXX.XXX (decimal). Example: 192.142.131.237 | ||
UserName | STRING[254] | Mail server login name | ||
PassWord | STRING[254] | Mail server password | ||
From | EMAIL_ADDR | Email sender address, which is defined using the following two STRING parameters. For example: "myname@mymailserver.com". | ||
LocalPartPlusAtSign | STRING[64] | Local part of sender address, including @ sign. Example: "myname@". | ||
FullQualifiedDomainName | STRING[254] | Fully Qualified Domain Name (FQDN for short) of the mail server. Example: "mymailserver.com". | ||
TMail_V6: Addressing the mail server by IP address to IPv6
Parameter | Data type | Description | ||
|---|---|---|---|---|
TMail_V6 | Struct | |||
InterfaceId | LADDR | Hardware identifier of the interface | ||
ID | CONN_OUC | Connection ID | ||
ConnectionType | BYTE | Connection type. Select 16#21 as the connection type for IPv6. | ||
ActiveEstablished | BOOL | Status bit. Set to "1" once the connection is established. | ||
CertIndex | BYTE | =0: SMTP used (Simple Mail Transfer Protocol). SMTP must be used if the e-mail is being sent via the interface of an S7-1500 CPU. ≠0: SMTPS used to secure the connection before it is established (with CPs/CMs). You use the CertIndex parameter to specify the certificate to be used (see "Project navigation" > "Global security settings" > "Certificate manager"). | ||
WatchDogTime | TIME | Execution watchdog. Use this parameter to define the maximum execution time for the send operation. Note: Connection establishment can take longer (approx. one minute) if the connection is slow. When you specify the WATCH_DOG_TIME parameter, remember to allow for the time required to establish the connection. The connection is terminated once the specified time has elapsed. | ||
MailServerAddress | IP_V6 | IP address of the mail server (IPv6) in the following format: XXXX.XXXX.XXXX.XXXX.XXXX.XXXX.XXXX.XXXX (hexadecimal). The address is divided into 8 blocks of 2 bytes each (16 bytes in total). Example: 2001:db8:1f11:08d3:290:27ff:0370:2093 | ||
UserName | STRING[254] | Mail server login name | ||
PassWord | STRING[254] | Mail server password | ||
From | EMAIL_ADDR | E-mail sender address, which is defined using the following two STRING parameters. For example: "myname@mymailserver.com". | ||
LocalPartPlusAtSign | STRING[64] | Local part of sender address, including @ sign. Example: "myname@" | ||
FullQualifiedDomainName | STRING[254] | Fully Qualified Domain Name (abbreviated to FQDN) of the mail server. Example: "mymailserver.com" | ||
TMail_FQDN : Addressing the mail server by FQDN
Parameter | Data type | Description | ||
|---|---|---|---|---|
TMail_FQDN | Struct | |||
InterfaceId | LADDR | Hardware identifier of the Ethernet interface | ||
ID | CONN_OUC | Connection ID | ||
ConnectionType | BYTE | Connection type. Select 16#22 as the connection type for FQDN. | ||
ActiveEstablished | BOOL | Active/passive connection establishment. A Communications Processor (CP) is always the SMTP client. | ||
CertIndex | BYTE | =0: SMTP used (Simple Mail Transfer Protocol). ≠0: SMTPS used to secure the connection before it is established (CP interface). CertIndex specifies the certificate to be used. | ||
WatchDogTime | TIME | Execution watchdog. Use this parameter to define the maximum execution time for the send operation. Note: Connection establishment can take longer (approx. one minute) if the connection is slow. When you specify the WatchDogTime parameter, remember to allow for the time required to establish the connection. | ||
MailServerAddress | STRING[254] | FQDN (Fully Qualified Domain Name) of the mail server. The mail server is addressed using the FQDN. Example: "www.mymailserver.com." | ||
UserName | STRING[254] | Mail server login name | ||
PassWord | STRING[254] | Mail server password | ||
From | Struct | Email sender address, which is defined using the following two STRING parameters. For example: "myname@mymailserver.com". | ||
LocalPartPlusAtSign | STRING[64] | Local part of sender address, including @ sign. Example: "myname@". | ||
FullQualifiedDomainName | STRING[254] | Fully Qualified Domain Name (FQDN for short) of the mail server. Example: "mymailserver.com". | ||
TMail_V4_SEC: Addressing the mail server by IP address (IPv4)
Parameter | Data type | Description | ||
|---|---|---|---|---|
TMail_V4_SEC | Struct | |||
InterfaceId | LADDR | Hardware identifier of the Ethernet interface Value range:
| ||
ID | CONN_OUC | Reference to the connection: Value range:
| ||
ConnectionType | BYTE | Connection type. Select 16#20 as the connection type for IPv4. | ||
ActiveEstablishment | BOOL | Active/passive connection establishment. The CPU is always the SMTP client. | ||
WatchDogTime | TIME | Execution watchdog. Use this parameter to define the maximum execution time for the send operation. This value determines how long the TMAIL_C instruction can remain in execution before a timeout is reached and the TMAIL_C instruction execution is stopped. As of TMAIL_C version V6.0, a WatchDogTime value of zero is now allowed, which signals the TMAIL_C instruction to disable the timer during execution. You can still enter a non-zero value for the WatchDogTime to make execution of the TMAIL_C instruction more deterministic. Note: Connection establishment can take longer (approx. one minute) if the connection is slow. When you specify the WatchDogTime parameter, remember to allow for the time required to establish the connection. | ||
MailServerAddress | IP_V4 | IP address of the mail server intrinsic in IPv4 format: XXX.XXX.XXX.XXX (decimal place) Example: 192.142.131.237 | ||
UserName | STRING[254] | User name You must use your "user name" to access your email inbox in order to identify yourself as the owner of the email inbox to the email provider. | ||
PassWord | STRING[254] | User password You must use your "password" to access your email inbox in order to identify yourself as the owner of the email inbox to the email provider. | ||
From | EMAIL_ADDR | Email sender address, which is defined using the following two STRING parameters. For example: "myname@mymailserver.com" | ||
LocalPartPlusAtSign | STRING[64] | Local part of sender address, including @ sign. Example: "myname@" | ||
FullQualifiedDomainName | STRING[254] | Fully Qualified Domain Name (abbreviated to FQDN) of the mail server. Example: "mymailserver.com" | ||
RemotePort | UINT | TCP port of the mail server | ||
ActivateSecureConn | BOOL | 0: SMTP connection (non-secure). In this case, the following parameters are irrelevant. 1: Secure SMTP connection | ||
ExtTLSCapabilities | BYTE | Not currently used | ||
TLSServerCertRef | UDINT | Reference to the X.509 V3 (CA) certificate of the mail server, which the TLS client uses to validate the authentication of the TLS server | ||
TMail_V6_SEC: Addressing of the e-mail server via the IP address in IPv6 format
Parameter | Data type | Description | ||
|---|---|---|---|---|
TMail_V6_SEC | Struct | |||
InterfaceId | LADDR | Hardware identifier of the Ethernet interface | ||
ID | CONN_OUC | Connection ID | ||
ConnectionType | BYTE | Connection type. Select 16#21 as the connection type for IPv6. | ||
ActiveEstablishment | BOOL | Active/passive connection establishment. Because the CP is always the SMTP client, this parameter must be set to "1". | ||
WatchDogTime | TIME | Execution watchdog. Use this parameter to define the maximum execution time for the send operation. Note: Connection establishment can take longer (approx. one minute) if the connection is slow. When you specify the WatchDogTime parameter, remember to allow for the time required to establish the connection. The connection is terminated once the specified time has elapsed. | ||
MailServerAddress | IP_V6 | IP address of the mail server in IPv6 format: XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX (hexadecimal). The address is divided into 8 blocks of 2 bytes each (16 bytes in total). Example: 2001:db8:1f11:08d3:290:27ff:0370:2093 | ||
UserName | STRING[254] | User name. This is required if users wants to access their email inbox in order to identify themselves as the owner of the email inbox to the email provider. | ||
PassWord | STRING[254] | User password. This is required if users wants to access their email inbox in order to identify themselves as the owner of the email inbox to the email provider. | ||
From | EMAIL_ADDR | E-mail sender address, which is defined using the following two STRING parameters. For example: "myname@mymailserver.com". | ||
LocalPartPlusAtSign | STRING[64] | Local part of sender address, including @ sign. Example: "myname@" | ||
FullQualifiedDomainName | STRING[254] | Fully Qualified Domain Name (abbreviated to FQDN) of the mail server. Example: "mymailserver.com" | ||
RemotePort | UINT | TCP port of the mail server | ||
ActivateSecureConn | BOOL | 0: SMTP connection (non-secure). In this case, the following parameters are irrelevant. 1: Secure SMTP connection | ||
ExtTLSCapabilities | BYTE | Not currently used | ||
TLSServerCertRef | UDINT | Reference to the X.509 V3 (CA) certificate of the mail server, which is used by the TLS client to validate the authentication of the TLS server. | ||
TMail_QDN_SEC: Addressing the mail server by FQDN
Parameter | Data type | Description | ||
|---|---|---|---|---|
TMail_QDN_SEC | Struct | |||
InterfaceId | LADDR | Hardware identifier of the Ethernet interface Value range:
| ||
ID | CONN_OUC | Reference to the connection: Value range:
| ||
ConnectionType | BYTE | Connection type. Select 16#22 as the connection type for FQDN. | ||
ActiveEstablishment | BOOL | Active/passive connection establishment. The CPU is always the SMTP client. | ||
WatchDogTime | TIME | Execution watchdog. Use this parameter to define the maximum execution time for the send operation. This value determines how long the TMAIL_C instruction can remain in execution before a timeout is reached and the TMAIL_C instruction execution is stopped. As of TMAIL_C version V6.0, a WatchDogTime value of zero is now allowed, which signals the TMAIL_C instruction to disable the timer during execution. You can still enter a non-zero value for the WatchDogTime to make execution of the TMAIL_C instruction more deterministic. Note: Connection establishment can take longer (approx. one minute) if the connection is slow. When you specify the WatchDogTime parameter, remember to allow for the time required to establish the connection. | ||
MailServerQDN | STRING[254] | FQDN (Fully Qualified Domain Name) of the mail server. The mail server is addressed using the fully qualified domain name, which must end with "." Example: "www.mymailserver.com." | ||
UserName | STRING[254] | User name You must use your "user name" to access your email inbox in order to identify yourself as the owner of the email inbox to the email provider. | ||
PassWord | STRING[254] | User password You must use your "password" to access your email inbox in order to identify yourself as the owner of the email inbox to the email provider. | ||
From | EMAIL_ADDR | Email sender address, which is defined using the following two STRING parameters. For example: "myname@mymailserver.com" | ||
LocalPartPlusAtSign | STRING[64] | Local part of sender address, including @ sign. Example: "myname@" | ||
FullQualifiedDomainName | STRING[254] | Fully Qualified Domain Name (abbreviated to FQDN) of the mail server. Example: "mymailserver.com" | ||
RemotePort | UINT | TCP port of the mail server | ||
ActivateSecureConn | BOOL | 0: SMTP connection (non-secure). In this case, the following parameters are irrelevant. 1: Secure SMTP connection | ||
ExtTLSCapabilities | BYTE | Not currently used | ||
TLSServerCertRef | UDINT | Reference to the X.509 V3 (CA) certificate of the mail server, which the TLS client uses to validate the authentication of the TLS server | ||
For TMAIL_C instructions prior to version 6.0 and S7-1200 CPU firmware V4.4, the following rules apply when entering the TO_S and CC parameters:
Enter a space and an opening pointed bracket "<" before each address.
Enter a closing pointed bracket ">" after each address.
Enter a comma between the addresses in TO and CC.
The following are examples of these TO_S and CC parameter strings:
<wenna@mydomain.com>, <ruby@mydomain.com>
<admin@mydomain.com>, <judy@mydomain.com>
As of TMAIL_C instruction version 6.0 or later and S7-1200 CPU firmware V4.x, only the following rule applies when entering the parameters:
Enter a comma or semicolon between the addresses in TO and CC.
The following are examples of these TO_S and CC parameter strings:
wenna@mydomain.com, ruby@mydomain.com
admin@mydomain.com, judy@mydomain.com
For runtime and memory space reasons, the TMAIL_C instruction does not perform a syntax check of parameter TO_S or CC.
The output parameters DONE, BUSY and ERROR are each displayed for only one cycle if the status of the BUSY output parameter changes from "1" to "0".
The following table shows the relationship between DONE, BUSY, and ERROR. Using this table, you can determine the current status of the instruction "TMAIL_C and when the sending of the email is complete.
DONE | BUSY | ERROR | Description |
|---|---|---|---|
0 | 1 | 0 | The job is being processed. |
1 | 0 | 0 | Job successfully completed. |
0 | 0 | 1 | The job ended with an error. The cause of the error can be found in the STATUS parameter. |
0 | 0 | 0 | The TMAIL_C instruction was not assigned a (new) job. |
As of TMAIL_C version V6.0 or later and S7-1200 CPU firmware version V4.x, you can add and access the TMail_FileReference SDT using the Attachment parameter of the TMAIL_C instruction. You can then address a file path on the SIMATIC memory card (SMC). If no memory card is present, you can still access the recipe and data log directories on the PLC's internal load storage.
The TMail_FileReference SDT automatically uses the FileName parameter for the AttachmentName parameter.
TMail_FileReference SDT
The TMail_FileReference SDT consists of two parameters, both of which are SIMATIC strings:
In the DirectoryPath parameter, you can address the directory of the desired file.
The FileName parameter denotes the name of the file and the extension (if applicable) of the file that you wish to access in the directory, which is specified by the previous parameter.
The TMAIL_C instruction restricts you to the DataLogs, Recipes, or UserFiles directories when addressing the DirectoryPath parameter. You can also address subdirectories within these directories.
Beyond the above base directory restriction, the File Addressing Rules section below prescribes the rules that you must follow to address subdirectories and file names.
The size of the file that you can send is not restricted by the TMAIL_C instruction. You should keep this in mind when constructing your program.
File Addressing Rules
There are certain rules that must be followed to properly address a file using the TMail_FileReference SDT with the TMAIL_C instruction. The following subsections describe the specifics for the DirectoryPath and FileName, respectively. In general, the following applies to both parameters in the TMail_FileReference SDT and failure to follow these rules results in the TMAIL_C instruction producing an error status:
You cannot use an empty string as a subdirectory or file name.
You cannot use any ASCII control characters (Hex Range: 0x00 to 0x1F) in either parameter string.
You cannot use the following reserved characters in either parameter string:
< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash) (This character is allowed in the DirectoryPath as a separator)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)
No subdirectory or file name can end with a space or a period.
DirectoryPath
When entering the desired directory into the DirectoryPath parameter of the SDT, keep the following in mind. The root directory is inferred by the PLC’s firmware logic and is not necessary for you to know. You can optionally enter a leading and trailing slash (/). If the user omits either slash, the firmware will automatically add these to the path. Thus, each of the following DirectoryPath entries are valid:
/DataLogs/
/DataLogs
DataLogs/
DataLogs
It is also possible to access a path at a greater depth than the base directory by using the following form, '/DataLogs/dir1/' where each (/) denotes a new directory. The maximum depth is eight, including the root directory.
In addition to the rules set forth in the File Addressing Rules section, you must be aware that the use of relative paths is strictly prohibited. Thus, '/DataLogs/' is an illegal path name. In addition, the use of a period in any subdirectory component to represent the current directory is prohibited (for example, '/DataLogs/').
FileName
When utilizing the FileName parameter of the SDT, keep in mind the rules laid out in the File Addressing Rules section. In addition to this, you must also be aware that the PLC’s operating system limits the file name to less than 60 characters. If you attempt to address a file name greater than or equal to 60 characters, the TMAIL_C instruction aborts its operation and produces an error.
Aside from these exceptions, you can attach any file regardless of size or extension. The addressed file may or may not include a file extension.
The following table shows the return values of TMAIL_C at the STATUS parameter:
Return value STATUS* (W#16#...): | Explanation | Notes |
|---|---|---|
0000 | The processing of TMAIL_C was completed without errors. | Error-free completion of TMAIL_C does not mean that the email sent will necessarily arrive. Incorrectly entering the recipient addresses does not generate a status error of the TMAIL_C instruction. In this case, there is no guarantee that the email will be sent to other recipients, even if these were entered correctly. |
7001 | TMAIL_C is active (BUSY = 1). | First call: Job triggered. |
7002 | TMAIL_C is active (BUSY = 1). | Intermediate call: Job already active. |
8xxx | The processing of TMAIL_C was completed with an error code of the communication instructions called internally. | For detailed information, refer to the STATUS parameter descriptions for the TCON, TDISCON, TSEND and TRCV communication instructions. |
8009 | Internal function error | An internal function has returned an error. You can find detailed information in the SFB_STATUS parameter of the instance DB. Its possible values are described below. |
8010 | Error during connection establishment | You will find further information on evaluation in the SFB_STATUS parameter of the instance data block. The error code displayed at the SFB_STATUS parameter is explained in the STATUS parameter description for the TCON instruction. |
8011 | Error sending the data | You will find further information on evaluation in the SFB_STATUS parameter of the instance data block. The error code displayed at the SFB_STATUS parameter is explained in the STATUS parameter description for the TSEND instruction. |
8012 | Error receiving the data | You will find further information on evaluation in the SFB_STATUS parameter of the instance data block. The error code displayed at the SFB_STATUS parameter is explained in the STATUS parameter description for the TRCV instruction. |
8013 | Error during connection establishment | You will find further information on evaluation in the SFB_STATUS parameter of the instance data block. The error code displayed at the SFB_STATUS parameter is explained in the STATUS parameter description for the TCON and TDISCON instructions. |
8014 | Establishment of a connection is not possible. | You may have entered an incorrect mail server IP address (MailServerAddress) or too short a time span (WatchDogTime) for connection establishment. It is also possible that the CPU has no connection to the network or that the CPU configuration is incorrect. |
8015 | Incorrect data type for MAIL_ADDR_PARAM | The only valid data types are the system data types (structures) Tmail_v4 and TMail_FQDN. |
8016 | Incorrect data type for the ATTACHMENT parameter | The valid data types are in the following list:
Note: The ArrayOfChar and String data types are only valid with TMAIL_C instruction version V5.0 or later. |
8017 | Incorrect data length for the ATTACHMENT parameter | Data length must be <= 65534 bytes. |
82xx, 84xx, or 85xx | The error message originates from the mail server and corresponds, except for the "8", to the error number of the SMTP protocol. The following lines list several error codes that can occur. | You will find more detailed information on the SMTP error code and other error codes in the SMTP protocol on the Internet or in the error documentation of the mail server. You can also view the most recent error message from the mail server in your instance DB in the BUFFER1 parameter. You will find the last data sent by the TMAIL_C instruction under DATEN in the instance DB. |
8450 | Action not executed: Mailbox not available/cannot be reached | Try again later. |
8451 | Action aborted: Local processing error | Try again later. |
8500 | Syntax error: Error not recognized. This also includes the error when a command string is too long. This can also occur when the email server does not support the LOGIN authentication procedure. | Check the parameters of TMAIL_C. Try to send an email without authentication. To do this, replace the content of the UserName parameter with an empty string. If no user name is specified, the LOGIN authentication procedure is not used. |
8501 | Syntax error: Incorrect input at a parameter | Possible cause: Incorrect address at the TO_S or CC parameter (see also: TO_S and CC parameters). |
8502 | Command unknown or not implemented | Check your entries, in particular the FROM parameter. It may be incomplete and you may have forgotten the "@" or "." (see also: TO_S and CC parameters). |
8535 | SMTP authentication incomplete | You have possibly entered an incorrect user name or incorrect password. |
8550 | Mail server cannot be reached. You have no access rights. | You may have entered an incorrect user name or password, or the mail server may not support your login. Another cause of error could be a mistake in the domain name after the "@" at the TO_S or CC parameter (see also: TO_S and CC parameters). |
8552 | Action aborted: Assigned memory size has been exceeded | Try again later. |
8554 | Transfer failed | Try again later. |
* You can display error codes as integer or hexadecimal values in the program editor. | ||
With version V6.0 or later of the TMAIL_C instruction, the following return values are possible at the SFB_STATUS parameter of the instance DB:
Return values at the SFB_STATUSparameter of the instance DB (W#16#...) | Explanation |
|---|---|
8085 | The connection ID (ID parameter) is already being used by a configured connection. |
8086 | The ID parameter is outside the valid range. |
8087 | Maximum number of connections reached; no further connections possible |
8088 * | The file does not exist or is currently unavailable. |
8089 * | Unable to open the file because the number of simultaneously opened files has exceeded the system's limit. The limit per filesystem is 26 on the S7-1200. |
808A * | The DirectoryPath contains a directory other than DataLogs, Recipes, or UserFiles, or one of the addressed subdirectories violates the previously-mentioned addressing rules. Refer to DirectoryPath for further information. |
808B * | The FileName contains an illegal character sequence or has been left blank. Refer to FileName for further information. |
808C * | The AttachmentName parameter must be blank when addressing a file path as an attachment. |
8092 | The TO_S and CC parameters are empty or the From sub-parameter is empty or incomplete. |
8093 | The MAIL_ADDR_PARAM parameter requires the connection to be upgraded to a secure connection, but the mail server does not support the STARTTLS command. |
8095 | Invalid response from mail server. The mail server may not be RFC-compliant. |
809A | The SDT structure at the MAIL_ADDR_PARAM parameter is not supported at an integrated interface. |
809B | Invalid interface ID in SDT at MAIL_ADDR_PARAM parameter |
80A1 | The specified connection or the remote port is already being used. |
80A3 | ID is used by a connection created by the user program. |
80A4 | IP address of the remote endpoint of the connection is invalid or it corresponds to the IP address of the local partner. |
80A7 | Communication error: You executed TDISCON before TMAIL_C had completed. |
80B7 | Remote port is 0 or IP address of the partner endpoint was set to 0.0.0.0. |
80C3 | Too few resources in the CPU |
80C4 | Temporary communication error:
|
80C5 | The mail server refuses to establish the connection, has terminated the connection, or is actively ending it. |
80C6 | The connection partner cannot be reached (network error). |
80C7 | Execution timeout |
80C8 | Attempt being made to re-establish an existing connection. |
80C9 | Validation of the connection partner failed. The mail server does not correspond to the defined partner at the MailServerAddress parameter. |
80CE | The IP address of the local interface is 0.0.0.0. |
80D0 | The MailServerAddress parameter contains an empty string in the attempt to use DNS. |
80D1 | The MailServerAddress parameter is not a fully qualified domain name. The period at the end may be missing. |
80D2 | You did not configure a DNS server address. |
80D3 | The Fully Qualified Domain Name (FQDN) could not be resolved. Possible causes:
|
80E0 | Communication with the mail server failed due to a message with errors. Possible causes:
|
80E1 | Error during the handshake. Possible causes:
|
80E2 | Certificate not supported / invalid Possible cause: The time-of-day of the module concerned is not set or the module is not synchronized. Example: The default setting for the date of the module is 1/1/2012, and the date was not set during commissioning. The validity period of the certificate starts on 20 August 2016 and ends on 20 August 2024. In this case, the date of the module is outside the validity period of the certificate; the certificate is invalid for the module. |
80E3 | Mail server certificate has been discarded. |
80E4 | No valid certification authority found for the mail server certificate. |
80E5 | Mail server certificate expired. |
80E6 | Integrity errors in the Transport-Layer-Security (TLS) protocol |
80E7 | Unsupported extension in mail server certificate |
80E9 | TLS server without server certificate is not supported |
* These error codes are added to the TMAIL_C instruction to assist in diagnosing improper file path addressing.
UDP is a standard protocol described by RFC 768: User Datagram Protocol. UDP provides a mechanism for one application to send a datagram to another; however, delivery of data is not guaranteed. This protocol has the following features:
A quick communications protocol
Suitable for small-sized to medium data amounts (up to 2048 bytes)
UDP is a simpler transport control protocol than TCP, with a thin layer that yields low overheads
Can be used very flexibly with many third-party systems
Routing-capable
Uses port numbers to direct the datagrams
Messages are unacknowledged: The application is required to take responsibility for error recovery and security
Programming effort is required for data management due to the SEND / RECEIVE programming interface
UDP supports broadcast communication. To use broadcast, you must configure the IP address portion of the ADDR configuration. For example: A CPU with an IP address of 192.168.2.10 and subnet mask of 255.255.255.0 would use a broadcast address of 192.168.2.255.
For further information, see "Configuring connections > Creating UDP/FDL connections with broadcast/multicast" in the TIA Portal Information System
The following instructions control the UDP communication process:
TCON establishes the communication between the client and server (CPU) PC.
TUSEND and TURCV send and receive data.
TDISCON disconnects the communication between the client and server.
Refer to TCON, TDISCON, TSEND, and TRCV in the "TCP and ISO-on-TCP" section for more information on the TCON and TDISCON communication instructions.
LAD / FBD | SCL | Description |
|---|---|---|
"TUSEND_DB"( req:=_bool_in_, ID:=_word_in_, len:=_udint_in_, done=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, data:=_variant_inout_); | The TUSEND instruction sends data via UDP to the remote partner specified by the parameter ADDR. To start the job for sending data, call the TUSEND instruction with REQ = 1. | |
"TURCV_DB"( en_r:=_bool_in_, ID:=_word_in_, len:=_udint_in_, ndr=>_bool_out_, busy=>_bool_out_, error=>_bool_out_, status=>_word_out_, rcvd_len=>_udint_out_, data:=_variant_inout_); | The TURCV instruction receives data via UDP. The parameter ADDR shows the address of the sender. After successful completion of TURCV, the parameter ADDR contains the address of the remote partner (the sender). TURCV does not support ad hoc mode. To start the job for receiving data, call the TURCV instruction with EN_R = 1. |
1 STEP 7 automatically creates the DB when you insert the instruction.
TCON, TDISCON, TUSEND, and TURCV operate asynchronously, which means that the job processing extends over multiple instruction executions.
Data transfer via UDP
RFC 768 specifies that UDP transfers data to the partner without acknowledgement, making it a non-secure method. The lack of acknowledgement can result in loss of data without any indication or notification. Transferring more than 1472 bytes significantly increases the risk of undetected transmission errors.
Design your program so that safety-critical functionality does not rely on successfully transmitting and receiving UDP messages. Instead, use a connection-oriented communication protocol.
Failure to follow these precautions can cause death or severe personal injury.
Unsecured data transfer
RFC 768 specifies that UDP transfers data to the remote partner without acknowledgement, making it an unreliable method. This lack of acknowledgement can result in data loss without any indication from the block.
Design your program so that safety-critical functionality does not rely on successfully transmitting and receiving UDP messages. Instead, use a connection-oriented communication protocol.
Failure to follow these precautions can cause death or severe personal injury.
Parameter and type | Data type | Description | |
|---|---|---|---|
REQ (TUSEND) | IN | Bool | Starts the send job on a rising edge. The data is transferred from the area specified by DATA and LEN. |
EN_R (TURCV) | IN | Bool |
|
ID | IN | Word | Reference to the associated connection between the user program and the communication level of the operating system. ID must be identical to the associated parameter ID in the local connection description. Range of values: W#16#0001 to W#16#0FFF. |
LEN | IN | UDInt | Number of bytes to be sent (TUSEND) or received (TURCV).
|
DONE (TUSEND) | IN | Bool | Status parameter DONE (TUSEND):
|
NDR (TURCV) | OUT | Bool | Status parameter NDR (TURCV):
|
BUSY | OUT | Bool |
|
ERROR | OUT | Bool | Status parameters with the following values:
|
STATUS | OUT | Word | Status information including error information. (Refer to the Error and Status condition codes in the table below.) |
RCVD_LEN | OUT | UDInt | Number of bytes received (TURCV) |
DATA | IN_OUT | Variant | Address of the sender area (TUSEND) or receive area (TURCV):
|
ADDR | IN_OUT | Variant | Pointer to the address of the receiver (for TUSEND) or sender (for TURCV) (for example, P#DB100.DBX0.0 byte 8). The pointer may point to any memory area. A structure of 8 bytes is required as follows:
|
The job status is indicated at the output parameters BUSY and STATUS. STATUS corresponds to the RET_VAL output parameter of asynchronously functioning instructions.
The following table shows the relationships between BUSY, DONE (TUSEND), NDR (TURCV), and ERROR. Using this table, you can determine the current status of the instruction (TUSEND or TURCV) or when the sending (transmission) / receiving process is complete.
BUSY | DONE / NDR | ERROR | Description |
|---|---|---|---|
TRUE | irrelevant | irrelevant | The job is being processed. |
FALSE | TRUE | FALSE | The job was completed successfully. |
FALSE | FALSE | TRUE | The job was ended with an error. The cause of the error can be found in the STATUS parameter. |
FALSE | FALSE | FALSE | The instruction was not assigned a (new) job. |
1 Due to the asynchronous function of the instructions: For TUSEND, you must keep the data in the sender area consistent until the DONE parameter or the ERROR parameter assumes the value TRUE. For TURCV, the data in the receiver area are only consistent when the NDR parameter assumes the value TRUE.
ERROR | STATUS | Description |
|---|---|---|
0 | 0000 |
|
0 | 7000 |
|
0 | 7001 |
|
0 | 7002 |
|
1 | 8085 | LEN parameter is greater than the largest permitted value, has the value 0 (TUSEND), or you changed the value of the LEN or DATA parameter since the first instruction execution (TURCV). |
1 | 8086 | The ID parameter is not in the permitted address range. |
1 | 8088 |
|
1 | 8089 | ADDR parameter does not point to a data block. |
1 | 80A1 | Communications error:
|
1 | 80A4 | IP address of the remote connection end point is invalid; it is possible that it matches the local IP address (TUSEND). |
1 | 80B3 |
|
1 | 80C3 |
|
1 | 80C4 | Temporary communications error:
|
Connection Ethernet protocols
Every CPU has an integrated PROFINET port, which supports standard PROFINET communications. The TUSEND and TURCV instructions support the UDP Ethernet protocol.
Refer to "Configuring the Local/Partner connection path"" in the "Device configuration" chapter for more information.
Operations
Both partners are passive in UDP communication. Typical parameter start values for the "TCON_Param" data type are shown in the following figures. Port numbers (LOCAL_TSAP_ID) are written in a 2-byte format. All ports except for 161, 34962, 34963, and 34964 are allowed.
The TUSEND instruction sends data through UDP to the remote partner specified in the "TADDR_Param" data type. The TURCV instruction receives data through UDP. After a successful execution of the TURCV instruction, the "TADDR_Param" data type shows the address of the remote partner (the sender), as shown in the figures below.
The T_CONFIG instruction can change the Ethernet address, the PROFINET device name, or the IP addresses of the NTP servers for time-of-day synchronization from within the user program. The following features can be adjusted permanently or temporarily:
IP address
Subnet mask
Router address
Station name
IP addresses of up to four NTP servers
Located in the CPU "Properties", "Ethernet address" page, the "IP address is set directly at the device" radio button allows you to change the IP address online or by using the "T_CONFIG" instruction after the program is downloaded.
Located in the CPU "Properties", "Ethernet address" page, the "PROFINET device name is set directly at the device" radio button allows you to change the PROFINET device name online or by using the "T_CONFIG" instruction after the program is downloaded.
Located in the CPU "Properties", "Time synchronization" page, the "Enable time synchronization via NTP server" box allows you to change the IP addresses of up to four NTP servers.
You cannot execute more than one T_CONFIG instruction at a time.
Changes to the IP address or name of station of the CPU can be temporary or permanent. Changes to the NTP server IP addresses can only be temporary:
A permanent change indicates that the change is retentive, meaning that the change persists through a power failure.
A temporary change indicates that the change is volatile and reverts to the original value after a power loss.
LAD / FBD | SCL | Description |
|---|---|---|
 | "T_CONFIG_DB"( Req:=_bool_in_, Interface:=_uint_in_, Conf_Data:=_variant_in_, Done=>_bool_out_, Busy=>_bool_out_, Error=>_bool_out_, Status=>_dword_out_, Err_Loc=>_dword_out_); | Use the T_CONFIG instruction to change the IP configuration parameters from your user program. T_CONFIG works asynchronously. The execution extends over multiple calls. |
Parameter and type | Data type | Description | |
|---|---|---|---|
REQ | Input | Bool | Starts the instruction on the rising edge. |
INTERFACE | Input | HW_Interface | ID of network interface |
CONF_DATA | Input | Variant | Reference to the structure of the configuration data; CONF_DATA is defined by a struct containing up to four System Data Types (SDT). |
DONE | Output | Bool |
|
BUSY | Output | Bool |
|
ERROR | Output | Bool | Status parameters with the following values:
|
STATUS | Output | DWord | Status information including error information. (Refer to the Error and Status condition codes in the table below.) |
ERR_LOC | Output | DWord | Fault location (field ID and subfield location within the CONF_DATA structure) |
The IP configuration information is placed in the CONF_DATA data block, along with a Variant pointer on parameter CONF_DATA referenced above. The successful execution of the T_CONFIG instruction ends with the handover of the IP configuration data to the network interface.
The status and error messages of the instruction "T_CONFIG" are output at the parameters STATUS and ERR_LOC:
The cause of the error is output at the parameter STATUS.
The location of the error that occurred is output at the parameter ERR_LOC. The following options are available here:
16#0000_0000: No error or error when calling the instruction (for example, errors when assigning parameters to the instruction or in communication with the PROFINET interface).
16#0001_0000: Error with the configuration data in the parameters of the system data type IF_CONF_HEADER.
16#0001_000x: Error in the configuration data in the parameters of system data type IF_CONF_V4 or IF_CONF_NOS or IF_CONF_NTP (x specifies the position of the bad sub-block in the T_CONFIG structure. If the T_CONFIG structure contains, for example, a sub-block for the IP address and a sub-block for the station name, and the error is located in the sub-block for the station name, ERR_LOC has the value 0001_0002.)
The following table shows the possible values for the parameters STATUS and ERR_LOC:
STATUS* | ERR_LOC* | Explanation |
|---|---|---|
0000_0000 | 0000_0000 | Order processing completed without errors. |
0070_0000 | 0000_0000 | No job processing active. |
0070_0100 | 0000_0000 | Start of the order processing. |
0070_0200 | 0000_0000 | Intermediate call (REQ irrelevant). |
C08x_yy00 | 0000_0000 | General error information. |
C080_8000 | 0000_0000 | Error at call of the instruction: The hardware ID at the parameter Interface is invalid. |
C080_8100 | 0000_0000 | Error at call of the instruction: The hardware ID at the parameter Interface does not address a PROFINET interface. |
C080_8700 | 0000_0000 | Error at call of the instruction: Incorrect length of the data block at the parameter CONF_DATA. |
C080_8800 | 0001_0000 | Error in the system data type IF_CONF_HEADER: The parameter FieldType has an invalid value. Use the value "0" for FieldType. |
C080_8900 | 0001_0000 | Error in the system data type IF_CONF_HEADER: The parameter FieldId has an invalid value or was used several times. Use the value "0" for FieldId. |
C080_8A00 | 0001_0000 | Error in the system data type IF_CONF_HEADER: Incorrect number at the parameter SubfieldCount. Enter the correct number of system data types IF_CONF_V4, IF_CONF_NOS, or IF_CONF_NTP being used. |
C080_8B00 | 0001_000x | Error in the system data type IF_CONF_V4, IF_CONF_NOS, or IF_CONF_NTP: The parameter Id has an invalid value. For IF_CONF_V4 use "30", for IF_CONF_NOS "40", for IF_CONF_NTP "17". |
C080_8C00 | 0001_000x | Error in the system data type IF_CONF_V4, IF_CONF_NOS, or IF_CONF_NTP: Incorrect data type system used, wrong order or multiple use of a system data type. |
C080_8D00 | 0001_000x | Error in the system data type IF_CONF_V4, IF_CONF_NOS, or IF_CONF_NTP: The parameter Length has an incorrect or invalid value. |
C080_8E00 | 0001_000x | Error in the system data type IF_CONF_V4, IF_CONF_NOS, or IF_CONF_NTP: The parameter Mode has an incorrect or invalid value.
|
C080_9000 | 0001_000x | Error in the system data type IF_CONF_V4, IF_CONF_NOS, or IF_CONF_NTP: Configuration data cannot be applied. Possible cause:
|
C080_9400 | 0001_000x | Error in the system data type IF_CONF_V4, IF_CONF_NOS, or IF_CONF_NTP: A parameter value is undefined or invalid. |
C080_9500 | 0001_000x | Error in the system data type IF_CONF_V4, IF_CONF_NOS, or IF_CONF_NTP: The values of two parameters are inconsistent. |
C080_C200 | 0000_0000 | Error at call of the instruction: The configuration data cannot be transferred. Possible cause: The PROFINET interface is not accessible. |
C080_C300 | 0000_0000 | Error at call of the instruction: Insufficient resources (for example, multiple calling of "T_CONFIG" with different parameters). |
C080_C400 | 0000_0000 | Error at call of the instruction: Temporary communication error. Time indication for change to daylight saving time. |
C080_D200 | 0000_0000 | Error at call of the instruction: Call not possible. Instruction is not supported by the selected PROFINET interface. |
The following diagram shows how the configuration data to be transferred is stored in the configuration DB.
① | Configuration DB | ④ | Subfield 2 |
② | Configuration data | ⑤ | Subfield n |
③ | Subfield 1 | ⑥ | Subfield-specific parameters |
The configuration data of CONF_DB consists of a field that contains a header (IF_CONF_Header) and several subfields. IF_CONF_Header provides the following elements:
field_type_id (data type UInt): Zero
field_id (data type UInt): Zero
subfield_cnt (data type UInt): Number of subfields
Each subfield consists of a header (subfield_type_id, subfield_length, subfield_mode) and the subfield-specific parameters. Each subfield must consist of an even number of bytes. The subfield_mode can support a value of 1 or 2. Please refer to the tables below.
Only one field (IF_CONF_Header) is currently allowed. Its parameters field_type_id and field_id must have the value zero. Other fields with different values for field_type_id and field_id are subject to future extensions.
subfield_type_id | Data type | Explanation |
|---|---|---|
30 | IF_CONF_V4 | IP parameters: IP address, subnet mask, router address |
40 | IF_CONF_NOS | PROFINET IO device name (Name of station) |
17 | IF_CONF_NTP | Network Time Protocol (NTP) |
Name | Data type | Start value | Description | |
|---|---|---|---|---|
Id | UInt | 30 | subfield_type_id | |
Length | UInt | 18 | subfield_length | |
Mode | UInt | 0 | subfield_mode (1: permanent or 2: temporary) | |
InterfaceAddress | IP_V4 | - | Interface address | |
ADDR | Array [1..4] of Byte | |||
ADDR[1] | Byte | 0 | IP address high byte: 200 | |
ADDR[2] | Byte | 0 | IP address high byte: 12 | |
ADDR[3] | Byte | 0 | IP address low byte: 1 | |
ADDR[4] | Byte | 0 | IP address low byte: 144 | |
SubnetMask | IP_V4 | - | Subnet mask | |
ADDR | Array [1..4] of Byte | |||
ADDR[1] | Byte | 0 | Subnet mask high byte: 255 | |
ADDR[2] | Byte | 0 | Subnet mask high byte: 255 | |
ADDR[3] | Byte | 0 | Subnet mask low byte: 255 | |
ADDR[4] | Byte | 0 | Subnet mask low byte: 0 | |
DefaultRouter | IP_V4 | - | Default router | |
ADDR | Array [1..4] of Byte | |||
ADDR[1] | Byte | 0 | Router high byte: 200 | |
ADDR[2] | Byte | 0 | Router high byte: 12 | |
ADDR[3] | Byte | 0 | Router low byte: 1 | |
ADDR[4] | Byte | 0 | Router low byte: 1 | |
Name | Data type | Start value | Description |
|---|---|---|---|
Id | UInt | 40 | subfield_type_id |
Length | UInt | 246 | subfield_length |
Mode | UInt | 0 | subfield_mode (1: permanent or 2: temporary) |
NOS (Name of station) | Array[1..240] of Byte | 0 | Station name: You must occupy the ARRAY from the first byte. If the ARRAY is longer than the station name to be assigned, you must enter a zero byte after the actual station name (in conformity with IEC 61158-6-10). Otherwise, NOS is rejected and the "T_CONFIG" instruction enters the error code DW#16#C0809400 in STATUS. If you occupy the first byte with zero, the station name is deleted. |
The station name is subject to the following limitations:
A name component within the station name, i.e., a character string between two dots, must not exceed 63 characters.
No special characters such as umlauts, brackets, underscore, slash, blank space, etc. The only special character permitted is the dash.
The station name must not begin or end with the "-" character.
The station name must not begin with a number.
The station name form n.n.n.n (n = 0, ... 999) is not permitted.
The station name must not begin with the string "port-xyz" or "port-xyz-abcde" (a, b, c, d, e, x, y, z = 0, ... 9).
You can also create an ARRAY "NOS" that is shorter then 240 bytes, but not less than 2 bytes. In this case, you must adjust the "Length" (length of subfield) tag accordingly.
Name | Data type | Start value | Description | |||
|---|---|---|---|---|---|---|
Id | UInt | 17 | subfield_type_id | |||
Length | UInt | 22 | subfield_length | |||
Mode | UInt | 0 | subfield_mode (2: temporary) | |||
NTP_IP | Array[1...4] of IP_V4 | - | IP addresses of NTP servers | |||
NTP_IP[1] | IP_V4 | IP addresses of NTP server 1 | ||||
ADDR | Array[1...4] of Byte | 0 | ||||
ADDR[1] | Byte | 0 | IP address high byte | |||
ADDR[2] | Byte | 0 | IP address high byte | |||
ADDR[3] | Byte | 0 | IP address low byte | |||
ADDR[4] | Byte | 0 | IP address low byte | |||
NTP_IP[2] | IP_V4 | IP addresses of NTP server 2 | ||||
ADDR | Array[1...4] of Byte | 0 | ||||
ADDR[1] | Byte | 0 | IP address high byte | |||
ADDR[2] | Byte | 0 | IP address high byte | |||
ADDR[3] | Byte | 0 | IP address low byte | |||
ADDR[4] | Byte | 0 | IP address low byte | |||
NTP_IP[3] | IP_V4 | IP addresses of NTP server 3 | ||||
ADDR | Array[1...4] of Byte | 0 | ||||
ADDR[1] | Byte | 0 | IP address high byte | |||
ADDR[2] | Byte | 0 | IP address high byte | |||
ADDR[3] | Byte | 0 | IP address low byte | |||
ADDR[4] | Byte | 0 | IP address low byte | |||
NTP_IP[4] | IP_V4 | IP addresses of NTP server 4 | ||||
ADDR | Array[1...4] of Byte | 0 | ||||
ADDR[1] | Byte | 0 | IP address high byte | |||
ADDR[2] | Byte | 0 | IP address high byte | |||
ADDR[3] | Byte | 0 | IP address low byte | |||
ADDR[4] | Byte | 0 | IP address low byte | |||
In the following example, in the "addr" subfield, the "InterfaceAddress" (IP address), "SubnetMask", and "DefaultRouter" (IP router) are changed. In the CPU "Properties", "Ethernet address" page, you must select the "IP address is set directly at the device" radio button to enable you to change the IP parameters using the "T_CONFIG" instruction after the program is downloaded.
In the following example, both the "addr" and "nos" (Name of station) subfields are changed. In the CPU "Properties", "Ethernet address" page, you must select the "PROFINET device name is set directly at the device" check box to enable you to change the PROFINET device name using the "T_CONFIG" instruction after the program is downloaded.
In the following example, in the "ntp" (Network Time Protocol (NTP) server) subfield, the T_CONFIG instruction changes the IP addresses of up to four NTP servers.
In the CPU Properties, PROFINET interface [X1], Time synchronization page, you configure NTP synchronization by selecting the "Enable time synchronization via NTP server" check box as shown in the figure below. You can then change the IP addresses in the NTP servers using the "T_CONFIG" instruction after the program is downloaded.
REQ input parameter
Many of the OUC instructions use the REQ input to initiate the operation on a low to high transition. The REQ input must be high (TRUE) for one execution of an instruction, but the REQ input can remain TRUE for as long as you choose. The instruction does not initiate another operation until it has been executed with the REQ input FALSE so that the instruction can reset the history state of the REQ input. This is required so that the instruction can detect the low to high transition to initiate the next operation.
When you place one of these instructions in your program, STEP 7 prompts you to identify the instance DB. Use a unique DB for each instruction call. This ensures that each instruction properly handles inputs such as REQ.
ID input parameter
The ID parameter is a reference to the "Local ID (hex)" on the "Network view" of "Devices and networks" in STEP 7 and is the ID of the network that you want to use for this communication block. The ID must be identical to the associated parameter ID in the local connection description.
DONE, NDR, ERROR, and STATUS output parameters
The following parameters are common to the OUC instructions and provide outputs describing the completion status:
Parameter | Data type | Default | Description |
|---|---|---|---|
DONE | Bool | FALSE | Is set TRUE for one execution to indicate that the last request completed without errors; otherwise, FALSE. |
NDR | Bool | FALSE | Is set TRUE for one execution to indicate that the requested action has completed without error and new data has been received; otherwise, FALSE. |
BUSY | Bool | FALSE | Is set TRUE when active to indicate that:
Is set FALSE when job is complete. |
ERROR | Bool | FALSE | Is set TRUE for one execution to indicate that the last request completed with errors, with the applicable error code in STATUS; otherwise, FALSE. |
STATUS | Word | 0 | Is set to a status value as follows:
STATUS retains its value for the duration of the execution of the function. |
Note that DONE, NDR, and ERROR are set for one execution only.
If you use the TCON instruction to set up and establish a passive communications connection, do not use the following restricted port addresses:
ISO TSAP (passive):
01.00, 01.01, 02.00, 02.01, 03.00, 03.01
10.00, 10.01, 11.00, 11.01, ... BF.00, BF.01
TCP port (passive) and UDP port (passive):
20, 80, 102, 5001, 34962, 34963, 34964
Figure 1. | A CPU can communicate with a STEP 7 programming device on a network. |
Consider the following when setting up communications between a CPU and a programming device:
Configuration/Setup: Hardware configuration is required.
No Ethernet switch is required for one-to-one communications; an Ethernet switch is required for more than two devices in a network.
The PROFINET interfaces establish the physical connections between a programming device and a CPU. Since Auto-Cross-Over functionality is built into the CPU, either a standard or crossover Ethernet cable can be used for the interface. An Ethernet switch is not required to connect a programming device directly to a CPU.
Follow the steps below to create the hardware connection between a programming device and a CPU:
Plug the Ethernet cable into the PROFINET port shown below.
Connect the Ethernet cable to the programming device.
①
PROFINET port
An optional strain relief is available to strengthen the PROFINET connection. For ordering information, see Spare parts and other hardware.
If you have already created a project with a CPU, open your project in STEP 7.
If not, create a project and insert a CPU into the rack. In the project below, a CPU is shown in the "Device View".
Assigning the IP addresses
In a PROFINET network, each device must also have an Internet Protocol (IP) address. This address allows the device to deliver data on a more complex, routed network:
If you have programming or other network devices that use an onboard adapter card connected to your plant LAN or an Ethernet-to-USB adapter card connected to an isolated network, you must assign IP addresses to them. Refer to "Assigning IP addresses to programming and network devices" for more information.
You can also assign an IP address to a CPU or network device online. This is particularly useful in an initial device configuration. Refer to "Assigning an IP address to a CPU online" for more information.
After you have configured your CPU or network device in your project, you can configure parameters for the PROFINET interface, to include its IP address. Refer to "Configuring an IP address for a CPU in your project" for more information.
After completing the configuration, you must download your project to the CPU. The download operation sets all IP addresses for devices configured as "Set IP address in the project".
The CPU "Download to device" function and its "Extended download to device" dialog can show all accessible network devices and whether or not unique IP addresses have been assigned to all devices. Refer to "Testing the PROFINET network" for more information.
Figure 1. | The CPU supports PROFINET communications connections to HMIs. The following requirements must be considered when setting up communications between CPUs and HMIs: |
Configuration/Setup:
The PROFINET port of the CPU must be configured to connect with the HMI.
The HMI must be setup and configured.
The HMI configuration information is part of the CPU project and can be configured and downloaded from within the project.
No Ethernet switch is required for one-to-one communications; an Ethernet switch is required for more than two devices in a network.
The rack-mounted CSM1277 4-port Ethernet switch can be used to connect your CPUs and HMI devices. The PROFINET port on the 1211, 1212, and 1214 CPUs does not contain an Ethernet switching device.
Supported functions:
Read/write data to the CPU
Trigger messages based upon information retrieved from the CPU
Read system diagnostics
Step | Task |
|---|---|
1 | Establishing the hardware communications connection A PROFINET interface establishes the physical connection between an HMI and a CPU. Since Auto-Cross-Over functionality is built into the CPU, you can use either a standard or crossover Ethernet cable for the interface. An Ethernet switch is not required to connect an HMI and a CPU. Refer to "Communication with a programming device: Establishing the hardware communications connection" for more information. |
2 | Configuring the devices Refer to "Communication with a programming device: Configuring the devices" for more information. |
3 | Configuring the logical network connections between an HMI and a CPU Refer to "HMI-to-PLC communication: Configuring the logical network connections between two devices" for more information. |
4 | Configuring an IP address in your project Use the same configuration process; however, you must configure IP addresses for the HMI and the CPU. Refer to "Device configuration: Configuring an IP address for a CPU in your project" for more information. |
5 | Testing the PROFINET network You must download the configuration for each CPU and HMI device. Refer to "Device configuration: Testing the PROFINET network" for more information. |
Supported HMI tags and subscriptions
The CPU supports 400 tags per HMI and up to 40 HMI subscriptions.
After you configure the rack with the CPU, you are now ready to configure your network connections.
In the Devices and Networks portal, use the "Network view" to create the network connections between the devices in your project. First, click the "Connections" tab, and then select the connection type with the dropdown, just to the right (for example, an ISO on TCP connection).
To create a PROFINET connection, click the green (PROFINET) box on the first device, and drag a line to the PROFINET box on the second device. Release the mouse button and your PROFINET connection is joined.
Refer to "Device Configuration: Creating a network connection" for more information.
Figure 1. | A CPU can communicate with another CPU on a network by using the TSEND_C and TRCV_C instructions. |
Consider the following when setting up communications between two CPUs:
Configuration/Setup: Hardware configuration is required.
Supported functions: Reading/Writing data to a peer CPU
No Ethernet switch is required for one-to-one communications; an Ethernet switch is required for more than two devices in a network unless the devices have a built in switch.
Step | Task |
|---|---|
1 | Establishing the hardware communications connection A PROFINET interface establishes the physical connection between two CPUs. Since Auto-Cross-Over functionality is built into the CPU, you can use either a standard or crossover Ethernet cable for the interface. An Ethernet switch is not required to connect the two CPUs. Refer to "Communication with a programming device: Establishing the hardware communications connection" for more information. |
2 | Configuring the devices You must configure two CPUs in your project. Refer to "Communication with a programming device: Configuring the devices" for more information. |
3 | Configuring the logical network connections between two CPUs Refer to "PLC-to-PLC communication: Configuring logical network connections between two devices" for more information. |
4 | Configuring an IP address in your project Use the same configuration process; however, you must configure IP addresses for two CPUs (for example, PLC_1 and PLC_2). Refer to "Device configuration: Configuring an IP address for a CPU in your project" for more information. |
5 | Configuring transmit (send) and receive parameters You must configure TSEND_C and TRCV_C instructions in both CPUs to enable communications between them. Refer to "Configuring communications between two CPUs: Configuring transmit (send) and receive parameters" for more information. |
6 | Testing the PROFINET network You must download the configuration for each CPU. Refer to "Device configuration: Testing the PROFINET network" for more information. |
After you configure the rack with the CPU, you are now ready to configure your network connections.
In the Devices and Networks portal, use the "Network view" to create the network connections between the devices in your project. First, click the "Connections" tab, and then select the connection type with the dropdown, just to the right (for example, an ISO on TCP connection).
To create a PROFINET connection, click the green (PROFINET) box on the first device, and drag a line to the PROFINET box on the second device. Release the mouse button and your PROFINET connection is joined.
Refer to "Device Configuration: Creating a network connection" for more information.
Configuring General parameters
You specify the communication parameters in the "Properties" configuration dialog of the communication instruction. This dialog appears near the bottom of the page whenever you have selected any part of the instruction.
Refer to "Device configuration: Configuring the Local/Partner connection path" for more information.
In the "Address Details" section of the Connection parameters dialog, you define the TSAPs or ports to be used. The TSAP or port of a connection in the CPU is entered in the "Local TSAP" field. The TSAP or port assigned for the connection in your partner CPU is entered under the "Partner TSAP" field.
Communication blocks (for example, TSEND_C and TRCV_C) are used to establish connections between two CPUs. Before the CPUs can engage in PROFINET communications, you must configure parameters for transmitting (or sending) messages and receiving messages. These parameters dictate how communications operate when messages are being transmitted to or received from a target device.
TSEND_C instruction
The TSEND_C instruction creates a communications connection to a partner station. The connection is set up, established, and automatically monitored until it is commanded to disconnect by the instruction. The TSEND_C instruction combines the functions of the TCON, TDISCON and TSEND instructions.
From the Device configuration in STEP 7, you can configure how a TSEND_C instruction transmits data. To begin, you insert the instruction into the program from the "Communications" folder in the "Instructions" task card. The TSEND_C instruction is displayed, along with the Call options dialog where you assign a DB for storing the parameters of the instruction.
You can assign tag memory locations to the inputs and outputs, as shown in the following figure:
Configuring General parameters
You specify the parameters in the Properties configuration dialog of the TSEND_C instruction. This dialog appears near the bottom of the page whenever you have selected any part of the TSEND_C instruction.
TRCV_C instruction
The TRCV_C instruction creates a communications connection to a partner station. The connection is set up, established, and automatically monitored until it is commanded to disconnect by the instruction. The TRCV_C instruction combines the functions of the TCON, TDISCON, and TRCV instructions.
From the CPU configuration in STEP 7, you can configure how a TRCV_C instruction receives data. To begin, insert the instruction into the program from the "Communications" folder in the "Instructions" task card. The TRCV_C instruction is displayed, along with the Call options dialog where you assign a DB for storing the parameters of the instruction.
You can assign tag memory locations to the inputs and outputs, as shown in the following figure:
Configuring the General parameters
You specify the parameters in the Properties configuration dialog of the TRCV_C instruction. This dialog appears near the bottom of the page whenever you have selected any part of the TRCV_C instruction.
In the Network view, use the hardware catalog to add PROFINET IO devices.
For example, expand the following containers in the hardware catalog to add an ET 200SP IO device: Distributed I/O, ET 200SP, Interface modules, and PROFINET. You can then select the interface module from the list of ET 200SP devices (sorted by part number) and add the ET 200SP IO device.
Insert the IO device | Result |
|---|---|
 |  |
You can now connect the PROFINET IO device to the CPU:
Right-click the "Not assigned" link on the device and select "Assign new IO controller" from the context menu to display the "Select IO controller" dialog.
Select your S7-1200 CPU (in this example, "PLC_1") from the list of IO controllers in the project.
Click "OK" to create the network connection.
You can also go to the "Devices and networks" portal and use the "Network view" to create the network connections between the devices in your project:
To create a PROFINET connection, click the green (PROFINET) box on the first device, and drag a line to the PROFINET box on the second device.
Release the mouse button and your PROFINET connection is joined.
Refer to "Device Configuration: Configuring the CPU for communication" for more information.
Assigning CPUs and device names
Network connections between the devices also assign the PROFINET IO device to the CPU, which is required for that CPU to control the device. To change this assignment, click the PLC Name shown on the PROFINET IO device. A dialog box opens that allows the PROFINET IO device to be disconnected from the current CPU and reassigned or left unassigned, if desired.
The devices on your PROFINET network must have an assigned name before you can connect with the CPU. Use the "Network view" to assign names to your PROFINET devices if the devices have not already been assigned a name or if the name of the device is to be changed. Right-click the PROFINET IO device and select "Assign device name" to do this.
For each PROFINET IO device, you must assign the same name to that device in both the STEP 7 project and to the PROFINET IO device in the PROFINET network. (You can use either the STEP 7 "Online & diagnostics" tool or the PRONETA commissioning, configuration, and diagnostics tool to assign the device name in the PROFINET network.) If a name is missing or does not match in either location, the PROFINET IO data exchange mode will not run. Refer to "Online and diagnostic tools: Assigning a name to a PROFINET device online" for more information.
Assigning the IP addresses
In a PROFINET network, each device must also have an Internet Protocol (IP) address. This address allows the device to deliver data on a more complex, routed network:
If you have programming or other network devices that use an onboard adapter card connected to your plant LAN or an Ethernet-to-USB adapter card connected to an isolated network, you must assign IP addresses to them. Refer to "Assigning IP addresses to programming and network devices" for more information.
You can also assign an IP address to a CPU or network device online. This is particularly useful in an initial device configuration. Refer to "Assigning an IP address to a CPU online" for more information.
After you have configured your CPU or network device in your project, you can configure parameters for the PROFINET interface, to include its IP address. Refer to "Configuring an IP address for a CPU in your project" for more information.
Configuring the IO cycle time
A PROFINET IO device is supplied with new data from the CPU within an "IO cycle" time period. The update time can be separately configured for each device and determines the time interval in which data is transmitted from the CPU to and from the device.
STEP 7 calculates the "IO cycle" update time automatically in the default setting for each device of the PROFINET network, taking into account the volume of data to be exchanged and the number of devices assigned to this controller. If you do not want to have the update time calculated automatically, you can change this setting.
To access the IO cycle parameters, click the PROFINET port on the ET 200SP IO device. From Properties dialog, select "Advanced options > Realtime settings > IO cycle".
Define the IO cycle "Update time" with the following selections:
To have a suitable update time calculated automatically, select "Calculate update time automatically".
To set the update yourself, select "Set update time manually" and choose the required update time in ms from the dropdown menu.
ET 200SP PROFINET IO device | ET 200SP PROFINET IO cycle dialog |
|---|---|
 |
The "I-device" (intelligent IO device) functionality of a CPU facilitates data exchange with an IO controller and operation of the CPU as intelligent preprocessing unit of sub processes, for example. The I-device is linked as an IO device to a "higher-level" IO controller.
The pre-processing is handled by the user program on the CPU. The process values acquired in the centralized or distributed (PROFINET IO or PROFIBUS DP) I/O are pre-processed by the user program and made available through a PROFINET IO interface to the CPU of a higher-level station.
"I-device" naming conventions
In the remainder of this description, a CPU or a CP with I-device functionality is simply called an "I-device".
Fields of application
Fields of application of the I-device:
Distributed processing:
A complex automation task can be divided into smaller units/subprocesses. This results in manageable processes which lead to simplified subtasks.
Separating subprocesses:
Complicated, widely distributed and extensive processes can be subdivided into several subprocesses with manageable interfaces by using I-devices. These subprocesses can be stored in individual STEP 7 projects if necessary, which can later be merged to form one master project.
Know-how protection:
Components can only be delivered with a GSD file for the I-device interface description instead of with a STEP 7 project. The user can protect his program since it no longer has to be published.
Properties
Properties of the I-device:
Unlinking STEP 7 projects:
Creators and users of an I-device can have completely separated STEP 7 automation projects. The GSD file forms the interface between the STEP 7 projects. This allows a link to standard IO controllers through a standardized interface.
Real-time communication:
The I-device is provided with a deterministic PROFINET IO system through a PROFINET IO interface.
Advantages
The I-device has the following advantages:
Simple linking of IO controllers
Real-time communication between IO controllers
Relieving the IO controller by distributing the computing capacity to I-devices
Lower communications load by processing process data locally
Manageable, due to processing of subtasks in separate STEP 7 projects
An I-device is included in an IO system like a standard IO device.
I-device without lower-level PROFINET IO system
The I-device does not have its own distributed I/O. The configuration and parameter assignment of the I-devices in the role of an IO device is the same as for a distributed I/O system (for example, ET 200).
I-device with lower-level PROFINET IO system
Depending on the configuration, an I-device can also be an IO controller on a PROFINET interface in addition to having the role of an IO device.
This means that the I-device can be part of a higher-level IO system through its PROFINET interface and as an IO controller can support its own lower-level IO system.
The lower-level IO system can, in turn, contain I-devices (see figure below). This makes hierarchically structured IO systems possible.
In addition to its role as IO controller, an I-device can also be used through a PROFIBUS interface as DP master for a lower-level PROFIBUS system.
Example: I-device as IO device and IO controller
The I-device as IO device and IO controller is explained based on the example of a print process. The I-device controls a unit (a subprocess). One unit is used, for example, to insert additional sheets such as flyers or brochures in a package of printed material.
Unit 1 and unit 2 each consist of an I-device with centralized I/O. The I-device along with the distributed I/O system (for example, ET 200) forms unit 3.
The user program on the I-device is responsible for preprocessing the process data. For this task, the user program of the I-device requires default settings (for example, control data) from the higher-level IO controller. The I-device provides the higher-level IO controller with the results (for example, status of its subtask).
Transfer areas are an interface to the user program of the I-device CPU. Inputs are processed in the user program and outputs are the result of the processing in the user program.
The data for communication between IO controller and I-device is made available in the transfer areas. A transfer area contains an information unit that is exchanged consistently between IO controller and I-device. You can find more information on configuration and use of transfer areas in "Configuring the I-device".
Input transfer areas behave differently upon network loss between controller and I-device
On the controller, the CPU writes zero to the input transfer areas upon network loss. On the I-device, the input transfer areas retain their last values.
You can configure your system to avoid this condition for the general I-device case (non-shared I-device). To do this, clear the input transfer areas for the I-device in a "Rack or Station Failure OB" for a coming event. Follow these steps:
Add a "Rack or Station Failure OB" to your project. (This OB defaults to the number OB 86).
Add logic to the OB to write the values of the inputs for the I-device to zero when the startup variable of LADDR indicates the value of the I-device hardware ID and the startup variable of Event_Class indicates a "coming" event:
You can find the I-device hardware ID in the Default tag table in the "System constants" tab. The hardware ID is a type of "HW_Device", and the name of the tag indicates that it is an I-device (for example, "Local~PROFINET_interface_1~IODevice").
A value of "16#39" in the Event_Class indicates a "coming" event. If the "Event_Class" input variable contains the value of "16#39", this indicates that the "Rack or Station Failure OB" is now active (as opposed to being cleared).
Data exchange flow
The next figure shows the data exchange between the higher- and lower-level IO system. The individual communication relations are explained below based upon the numbers:
① | Data exchange between higher-level IO controller and normal IO-device In this way, the IO controller and IO devices exchange data through PROFINET. |
② | Data exchange between higher-level IO controller and I-device In this way, the IO controller and the I-device exchange data through PROFINET. The data exchange between a higher-level IO controller and an I-device is based upon the conventional IO controller / IO device relationship. For the higher-level IO controller, the transfer areas of the I-devices represent submodules of a pre-configured station. The output data of the IO controller is the input data of the I-device. Analogously, the input data of the IO controller is the output data of the I-device. |
③ | Transfer relationship between the user program and the transfer area In this way, the user program and the transfer area exchange input and output data. |
④ | Data exchange between the user program and the I/O of the I-device In this way, the user program and the centralized / distributed I/O exchange input and output data. |
⑤ | Data exchange between the I-device and a lower-level IO device In this way, the I-device and its IO devices exchange data. The data transfer is through PROFINET. |
There are basically two possibilities for configuration:
Configuration of an I-device within a project
Configuration of an I-device that is used in another project or in another engineering system.
STEP 7 allows you to configure an I-device for another project or for another engineering system by exporting a configured I-device to a GSD file. You import the GSD file in other projects or engineering systems as with other GSD files. The transfer areas for the data exchange, among other data, are stored in this GSD file.
When you use the S7-1200 as a shared I-device and as a controller, ensure that you increase the PROFINET I-device and PROFINET IO Update times to alleviate the communications performance impact. The system is very stable and works well when you select 2 ms for the Update time of a single PROFINET I-device time and you select 2 ms for the Update time of a single PROFINET IO time.
Configuration of an I-device within a project
Drag-and-drop a PROFINET CPU from the hardware catalog into the network view.
Drag-and-drop a PROFINET CPU, which can also be configured as an IO device, from the hardware catalog into the network view. This device is configured as an I-device (for example, CPU 1215C).
Select the PROFINET interface for the I-device.
In the Inspector window in the area navigation choose "Operating mode" and select the check box "IO device".
Now you have the option of choosing the IO controller in the "Assigned IO controller" drop-down list.
Once you have chosen the IO controller, the networking and the IO system between both devices are displayed in the network view.
With the "Parameter assignment of PN interface by higher-level IO controller" check box, you specify whether the interface parameters will be assigned by the I-device itself or by a higher-level IO controller.
If you operate the I-device with a lower-level IO system, then the parameters of the I-device PROFINET interface (for example, port parameter) cannot be assigned with the higher-level IO controller.
Configure the transfer areas. The transfer areas are found in the area navigation section "I-device communication":
Click in the first field of the "Transfer area" column. STEP 7 assigns a default name which you can change.
Select the type of communication relation: you can currently only select CD or F-CD.
Addresses are automatically preset; you can correct addresses if necessary, and determine the length of the transfer area which is to be consistently transferred.
A separate entry is created in the area navigation for each transfer area. If you select one of these entries, you can adjust the details of the transfer area, or correct them and comment on them.
If you configure an S7-1200 as an I-device, the maximum size of a transfer area is 1024 input or output bytes. There are possible constraining factors depending on local I/O as well as address space limitations on the controlling device.
Configuring an I-device with a GSD file
If you use an I-device in another project, or if the I-device is used in another engineering system, then configure the higher-level IO controller and the I‑device as described above.
However, click on the "Export" button after configuring the transfer areas so a new GSD file is created from the I-device. This GSD file represents the configured I-device in other projects.
The "Export" button is found in the "I-device communication" section of the Inspector window.
The hardware configuration is compiled and the export dialog opened.
Assign a name for the I-device proxy as well as a description in the fields provided. Click the "Export" button to complete your process.
Finally, import the GSD file, for example, in another project.
Numerous IO controllers are often used in larger or widely distributed systems.
Without the "Shared Device" function, each I/O module of an IO device is assigned to the same IO controller. If sensors that are physically close to each other must provide data to different IO controllers, several IO devices are required.
The "Shared Device" function allows the modules or submodules of an IO device to be divided up among different IO controllers. This allows flexible automation concepts. You have, for example, the possibility of combining I/O modules lying near each other into an IO device.
① | PROFINET |
② | Logical assignment |
Principle
Access to the submodules of the shared device is then divided up among the individual IO controllers. Each submodule of the shared device is assigned exclusively to one IO controller.
Requirement (GSD configuration)
STEP 7
S7-1200 CPU with firmware of V4.1 or later as IO controller
IO device supports the shared device function, e.g. interface module IM 155-5 PN ST
GSD file for configuring the IO device is installed
An S7-1200 CPU configured as an I-device supports the Shared Device functionality. You must export the PROFINET GSD file for the I-device from STEP 7 and then import it into STEP 7 (TIA Portal).
Configuring the access
The IO device must be present in several projects so that the modules or submodules of an IO device can be assigned to different IO controllers. A separate project is required for each IO controller.
You use the "Shared device" parameter of the interface module to determine the modules or submodules to which the IO controller has access:
If the local IO controller has access to the configured module, select the name of the IO controller from the list.
If the IO controller from a different project and not the local IO controller is to have access to the configured module, select the entry "---".
The configuration is consistent regarding access if each module or submodule in exactly one project is assigned to an IO controller.
Module or submodule is assigned to another IO controller
The paragraph below describes the consequences of the "---" setting of the "Shared device" parameter from the point of view of the local IO controller.
In this case, the local IO controller does not have access to the module configured in this way. Specifically, this means:
No data exchange with the module or submodule
No reception of alarms or diagnostics, which means no display of the diagnostics status in the online view
No parameter assignment of the module or submodule
Setting of the real-time properties
STEP 7 calculates the communication load and thus the resulting update times. You must enter the number of project-external IO controllers in the project in which the PROFINET interface of the shared device is assigned to the IO controller so that a calculation is possible with shared device configurations.
The maximum possible number of IO controllers for the shared device depends on the device. This number is stored in the GSD file of the shared device.
You can set a very short send clock (minimum of 1 ms) with an S7-1200 CPU as IO controller. The send clock can be shorter than the shortest send clock supported by the shared device. In this case, the shared device is operated by the IO controller with a send clock that it supports (send clock adaptation).
Example: A CPU supports send clocks starting from 1 ms. A configured IO device supports send clocks starting at 1.25 ms; another IO device supports send clocks starting at 1 ms. In this case, you have the option of setting the short send clock of 1 ms for the CPU. The CPU operates the "slow" IO device with the send clock of 1.25 ms.
Rules for the configuration
IO controllers that use the shared device are created in different projects. In each project, care must be taken that the shared device is configured identically in each station. Only one IO controller may ever have full access to a submodule. Inconsistencies in the configuration result in a failure of the shared device.
I/O addresses of a module or submodule can only be edited if a module or submodule is assigned to the IO controller in the same project.
The shared device must have the same IP parameters and the same device name in each project.
The send clock must be identical for all IO controllers that have access to the shared device.
The S7 subnet ID of the subnet to which the shared device is connected must be identical in all projects.
The following functions are only available if the PROFINET interface of the shared device is assigned to the local IO controller:
Prioritized startup
Parameter assignment of the port properties
Boundary conditions
The following boundary conditions result because a shared device configuration is distributed across several projects:
The addresses of modules or submodules that are not assigned to this IO controller are missing in the address overview of each IO controller that has access to a shared device.
The modules or submodules that are not assigned are not taken into consideration in the configuration limit calculation for the shared device during the consistency check. For this reason, you must verify for yourself that the maximum number of submodules or the maximum amount of cyclic IO data for the shared device will not be exceeded. For information on the maximum quantities, refer to the documentation for the devices you are using.
Configuration errors such as the assignment of a module or submodule to several IO controllers are not detected in STEP 7.
CPUs that are loaded with a shared device configuration do not have any information on whether the IO device is a shared device. Modules or submodules that are assigned to other IO controllers and therefore other CPUs are missing in the loaded configuration. These modules or submodules are therefore displayed neither in the CPU web server nor in the CPU display.
This example describes how to configure a distributed I/O system as a shared device with STEP 7.
A "distributed" configuration with different engineering tools for different IO controller families is possible. The procedure described below is based on STEP 7 and is limited to configuration with two IO controllers of the S7-1200 series that share one shared device.
The example creates two projects with one IO controller each:
Controller1
Controller2
You must create the shared device in both projects, even though it is physically one and the same IO device.
Requirements
STEP 7
IO device supports shared device functionality (for example, ET 200SP IM 155-6 PN HF V3.1).
GSD file for configuring the IO device as a shared device is installed.
Procedure: Creating project 1
To create the first project with a shared device, follow these steps:
Start STEP 7.
Create a new project with the name "Controller1".
Insert a CPU 1215C from the hardware catalog in the network view. Name it "Controller1".
Insert an IO device with the "Shared Device" function (for example, an ET 200SP) from the hardware catalog (hardware catalog: Other field devices > PROFINET IO > I/O).
Assign the IO controller "Controller1" to the IO device.
Double-click the IO device and insert all required modules and submodules from the hardware catalog in the device overview table.
Assign the module parameters.
Save the project.
Procedure: Creating project 2
To create the second project with a shared device, follow these steps:
Start STEP 7 once again.
A new instance of STEP 7 opens.
In the new instance, create a new project with the name "Controller2".
Insert a CPU 1215C in the network view. Name it "Controller2".
Copy the IO device from the project "Controller1" and insert it in the network view of project "Controller2".
Assign the IO controller "Controller2" to the IO device.
Save the project.
Both projects now have an identically structured IO device that must be configured in the next step for the different types of IO controller access.
Procedure: Configuring access to the shared device
The modules and submodules you insert in the shared device are automatically assigned to the local CPU. To change the assignment, follow these steps:
Select the interface module in the network or device view of project "Controller1".
Select the "Shared Device" area in the Inspector window.
A table shows which CPU has access to the respective module or submodule for all configured modules. The default setting is that the local CPU has access to all modules and submodules.
Keep the "Controller1" setting for all modules and submodules that are to remain in the address range of the local CPU.
Select the setting "---" for all modules and submodules that are to be located in the address range of the CPU from the "Controller2" project (Controller2). This means that an IO controller outside the project is to have access to the module or submodule.
Select the interface module in the network or device view of project "Controller2".
Select the "Shared Device" area in the Inspector window.
A table shows which CPU has access to the respective module or submodule for all configured modules.
Select the setting "---" for all modules and submodules that are to be located in the address range of the CPU from the "Controller1" project (Controller1).
Finally, check whether the settings for access are "complementary" for each module or submodule in both projects. This means that if the local CPU has access in one project, the option "---" must be set in the other project and vice versa.
Note: The option "---" for the PROFINET interface and therefore for the ports makes the associated parameters read-only and not changeable. Parameters of the PROFINET interface and port parameters can only be edited in the project in which the PROFINET interface is assigned to the local CPU. The ports can be interconnected in both projects regardless of this.
Check whether the same IP address parameters and device name are set for the shared device in all projects.
Check whether the same S7 subnet ID is set in all projects for the subnet to which the shared device is connected (subnet properties, "General" area in the Inspector window).
If you make changes to the shared device: Make the same changes in each project on the shared device. Make sure that only one IO controller has access to a module or submodule.
Procedure: Adjusting the real-time settings
To ensure that all IO controllers and shared devices are operated with the appropriate send clock and that the update times are calculated correctly based on the communication load, you must adjust and check the following settings:
Select the project whose IO controllers have access to the PROFINET interface and the ports of the shared device.
Select the interface module of the shared device in the network view.
In the Inspector window, navigate to the "PROFINET interface > Advanced options > Real time settings > IO cycle" area.
In the "Shared device" area, set the number of project-external IO controllers. The maximum number depends on the IO device (specification in GSD file).
You must set the same send clock for each IO controller that has access to modules and submodules of the shared device:
If you configure the IO controller with STEP 7 (TIA Portal):
Open the corresponding project.
Select the PROFINET interface of the IO controller.
Select the "Advanced options > Real time settings > IO communication" area in the Inspector window and set the shared send clock.
If you configure the IO controller with a different engineering tool:
Select the PROFINET interface of the shared device in STEP 7 (TIA Portal) and read out the send clock on the shared device ("Advanced options > Real time settings" area).
Enter the read send clock in the engineering tool.
If you configure all IO controllers that have access to the shared device in STEP 7 (TIA Portal), you can set shorter send clocks on the IO controller than supported by the shared device (send clock adaptation).
Compiling and loading
You must compile the configurations for the different IO controllers and load them to the CPUs one after the other.
Due to the distributed configuration with separate projects, STEP 7 does not output consistency errors in the case of incorrect access parameter assignment. These are examples of incorrect access parameter assignment:
Several IO controllers have access to the same module
IP address parameters or send clocks are not identical
These errors do not show up until controller operation and are output as configuration errors.
This example describes how to configure an S7-1200 as an I-device with STEP 7 Version V13 SP1 or higher and then use it in two projects as a shared device.
A "distributed" configuration with different engineering tools for different IO controller families is possible. The procedure described below is based on STEP 7 and is limited to a configuration with two IO controllers of the S7-1200 family that share the transfer areas of an I-device as a shared device. The I-device itself is a CPU 1215C.
The example creates three projects with one IO controller each:
S7-1200-I-Device
Controller1
Controller2
You use the S7-1200-I-Device project to configure the I-device. You use the PROFINET GSD variant of S7-1200-I-Device in the Controller1 and Controller2 projects in order to assign the transfer areas in the respective higher-level IO controller.
Shared I-device concept
The shared I-device concept requires a minimum of three separate projects:
I-device project: You configure and program an I-device to perform a particular automation task. You define transfer areas as the I/O interface for the higher level controllers and assign these transfer areas to different IO controllers. For the connection to higher-level IO controllers, you provide a PROFINET GSD file and use the transfer areas to access the I-device.
Controllers that share the I-device (two projects): You use the I-device as a PROFINET GSD variant during configuration of the PROFINET IO system and, in this process, specify the I/O addresses under which the IO controllers access the transfer areas.
If you configure an S7-1200 as an I-device, the maximum size of a transfer area is 1024 input or output bytes. There are possible constraining factors depending on local I/O as well as address space limitations on the controlling device.
I-device
You assign the following parameters for an S7-1200 CPU as an I-device:
Centralized and distributed I/O
Desired transfer areas
Number of IO controllers having access to this I-device (always greater than 1 for a shared device)
You configure the I-device without a higher-level IO controller. As a result, you can only use the local I/O addresses of the transfer area (corresponds with the "Address in the I-device") to create the user program for editing the addresses from the transfer area. You download the I-device, completely configured except for the connection to the higher-level IO controller, to the S7-1200 CPU.
You export a PROFINET GSD file from the I-device configuration.
Controllers that share the I-device
You must install the PROFINET GSD file created from the I-device configuration in all engineering systems that you use in configuring a PROFINET IO system with this shared I‑device. If you configure all uses of this I-device with STEP 7, install the GSD file in STEP 7.
You configure the I-device as a GSD variant on the PROFINET IO system in the projects involved. You can find this I-device under "Other field devices > PROFINET IO > PLCs & CPs" following installation.
In each of the projects involved, you assign transfer areas exclusively to the higher-level IO controllers (default setting: all). You set the other transfer areas to "---" (not assigned). When you do so, the local IO controller cannot access this transfer area, and you can assign the transfer area to another IO controller in another project.
Requirements
IO device supports shared device functionality (for example, ET 200SP IM 155-6 PN HF V3.1).
GSD file for configuring the IO device as a shared device is installed.
Procedure: Creating the S7-1200-I-device project
To create the project with a shared I-device, follow these steps:
Start STEP 7.
Create a new project with the name "S7-1200-I-device".
Insert a CPU 1215C from the hardware catalog in the network view. Assign the name "S7-1200-I-device".
Double-click the IO device and configure all required modules and submodules.
Assign the module parameters. In particular, you must configure the following settings for the CPU in the area of the PROFINET interface [X1]:
Enable the "IO device" option in the "Operating mode" area.
Configure the transfer areas in the "Operating mode" > "I-device communication". The "Address in IO controller" column remains empty because no IO controller is assigned.
Note: To change an input area to an output area, and vice versa, you must navigate to the area of the corresponding transfer area.
Select the number of IO controllers (at least two) that will access the shared I-device during operation ("Operating mode" > "Real time settings" > "IO cycle").
Save the project.
From the General tab, select PROFINET interface [X1] > Operating mode > I-device communication. From the "Export generic station description file (GSD)" area, click the Export button. If you do not change the name in the Export dialog, the GSD file uses an assigned format name (for example, "GSDML-V2.31-#Siemens-PreConf_S7-1200-I-Device-20130925-123456").
Procedure: Creating the Controller1 project
To create the first project with a shared I-device, follow these steps:
Start STEP 7.
From the Options menu, select "Manage general station description files (GSD)".
From the "Manage general station description files" dialog, install the PROFINET GSD file that you exported.
Create a new project with the name "Controller1".
Insert the CPU 1215C in the network view. The name of the CPU should be "Controller1".
Insert the I-device from the hardware catalog (Hardware catalog: Other field devices > PROFINET IO > PLCs & CPs).
Assign the IO controller "Controller1" to the I-device.
Select the "Shared device" area in the properties of the I-device:
In the table, all transfer areas and the PROFINET interface are assigned to the local IO controller (Controller1).
Define the transfer areas to which the Controller1 CPU should not have access. Select the "---" entry for these areas. These transfer areas are provided for Controller2.
You can adapt the addresses from the Device view of the IO controller in the Device overview. To open the device overview, double-click the I-device.
Save the project.
Procedure - Creating the Controller2 project
To create the second project with a shared device, follow these steps:
Start STEP 7 once again.
A new instance of STEP 7 opens.
In the new instance, create a new project with the name "Controller2".
Insert the CPU 1215C in the network view. Assign the name "Controller2".
Insert the I-device from the hardware catalog (Hardware catalog: Other field devices > PROFINET IO > PLCs & CPs).
Assign the IO controller "Controller2" to the I-device.
Adapt the access to the transfer areas as in the Controller1 project. Ensure that no duplicate assignments result.
Adapt the parameters of the subnet and PROFINET interface. Because the shared I-device involves the same device in different projects, these data must match.
Save the project.
Both projects now have an identically configured shared I-device. The IO controller access and the parameters of the PROFINET interface should still be checked in the different projects during the next step.
Summary - Assigning parameters for access to the shared device
The transfer areas are automatically assigned to the local IO controller. To change the assignment, follow these steps:
Click the "S7-1200-I-Device" device in the network view of the "Controller1" project, and select the "Shared device" area.
A table shows which CPU has access to each of the configured transfer areas. The default setting is that the local CPU has access to all modules and submodules.
Keep the setting "Controller1" for all transfer areas that are to remain in the address range of the local CPU.
Select the setting "---" for all transfer areas that are to be located in the address range of the "Controller2" CPU from the "Controller2" project. This means that an IO controller outside the project is to have access to the transfer area.
Follow the same procedure for the remaining projects.
Finally, check whether the settings for access are "complementary" for each module or submodule in both projects. This means that if the local CPU has access in one project, the option "---" must be set in the other project and vice versa.
Note: The option "---" for the PROFINET interface and therefore for the ports makes the associated parameters read-only and not changeable. Parameters of the PROFINET interface and port parameters can only be edited in the project in which the PROFINET interface is assigned to the local CPU. The ports can be interconnected in both projects regardless of this.
Check whether the same IP address parameters and device name are set for the shared device in all projects.
Check whether the same S7 subnet ID is set in all projects for the subnet to which the shared device is connected (subnet properties, "General" area in the Inspector window).
If you make changes to the I-device (for example, change the number or length of the transfer areas), export the I-device as a GSD file again. Re-install the GSD file in each project that uses the I-device as a shared device. Make sure that only one IO controller has access to a transfer area.
When you use the S7-1200 as a shared I-device and as a controller, ensure that you increase the PROFINET I-device and PROFINET IO Update times to alleviate the communications performance impact. The system is very stable and works well when you select 2 ms for the Update time of a single PROFINET I-device time and you select 2 ms for the Update time of a single PROFINET IO time.
You specify the "IO cycle" parameters in the "Properties" configuration dialog of the PROFINET I-device or IO. Refer to "Configuring the IO cycle time" for further information.
Procedure - Adjusting the real-time settings
To ensure that all IO controllers and shared devices are operated with the appropriate send clock and that the update times are calculated correctly based on the communication load, you must adjust and check the following settings:
You must set the same send clock for each IO controller that has access to modules and submodules of the shared device:
If you configure the IO controller with STEP 7 (TIA Portal), perform these steps:
Open the corresponding project.
Select the PROFINET interface of the IO controller.
Select the "Advanced options > Real time settings > IO cycle" area in the Inspector window and set the shared send clock.
If you configure the IO controller with a different engineering tool, perform these steps:
Select the PROFINET interface of the shared device in STEP 7 (TIA Portal) and read out the send clock on the shared device ("Advanced options > Real time settings" area)
Enter the read send clock in the engineering tool.
If you configure all IO controllers that have access to the shared I-device in STEP 7 (TIA Portal), you can set shorter send clocks on the IO controller than supported by the shared device (send clock adaptation).
Compiling and downloading
You must compile the configurations for the different IO controllers and download them to the CPUs one after the other.
Due to the distributed configuration with separate projects, STEP 7 does not output consistency errors in the case of incorrect access parameter assignment. These are examples of incorrect access parameter assignment:
Several IO controllers have access to the same module.
IP address parameters or send clocks are not identical.
These errors do not show up until controller operation and are output as configuration errors.
The following CPUs support MRP functionality as a MRP Manager and a client.
CPU 1215C
CPU 1217C
CPU 1215FC
As a "Client" the 1215/1217 must operate in an MRP ring by forwarding MRP packets over its interface and reporting connection breaks to a manager in the network.
As a "Manager" the 1215/1217 must send MRP packets around the network, detect open ports in the ring, manage blocked ports, and negotiate manager status with other potential managers.
The S7-1200 CPU family has three models (see above) that support the MRP protocol, and the configuration parameters used to initialize MRP client and manager operation. These CPUS have two PN ports.
With these three CPUs you can set up an MRP ring with the S7-1200 as either a client or a manager. When acting as a manager, the CPU uses test frames to check and make sure the ring is not interrupted. When acting as a client, it forwards these test frames instead of making the check itself. This allows the S7-1200 to be used in both roles if needed.
MRP Manager (auto) role and Manager
You can use the S7-1200 (1215C/1217C) as a Manager and Manager (auto) role in a Media Redundancy Ring (MRP). MRP allows you to connect their devices into a ring configuration. The MRP Manager typically forces data to flow in one linear direction by blocking a port of the ring. When this ring configuration experiences an interruption, the Manager detects the interruption and unblocks the port, allowing data to flow in the other direction. MRP allows the network to remain operational because of a broken wire or failed device. MRP Specification allows a maximum of 50 devices in a ring configuration.
MRP Manager
The MRP Manager allows the S7-1200 PLC to act as the redundancy manager. When configured for this role, the S7-1200 uses test frames to communicate with client PLCs to ensure connection within the ring is not interrupted. If an interruption to a client is detected, the S7-1200, acting as the MRP Manager, will inform client devices within the ring of the change immediately using the ring ports. TIA Portal only allows one device to be set to MRP Manager in an MRP Loop.
MRP Manager (auto) role
When multiple devices are assigned the MRP Manager (auto) role, they negotiate for Manager status amongst one another. If the negotiated MRP Manager is disconnected from the configuration, the remaining devices set as Manager (auto) will renegotiate the Manager role amongst themselves until the original configuration returns. When the original manager returns successfully, they will renegotiate the manager status back, and resume the original configuration.
Reconfiguration of ring
The reconfiguration of the ring can take up to 200 ms. For this reason, the PROFINET watchdog time for each device must be set higher than 200 ms.
MRP Manager (auto) mode is default
If there is not a project, the CPU will, by default, be in the MRP Manager (auto) mode. This is important to know if you plug an out-of-the-box device into a non-ring topology and notice test frames on your network.
S7-1200 (1214C, 1212C, and 1211C CPUs) cannot enable MRP Manager and Manager (auto) functionality. The menu options in TIA Portal are not available for these CPUs.
The S7-1200 does not support MRPD because the S7-1200 does not have IRT (Isochronous Realtime) capability.
Diagnostic interrupts can be toggled on and off in the media redundancy configuration window of the TIA portal to allow the manager and clients to provide relevant MRP change reports such as:
A neighbor device of the ring port not supporting MRP
A ring port being connected to a non-ring port neighbor
A ring port connected to a different MRP Domain
(Manager only) Interruption / return diagnostic interrupts when the MRP ring is interrupted and when the original configuration returns
In order to increase the network availability of an Industrial Ethernet network with optical or electrical linear bus topologies, you can convert a linear bus topology to a ring topology by joining the ends together.
Devices in a ring topology can be IO devices, IO controllers, external switches, and/or the integrated switches of communication modules.
To set up a ring topology with media redundancy, you need to bring together the two free ends of a linear bus topology in one device. Closing the linear bus topology to form a ring is achieved with two ports (ring ports) of a device in the ring. One device of the resulting ring then takes over the role of the MRP manager. All other devices in the ring are MRP clients.
① | MRP manager (Can be an S7-1500 CPU, an S7-1200 CPU 1215C, an S7-1200 CPU 1215FC, or an S7-1200 CPU 1217C) |
② | Test frames |
③ | MRP clients |
The ring ports of a device are the ports that establish the connection to the two neighboring devices in the ring topology. The ring ports are selected and set in the configuration of the relevant device (is also preset, if applicable).
How media redundancy works in a ring topology
The data paths between the individual devices are automatically reconfigured if the ring is interrupted at any point. The devices are available again after reconfiguration.
In the MRP manager, one of the two ring ports is blocked in uninterrupted network operation for normal communication so that no data frames are circulated. The MRP manager monitors the ring for interruptions. It does this by sending test frames both from ring port 1 and ring port 2. The test frames run round the ring in both directions until they arrive at the other ring port of the MRP manager.
An interruption of the ring can be caused by loss of the connection between two devices or by failure of a device in the ring.
If the test frames of the MRP manager no longer arrive at the other ring port during an interruption of the ring, the MRP manager connects its two ring ports. This substitute path once again restores a functioning connection between all remaining devices in the form of a linear bus topology.
The time between the ring interruption and restoration of a functional linear topology is known as the reconfiguration time.
As soon as the interruption is eliminated, the original transmission paths are established again, the two ring ports of the MRP manager are disconnected, and the MRP clients informed of the change. The MRP clients then use the original paths again to the other devices.
Media redundancy method
The standard method of media redundancy in SIMATIC is Media Redundancy Protocol (MRP) with a typical reconfiguration time of 200 ms. Up to 50 devices can participate per ring.
Reconfiguration of ring
The reconfiguration of the ring can take up to 200 ms. The PROFINET watchdog time for each device must be set higher than 200 ms.
The "MRP" process works in conformity with Media Redundancy Protocol (MRP), which is specified in IEC 61158 Type 10 "PROFINET".
Requirements
The following requirements must be met for error-free operation with MRP:
The ring in which you want to use MRP may only consist of devices that support this function.
"MRP" must be activated for all devices in the ring.
All devices must be interconnected using their ring ports.
At least one MRP manager or Role "Manager" must be available.
The ring must contain not more than 50 devices. Otherwise, reconfiguration times of greater than or equal to 200 ms can occur.
All partner ports within the rings must have identical settings.
Topology
The following schematic shows a possible topology for devices in a ring with MRP. The devices inside the shaded oval are in the redundancy domain.
This is an example of a ring topology with MRP:
The following rules apply to a ring topology with media redundancy using MRP:
All devices in the ring belong to the same redundancy domain.
One device in the ring must be configured for the role of MRP manager or MRP manager(auto).
Only one device in the ring can be an MRP manager; all other devices must be MRP clients.
If there is no MRP manager, multiple devices can be configured as MRP manager(auto).
You can connect non MRP-compliant devices to the network through ports not configured as ring ports. You can only do this with devices that have more than two ports (for example, a SCALANCE X switch or a PC with a CP1616).
Boundary conditions
You can have the following communication possibilities:
MRP and RT: RT operation is possible with the use of MRP.
The RT communication is disrupted (station failure) if the reconfiguration time of the ring is greater than the selected watchdog time of the IO device. You must select a watchdog time greater than 200 ms for your IO devices. Refer to the "Watchdog time" section below for further information.
MRP and TCP/IP (TSEND, HTTP, ...): The TCP/IP communication with MRP is possible because lost data packages are resent, if applicable.
MRP and prioritized startup:
If you configure MRP in a ring, you cannot use the "prioritized startup" function in PROFINET applications on the devices involved.
If you want to use the "prioritized startup" function, then you must disable MRP in the configuration (the device cannot be part of the ring).
MRP on PROFINET devices with more than two ports: If you operate a PROFINET device with more than two ports in a ring, you should set a sync boundary on the ports that are not in the ring. By setting the sync boundary, you define a boundary for a sync domain. You cannot forward sync frames transmitted to synchronize devices within a sync domain.
Watchdog time
The PROFINET watchdog time is the time interval that an IO controller or IO device permits, without receiving IO data. If the IO device is not supplied by the IO controller with data within the watchdog time, the device detects the missing frames and outputs substitute values. This is reported in the IO controller as a station failure.
You can configure the watchdog time for PROFINET IO devices. Do not enter the watchdog time directly, but as "Accepted update cycles without IO data". The resulting watchdog time is automatically calculated from the number of update cycles.
To assign the watchdog time, follow these steps:
Select the PROFINET interface of the IO device in the Network or Device view.
In the properties of the interface, navigate to: Advanced options > Realtime settings > IO cycle
Select the required number of cycles from the drop-down list.
All of the components in your application must support Media Redundancy Protocol (MRP).
Procedure
To configure media redundancy, proceed as follows:
Establish a ring by means of appropriate port interconnections (for example, in the topology view).
Select a PROFINET device for which you want to configure media redundancy.
In the Inspector window, navigate to "PROFINET" interface [X1]">"Advanced options">"Media redundancy".
Under "Media redundancy role", assign the "Manager (Auto)", "Client", or "Not device in the ring" role to the device.
When you configure a ring in the TIA Portal Topology view, the TIA Portal automatically sets the Media Redundancy role for you. If a device can be a Manager, the TIA Portal sets the Media redundancy role as "Manager (Auto)". For the S7-1200, the Media Redundancy role can now be set to either "Client" or "Manager".
You can assign the "Manager" or "Manager (Auto)" MRP roles to the S7-1200 CPU 1215C/1215FC/1217C.
Repeat steps 2 to 4 for all PROFINET devices in the ring.
Or:
Highlight the PROFINET IO system in the network view.
Click on the PROFINET IO system.
Navigate to the device of the required MRP domain in the inspector window.
For the PROFINET devices, set the "Manager (Auto)", "Client", or "Not device in the ring" role.
"Media redundancy" setting option: MRP role
Depending on the device used, the roles "Manager", "Manager (Auto)", "Client", and "Not device in the ring" are available.
Rules:
A ring can have only one device with the role of "Manager". No additional devices with the role of "Manager" or "Manager (Auto)" are permissible. All other devices in the ring can only have the role of "Client". Devices not in the ring can have the role "Not device in the ring".
If a ring has no device with the "Manager" role, the ring must at least have one device with the role "Manager (Auto)". A ring can have any number of devices with the roles "Client" and "Manager (Auto)".
"Media redundancy" setting option: Ring port 1 and Ring port 2
Select one at a time those ports you want to configure as ring port 1 or ring port 2. The drop-down list box shows the selection of possible ports for each device type. If the ports are set at the factory, then the fields are unavailable.
Ring port configuration is not necessary in the S7-1200 because the S7-1200 CPU has only two ports.
Diagnostic interrupts
If diagnostic interrupts to the MRP state are to be output in the local CPU, select the "Diagnostic interrupts" check box. The following diagnostic interrupts can be configured:
Wiring or port error:
The CPU generates diagnostic interrupts for the following errors in the ring ports:
A neighbor of the ring port does not support MRP.
A ring port is connected to a non-ring port.
A ring port is connected to the ring port of another MRP domain.
Interruption / return (MRP manager only):
If the ring is interrupted and the original configuration is returned, the CPU generates diagnostic interrupts. If both of these interrupts occur within 0.2 seconds, this indicates an interruption of the ring.
You can respond to these events in the user program by programming the appropriate response in the diagnostic error interrupt OB (OB 82).
Third-party devices as MRP manager
To assure error-free operation when a third party device is used as MRP manager in a ring, you must assign the fixed role of "Client" to all other devices in the ring before you close the ring. Otherwise, circulating data frames and network failure could occur.
From the STEP 7 Network view, you can create a complex communication topology by connecting devices in different S7 subnets. You can connect classic S7-300/S7-400 CPUs and CPs as well as the latest S7 CPUs and CPs and can include HMIs and PC stations such as an OPC server.
Once you decide which devices must communicate and establish the necessary connections using STEP 7, the Engineering System (ES) can download the corresponding routing tables to the various S7 routers as part of the hardware configuration. After you download the routing tables to the various S7 routers, the ES or other communication partners can communicate with each device even though the devices are on different S7 subnets. This is possible because the CPUs and/or CPs, in between, act as S7 routers. The CPUs and/or CPs forward incoming connection requests to the next S7 router until the connection request reaches the targeted device, and the devices establish the S7 connection.
The CPU uses the write record mechanism to transfer the routing tables required by the CP devices in the local base. The routing tables establish the route from one device to another at the time of a connection request, which includes a remote S7 Subnet_ID. The device receiving the connection request interrogates its routing table, finds the next station in the path to the target S7 subnet, and forwards the connection request. Eventually, the connection request reaches the intended target and the response traverses the route in the reverse direction.
The S7-1200 CPUs have a single PN interface and up to three CP devices connected to the local communication bus. Therefore, you have two options for routing within the S7-1200 station:
Routing between the CPU and a CP
Routing from one CP to another CP
Refer to S7-1200 CPs at Siemens Industry Online Support for further information on all S7-1200 CPs that support the S7 routing function.
Since the S7-1200 CPUs are limited to a single PN interface, a stand-alone CPU cannot serve the function of a router. You can never connect a stand-alone CPU to more than one S7 subnet at a time. When you install CP modules in the local base of the CPU, you can connect to multiple S7 subnets and utilize routing.
In the example system below, in order for PLC_1 to communicate with PLC_3, the Engineering System (ES) must rout messages through PLC_2. The ES must download the routing table for PLC_2, and PLC_2 must provide the routing table for the CP module in its local base. With these routing tables in place, PLC_1 and PLC_3 can communicate with each other, even though not directly connected.
In order to check routing from either S7 subnet to the other S7 subnet, PLC_1 must establish a transport connection to PLC_3, and PLC_3 must establish a connection to PLC_1. Doing so, makes sure that routing from the PLC’s PN/IE interface to a CP module is possible as well as routing from a CP module to the PLC’s PN/IE interface.
Since the S7-1200 CPUs support up to three CP modules, you can connect all three modules to different S7 subnets. When you install at least two CP modules in the local base of the CPU and connect to different S7 subnets, you can utilize routing.
In the example system below, in order for PLC_1 to communicate with PLC_3, the Engineering System (ES) must rout messages by PLC_2 from the CP module to the CP module in its local base. The ES must download the routing table for PLC_2, and PLC_2 must provide the routing table for the two CP modules. With these routing tables in place, PLC_1 and PLC_3 can communicate with each other, even though not directly connected. Also, you should note that routing takes place from CP module to CP module without messages being sent over the PN/IE interface of PLC_2.
Simple Network Management Protocol (SNMP) is an Internet-standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, and more.
Network management systems use SNMP to monitor network-attached devices for conditions that warrant administrative attention. SNMP uses various services and tools for detection and diagnostics of the network topology. You can find information about the properties of devices capable of SNMP in the Management Information Base (MIB) files. You must have the required rights to access the MIB files.
SNMP exposes management data in the form of variables on the managed systems, which describe the system configuration. Managing applications can query (and sometimes set) these variables.
SNMP uses the UDP transport protocol and has two network components:
SNMP manager: Monitors the network nodes
SNMP client: Collects the various network-specific information in the individual network nodes and stores it in a structured form in the Management Information Base (MIB). You can use this data to perform detailed network diagnostics.
For security reasons, SNMP is disabled by default on S7-1200 CPUs, preventing read and write access of SNMP variables. You must enable SNMP to remotely view and edit SNMP variables.
S7-1200 CPUs prior to V4.6 enable SNMP by default. If you downgrade the firmware to a version earlier than V4.6, you can only disable SNMP from the STEP 7 program.
After enabling SNMP, certain conditions might require you to disable it. Examples of these conditions include the following:
The security settings in your network do not allow the use of SNMP.
You use your own SNMP solution (for example, with your own communications instructions).
If SNMP is disabled on the device, some functions and tools that rely on access to SNMP variables are unavailable or inoperable. For example, topology detection in TIA Portal is inoperable, and some functions of the SIMATIC Automation Tool V4.x and prior, are inoperable.
You can enable or disable SNMP from the device configuration and STEP 7 program.
Restoring the CPU to factory defaults disables SNMP.
Enabling and disabling SNMP from the device configuration
To enable or disable SNMP follow these steps:
From the Project Tree, under the CPU, double-click Device configuration.
From the General tab of the device properties, expand Advanced configuration and select SNMP.
The Inspector window displays the SNMP configuration settings.
To enable SNMP, select the "Activate SNMP" checkbox or to disable SNMP, deselect it.
Enter a Read-only community string or use the default (public) and enter a Read-write community string or use the default (private).
Follow these conventions when entering Read-only and Read-write community strings:
Names must be at least 8 characters long, but no more than 240 characters long.
Names can include any letter of the alphabet or number.
Names cannot end or begin with a period or hyphen.
To share SNMP data between the STEP 7 project and the PLC, the community name entered in the STEP 7 project must match the community name entered for the host when creating the SNMP database connection.
Download the configuration to the CPU.
Enabling and disabling SNMP from the STEP 7 program
To enable or disable SNMP follow these steps:
Create a data block (DB):
Select the Properties of the newly-created DB.
Select the Attributes tab. Deselect the check box for "Optimized block access":
Click the OK button.
When prompted, recompile your program.
In the DB block interface, create the following static tags with the values shown. You will use these tags in your program to enable or disable the internal SNMP implementation. Change the Start value of the SNMPControl tag to enable or disable SNMP. Entering a Start value of 1 enables SNMP, while entering a Start value of 0 disables SNMP:
Add the Temporary variables, as shown below, to any program block (OB, FB, or FC) that executes when you want to enable or disable SNMP. This example uses Startup OB (OB100) to enable SNMP at the beginning of the program's execution:
Using the LAD editor insert a Label (Jump label) into Network 1 of the Startup OB (OB100). In the example below, the Label is named "Check." Then, in the same network, insert a WRREC (Write Record) instruction with the inputs and outputs shown:
Enter the following code for Network 2. This code ensures that the WRREC call completes, enabling or disabling SNMP before leaving the Startup OB (OB100):
Download the STEP 7 project software to the CPU.
You cannot set community strings from the STEP 7 program. You can activate configured community strings from the STEP 7 program. When activating SNMP from the STEP 7 program, SNMP is active in RUN mode and is non-retentive. Because it is non-retentive, after a POWER OFF/ ON transition SNMP reverts to the settings selected in the device configuration. When activating SNMP from the device configuration, SNMP is active at download and is retentive.
Refer to "Organization blocks (OBs)" for information on how to use organization blocks (OBs) for diagnostics with these communication networks.
Refer to Distributed I/O (PROFINET, PROFIBUS, or AS-i) for information on Distributed I/O and Diagnostics instructions.
Refer to Diagnostic events for distributed I/O for handling diagnostic events.
A PROFIBUS system uses a bus master to poll slave devices distributed in a multi-drop fashion on an RS485 serial bus. A PROFIBUS slave is any peripheral device (I/O transducer, valve, motor drive, or other measuring device) that processes information and sends its output to the master. The slave forms a passive station on the network since it does not have bus access rights, and can only acknowledge received messages, or send response messages to the master upon request. All PROFIBUS slaves have the same priority, and all network communication originates from the master.
A PROFIBUS master forms an "active station" on the network. PROFIBUS DP defines two classes of masters. A class 1 master (normally a central programmable controller (PLC) or a PC running special software) handles the normal communication or exchange of data with the slaves assigned to it. A class 2 master (usually a configuration device, such as a laptop or programming console used for commissioning, maintenance, or diagnostics purposes) is a special device primarily used for commissioning slaves and for diagnostic purposes.
The S7-1200 is connected to a PROFIBUS network as a DP slave with the CM 1242-5 communication module. The CM 1242-5 (DP slave) module can be the communications partner of DP V0/V1 masters. If you want to configure the module in a third-party system, there is a GSD file available for the CM 1242‑5 (DP slave) that ships with the module and on Siemens Industry Online Support pages on the Internet.
In the figure below, the S7-1200 is a DP slave to an S7-1500 controller:
The S7-1200 is connected to a PROFIBUS network as a DP master with the CM 1243-5 communication module. The CM 1243-5 (DP master) module can be the communications partner of DP V0/V1 slaves. In the figure below, the S7-1200 is a master controlling an ET 200SP DP slave:
If a CM 1242-5 and a CM 1243-5 are installed together, an S7-1200 can perform as both a slave of a higher-level DP master system and a master of a lower-level DP slave system, simultaneously:
You can configure a maximum of three PROFIBUS CMs per station, in which there can be any combination of DP master or DP slave CMs. DP masters can each control a maximum of 32 slaves.
The configuration data of the PROFIBUS CMs is stored on the local CPU. This allows simple replacement of these communications modules when necessary.
To use PROFIBUS, the PROFIBUS Master CM firmware must be at least V1.3.
Always update the PROFIBUS CM firmware to the latest version available. You can perform a firmware update by any of these methods:
The PROFIBUS CMs use the PROFIBUS DP-V1 protocol.
Types of communication with DP‑V1
The following types of communication are available with DP-V1:
Cyclic communication (CM 1242‑5 and CM 1243‑5)
Both PROFIBUS modules support cyclic communication for the transfer of process data between DP slave and DP master.
Cyclic communication is handled by the operating system of the CPU. No software blocks are required for this. The I/O data is read or written directly from/to the process image of the CPU.
Acyclic communication (CM 1243‑5 only)
The DP master module also supports acyclic communication using software blocks:
The "RALRM" instruction is available for interrupt handling.
The "RDREC" and "WRREC" instructions are available for transferring configuration and diagnostics data.
Functions not supported by the CM 1243‑5: SYNC/FREEZE and Get_Master_Diag
Other communications services of the CM 1243‑5
The CM 1243‑5 DP master module supports the following additional communications services:
S7 communication
PUT/GET services
The DP master functions as a client and server for queries from other S7 controllers or PCs via PROFIBUS.
PG/OP communication
The PG functions allow the downloading of configuration data and user programs from a PG and the transfer of diagnostics data to a PG.
Possible communications partners for OP communication are HMI panels, SIMATIC panel PCs with WinCC flexible or SCADA systems that support S7 communication.
In the "Devices and networks" portal, use the hardware catalog to add PROFIBUS modules to the CPU. These modules are connected to the left side of the CPU. To insert a module into the hardware configuration, select the module in the hardware catalog and either double-click or drag the module to the highlighted slot.
Module | Select the module | Insert the module | Result |
|---|---|---|---|
CM 1243-5 (DP master) |  |  |
Use the hardware catalog to add DP slaves as well. For example, to add an ET 200SP DP slave, in the Hardware Catalog, expand the following containers:
Distributed I/O
ET 200SP
Interface modules
PROFIBUS
Next, select "6ES7 155-6BU00-0CN0" (IM155-6 DP HF) from the list of part numbers, and add the ET 200SP DP slave as shown in the figure below.
Insert the DP slave | Result |
|---|---|
 |  |
After you configure the CM 1243-5 (DP master) module, you are now ready to configure your network connections.
In the Devices and Networks portal, use the "Network view" to create the network connections between the devices in your project. To create the PROFIBUS connection, select the purple (PROFIBUS) box on the first device. Drag a line to the PROFIBUS box on the second device. Release the mouse button and your PROFIBUS connection is joined.
Refer to "Device Configuration: Creating a network connection" for more information.
Configuring the PROFIBUS interface
After you configure logical network connections between two PROFIBUS devices, you can configure parameters for the PROFIBUS interfaces. To do so, click the purple PROFIBUS box on the CM 1243-5 module, and the "Properties" tab in the inspector window displays the PROFIBUS interface. The DP slave PROFIBUS interface is configured in the same manner.
CM 1243-5 (DP master) module | ET 200SP DP slave |
|---|---|
 |
① PROFIBUS port
Assigning the PROFIBUS address
In a PROFIBUS network, each device is assigned a PROFIBUS address. This address can range from 0 through 127, with the following exceptions:
Address 0: Reserved for network configuration and/or programming tools attached to the bus
Address 1: Reserved by Siemens for the first master
Address 126: Reserved for devices from the factory that do not have a switch setting and must be re-addressed through the network
Address 127: Reserved for broadcast messages to all devices on the network and may not be assigned to operational devices
Thus, the addresses that may be used for PROFIBUS operational devices are 2 through 125.
In the Properties window, select the "PROFIBUS address" configuration entry. STEP 7 displays the PROFIBUS address configuration dialog, which is used to assign the PROFIBUS address of the device.
Parameter | Description | |
|---|---|---|
Subnet | Name of the Subnet to which the device is connected. Click the "Add new subnet" button to create a new subnet. "Not connected" is the default. Two connection types are possible:
| |
Parameters | Address | Assigned PROFIBUS address for the device |
Highest address | The highest PROFIBUS address is based on the active stations on the PROFIBUS (for example, DP master). Passive DP slaves independently have PROFIBUS addresses from 1 to 125 even if the highest PROFIBUS address is set to 15, for example. The highest PROFIBUS address is relevant for token forwarding (forwarding of the send rights), and the token is only forwarded to active stations. Specifying the highest PROFIBUS address optimizes the bus. | |
Transmission rate | Transmission rate of the configured PROFIBUS network: The PROFIBUS transmission rates range from 9.6 Kbits/sec to 12 Mbits/sec. The transmission rate setting depends on the properties of the PROFIBUS nodes being used. The transmission rate should not be greater than the rate supported by the slowest node. The transmission rate is normally set for the master on the PROFIBUS network, with all DP slaves automatically using that same transmission rate (auto-baud). | |
Refer to Distributed I/O (PROFINET, PROFIBUS, or AS-i) for information on Distributed I/O and Diagnostics instructions.
Refer to Diagnostic events for distributed I/O for handling diagnostic events.
The S7-1200 AS-i master CM 1243-2 allows the attachment of an AS-i network to an S7-1200 CPU.
The actuator/sensor interface, or AS-i, is a single master network connection system for the lowest level in automation systems. The CM 1243-2 serves as the AS-i master for the network. Using a single AS-i cable, sensors and actuators (AS-i slave devices) can be connected to the CPU through the CM 1243-2. The CM 1243-2 handles all AS-i network coordination and relays data and status information from the actuators and sensors to the CPU through the I/O addresses assigned to the CM 1243-2. You can access binary or analog values depending on the slave type. The AS-i slaves are the input and output channels of the AS-i system and are only active when called by the CM 1243-2.
In the figure below, the S7-1200 is an AS-i master controlling AS-i I/O module digital/analog slave devices.
To use AS-i with S7-1200 V4.0 CPUs, you must upgrade the AS-i Master CM firmware to V1.1.
You can make this upgrade using the webserver or a SIMATIC memory card.
For V4.0 S7-1200 CPUs, if using the web server or a SIMATIC memory card to upgrade from V1.0 to V1.1 AS-i firmware, you must update the AS-i firmware in the AS-i Master CM 1243-2 according to the following procedure:
Download the firmware upgrade to the AS-i Master CM 1243-2.
When the download is complete, power cycle the S7-1200 CPU to complete the firmware upgrade process in the AS-i Master CM 1243-2.
Repeat steps 1 and 2 for each additional AS-i Master CM 1243-2. The S7-1200 PLC allows a maximum of three AS-i Master CM 1243-2.
It is recommended that you always update the AS-i CM firmware to the latest version available at the Siemens Service and Support Web site.
The AS-i master CM 1243-2 is integrated into the S7-1200 automation system as a communication module.
You can find detailed information on the AS-i master CM 1243-2 in the "AS-i master CM 1243-2 and AS-i data decoupling unit DCM 1271 for SIMATIC S7-1200" Manual.
Use the hardware catalog to add AS-i master CM1243-2 modules to the CPU. These modules are connected to the left side of the CPU, and a maximum of three AS-i master CM1243-2 modules can be used. To insert a module into the hardware configuration, select the module in the hardware catalog and either double-click or drag the module to the highlighted slot.
Module | Select the module | Insert the module | Result |
|---|---|---|---|
CM 1243-2 AS-i Master |  |
Use the hardware catalog to add AS-i slaves as well. For example, to add an "I/O module, compact, digital, input" slave, in the Hardware Catalog, un-check Filter (if checked) and expand the following containers:
Field devices > AS-Interface > Input/Output modules IP6x, compact modules > Digital > Input > User modules > AS-i SM-U, 4DI
Next, select "3RG9 001-0AA00" from the list of part numbers, and add the "I/O module, compact, digital, input" slave as shown in the figure below.
Insert the AS-i slave | Result |
|---|---|
 |  |
After you configure the AS-i master CM1243-2, you are now ready to configure your network connections.
In the Devices and Networks portal, use the "Network view" to create the network connections between the devices in your project. To create the AS-i connection, select the yellow (AS-i) box on the first device. Drag a line to the AS-i box on the second device. Release the mouse button and your AS-i connection is joined.
Refer to "Device Configuration: Creating a network connection" for more information.
To configure parameters for the AS-i interface, click the yellow AS-i box on the AS-i master CM1243-2 module, and the "Properties" tab in the inspector window displays the AS-i interface.
In the STEP 7 inspector window, you can view, configure, and change general information, addresses and operating parameters:
Property | Description |
|---|---|
General | Name of the AS‑i master CM 1243‑2 |
Operating parameters | Parameters for the response of the AS-i master |
I/O addresses | Address area for the slave I/O addresses |
AS‑i interface (X1) | Assigned AS-i network |
"Diagnostic interrupt for faults in the AS‑i configuration" and "Automatic address programming" are always active and are therefore shown in gray.
Configuring the AS-i slave interface
To configure parameters for the AS-i interface, click the yellow AS-i box on the AS‑i slave, and the "Properties" tab in the inspector window displays the AS-i interface.
① | AS-i port |
Assigning the AS-i slave address
In an AS-i network, each device is assigned an AS-i slave address. This address can range from 0 through 31; however, address 0 is reserved only for new slave devices. The slave addresses are 1(A or B) to 31(A or B) for a total of up to 62 slave devices.
"Standard" AS-i devices use the entire address, having a number address without the A or B designation. "A/B node" AS-i devices use the A or B portion of each address, enabling each of the 31 addresses to be used twice. The address space range is 1A to 31A plus 1B to 31B.
Any address in the range of 1 - 31 can be assigned to an AS-i slave device; in other words, it does not matter whether the slaves begin with address 21 or whether the first slave is actually given the address 1.
In the example below, three AS-i devices have been addressed as "1" (a standard type device), "2A" (an A/B node type device), and "3" (a standard type device):
① | AS-i slave address 1; Device: AS-i SM-U, 4DI; article number: 3RG9 001-0AA00 |
② | AS-i slave address 2A; Device: AS-i 8WD44, 3DO, A/B; article number: 8WD4 428-0BD |
③ | AS-i slave address 3; Device: AS-i SM-U, 2DI/2DO; article number: 3RG9 001-0AC00 |
Enter the AS-i slave address here:
Parameter | Description | |
|---|---|---|
Network | Name of the network to which the device is connected | |
Address(es) | Assigned AS-i address for the slave device in range of 1(A or B) to 31(A or B) for a total of up to 62 slave devices | |
The AS-i master reserves a 62-byte data area in the I/O area of the CPU. Access to the digital data is performed here in bytes; for each slave, there is one byte of input and one byte of output data.
The assignment of the AS-i connections of the AS-i digital slaves to the data bits of the assigned byte is indicated in the inspection window of the AS-i master CM 1243-2.
You can access the data of the AS-i slaves in the user program by using the displayed I/O addresses with the appropriate bit logic operations (for example, "AND") or bit assignments.
"System assignment" is automatically activated if you do not configure the AS-i slaves with STEP 7.
If you do not configure any slaves, you must inform the AS-i master CM1243-2 about the actual bus configuration using the online function "ACTUAL > EXPECTED".
Further information
You can find detailed information on the AS-i master CM 1243-2 in the "AS-i master CM 1243-2 and AS-i data decoupling unit DCM 1271 for SIMATIC S7-1200" Manual.
Transferring AS-i digital values
The CPU accesses the digital inputs and outputs of the AS-i slaves through the AS-i master CM1243-2 in cyclic operation. The data is accessed through I/O addresses or by means of a data record transfer.
① | AS-i slave address 1 |
② | AS-i slave address 2A |
③ | AS-i slave address 3 |
Access to the digital data is performed here in bytes (in other words, one byte is assigned to each AS-i digital slave). When you configure the AS-i slaves in STEP 7, the I/O address for accessing the data from the user program is displayed in the inspection window for the respective AS-i slave.
The digital input module (AS-i SM-U, 4DI) in the AS-i network above has been assigned slave address 1. By clicking on the digital input module, the "AS interface" tab in the device "Properties" displays the slave address, as shown below:
The digital input module (AS-i SM-U, 4DI) in the AS-i network above has been assigned I/O address 2. By clicking on the digital input module, the "I/O addresses" tab in the device "Properties" displays the I/O address, as shown below:
You can access the data of the AS-i slaves in the user program by using their I/O addresses with the appropriate bit logic operations (for example, "AND") or bit assignments. The following simple program illustrates how the assignment works:
Input 2.0 is polled in this program. In the AS-i system, this input belongs to slave1 (Input byte 2, bit 0). Output 4.3, which is then set, corresponds to AS-i slave 3 (Output byte 4, bit 3)
Transferring AS-i analog values
You can access analog data of an AS-i slave through the process image of the CPU if you have configured this AS-i slave in STEP 7 as an analog slave.
If you did not configure the analog slave in STEP 7, you can only access the data of the AS-i slave through the acyclic functions (data record interface). In the user program of the CPU, AS-i calls are read and written using the RDREC (read data record) and WRREC (write data record) distributed I/O instructions.
A configuration of the AS-i slaves specified through STEP 7 and downloaded into the S7 station is transferred by the CPU on the AS-i master CM1243-2 during S7 station start-up. Any existing configuration that was determined through the "System assignment" online function ("ACTUAL -> EXPECTED") will be overwritten.
Further information
You can find detailed information on the AS-i master CM 1243-2 in the "AS-i master CM 1243-2 and AS-i data decoupling unit DCM 1271 for SIMATIC S7-1200" Manual.
Refer to Distributed I/O (PROFINET, PROFIBUS, or AS-i) for information on Distributed I/O and Diagnostics instructions.
Refer to DPNRM_DG (Read diagnostic data from a PROFIBUS DP slave) for handling diagnostic events.
You must go online in STEP 7 to view and change the AS-i operational modes.
To change the AS-i operational modes, follow these steps:
Select the AS-i master CM1243-2 module from the device configuration of your PLC.
Click the "Go online" button in the toolbar.
Select the "Online and diagnostics" command from the "Online" menu or from the project tree.
Under "Operating mode" for the Control panel, you see two modes:
Configuration mode:
You can make required changes in your AS-i slave device and CPU I/O addresses.
The green "CM" LED is ON.
Protected operation:
You cannot change AS-i slave device and CPU I/O addresses.
The green "CM" LED is OFF.
If your mode is configuration mode, you can set the AS-i slave address. A new slave that has not been assigned an address always has address 0. The master detects it as a new slave without an address assignment. It is not included in normal communication until assigned an address.
Configuration error
When the yellow "CER" LED is ON, there is an error in the AS-i slave device configuration. Select the "ACTUAL > EXPECTED" button to overwrite the AS-i master CM1243-2 module slave device configuration with the AS-i field network slave device configuration.
You can use the GET and PUT instructions to communicate with S7 CPUs through PROFINET and PROFIBUS connections. This is only possible if the "Permit access with PUT/GET communication from remote partner" function is activated for the partner CPU in the "Protection & Security" property of the local CPU properties:
Accessing data in a remote CPU: An S7-1200 CPU can only use absolute addresses in the ADDR_x input field to address variables of remote CPUs (S7-200/300/400/1200).
Accessing data in a standard DB: An S7-1200 CPU can only use absolute addresses in the ADDR_x input field to address DB variables in a standard DB of a remote S7 CPU.
Accessing data in an optimized DB: An S7-1200 CPU cannot access DB variables in an optimized DB of a remote S7-1200 CPU.
Accessing data in a local CPU: An S7-1200 CPU can use either absolute or symbolic addresses as inputs to the RD_x or SD_x input fields of the GET or PUT instruction, respectively.
GET/PUT operation is not automatically enabled for V4.x
To enable GET/PUT access, follow these steps:
Enable the Anonymous user under "Security settings" > "Users and roles".
Assign any access level to the Anonymous user.
In the CPU's "Device configuration" inspector window, select the "Properties" tab > "Protection & Security" and click the check box to "Permit access to the PUT/GET communication from remote partner".
Avoiding security risks from physical network attacks
If an attacker can physically access your networks, the attacker can possibly read and write data.
For example, I/O exchange through PROFIBUS, PROFINET, AS-i, or other I/O bus, GET/PUT, T-Block, and communication modules (CMs) have no security features. You must protect these forms of communication by limiting physical access. If an attacker can physically access your networks using these forms of communication, the attacker can possibly read and write data.
If you fail to protect these forms of communication, death or severe personal injury can result.
For security information and recommendations, see the "Operational Guidelines" white paper on the Siemens Industrial Cybersecurity Web site.
LAD / FBD | SCL | Description |
|---|---|---|
 | "GET_DB"( req:=_bool_in_, ID:=_word_in_, ndr=>_bool_out_, error=>_bool_out_, status=>_word_out_, addr_1:=_remote_inout_, [...addr_4:=_remote_inout_,] rd_1:=_variant_inout_ [,...rd_4:=_variant_inout_]); | Use the GET instruction to read data from a remote S7 CPU. The remote CPU can be in either RUN or STOP mode. STEP 7 automatically creates the DB when you insert the instruction. |
 | "PUT_DB"( req:=_bool_in_, ID:=_word_in_, done=>_bool_out_, error=>_bool_out_, status=>_word_out_, addr_1:=_remote_inout_, [...addr_4:=_remote_inout_,] sd_1:=_variant_inout_, [....sd_4:=_variant_inout_]); | Use the PUT instruction to write data to a remote S7 CPU. The remote CPU can be in either RUN or STOP mode. STEP 7 automatically creates the DB when you insert the instruction. |
Parameter and type | Data type | Description | |
|---|---|---|---|
REQ | Input | Bool | A low to high (positive edge) signal starts the operation. |
ID | Input | CONN_PRG (Word) | S7 connection ID (Hex) |
NDR (GET) | Output | Bool | New Data Ready:
|
DONE (PUT) | Output | Bool | DONE:
|
ERROR STATUS | Output Output | Bool Word |
|
ADDR_1 | InOut | Remote | Pointer to the memory areas in the remote CPU that stores the data to be read (GET) or that is sent (PUT). |
ADDR_2 | InOut | Remote | |
ADDR_3 | InOut | Remote | |
ADDR_4 | InOut | Remote | |
RD_1 (GET) SD_1 (PUT) | InOut | Variant | Pointer to the memory areas in the local CPU that stores the data to be read (GET) or sent (PUT). Data types allowed: Bool (only a single bit allowed), Byte, Char, Word, Int, DWord, DInt, or Real. Note: If the pointer accesses a DB, you must specify the absolute address, such as: P# DB10.DBX5.0 Byte 10 In this case, 10 represents the number of bytes to GET or PUT. |
RD_2 (GET) SD_2 (PUT) | InOut | Variant | |
RD_3 (GET) SD_3 (PUT) | InOut | Variant | |
RD_4 (GET) SD_4 (PUT) | InOut | Variant | |
You must ensure that the length (number of bytes) and data types for the ADDR_x (remote CPU) and RD_x or SD_x (local CPU) parameters match. The number after the identifier "Byte" is the number of bytes referenced by the ADDR_x, RD_x, or SD_x parameter.
The total number of bytes received on a GET instruction or the total number of bytes sent on a PUT instruction is limited. The limitations are based on how many of the four possible address and memory areas you use:
If you use only ADDR_1 and RD_1/SD_1, a GET instruction can get 222 bytes and a PUT instruction can send 212 bytes.
If you use ADDR_1, RD_1/SD_1, ADDR_2, and RD_2/SD_2, a GET instruction can get a total of 218 bytes and a PUT instruction can send a total of 196 bytes.
If you use ADDR_1, RD_1/SD_1, ADDR_2, RD_2/SD_2, ADDR_3, and RD_3/SD_3 a GET instruction can get a total of 214 bytes and a PUT instruction can send a total of 180 bytes.
If you use ADDR_1, RD_1/SD_1, ADDR_2, RD_2/SD_2, ADDR_3, RD_3/SD_3, ADDR_4, RD_4/SD_4 a GET instruction can get a total of 210 bytes and a PUT instruction can send a total of 164 bytes.
The sum of the number of bytes of each of your address and memory area parameters must be less than or equal to the defined limits. If you exceed these limits, the GET or PUT instruction returns an error.
On the rising edge of the REQ parameter, the read operation (GET) or write operation (PUT) loads the ID, ADDR_1, and RD_1 (GET) or SD_1 (PUT) parameters.
For GET: The remote CPU returns the requested data to the receive areas (RD_x), starting with the next scan. When the read operation has completed without error, the NDR parameter is set to 1. A new operation can only be started after the previous operation has completed.
For PUT: The local CPU starts sending the data (SD_x) to the memory location (ADDR_x) in the remote CPU. When the write operation has completed without error, the remote CPU returns an execution acknowledgement. The DONE parameter of the PUT instruction is then set to 1. A new write operation can only be started after the previous operation has completed.
To ensure data consistency, always evaluate when the operation has been completed (NDR = 1 for GET, or DONE = 1 for PUT) before accessing the data or initiating another read or write operation.
The ERROR and STATUS parameters provide information about the status of the read (GET) or write (PUT) operation.
ERROR | STATUS (decimal) | Description |
|---|---|---|
0 | 11 |
|
0 | 25 | Communication has started. The job is being processed. |
1 | 1 | Communications problems, such as:
|
1 | 2 | Negative acknowledgement from the partner device. The task cannot be executed. |
1 | 4 | Errors in the send area pointers (RD_x for GET, or SD_x for PUT) involving the data length or the data type. |
1 | 8 | Access error on the partner CPU |
1 | 10 | Access to the local user memory not possible (for example, attempting to access a deleted DB) |
1 | 12 | When the SFB was called:
|
1 | 20 |
This status is possible for first execution of the GET or PUT instruction |
1 | 27 | There is no corresponding GET or PUT instruction in the CPU. |
Connection mechanisms
To access remote connection partners with PUT/GET instructions, the user must also have permission.
By default, the "Permit access with PUT/GET communication from remote partner" option is not enabled. In this case, read and write access to CPU data is only possible for communication connections that require configuration or programming both for the local CPU and for the communication partner. Access through BSEND/BRCV instructions is possible, for example.
If the local CPU is used only as a server, the CPU cannot program or configure communication with the communication partner. The following connections are therefore not possible during the operation of the CPU:
PUT/GET, FETCH/WRITE or FTP access through communication modules
PUT/GET access from other S7 CPUs
HMI access through PUT/GET communication
If you want to allow access to CPU data from the client side, that is, you do not want to restrict the communication services of the CPU, you can configure the access protection for the S7-1200 CPU for this level of security.
Connection types
The connection type that you select creates a communication connection to a partner station. The connection is set up, established, and automatically monitored.
In the Devices and Networks portal, use the "Network view" to create the network connections between the devices in your project. First, click the "Connections" tab, and then select the connection type with the dropdown, just to the right (for example, an S7 connection). Click the green (PROFINET) box on the first device, and drag a line to the PROFINET box on the second device. Release the mouse button and your PROFINET connection is joined.
Click the "Highlighted: Connection" button to access the "Properties" configuration dialog of the communication instruction.
Configuring General parameters
You specify the communication parameters in the "Properties" configuration dialog of the communication instruction. This dialog appears near the bottom of the page whenever you have selected any part of the instruction.
Refer to "Device configuration: Configuring the Local/Partner connection path" for more information.
In the "Address Details" section of the Connection parameters dialog, you define the TSAPs or ports to be used. The TSAP or port of a connection in the CPU is entered in the "Local TSAP" field. The TSAP or port assigned for the connection in your partner CPU is entered under the "Partner TSAP" field.
The GET/PUT instructions connection parameter assignment is a user aid for configuring CPU-to-CPU S7 communication connections.
After inserting a GET or PUT block, STEP 7 displays the connection parameter assignment dialog for the GET/PUT instructions:
The inspector window displays the properties of the connection whenever you have selected any part of the instruction. You can configure the communication parameters in the "Configuration" tab of the "Properties" for the communication instruction.
GET/PUT operation is not automatically enabled for V4.x
To enable GET/PUT access, go to the CPU "Device configuration", inspector window "Properties" tab, "Protection & Security" property.
The "Connection parameters" page allows you to configure the necessary S7 connection and to configure the parameter "Connection ID" that is referenced by the GET/PUT block parameter "ID". The page's content has information about the local endpoint and allows you to define the local interface. You can also define the partner end point.
The "Block parameters" page allows you to configure the additional block parameters.
Parameter | Definition | |
|---|---|---|
Connection parameter: General | End point | "Local End point": Name assigned to the Local CPU "Partner End point": Name assigned to the Partner (remote) CPU Note: In the "Partner End point" dropdown list, the system displays all potential S7 connection partners of the current project as well as the option "unspecified". An unspecified partner represents a communication partner which is not currently in the STEP 7 project (for example, a third party device communication partner). |
Interface | Name assigned to the interfaces Note: You can change the connection by changing the Local and Partner interfaces | |
Interface type | Type of interface | |
Subnet name | Name assigned to the subnets | |
Address | Assigned IP addresses Note: You can specify the remote address of a third party device for an "unspecified" communication partner. | |
Connection ID | ID number: Automatically generated by the GET/PUT connection parameter assignment | |
Connection name | Local and Partner CPU data storage location: Automatically generated by the GET/PUT connection parameter assignment | |
Active connection establishment | Checkbox to select Local CPU as the active connection | |
One-way | Checkbox to specify a one-way or two-way connection; read-only Note: In a PROFINET GET/PUT connection, both the local and partner devices can act as a server or a client. This allows a two-way connection, and the "One-way" checkbox is unchecked. In a PROFIBUS GET/PUT connection, in some cases, the Partner device can only act as a server (for example, an S7-300), and the "One-way" checkbox is checked. | |
There are three ways to change the system-defined connection IDs:
The user can change the current ID directly on the GET/PUT block. If the new ID belongs to an already existing connection, the connection is changed.
The user can change the current ID directly on the GET/PUT block, but the new ID does not already exist. A new S7 connection is created by the system.
The user can change the current ID through the "Connection overview" dialog: The user-input is synchronized with the ID-parameter on the corresponding GET/PUT block.
The parameter "ID" of the GET/PUT block is not a connection name, but a numerical expression which is written like the following example: W#16#1
The connection name is editable through a special user control, the "Connection overview" dialog. This dialog offers all the available S7 connections which could be selected as an alternative for the current GET/PUT communication. The user can create a completely new connection in this table. Click the button to the right of the "Connection name" field to start the "Connection overview" dialog.
Given the configuration of PLC_1, PLC_2, and PLC_3 as shown in the figure below, insert GET or PUT blocks for "PLC_1".
For the GET or PUT instruction, the "Properties" tab is automatically displayed in the inspector window with the following menu selections:
Connection parameter
Block parameter
For the "Partner End point", select "PLC_3".
The system reacts with the following changes:
Parameter | Definition | |
|---|---|---|
Connection parameter: General | End point | "Local End point" contains "PLC_1" as read-only. "Partner End point" field contains "PLC_3[CPU319-3PN/DP]":
|
Interface | "Local Interface" contains "CPU1214C DC/DC/DC, PROFINET interface (R0/S1)". "Partner Interface" contains: "CPU319-3PN/DP, PROFINET interface (R0/S2)". | |
Interface type | "Local Interface type" contains "Ethernet/IP"; control is read-only. "Partner Interface type" contains "Ethernet/IP"; control is read-only. Interface type images are shown at the right beside the Local and Partner "Interface type" (green Ethernet icon). | |
Subnet name | "Local Subnet name" contains "PN/IE_1"; control is read only. "Partner Subnet name" contains "PN/IE_1"; control is read only. | |
Address | "Local Address" contains the Local IP address; control is read only. "Partner Address" contains the Partner IP address; control is read only. | |
Connection ID | "Connection ID" contains "100". In the Program editor, in the Main [OB1], the GET/PUT block "Connection ID" value also contains "100". | |
Connection name | "Connection name" contains the default connection name (for example, "S7_Connection_1"); control is enabled. | |
Active connection establishment | Checked and enabled to select the Local CPU as the active connection. | |
One-way | Read-only and unchecked. Note: "PLC_1" (an S7-1200 CPU 1214CDC/DC/Relay) and "PLC_3" (an S7-300 CPU 319-3PN/DP) can both act as a server and a client in a PROFINET GET/PUT connection, allowing a two-way connection. | |
The GET/PUT icon in the Property View tree also changes from red to green.
Completed PROFINET S7 connection
In the "Network view", a two-way S7 connection is shown in the "Connections" table between "PLC_1" and "PLC_3".
For the "Partner End point", select "PLC_3".
The system reacts with the following changes:
Parameter | Definition | |
|---|---|---|
Connection parameter: General | End point | "Local End point" contains "PLC_1" as read-only. "Partner End point" field contains "PLC_3[CPU319-3PN/DP]":
|
Interface | "Local Interface" contains "CPU1214C DC/DC/DC, PROFIBUS interface (R0/S1)". "Partner Interface" contains: "CPU319-3PN/DP, PROFIBUS interface (R0/S2)". | |
Interface type | "Local Interface type" contains "PROFIBUS"; control is read-only. "Partner Interface type" contains " PROFIBUS "; control is read-only. Interface type images are shown at the right beside the Local and Partner "Interface type" (purple PROFIBUS icon). | |
Subnet name | "Local Subnet name" contains " PROFIBUS _1"; control is read only. "Partner Subnet name" contains " PROFIBUS _1"; control is read only. | |
Address | "Local Address" contains the Local IP address; control is read only. "Partner Address" contains the Partner IP address; control is read only. | |
Connection ID | "Connection ID" contains "100". In the Program editor, in the Main [OB1], the GET/PUT block "Connection ID" value also contains "100". | |
Connection name | "Connection name" contains the default connection name (for example, "S7_Connection_1"); control is enabled. | |
Active connection establishment | Read-only, checked, and enabled to select the Local CPU as the active connection. | |
One-way | Read-only and checked. Note: "PLC_3" (an S7-300 CPU319-3PN/DP) can act only as a server (cannot also be a client) in a PROFIBUS GET/PUT connection, allowing only a one-way connection. | |
The GET/PUT icon in the Property View tree also changes from red to green.
Completed PROFIBUS S7 connection
In the "Network view", a one-way S7 connection is shown in the "Connections" table between "PLC_1" and "PLC_3".
With a PROFIBUS IO system, after a download or power cycle, the CPU will go to RUN mode unless the hardware compatibility is set to allow acceptable substitute modules and one or more modules is missing or is not an acceptable substitute for the configured module.
As shown in the following table, the CPU supports diagnostics that can be configured for the components of the distributed I/O system. Each of these errors generates a log entry in the diagnostics buffer.
Type of error | Diagnostic information for the station? | Entry in the diagnostics buffer? | CPU operating mode |
|---|---|---|---|
Diagnostic error | Yes | Yes | Stays in RUN mode |
Rack or station failure | Yes | Yes | Stays in RUN mode |
I/O access error 1 | No | Yes | Stays in RUN mode |
Peripheral access error 2 | No | Yes | Stays in RUN mode |
Pull / plug event | Yes | Yes | Stays in RUN mode |
1 I/O access error example cause: A module that has been removed.
2 Peripheral access error example cause: Acyclic communication to a submodule that is not communicating.
Use the GET_DIAG instruction for each station to obtain the diagnostic information. This will allow you to programmatically handle the errors encountered on the device and if desired take the CPU to STOP mode. This method requires you to specify the hardware device from which to read the status information.
The GET_DIAG instruction uses the "L address" (LADDR) of the station to obtain the health of the entire station. This L Address can be found within the Network Configuration view and by selecting the entire station rack (entire gray area), the L Address is shown in the Properties Tab of the station. You can find the LADDR for each individual module either in the properties for the module (in the device configuration) or in the default tag table for the CPU.
In case you cannot reach a CPU by the IP address, you can set an emergency (temporary) IP address for the CPU. The emergency IP address enables you to re-establish communication with the CPU in order to download a device configuration with a valid IP address.
Reasons why you might need an emergency IP address
Your CPU might be inaccessible if someone downloaded a project with one of the following problems:
The IP address of the PROFINET interface of the CPU is a duplicate of another device on the network.
The subnet is incorrect for the CPU.
The subnet mask makes the CPU unreachable.
In these cases, the CPU is no longer accessible from STEP 7.
Assigning an emergency IP address
You can assign an emergency IP address under the following conditions:
The device configuration in STEP 7 has "Set IP address in the project" for the IP protocol.
The CPU is in STOP mode.
Under these conditions, you can use a DCP tool to set the IP address of the device to an emergency IP address. The SIMATIC Automation Tool, for example, has a DCP Set IP address command. You can set an emergency IP address regardless of the protection level of the CPU. After you set a temporary IP address with a DCP tool, the Maintenance LED on the CPU turns on. The Diagnostics Buffer also includes an entry indicating that you enabled an emergency address of an Ethernet interface.
Restoring an IP address after assigning an emergency IP address
The diagnostics buffer informs you when you have enabled or disabled an emergency IP address. You can reset the emergency IP address by powering the CPU off and on.
After you have assigned an emergency IP address, you can then download a STEP 7 project with a valid IP address for the CPU. After you download the project, power cycle the CPU.
S7-1200 CPUs support the OPC UA Micro-Embedded Profile. For more information on the OPC UA Micro-Embedded Profile, visit the TIA Portal Information system.
Additionally, S7-1200 CPUs support the following:
User management
Communications security
Subscriptions
Program tag reading and writing
Method calls
User management access control (UMAC) allows you to centrally manage a CPU's local users, including OPC UA users, from one location in the STEP 7 project: "Security settings > Users and roles". For CPUs with older projects, see Access control for the S7-1200 CPU.
S7-1200 CPUs support a subset of OPC UA functionality, as described in the following sections. For additional information on OPC UA servers, visit the OPC Foundation Web site.
By default, the OPC UA server is inactive. Activate the OPC UA server by selecting the checkbox for "Activate OPC UA server" in the CPU's hardware properties.
To activate the OPC UA server, follow these steps:
Select the General tab in the Device Configuration view.
In the General window, select "OPC UA".
In the OPC UA>Server>General window, select the "Activate OPC UA server" checkbox.
The OPC UA server is operational once you activate the server and download the project to the S7-1200 CPU.
Behavior in STOP mode of the CPU
An activated OPC UA server is operational even when the CPU is switched to "STOP". The OPC UA server continues responding to requests from OPC UA clients.
Server response in detail:
When requesting the values of PLC tags, the CPU is returning the values written before it was set to "STOP" mode.
You can write values to the OPC UA server while in "STOP" mode. However, the CPU is not processing the values because the user program is not executing while in "STOP" mode. Any values written while in "STOP" mode are readable by OPC UA clients from the OPC UA server of the CPU.
Loading of the CPU with running OPC UA server
Loading certain objects while the OPC UA server is running can cause the CPU to stop. If the CPU stops, you are prompted to restart the server. Restarting the server interrupts active connections. You must re-establish the connections when the server restarts.
The following parameters affect the duration of the restart:
The scope of the data structure
The number of variables visible in the OPC UA address space
The setting for downward compatible data type definition according to OPC UA specification to V1.03 (TypeDictionary enabled)
The Settings for the communication load and minimum cycle time
The OPC UA server behavior is as follows:
Downloading objects while the CPU is in the "STOP" mode causes the OPC UA server to stop and restart. STEP 7 does not display a warning.
Downloading objects while the CPU is in "RUN" mode causes the OPC UA server to stop when the objects are or maybe OPC UA-relevant. The modified OPC UA data causes the OPC UA server to restart after re-initialization.
STEP 7 displays a warning in the preview dialog before loading OPC-UA-relevant objects into the CPU and stopping the OPC UA server. If a server restart is incompatible with your running process, you can cancel the download. These warnings are only displayed when the OPC UA server is running. If the OPC UA server is not enabled, modified OPC UA data has no influence on the download process.
Examples of how a running OPC UA server reacts during loading
Example 1:
Desired action: You want to add another code block to the program. Data blocks, inputs, outputs, and flags are not affected.
Server reaction: The running OPC UA server is not interrupted.
Example 2:
Desired action: You want to load a new data module and you have flagged the data module as not OPC UA relevant.
Server reaction: The running OPC UA server is not interrupted.
Example 3:
Desired action: You want to overwrite a data module.
Server reaction: Because STEP 7 cannot determine whether the changes affect OPC UA relevant data, a warning appears indicating the server is restarting.
From the Options dialog you can adjust the OPC UA server settings:
The following General settings and Subscriptions settings tables give further information about the server's configurable settings.
The default values for each row work with the default CPU communication load of 20%. Increase the CPU communication load percentage to suit your needs. The current load of communication activities (for example, PROFINET) affects the CPU percentage load.
General settings | Range | Default |
|---|---|---|
Ports | 1024 - 49151 | 4840 |
Max. session timeout | 1s - 600000s | 60s |
Max. number of OPC UA sessions | 1 - 10 | 10 |
Subscriptions settings | Range | Default |
|---|---|---|
Minimum sampling interval | 100 ms, 250 ms, 500 ms, 1000 ms, 5000 ms, 10000 ms | 1000 ms |
Minimum publishing interval | 200 ms - 20000000 ms | 1000 ms |
Max. number of monitored items | 100 - 1000 | 200 |
When using OPC UA server interfaces, you must comply with the following limitations:
Number of server interfaces
Number of OPC UA nodes
Number of server methods or server method instances if you have implemented methods
Interface, method, and subscription limitations
The following tables apply to S7-1200 CPUs and S7-1200 Fail-safe CPUs; consider these limitations when compiling and loading a configuration. Violating a server limitation results in an error message.
Interface limitations | Max. |
|---|---|
OPC UA server interfaces1 | 2 |
User-defined nodes on server interface2 | 2000 |
Namespaces3 | 18 |
1A server interface can be a "Companion specification" type or a "Server interface" type.
2 The maximum number includes nodes internally defined by the server interface.
3 This is the total number of defined namespaces for all server interface types: "Interface", "Companion specification", and "Reference namespace".
Method limitations | Max. |
|---|---|
Server methods1 | 20 |
Server method instance DBs for all server interfaces and associated server methods | 20 |
Server method input arguments | 20 |
Server method output arguments | 20 |
1 Any methods above this limit are non-executable, and result in a client runtime error. You can use multiple instances of the same method.
Subscription limitations | Max. |
|---|---|
Concurrent subscriptions1 | 50 |
Subscriptions per session | 5 |
1 Concurrent Subscriptions is equal to the configured number of concurrent sessions multiplied by the maximum number of subscriptions per session.
Server security is one of several security methods available to secure communication. TIA Portal security and PLC security are two other security methods.
The OPC UA server requires a certificate for activation. When you activate the server, TIA Portal generates a certificate. You can change this certificate in the PLC properties.
S7-1200 certificate limit
The S7-1200 has a system certificate limit of 64.
All certificates count against this number (for example, Web certificates, OPC UA certificates, and OUC certificates).
If you have more than 64 certificates, the TIA Portal displays an error stating that you have exceeded the maximum number of 64 certificates. You must remove some certificates from the PLC configuration.
Selecting a supported security policy at runtime determines the security of communications between the client and server.
To select your OPC UA security policy, follow these steps:
Select the General tab in the Device Configuration view.
In the General window, select "OPC UA".
Under OPC UA, select "Server > Security > Secure Channel".
Select the security policy you need from the list of available server policies.
Security policy | Enabled by default? |
|---|---|
No security | Yes |
Basic128Rsa15 – sign | No |
Basic128Rsa15 – sign & encrypt | No |
Basic256 – sign | No |
Basic256 – sign & encrypt | No |
Basic256Sha256 – sign | Yes |
Basic256Sha256 – sign & encrypt | Yes |
Establishing a secure OPC UA connection
Using enhanced security policies when establishing an initial connection between the OPC UA client and the S7-1200 server can significantly increase connection time, especially during RUN mode. This can cause the OPC UA client to time out before a connection is established and interrupt online connections to external devices such as TIA portal, HMIs, etc.
To prevent the OPC UA client from timing out, you can increase the OPC UA client's session connection time to 60 seconds.
To maintain online connections to external devices, you can increase the communications load percentage.
If necessary, to avoid increasing the communications load while establishing the initial OPC UA connection, you can do one of the following:
Abort any online connections to external devices and once the initial OPC UA connection is established, reconnect.
Re-establish online connections to external devices once they have timed out.
Increasing the cycle load due to communication proportionately increases the scan cycle time relative to active communication in progress.
You can configure the OPC UA server to only allow connections from trusted clients. The default server configuration automatically accepts client certificates.
You define the list of trusted clients. The server uses certificates to identify trusted clients. If selected, only clients that present trusted certificates at runtime are allowed to connect to the server.
To specify trusted clients, add their certificates to the "Trusted clients" list in TIA Portal under "Hardware properties > OPC UA security > Secure channel > Trusted clients".
If the firmware version of the CPU in your STEP 7 project is V4.7 or later, you can assign OPC UA users with User Management & Access Control (UMAC).
Assign roles and rights by doing the following:
Select "Security Settings" in the STEP 7 project tree.
Double-click "Users and roles".
From Users and Roles, you can add a user, create a new role, assign rights to the new role, and assign the role to a user.
To add a user, do the following:
Select the "Users" tab on the top, right side of the window.
Double-click "add a new user", then select "Add new local user" from the pop-up.
Enter the User name and Password. Runtime timeout defaults to 30 minutes but can be configured by entering the time manually in the field or using the arrows to change the time by one minute increments . The UM domain ID and Comment fields are optional.
In addition to defining a user name and password using UMAC, you must enable corresponding OPC UA user function rights for the client and the server.
The value in the column "Runtime timeout" (max. session duration) in the Users table under the Users tab does not evaluate the CPU for OPC UA runtime rights; users are not automatically logged out after a certain period of time.
To automatically log users out, you must use OPC UA specific mechanisms like the parameter "Max. session timeout" which is located under "OPC UA > Server > Options" on the "Properties" tab.
To create a new role, follow these steps:
Select the "Roles" tab from the top, right side of the window.
In the "Roles" section, double-click "Add new role".
Enter the Role Name, Description, Runtime timeout, and optional Comment.
Assign rights to the role in the following way:
Click the "Runtime rights" tab in the bottom window.
Select your PLC from the "Runtime rights" dropdown at left. This will populate all of the Function rights you can assign for that PLC.
Select the check boxes that you wish to assign for this role.
To assign a role to a user, do the following:
Select the "Users" tab on the top, right side of the window.
Click the check box and highlight the name of the user you want to assign with a role.
Click the "Assigned roles" tab in the bottom window.
Select the check box next to the role(s) you want to assign to the user.
After you download the configuration to the CPU, only authorized users can access OPC UA functions for which they have privileges.
OPC UA user role runtime rights
The default "Anonymous" user is disabled for security. You can enable the anonymous user by selecting the checkbox and agreeing to the security warning. For more information on working with the anonymous user, see "Managing users and roles > Activating or deactivating anonymous user" in the TIA Portal Information System.
Assignable user role runtime rights are as follows:
OPC UA server access
User authentication of the OPC UA client
Mange certificates
Unauthorized access to a CPU
Users with CPU full access or full access (incl. fail-safe) privileges have privileges to read and write PLC variables. Regardless of the access level for the CPU, Web server or OPC UA users can have privileges to modify PLC data and execute functions. Unauthorized access to the CPU can disrupt process operation.
Siemens recommends that you observe the following security practices:
Enable Access control under "Protection & Security > Access control".
Do not enable the "Anonymous" user.
Use strong passwords, as defined in STEP 7.
Enable the setting "Only allow secure PG/PC and HMI communication" under "Protection & Security > Connection mechanisms".
Use a secure Virtual Private Network (VPN) to connect to the S7-1200 PLC from a location outside your protected network.
Enable access to the Web server only with the HTTPS protocol.
Perform error-checking and range-checking on your variables in your program logic because Web server or OPC UA users can change PLC variables to invalid values.
For the OPC UA server: In your STEP 7 Device configuration, navigate to "Properties > OPC UA > Server > Security" and deselect "No security" in "Security policies available on the server for the secure channel".
Disruption of process operations can result in death, severe personal injury, and/or property damage.
User Management Access Control (UMAC) is only available when the configured firmware version of the CPU in the project is V4.7.
If you have a CPU configured in your STEP 7 project to use a firmware version earlier than V4.7, you authenticate OPC UA users under "Properties > OPC UA > Server > Security > User authentication".
For more information on how to add and authenticate OPC UA users for projects with older CPU versions, see OPC UA user authentication.
Unauthorized access to a CPU
Users with CPU full access or full access (incl. fail-safe) privileges have privileges to read and write PLC variables. Regardless of the access level for the CPU, Web server or OPC UA users can have privileges to modify PLC data and execute functions. Unauthorized access to the CPU can disrupt process operation.
Siemens recommends that you observe the following security practices:
Enable Access control under "Protection & Security > Access control".
Do not enable the "Anonymous" user.
Use strong passwords, as defined in STEP 7.
Enable the setting "Only allow secure PG/PC and HMI communication" under "Protection & Security > Connection mechanisms".
Use a secure Virtual Private Network (VPN) to connect to the S7-1200 PLC from a location outside your protected network.
Enable access to the Web server only with the HTTPS protocol.
Perform error-checking and range-checking on your variables in your program logic because Web server or OPC UA users can change PLC variables to invalid values.
For the OPC UA server: In your STEP 7 Device configuration, navigate to "Properties > OPC UA > Server > Security" and deselect "No security" in "Security policies available on the server for the secure channel".
Disruption of process operations can result in death, severe personal injury, and/or property damage.
Upgrading configured firmware from an earlier version to V4.7
When you upgrade the configured firmware version in your STEP 7 project to V4.7, STEP 7 migrates users that you previously configured in "User management" to "Users and Roles". You reassign user passwords in the Project tree under "Security settings > Users and roles > Users."
For more information about OPC UA user rights when upgrading firmware in the STEP 7 project, see "Editing devices and networks > Configuring devices and networks > Creating configurations > Configuring automation systems > Functional description of S7-1200 CPUs > Setting the operating behavior > Protection and Security > Settings for users and roles > Information about compatibility" in the TIA Portal Information System.
Downgrading configured firmware from V4.7 to an earlier version
When you downgrade the configured firmware version in your STEP 7 project from V4.7 to an earlier version, users configured in the Project tree under "Security settings > Users and roles > Users" will not be migrated. OPC UA users must be reconfigured from the CPU's "Properties" tab under "OPC UA > Server > Security > User authentication" in the "User management" area.
For more information about OPC UA user rights when downgrading firmware in the STEP 7 project, see "Editing devices and networks > Configuring devices and networks > Creating configurations > Configuring automation systems > Functional description of S7-1200 CPUs > Setting the operating behavior > Protection and Security > Settings for users and roles > Information about compatibility" in the TIA Portal Information System.
The S7‑1200 OPC UA server supports the standard SIMATIC server interface. It does not support the automatic publishing of CPU and DB tags using this selection. You must define the structure and content of the server interface in TIA Portal and then download to the PLC.
To add a server interface, perform the following steps:
In the project tree, click the PLC name.
Select "OPC UA communication."
Select "Server interfaces."
Select "Add new server interface" and click OK.
In the new server interface, enter variables from your PLC program.
Download the server to your PLC.
When you are adding a server interface, note that the OPC UA elements of the screen lists all available tags. You can drag the elements from the "OPC UA elements" window to the "OPC UA server interface" window. There is a consistency checker to verify the service interface contents. You can export the interface to an XML file.
You define the OPC UA server interface when you add an OPC UA server interface to your project.
To define the OPC UA server interface, select one of the following options from the OPC UA server creation dialog:
Select "Server interface", Type: Interface
Select "Companion specification", Type: Companion specification
Select "Companion specification", Type: Reference namespace
The OPC Foundation defines a set of supported data types that describe the structure of the Value attribute of Variables and their VariableTypes. The S7‑1200 supports a subset of those data types, as well as other defined types that derive from those data types.
The following table lists the data types that the S7-1200 supports:
SIMATIC type | OPC UA type name | Node identifier |
|---|---|---|
Bool | Boolean | i=1 |
SInt | SByte | i=2 |
USInt | Byte | i=3 |
Int | Int16 | i=4 |
UInt | UInt16 | i=5 |
DInt | Int32 | i=6 |
UDInt | UInt32 | i=7 |
Real | Float | i=10 |
LReal | Double | i=11 |
WString | String | i=12 |
DWord | StatusCode | i=19 |
DATE | UInt16 | i=5 |
TOD | UInt32 | i=7 |
TIME | Int32 | i=6 |
DTL | Structure | N/A |
Note that this list represents supported base node types. It does not represent a complete list of supported node types since many SIMATIC data types map to the base node types. Any SIMATIC data type that maps to a base node type is also a supported node type.
The S7-1200 CPUs support server methods as well as structured data types (structures and arrays).
The S7-1200 CPUs do not support Unions.
The S7‑1200 accepts a download of a server with unsupported types. However, the PLC returns an error if the client attempts to read or write to a node with an unsupported type.
The OPC UA server interface provides nodes that represent the PLC with properties that describe the PLC. These are available whenever the OPC UA server is active.
The standard SIMATIC server interface provides the following information:
Attribute | Value | ||
|---|---|---|---|
Nodeld | Ns=SI;s=PLC | ||
BrowseName | SI:<PLC> Where <PLC> is the name the user has assigned to the PLC in their TIA Portal project | ||
References | NodeClass | BrowseName | Comment |
ComponentOf the DeviceSet Object | |||
OrganizedBy the Objects folder | |||
HasTypeDefinition | ObjectType | SimaticDeviceType | Derived from device type |
HasProperty | Variable | DeviceManual | |
HasProperty | Variable | DeviceRevision | |
HasProperty | Variable | EngineeringRevision | |
HasProperty | Variable | HardwareRevision | |
HasProperty | Variable | Icon | |
HasProperty | Variable | Manufacturer | |
HasProperty | Variable | Model | |
HasProperty | Variable | OperatingMode | |
HasProperty | Variable | OrderNumber | |
HasProperty | Variable | RevisionCounter | |
HasProperty | Variable | SerialNumber | |
HasProperty | Variable | SoftwareRevision | |
You create and edit components of the OPC UA server interface in TIA Portal. You can define OPC UA server interfaces in two ways:
Companion specification externally‑created XML files
Server interface defined directly in the TIA Portal based on data block elements and global tags you include in your program
When downloaded, these components define the server interface that is visible to an OPC UA client.
You must set specific TAG attributes for the TAG to be readable/writable from OPC UA.
Runtime license required
The OPC UA server for the S7-1200 CPU requires a runtime license to operate. The following licenses are available:
SIMATIC OPC UA S7-1200 Basic DVD 6ES7823-0BA00-2BA0
SIMATIC OPC UA S7-1200 Basic DL 6ES7823-0BE00-2BA0
To find the required license type select "Properties > General > Runtime licenses > OPC-UA > Type of required license." To confirm purchase of the required license, follow these steps:
Click "Runtime licenses > OPC UA" in the properties of the CPU.
Select the required license from the "Type of purchased license" drop-down list.
You configure the OPC UA diagnostics in the TIA Portal and download the settings to the PLC. You can check the diagnostics buffer entries using the OPC UA client.
Diagnostics messages on status change do not appear with high frequency. Each of these messages has a high importance for the usage of OPC UA.
Summarizing diagnostics messages applies only to the diagnostic messages of the OPC UA Server. You can choose different settings for the CPU-global security events.
To limit the number of diagnostic messages in the case of high message volume, you can specify a message collection interval in seconds. The value range is 1 to 7200 seconds.
Enabled/disabled OPC UA server
You can only change the settings of the OPC UA diagnostics menu when OPC UA server is enabled.
When you disable the OPC UA server, all settings become gray and are read-only.
The server tells you when a system limit is reached, for example if it cannot provide data or when you cannot use the server/client in the normal way.
The OPC UA server has specific system limits for the number of subscriptions/monitored items, number of registered items, sampling rate of subscriptions, and number of connected clients.
When you reach any of these specific system limits, the server creates a diagnostics buffer entry.
The creation of a new diagnostics buffer entry causes a diagnostic message to display:
OPC UA Server: Exceeded limit of <Name of Limit>.
The diagnostic message specifies one of the following limits:
Number of Sessions
Number of Monitored Items
Number of Subscriptions
Number of Registered Nodes
Number of Server Methods
Number of Monitored Items per Call
Number of Nodes per Browse
Number of Nodes per Read
Number of Nodes per RegisterNodes
Number of Nodes per TranslateBrowsePathsToNodeIds
Number of Nodes per Write
Number of Nodes per MethodCall
Memory Consumption
If a service request exceeds a configured limit or a system limit, the server will respond with a service fault in the most cases.
The following use cases are shown below:
User action | Expected behavior | Limit |
|---|---|---|
Client creates more sessions as allowed by HWCN | The CPU adds a diagnostic message with exceeded limit to the diagnostics buffer. | Sessions |
Client creates more Monitored Items as allowed by HWCN | The CPU adds a diagnostic message with exceeded limit to the diagnostics buffer. | Monitored Items |
Client creates more Subscriptions as allowed (depends on PLC type) | The CPU adds a diagnostic message with statuscode <Statuscode> to the diagnostics buffer. | Client tries to connect with an unsupported identity token |
Clients registers more nodes as allowed by HWCN | The CPU adds a diagnostic message with exceeded limit to the diagnostics buffer. | Registered Nodes |
Client triggers a BadOutOfMemory response from the server by a high number of sessions/ subscriptions/ registered Nodes | The CPU adds a diagnostic message with exceeded limit to the diagnostics buffer. | Memory Consumption |
Client exceeds an operational limit of a service. (amount of operations in a single request exceeds the limit specified by the server) | The CPU adds a diagnostic message with exceeded limit to the diagnostics buffer. | Nodes per Browse Nodes per Read Nodes per Write Nodes per MethodCall Nodes per RegisterNodes Nodes per Translate |
Diagnostic message for "Overload behavior of subscriptions"
With an OPC UA subscription on different variables the OPC UA server checks the items for value change at predefined sampling intervals. This check, the "Sampling", needs a certain time that is independent of the number and data type of the items. Once sampling is complete the server publishes the results and sends the items to the client. If there are too many items in the queue, an "Overload" of the communication stack might occur. The CPU cannot check all the items in the specified sampling interval and jumps to the next sampling job.
If you cannot reach the set sampling rate, the server triggers a "Sampling Overload" diagnostics buffer entry.
Examples of OPC UA sampling overload diagnostic messages:
OPC UA server: Sampling rate 100 ms could not be reached. Overload of Subscription ID 12345678
OPC UA server: Sampling rate could not be reached. -Summary message for 3 occurrences during the last 20 second(s)
The OPC UA server alerts you whenever security events occur so you can react if the OPC UA server is vulnerable or if it detects an attack. The occurrence of specific OPC UA security events in the OPC UA server/client system triggers the entry of a message in the diagnostics buffer.
Denying a session or connection attempt due to incorrect authentication data is an example of a possible security event.
The OPC UA Server uses this message to report security problems:
"OPC UA Server: Security checks failed"
When a security check fails it generates warning messages and the operation does not execute.
Often, other security components like OpenSSL, UMAC 711, or OPC UA Stack return a status code and the server writes the status code into the diagnostic message.
Any time you get a negative response, the server generates a message. The most common use cases are shown below:
User action | Expected behavior | Statuscode |
|---|---|---|
Client tries to connect with an unsupported security model | The CPU adds the diagnostic message with statuscode <Statuscode> to the diagnostics buffer. | 16#8054_0000 (BadSecurityModeRejected) |
Client tries to connect with an unsupported security policy | The CPU adds the diagnostic message with statuscode <Statuscode> to the diagnostics buffer. | 16#8055_0000 (BadSecurityPolicyRejected) |
Client tries to connect with an unsupported identity token | The CPU adds the diagnostic message with statuscode <Statuscode> to the diagnostics buffer. | 16#8020_0000 (BadIdentityTokenInvalid) |
Client tries to connect with the wrong authentication (username or password wrong) | The CPU adds the diagnostic message with statuscode <Statuscode> to the diagnostics buffer. | 16#8021_0000 (BadIdendityTokenRejected) |
Client tries to connect with an invalid certificate (there are several possible reasons for invalidity of certificates) | The CPU adds the diagnostic message with statuscode <Statuscode> to the diagnostics buffer. | Depends on reason for invalidity e.g. 16#8014_0000 (BadCertificateTimeInvalid) 16#801A_0000 (BadCertificateUntrusted) |
Types of Security messages
There are two types of security messages: CPU-wide security messages and Security of OPC UA messages.
CPU-Wide security messages
CPU-wide security messages are diagnostic messages generated in scenarios defined as CPU-wide critical by the security officer. Such messages are using a special Alarm-Domain. This allows HMIs to filter for them and to handle them differently. Such security messages are authentication failures that can occur when you try to log on to the CPU’s Web- or the OPC UA -Server. There is a configuration dialog in TIA-Portal beneath the item "Protection & Security".
Security of OPC UA messages
The OPC UA server generates messages from OPC UA concerning server security and uses the standard alarm domain or checks during certificate verification.
Enable or disable the "Check of security policy failed" option in the TIA-Portal property view, as shown below.
OPC UA server connection information
With the OPC UA diagnostics buffer, you can see the status of clients using the OPC UA server. For example, the diagnostics buffer shows the following information:
When a client connects to your OPC UA server
When the client disconnects from your OPC UA server
The server writes a diagnostic message to the diagnostics buffer when the state of a session changes. The possible session state transitions are:
Created
Activated
Closed
TimedOut
ActivationFailed
The following use cases are implemented:
User action | Expected behavior | Security policies |
|---|---|---|
Starting the OPC UA Server (for example, power cycle) | The S7-1200 CPU adds a diagnostic message with lowest security policy to the diagnostics buffer. | None, Basic128Rsa15, Basic256, Basic256Sha256, |
Precondition | User action | Expected behavior | States |
|---|---|---|---|
OPC UA Server running, no client connected | Client connects to OPC UA Server and passes correct credentials | The S7-1200 CPU generates a diagnostic message showing the state change. | Created, Activated |
OPC UA Server running, no client connected | Client connects to OPC UA Server and passes wrong credentials | The S7-1200 CPU generates a diagnostic message showing the state change. | Created, Activation failed |
OPC UA Server running, Client is connected | Client closes session correctly | The S7-1200 CPU generates a diagnostic message showing the state change. | Closed |
OPC UA Server running, Client is connected | Client sends no more messages to the server until session times out | The S7-1200 CPU generates a diagnostic message showing the state change. | TimedOut |
OPC UA Server started/stopped
Use the OPC UA diagnostics buffer to see the global status of the OPC UA server. Diagnostic buffer messages show when the OPC UA server starts and stops. You can also see additional information, such as if the generic interface is on, or how many server interfaces or namespaces are active.
The OPC UA server can be in any of the following states:
Running
Failed
NoConfiguration
Suspended
Shutdown
Test
CommunicationFault
Unknown
Starting
Restarting
State change reasons: download/power cycle, instruction called by user program, remote request. The possible server-state transitions are shown below.
Precondition | User action | Expected behavior | States |
|---|---|---|---|
OPC UA Server running | HW download with activated OPC UA Server | The S7-1200 CPU generates a diagnostic message showing the state change. Reason: Download / Power Cycle | Shutdown, Starting, Running |
OPC UA Server stopped | HW download with activated OPC UA Server | The S7-1200 CPU generates a diagnostic message showing the state change. | Created, Activated |
OPC UA Server running | HW download with disabled OPC UA Server | The S7-1200 CPU generates a diagnostic message showing the state change. | Created, Activation failed |
OPC UA Server running | HW download with activated OPC UA Server and too large type dictionary (too many structures) | The S7-1200 CPU generates a diagnostic message showing the state change. | Closed |
OPC UA Server stopped | HW download with activated OPC UA Server and too large type dictionary | The S7-1200 CPU generates a diagnostic message showing the state change. | TimedOut |
Software download
A software download also results in a OPC UA Server restart.
OPC UA session/subscription timeout
You can see when an OPC UA session or subscription has timed out and which sessions or subscriptions are still active.
When you change the state of an OPC UA session or subscription, the server writes information about the state change to the OPC UA diagnostics buffer. The possible OPC UA subscription states are as follows:
Created
Closed
Normal
Late
KeepAlive
TimedOut
A running subscription often changes between the states "Normal" and "KeepAlive" (when the monitored values changes only occasionally). There are no messages triggered for the "KeepAlive" state. The following use cases are implemented:
User action | Expected behavior | Security policies |
|---|---|---|
OPC UA Server was started (for example, power cycle) | The S7-1200 CPU adds a diagnostic message with lowest security policy to the diagnostics buffer. | None, Basic128Rsa15, Basic256, Basic256Sha256, |
The OPC UA server notifies you when a "wrong usage" occurs.
A "wrong usage" occurs when a client requests data or tries to use a function in a way not intended. Sending an invalid request causes the server to display a "wrong usage" diagnostic message.
Requesting an invalid NodeID causes the "wrong usage" diagnostic message to display. You can identify an invalid NodeID by browsing.
The "wrong usage" diagnostic message does not display during the following events:
A client tries to read optional attributes
A client exceeds subscriptions
A client exceeds the server's session limits
Note: The namespace "http://opcfoundation.org/UA/" (ns=0) is a special namespace handled by the OPC Foundation (or the SDK) and diagnostics functions are limited. Not every "wrong usage" in this namespace triggers a message (for example, registering an unknown node)
The server writes the diagnostic message "OPC UA Server: Wrong usage of service <Service-Name> in session ID <Session-ID>" to the diagnostics buffer when it detects the "wrong usage" of a service. It only considers services that the S7-1200 OPC UA server supports:
FindServers
GetEndpoints
FindServersOnNetwork
CreateSession
ActivateSession
CloseSession
Cancel
Browse
BrowseNext
TranslateBrowsePathsToNodeIds
RegisterNodes
UnregisterNodes
Write
Read
Call
CreateMonitoredItems
ModifyMonitoredItems
DeleteMonitoredItems
SetMonitoringMode
SetTriggering
CreateSubscription
ModifySubscription
DeleteSubscription
Publish
Republish
SetPublishingMode
OpenSecureChannel
CloseSecureChannel
The following is an example of a "wrong usage" OPC UA Diagnostics buffer message:
Message | Single Event | Summary Event |
|---|---|---|
OPC UA Wrong Usage | ||
Example | OPC UA Server: Wrong usage of service Read in session ID 12345678 | OPC UA Server: Wrong usage of a service. – Summary Message. - Summary Message for 3 occurrences during the last 20 second(s) |
Providing user programs for server methods
You can provide OPC UA methods through the user program on the OPC UA server of an S7-1200 CPU.
Using OPC UA methods, you can trigger specific actions on the controller and transfer data consistently.
For example, OPC UA methods can use an OPC UA client to process a manufacturing job with the method call of the S7-1200.
OPC UA methods, an implementation of "Remote Procedure Calls", provide an efficient mechanism for interactions between different communication nodes. The mechanism provides both job confirmation and feedback values, eliminating the need to program handshaking mechanisms.
How does an OPC UA method work?
An OPC UA method in principle operates like a know-how protected function block that you call during runtime.
The OPC UA client only "sees" defined inputs and outputs. The content of the function block (the method or algorithm) remains hidden to the external OPC UA client. The OPC UA client receives feedback on successful execution and values returned by the function block (method), or an error message if execution is not successful.
As the programmer, you have full control over and responsibility for the program context in which the OPC UA method runs.
Rules for programming a method and runtime behavior
Make sure that the values returned by the OPC UA method are consistent with the input values provided by the OPC UA client.
Follow the rules on assigning name and the structure of parameters, and the permitted data types (see description of the OPC UA server instructions).
Behavior during runtime: The OPC UA server accepts one call per instance. The method instance is not available for other OPC UA clients until the call is complete or has timed out. The instance times out when you reach the maximum amount of time allowed for establishing a connection to the server.
Implementing a server method
Implementing a server method involves the following tasks:
Defining optional input and output parameters for the server method
Querying the server method call with OPC_UA_ServerMethodPre
Writing the server method
Responding to the server method with the OPC_UA_ServerMethodPost
Defining optional input and output parameters for the server method
An OPC UA method can optionally define input or output parameters. Neither type of parameter is required. The OPC UA client supplies input parameters to the OPC UA method at runtime. The OPC UA method returns output parameters to the OPC UA client at runtime, when the method completes.
Follow these steps to define OPC UA method input parameters:
Within the Static section of the FB interface, define a struct named UAMethod_InParameters. Mark this struct as “Accessible from HMI/OPC UA/Web API” and “Writable from HMI/OPC UA/Web API”.
Within this struct, define the OPC UA method input parameters. The input parameters can have any valid name. The data types for an OPC UA method input parameter can be scalar types (Int, Real, etc.), structured data types, or arrays.
Follow these steps to define OPC UA method output parameters:
Within the Static section of the FB interface, define a struct named UAMethod_OutParameters. Mark this struct as “Accessible from HMI/OPC UA/Web API”.
Within this struct, define the OPC UA method output parameters. The output parameters can have any valid name. The data types for an OPC UA method output parameter can be scalar types (Int, Real, etc.), structured data types, or arrays
The following is an example of user-defined input and output parameters for an OPC UA method:
Querying the server method call with OPC_UA_ServerMethodPre
Call the "OPC_UA_ServerMethodPre" instruction in your user program from your server method.
This instruction asks the OPC UA server of the S7-1200 CPU whether the server method was called from an OPC UA client.
Once an OPC UA client calls the server method, the server method receives any input parameters from the OPC UA client.
Writing the server method
In the section of the server method between the calls to OPC_UA_ServerMethodPre and OPC_UA_ServerMethodPost, you provide the actual user program. You have the same options as in any other user program (for example, access to other function blocks or global data blocks). If the server method uses input parameters, these parameters are available to you. The server method must only execute this section if an OPC UA client has called the server method and the server method has called OPC_UA_ServerMethodPre.
After successful execution of the method, set the output parameters of the server method (if the method has output parameters.)
Responding to the server method with the OPC_UA_ServerMethodPost
To complete the server method, call the "OPC_UA_ServerMethodPost" instruction.
Use the parameters to notify the "OPC_UA_ServerMethodPost" instruction of the processing status of the user program.
Once the user program successfully executes, the relevant parameters notify the OPC UA server. The OPC UA server then sends the output parameters of the server method to the OPC UA client.
Information about server methods
Always use the "OPC_UA_ServerMethodPre" and the "OPC_UA_ServerMethodPost" as a pair when writing an OPC UA method. OPC UA methods will not function unless you add both methods.
For a detailed description of the "OPC_UA_ServerMethodPre" and "OPC_UA_ServerMethodPost" visit the TIA Portal Information system.
Integrating the server method
The diagram below shows how an OPC UA client calls the server method "Cool":
A | The OPC UA client calls the OPC UA server method and manages its "Done" status. |
① | The OPC UA method calls between the OPC UA client and the OPC UA server method are asynchronous. |
B | The OPC UA server firmware waits for OPC UA client calls, manages calls in the queue, and forwards "Done" information from the cyclic user program to the OPC UA client. |
② | This call transfers data from the OPC UA server to the instance of the user program, method FB "Cool". |
C | The instruction, OPC_UA_ServerMethodPre, asks the OPC UA server of the CPU if the OPC UA server method has been called by an OPC UA client. Once an OPC UA client calls the OPC UA server method, the OPC_UA_ServerMethodPre instruction sets a flag to indicate the OPC UA client is calling the OPC UA server method. If there are input parameters from the OPC UA client, the OPC_UA_ServerMethodPre instruction provides them to the method FB "Cool". The user program, method FB "Cool", must first call the OPC_UA_ServerMethodPre instruction. |
③ | Method FB "Cool" performs a synchronous call of the OPC_UA_ServerMethodPre instruction. The OPC_UA_ServerMethodPre instruction is a multi-instance static variable that stores input data from the OPC UA client. The return value from the synchronous call indicates whether a client did or did not call the OPC UA server method. |
④ | The cyclic user program asynchronously calls the method FB "Cool" with the required instance parameters. |
⑤ | This synchronous call checks the status, complete or "busy," of the OPC UA server method. |
D | The OPC_UA_ServerMethodPost, once the OPC UA server method is complete, forwards the output data of the method instance to the OPC UA server. The OPC_UA_ServerMethodPost also notifies the method instance and the OPC UA server that the method is complete. |
⑥ | This call transfers data to the OPC UA server from the instance of the user program, method FB "Cool". |
⑦ | The OPC UA server firmware sends information back to the OPC UA client. |
How this example works
The CPU executes the instance "Cool1" of the server method FB "Cool" in the cyclic user program ④.
The instance "Cool1" calls the instruction "OPC_UA_ServerMethodPre" to query ③ whether an OPC UA client has called the server method FB "Cool" ①.
If the server method FB "Cool" has not called OPC_UA_ServerMethodPre, program execution returns directly to the cyclic user program over ③ and ④. The CPU resumes the cyclic user program after "Cool1".
If the server method FB "Cool" has already called OPC_UA_ServerMethodPre, OPC_UA_ServerMethodPre returns information directly to the server method FB "Cool" over ③. The method FB "Cool" now executes and accesses data from the plant machinery.
Once the OPC UA server method is complete, the server method FB "Cool" then calls the instruction "OPC_UA_ServerMethodPost" ⑤ to notify the firmware (B) that the instruction has executed ⑥.The firmware returns this information over ⑦ to the calling OPC UA client (A). The CPU resumes the cyclic user program after "Cool1".
If you provide server methods, assign the data types as shown below (SIMATIC data type - OPC UA data type). Do not use other assignments.
STEP 7 does not prevent incorrect assignments. You are responsible for making compliant selections and data type assignments.
You can also use the listed data types, for example, as elements of structures/arrays/UDTs for input and output parameters of self-created server methods (UAMethod_InParameters and UAMethod_OutParameters).
SIMATIC data type | OPC UA data type |
|---|---|
BOOL | Boolean |
SINT | SByte |
INT | INT16 |
DINT | INT32 |
USINT | Byte |
UINT | UINT16 |
UDINT | UINT32 |
REAL | Float |
LREAL | Double |
WSTRING | String |
DINT | Enumeration (Encoding Int32) and all derived data types |