View
242
Download
0
Category
Preview:
Citation preview
https://support.industry.siemens.com/cs/ww/en/view/109483258
Application Example 05/2016
Saving SCALANCE Configuration Data in an S7-1500 SIMATIC S7-1500, SCALANCE XB-200, W761-1, W72x-1
Warranty and Liability
TFTP Entry ID: 109483258, V1.0, 05/2016 2
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Warranty and Liability
Note The Application Examples are not binding and do not claim to be complete regarding the circuits shown, equipping and any eventuality. The Application Examples do not represent customer-specific solutions. They are only intended to provide support for typical applications. You are responsible for ensuring that the described products are used correctly. These Application Examples do not relieve you of the responsibility to use safe practices in application, installation, operation and maintenance. When using these Application Examples, you recognize that we cannot be made liable for any damage/claims beyond the liability clause described. We reserve the right to make changes to these Application Examples at any time without prior notice. If there are any deviations between the recommendations provided in this Application Example and other Siemens publications – e.g. Catalogs – the contents of the other documents shall have priority.
We do not accept any liability for the information contained in this document. Any claims against us – based on whatever legal reason – resulting from the use of the examples, information, programs, engineering and performance data etc., described in this Application Example shall be excluded. Such an exclusion shall not apply in the case of mandatory liability, e.g. under the German Product Liability Act (“Produkthaftungsgesetz”), in case of intent, gross negligence, or injury of life, body or health, guarantee for the quality of a product, fraudulent concealment of a deficiency or breach of fundamental contractual obligations (“wesentliche Vertragspflichten”). The damages for a breach of a substantial contractual obligation are, however, limited to the foreseeable damage, typical for the type of contract, except in the event of intent or gross negligence or injury to life, body or health. The above provisions do not imply a change of the burden of proof to your detriment. Any form of duplication or distribution of these Application Examples or excerpts hereof is prohibited without the expressed consent of Siemens AG.
Security informa-
tion
Siemens provides products and solutions with industrial security functions that support the secure operation of plants, systems, machines and networks.
To protect plants, systems, machines and networks against cyber threats, it is necessary to implement (and continuously maintain) a holistic, state-of-the-art industrial security concept. Products and solutions from Siemens are only one part of such a concept.
The customer is responsible for preventing unauthorized access to the customer’s plants, systems, machines and networks. Systems, machines and components should be connected to the company network or the Internet only if and to the extent necessary and if appropriate protective action (e.g., use of firewalls and network segmentation) was taken.
In addition, Siemens’ recommendations regarding appropriate protective action should be followed. For more information about industrial security, visit http://www.siemens.com/industrialsecurity.
Siemens’ products and solutions undergo continuous development to make them even more secure. Siemens strongly recommends to perform updates as they become available and use only the latest product versions. Using versions that are out of date or no longer supported can increase the risk of cyber threats.
To stay informed about product updates as they occur, subscribe to the Siemens Industrial Security RSS feed at http://www.siemens.com/industrialsecurity.
Table of Contents
TFTP Entry ID: 109483258, V1.0, 05/2016 3
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Table of Contents Warranty and Liability ................................................................................................. 2
1 Motivation and Task .......................................................................................... 4
1.1 Reason ................................................................................................. 4 1.2 Task ...................................................................................................... 4
2 Solution............................................................................................................... 6
2.1 Explanation and graphical representation ............................................ 6 2.2 Description of the core functionality ..................................................... 8 2.3 Hardware and software components ................................................... 9
3 Valuable Information on Loading and Saving Device Data in SCALANCE Devices ........................................................................................ 10
3.1 Options for data transfer..................................................................... 10 3.2 The communications protocols involved ............................................ 11 3.2.1 The SNMP communications protocol ................................................. 11 3.2.2 The TFTP file transfer protocol .......................................................... 12 3.3 Implementation in the program .......................................................... 13
4 Programming in Detail .................................................................................... 15
4.1 Overview of the STEP 7 program ...................................................... 15 4.2 Program details on the “SNMP” block ................................................ 17 4.2.1 Block description ................................................................................ 17 4.2.2 Required auxiliary blocks ................................................................... 21 4.3 Program details on the “TFTP” block ................................................. 22 4.3.1 Block description ................................................................................ 22 4.3.2 Required auxiliary blocks ................................................................... 25 4.3.3 The file directory ................................................................................. 26 4.4 Automatic mode functional sequence ................................................ 27
5 Valuable Information on the Configuration................................................... 30
5.1 Rules for running the function blocks ................................................. 30 5.2 Parts of the TIA projects ..................................................................... 30 5.3 Customizing the sample code ............................................................ 31 5.3.1 Changes for the “Automatic” variant .................................................. 31 5.3.2 Changes for the “Manual” variant ....................................................... 31
6 Installation and Startup ................................................................................... 33
6.1 Installation .......................................................................................... 33 6.2 Starting up the “Automatic” variant ..................................................... 34 6.3 Starting up the “Manual” variant ......................................................... 35
7 Operation of the Application .......................................................................... 36
7.1 “Automatic” variant ............................................................................. 36 7.2 “Manual” variant ................................................................................. 37
8 Links & Literature ............................................................................................ 41
9 History............................................................................................................... 41
1 Motivation and Task
1.1 Reason
TFTP Entry ID: 109483258, V1.0, 05/2016 4
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
1 Motivation and Task
1.1 Reason
In automation, two switch variants are used depending on the requirements:
• Unmanaged switches for simple applications
• Managed switches for more complex plants or when integrating into PROFINET’s diagnostic system.
Managed switches have more functions that are parameterized using CLI (command-line interface) or WBM (Web Based Management). These parameters are not stored in the engineering system.
To back up the configuration data or in case of device replacement, the user has the option to store the configuration on a storage medium (C-PLUG or configuration plug).
The SCALANCE switches of the XB-200 series, the W761 access point and the W72x client modules do not feature a C-PLUG slot. A backup of the configuration data must be triggered manually and specifically using CLI or WBM.
This requires knowledge of the components on the maintenance staff side (entry of parameters) and a PC.
As this is not always the case, it is necessary to find a new data backup solution.
1.2 Task
Automatic saving on the controller is an alternative to the C-PLUG. It should be possible to save (“upload”) the configuration data for modules without a storage medium (C-PLUG) as data blocks in the SIMATIC controller and restore (“download”) it, if necessary (e.g., module replacement) – without any additional manufacturer tools.
Overview of the automation task
The figure below provides an overview of the automation task.
Figure 1-1
SIMATIC controller
Upload
Download
SCALANCE
Configurationdata
Load memory
Configurationdata
PROFINET IE
1 Motivation and Task
1.2 Task
TFTP Entry ID: 109483258, V1.0, 05/2016 5
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Description of the automation task
The network consists of a SIMATIC S7-1500 controller and SCALANCE components such as an XB-200 switch or WLAN devices (W761, W72x). To provide a better overview, the figure shows only one component.
The objective of the automation task is to handle the exchange of configuration data (“upload”/“download”) using standardized network protocols.
The trigger for this procedure (“upload”/(“download”) is to be triggered automatically or manually using a variable.
The preferred storage location of the data blocks is the controller’s load memory. The configuration data size can be very large (several hundred 100kB), which can cause it to spread over multiple data blocks. Therefore, the configuration data only uses space in the load memory and not in the main memory.
As multiple data blocks can be stored per device, file management is required. This file management must be programmed by the user.
Variants
Two variants are provided for triggering:
“Automatic” variant
“Manual” variant
The “Automatic” variant is based on a PROFINET connection between the controller and the network components. The “upload” and – where necessary – the “download” are to be automatically implemented through PROFINET mechanisms and active for all supported network components in the IO system.
The “Manual” variant, however, requires direct user intervention. It is up to the user to decide – triggered via a variable – for which (supported) network component an “upload” or “download” should be implemented.
For both variants, file management manages the association between data block number and network component.
2 Solution
2.1 Explanation and graphical representation
TFTP Entry ID: 109483258, V1.0, 05/2016 6
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
2 Solution
2.1 Explanation and graphical representation
Description
The “SNMP” and “TFTP” function blocks are used to implement the task – save the configuration data in the controller.
These function blocks allow you to save and back up (“upload”) the configuration data (depending on the size) in one or more data blocks (DBs) and restore it due to maintenance or repair (“download”). The DBs are stored in the CPU’s load memory.
To do this, the application uses two protocols:
SNMP (Simple Network Management Protocol)
TFTP (Trivial File Transfer Protocol)
Variants
This application example provides two variants:
“Automatic” variant: Automatic “upload”/“download” of the configuration data of all network components supported and configured as a PROFINET IO device.
“Manual” variant: Manual, device-specific “upload”/“download” of the configuration data of one supported network component. An HMI can be used for operator control.
Note A separate TIA project is created for each variant.
Schematic representation
The following figure uses the example of a SCALANCE XB-200 to show the principle of data storage by using SNMP and TFTP. This figure does not show the identification of network components via PROFINET – necessary, among other things, for the “Automatic” variant.
2 Solution
2.1 Explanation and graphical representation
TFTP Entry ID: 109483258, V1.0, 05/2016 7
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Figure 2-1
S7-1500TFTP server
XB-200TFTP client
PROFINET IE Configura-tion data
Configuration
data
“TFTP” TFTP
“SNMP”
SNMP
parameters
SNMP
variables
SNMP
Description of the “Automatic” variant
A PROFINET network is the basis of this variant. The S7-1500 controller is the IO controller, the SCALANCE devices involved are configured as IO devices.
The “upload”/“download” of the configuration data of all supported SCALANCE devices and appropriate file management for the data blocks are fully automatic.
The information required by SNMP and TFTP, too, is determined automatically when the program is run.
Description of the “Manual” variant
Unlike the variant described above, manual operation of the application does not require a PROFINET network.
The “upload”/“download” of the configuration data of a supported SCALANCE device takes place on a variable-triggered basis.
The information required by SNMP and TFTP must be transferred as parameters.
Advantages
The solution presented here offers the following advantages:
Central storage of the configuration data in the controller’s load memory.
Configuration data can be easily loaded back to the device in case of replacement or when restoring the original configuration.
Saves time and costs due to the use of existing mechanisms/protocols.
No additional hardware tools or devices required.
2 Solution
2.2 Description of the core functionality
TFTP Entry ID: 109483258, V1.0, 05/2016 8
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Scope
This application does not include a detailed description of the SNMP and TFTP network protocols and PROFINET IO. Basic knowledge of these topics is required.
2.2 Description of the core functionality
Description
Due to the “upload” request (“backup request”), the network component transfers its configuration data to the controller. It stores the configuration data in one or more defined data blocks that are unique throughout the project.
This data block is automatically generated by the application.
Due to the “download” request (“restore request”), the application provides the saved configuration data from the module’s data block for restoring.
This main task – “upload”/“download” the configuration data – is implemented using the standardized network protocols SNMP and TFTP and applies to both variants presented here without any restrictions.
NOTICE If – due to device replacement – it is necessary to restore the configuration, the replacement device type must match the one of the replaced device.
SNMP
SNMP (Simple Network Management Protocol) is a protocol managing network components in Ethernet. This standardized protocol allows you to read or write information (for example, settings).
Specifically for this automation task, the network component requires the following information:
TFTP server address
Configuration file name
Trigger “upload/download”
Enable configuration for “download”
TFTP
The actual transfer of the configuration data (“upload”, “download”) takes place via TFTP. The network component is a TFTP client, the controller performs the TFTP server function.
2 Solution
2.3 Hardware and software components
TFTP Entry ID: 109483258, V1.0, 05/2016 9
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
2.3 Hardware and software components
Validity
This application is valid for
STEP 7 V13 SP1 Update 7 or higher
S7-1500 firmware 1.8 or higher
SCALANCE switches of the XB-200 series
SCALANCE W761
SCALANCE W722, W721
Components used
The application example was created with the following components:
Table 2-1
Component No. Article number Note
S7-1516-3 PN/DP 1 6ES7 516-3AN00-0AB0 A different CPU of the S7-1500 family can also be used.
SCALANCE XB 208 1 6GK5 208-0BA00-2AB2
SCALANCE W761 1 6GK5 761-1FC00-0AA0
TP700 Comfort HMI panel
1 6AV 124-0MC01-0AX0 Optional for using the application with the “Manual” variant. WinCC Runtime can also be used.
SIMATIC MEMORY Card
1 6ES7954-8L… The size of the memory card depends on the size of the configuration data of your application. It should have a minimum size of 4MB.
TIA Portal V13 SP1 1 6ES7822-1AA03-0YA5 For updates, please see \3\.
WinCC Advanced V13 SP1
1 6AV210.-....3-0
Sample files and projects
The following list contains all files and projects that are used in this example.
Table 2-2
Component Note
109483258_Saving_ConfigData_TFTP_CODE_v10.zip This zip file contains the STEP 7 projects for the variants presented in this document. • SAVE_CONFIG_AUTO.ap13 (“Automatic” variant)
• SAVE_CONFIG_MANUAL.ap13 (“Manual” variant)
109483258_Saving_ConfigData_TFTP_DOC_v10_de.pdf This document.
3 Valuable Information on Loading and Saving Device Data in SCALANCE Devices
3.1 Options for data transfer
TFTP Entry ID: 109483258, V1.0, 05/2016 10
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
3 Valuable Information on Loading and Saving Device Data in SCALANCE Devices
3.1 Options for data transfer
The SCALANCE devices support different methods for loading and saving device data.
They are triggered using a graphical user interface in Web Based Management (WBM) or, on a command-oriented basis, with the command-line interface (CLI).
The SCALANCE devices support the following methods:
Load and save via http/https (WBM only): WBM provides the option to save device data to an external file on a client PC or load such data from an external file on the client PC to the devices.
Load and save via TFTP: Specifying a TFTP server and file name allows you to save the device data to an external file on a TFTP server or load such data from an external file on the TFTP server to the devices.
Note For more information, please refer to the SCALANCE device manuals (see chapter 8).
3 Valuable Information on Loading and Saving Device Data in SCALANCE Devices
3.2 The communications protocols involved
TFTP Entry ID: 109483258, V1.0, 05/2016 11
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
3.2 The communications protocols involved
3.2.1 The SNMP communications protocol
Description
Simple Network Management Protocol (SNMP) is a UDP/IP-based open protocol. It is a key part for loading and saving device data as it allows centralized network management for many network components such as switches, controllers, etc.
SNMP enables the user to retrieve information about network components from a remote network management system or change their parameters. Furthermore, SNMP allows instructions to control the devices.
Architecture model
SNMP operates on the client-server model.
The network consists of the following functional components:
Managing unit/management station
Managed devices/management agents
The managing unit (e.g., a controller, PC) is at the core of the network management activities and performs the client function. It requests information about the network components and can change their values. The SNMP Manager runs on the managing unit.
Managed devices are network components (e.g., SCALANCE), including their software. The managed devices have agents (server function) installed that capture the device state and can change values.
Management Information Base (MIB)
The Management Information Base (MIB) plays an important role in SNMP. It is a collection of all MIB objects that can be retrieved or changed by the SNMP Manager. It manages individual system aspects such as information about the configuration or statistical information about packet throughput, error messages, etc.
The MIB objects are organized in a tree structure and identified by a unique object identifier (OID).
Protocol structure
The SNMP message is composed of several sequences and individual items. The following figure shows the basic structure:
Figure 3-1
SNMP Message
SNMP Version
SNMP Community
SNMP PDU
RequestID
ErrorErrorIndex
VarbindList
Varbind
OID Value
3 Valuable Information on Loading and Saving Device Data in SCALANCE Devices
3.2 The communications protocols involved
TFTP Entry ID: 109483258, V1.0, 05/2016 12
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
SNMP starts with general information such as the SNMP version or access rights (SNMP Community). What follows is the actual job, for example GetRequest (read information). This sequence is composed of a sequential number (request ID) and the error status of the actual variable list (Varbind) with the OIDs and associated values.
This message structure must be emulated in the controller.
3.2.2 The TFTP file transfer protocol
Description
Trivial File Transfer Protocol (TFTP) is a very simple file transfer protocol based on the client-server model. It only reads/writes files.
The protocol is based on UDP and therefore connectionless. This means that client and server have to monitor the transfer and provide message repetitions in the event of a loss.
The motivation for the development of TFTP was the loading of operating systems or configurations via the network. As this is mostly done from firmware or a small program, the connection-oriented TCP and FTP based on it are far too complex for this purpose.
Protocol structure
TFTP is kept very simple and transferred as a data portion in UDP. It consists of a 2-byte header and an appropriate data portion.
There are five packet types that are identified by a two-byte field (“OPCode”):
Figure 3-2
OPCode String Delimiter
String Delimiter
Read requestWrite request
00010002
Filename
00 Mode 00
OPCode 2 bytes N bytes
Data 0003 BlockNo Data
OPCode 2 bytes
Acknowledgment(ACK)
0003 BlockNo
OPCode 2 bytes String Delimiter
Error 0005ErrorCode
ErrMsg 00
3 Valuable Information on Loading and Saving Device Data in SCALANCE Devices
3.3 Implementation in the program
TFTP Entry ID: 109483258, V1.0, 05/2016 13
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
3.3 Implementation in the program
Roles
Both SNMP and TFTP operate on the client-server principle. As – due to the firmware – the role of the SCALANCE devices is predefined, the SIMATIC controller must act as the counterpart.
Only the TFTP client functionality is implemented in the switch. The server function is missing. Therefore, the S7 CPU must perform the server functions.
Defined by the SNMP architecture, the network component takes only the SNMP server role. Accordingly, the S7 CPU must act as an SNMP client.
The following table shows the resulting roles for this application example:
Table 3-1
Role SNMP TFTP
SCALANCE device SNMP server TFTP client
SIMATIC S7-1500 SNMP client TFTP server
The S7-1500 is not designed for the TFTP server function and the SNMP client function. Therefore, function blocks that implement and emulate these protocols are required in the CPU.
Required information
To load and save the configuration data of a network component with the aid of the protocols introduced above, the function blocks require the following information:
TFTP server address
Configuration file name
Trigger “upload/download”
Enable configuration for “download”
All these pieces of information/parameters are stored in different MIB objects in the network component and can be read/written via SNMP and the referencing object identifier (OID).
3 Valuable Information on Loading and Saving Device Data in SCALANCE Devices
3.3 Implementation in the program
TFTP Entry ID: 109483258, V1.0, 05/2016 14
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Sequence
These definitions result in the following “upload”/“download” sequence.
Figure 3-3
Controller SCALANCE
Timing diagram following “upload” request
Timing diagram following “download” request
SNM
PSN
MP
SNM
PTF
TPTF
TP
4 Programming in Detail
4.1 Overview of the STEP 7 program
TFTP Entry ID: 109483258, V1.0, 05/2016 15
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
4 Programming in Detail
4.1 Overview of the STEP 7 program
Program overview
The following figure shows the program structure of the “Automatic” variant:
Figure 4-1
User program Library blocks System blocks Data blocks
MAIN
[OB 1]
SNMP
TFTP
-TCON
-TSEND
DeviceState
StorageActual
Devices
StorageRead
FileData
MainDevi
ceBlock
GEO2LOC
GetStationI
nfo
RDREC
-TCON-TUSEND-TURCV
StorageTarget
Devices
StorageOIDs
GetAnyAd
dress
GetIMData
4 Programming in Detail
4.1 Overview of the STEP 7 program
TFTP Entry ID: 109483258, V1.0, 05/2016 16
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
The following figure shows the program structure of the “Manual” variant.
Figure 4-2
User program System blocks Data blocks
MAIN
[OB 1]
SNMP
TFTP
-TCON
-TSENDStorageTarget
Devices
StorageRead
FileData
MainDevi
ceBlock
-TCON-TUSEND-TURCV
StorageOIDs
GetAnyAd
dress
The following table lists the blocks of the application in their entirety. It does not list library and system blocks. For these blocks, please refer to the TIA Online Help.
Table 4-1
Block Description Note
Main Organization block
MainDeviceBlock Start block for the application.
contains the “SNMP” and “TFTP” calls.
interlocks the blocks.
SNMP Implements the SNMP client function.
retrieves required information using PROFINET mechanisms (“Automatic” variant only).
reads and writes to the SNMP variables in the network component (automatic or triggered process – depending on the variant).
TFTP Implements the TFTP server function.
saves the received configuration data of the network component in the load memory.
provides the configuration data upon request.
organizes the data blocks in a file management system.
GetAnyAddress
Dynamically generates an Any pointer.
required for access to the file management system.
StorageOIDs Contains the OIDs for the required SNMP variables.
StorageActualDevices (“Automatic” variant
Lists all supported components detected in the PROFINET system, including
the network components are detected using “DeviceState”.
the device information is read out
4 Programming in Detail
4.2 Program details on the “SNMP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 17
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Block Description Note
only) device information. using GEO2LOC and RDREC.
StorageTargetDevices Contains all network components involved in “loading and saving configuration data”, including device information.
for the “Automatic” variant, this is the reference list for “StorageActualDevices”. If a device entry does not match, an “upload”/“download” is necessary.
for the “Manual” variant, this block lists all devices for which an “upload”/“download” is planned.
StorageReadFileBuffer Buffer for the configuration data of the network component
4.2 Program details on the “SNMP” block
4.2.1 Block description
Function
The main task of the “SNMP” block is to emulate the SNMP client functionality in order to write to the SNMP variables of the network component.
In specific terms, these are the following SNMP variables:
TFTP server address
Configuration file name
Trigger “upload/download” via “TFTP-LOAD”/“TFTP-SAVE”
Enable configuration for “download”.
It is only this information that enables the network component to save/load its configuration data on the TFTP server.
The “Automatic” variant first automatically determines which values will be written to these variables. For the “Manual” variant, this is partly provided to the block as a parameter set.
Note regarding the configuration name
For the file management system, it is mandatory that the configuration file name be unique throughout the project and predefined conventions be followed. The name is composed as follows: “Config” + “serial device number” + “.cfg”. If identical names are used, the file can no longer be assigned to the network component. An “upload” is no longer possible.
To ensure this, both variants automatically generate the configuration name based on the above pattern.
4 Programming in Detail
4.2 Program details on the “SNMP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 18
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Sequence
The block is designed as a sequencer and its (simplified) sequence is shown below:
Figure 4-3
Establish SNMP connection
Automatically
collect
information
Transfer
information
via
parameters
Write to SNMP variable
“Konfigname”
Write to SNMP variable
“TFTP-Server-IP”
Set SNMP variable
“TFTP-LOAD”Set SNMP variable
“TFTP-SAVE”
Disconnect SNMP connection
Set SNMP variable “Reboot”
Enable “TFTP” block
Emulating the protocol
To write to the SNMP variables, SNMP must be emulated according to the specification and this data block must be sent to the module via the open communication blocks.
Each SNMP variable can be referenced by a unique OID. This OID and the associated value are parts of the “Varbind” sequence in the SNMP message.
4 Programming in Detail
4.2 Program details on the “SNMP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 19
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Call and parameters of the “Automatic” variant
The following figure shows the call of the “SNMP” block for the “Automatic” variant:
Figure 4-4
The following table lists the parameters of the block:
Table 4-2
Parameter Data type Description Comment
Input parameter
id CONN_OUC Connection ID for the open communication blocks.
This ID must be unique throughout the project.
hwInterface HW_ANY Hardware identifier for the PROFINET interface of the CPU.
Use the appropriate system constant.
pnioSystem HW_IOSYSTEM
Hardware identifier for the PROFINET system.
Use the appropriate system constant.
pnioSysNr UInt Number of the PROFINET system.
req BOOL Starts the application.
reqReset BOOL Resets the application. Only necessary if an error occurs.
transferRunning
BOOL Interlocking to avoid simultaneous TFTP and SNMP communication with the network component.
Must be interconnected with the associated output parameter of “TFTP”.
Output parameter
state typeBlockStateVariables
Status information.
4 Programming in Detail
4.2 Program details on the “SNMP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 20
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Call and parameters of the “Manual” variant
The following figure shows the call of the “SNMP” block for the “Manual” variant:
Figure 4-5
The following table lists the parameters of the block:
Table 4-3
Parameter Data type Description Comment
Input parameter
id CONN_OUC Connection ID for the open communication blocks.
This ID must be unique throughout the project.
hwInterface HW_ANY Hardware identifier for the PROFINET interface of the CPU.
Use the appropriate system constant.
targetElementNr
UInt Number of the array field in the “StorageTargetDevices” data block that contains the information of this network component.
“0” refers to the first entry in the “StorageTargetDevices” data block.
req BOOL Starts the application. Scans for a positive edge.
reqReset BOOL Resets the application. Only necessary if an error occurs.
cmd Int Command for the application.
1: SAVE 2: LOAD
transferRunning
BOOL Interlocking to avoid simultaneous TFTP and SNMP communication with the network component.
Must be interconnected with the associated output parameter of “TFTP”.
Output parameter
state typeBlockStateVariables
Status information.
4 Programming in Detail
4.2 Program details on the “SNMP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 21
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
4.2.2 Required auxiliary blocks
The “SNMP” block requires other auxiliary blocks that are stored in the project as data types, data blocks and system functions.
“DeviceState” system function
This function is only available for the “Automatic” variant. This statement allows you to retrieve specific status information about all IO devices in a PROFINET network.
“GEO2LOG” system function
This function is only available for the “Automatic” variant. This statement allows you to determine the hardware identifier of a module.
“Get_IM_Data” system function
This function is only available for the “Automatic” variant. This statement reads the identification and maintenance data from a module.
“RDREC” system function
This function is only available for the “Automatic” variant. This statement allows you to read a data record from a module.
TCON, TUSEND, TURCV, TDISCON communication blocks
With the aid of these communication blocks, a (UDP) connection is established between the controller and a partner in order to send and receive data.
Variables of the “typeBlockStateVariables” type are used to display the output parameters of these blocks.
“StorageTargetDevices”/“StorageActualDevices” data block
These two data blocks are almost identical.
“StorageActualDevices” is only required for the “Automatic” variant. All network components scanned by “DeviceState” and supported by the application are saved, including the determined (ACTUAL) device data and information.
“StorageTargetDevices” includes the (TARGET) device data and information of all network components actually involved and supported by the application. For the “Automatic” variant, this is the reference list for “StorageActualDevices”.
For the “Manual” variant, the parameters still required for the network component are entered here.
Both data blocks use the “typeBasicInfoDevice” data type.
“StorageOID” data block
As the OIDs may differ depending on the SCALANCE family, this data block contains the OIDs for the relevant SNMP variables.
The data block uses the “typeOidSNMP” data type.
“typeBasicHeaderSNMP” data type
Except for the “Varbind” sequence, the SNMP message is almost identical for all SNMP variables.
All identical parameters are stored in this data block.
4 Programming in Detail
4.3 Program details on the “TFTP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 22
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
4.3 Program details on the “TFTP” block
4.3.1 Block description
Function
The main task of the “TFTP” block is to emulate the TFTP server functionality in order to receive or provide the configuration data.
The appropriate function – “upload” or “download” – is triggered via SNMP and the associated SNMP variables.
Sequence
The block is designed as a sequencer and its (simplified) sequence is shown below:
Figure 4-6
Wait for job
Establish TFTP
control connection
“Write-Request”
function code received“Read-Request”
function code received
Disconnect data connection
Disconnect control connection
Send ack to client
Receive data from client block by block
Transfer data toload memory
Establish data connection
Provide data block by block
Transfer data fromload memory
4 Programming in Detail
4.3 Program details on the “TFTP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 23
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Emulating the protocol
To respond to the requests of a network component (TFTP client), TFTP must be interpreted and emulated in the controller (TFTP server) according to the specification. The exchange takes place via the open communication blocks.
If the client wants to send data to the server, it sends a WRQ (write request) with the file name and a transfer mode to port 69 of the server. The server acknowledges this message with an ACK (acknowledge) and its local port. If the client receives the ACK with block number 0, block-by-block data transfer starts. The last block is once again acknowledged and the transfer is complete. The data can now be saved.
If the client wants to retrieve data from the server, it sends an RRQ (read request) with the desired file name and a transfer mode to port 69 of the server. The server acknowledges this request with the first data block (DATA). The client acknowledges with the ACK and the block number until the last data block has been transferred.
The client request uses a control connection, the data transfer takes place via a separate data connection. To use only one connection resource, the control connection is closed due to the simple protocol and the data connection is set up. When the data transfer is complete, the control connection is reactivated.
Call and parameters
The following figure shows the call of the “TFTP” block for the “Automatic” and “Manual” variant:
Figure 4-7
4 Programming in Detail
4.3 Program details on the “TFTP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 24
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
The following table lists the parameters of the block:
Table 4-4
Parameter Data type Description Comment
Input parameter
id CONN_OUC Connection ID for the open communication blocks.
This ID must be unique throughout the project.
hwInterface HW_ANY Hardware identifier for the PROFINET interface of the CPU.
Use the appropriate system constant.
startNrDataBlockTftp
UInt Start number for the data blocks in the load memory.
The first number is reserved for the data block for saving the file directory. The following ones will later contain the configuration data of the network components.
nrBufferDataBlockTFTP
UInt Number of the data block for the data buffer.
reqReset BOOL Resets the application. Only necessary if an error occurs.
Output parameter
status typeBlockStateVariables
Status information.
transferRunning
BOOL Interlocking to avoid simultaneous TFTP and SNMP communication with the network component.
Must be interconnected with the associated input parameter of “SNMP”.
Input/output parameter
bufferConfigData
VARIANT Buffer for the configuration data.
The area must have a size of at least 500 bytes.
4 Programming in Detail
4.3 Program details on the “TFTP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 25
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
4.3.2 Required auxiliary blocks
The “TFTP” block requires other auxiliary blocks that are stored in the project as data types, data blocks and system functions.
“Create_DB” system function
This statement allows you to create a data block.
“Delete_DB” system function
This statement allows you to delete a data block.
“Read_DBL” system function
This statement allows you to copy the entire content of a data block or parts of it in the load memory.
“Write_DBL” system function
This statement allows you to transfer data from the main memory to a data block in the load memory.
“Attrib_DB” system function
This statement allows you to retrieve information about a block.
TCON, TUSEND, TURCV, TDISCON communication blocks
With the aid of these communication blocks, a (UDP) connection is established between the controller and a partner in order to send and receive data.
Variables of the “typeBlockStateVariables” type are used to display the output parameters of these blocks.
“typeTftpFileManagement” data type
This data type is the template for the entries in the file management system. The “typeTftpStorageInfos” data type is then used to list the required data block numbers per entry.
4 Programming in Detail
4.3 Program details on the “TFTP” block
TFTP Entry ID: 109483258, V1.0, 05/2016 26
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
4.3.3 The file directory
As no file management is available in the CPU, the files have to be managed by the program itself. The file directory is stored in the load memory.
The directory includes an array with a file list. A directory entry contains the following information:
Configuration file name
Last saved date
Length of the data block
Number of DBs used.
Multiple data block numbers can be saved for each entry. This is necessary as the configuration file sizes can exceed 64kB. The maximum size of a DB in the load memory (generated dynamically) is 64kB.
The following excerpt shows the file directory structure:
Figure 4-8
When the TFTP server receives a job from the network component (WRQ/RRQ + file name), the program browses all entries in the file directory for the same file name. As soon as it finds a match, this entry is used for further processing.
For this reason, it is mandatory for the file management system that the configuration file name be unique throughout the project and predefined conventions be followed.
Note The directory contents can be viewed using the instance data of the “TFTP” block. The “Manual” variant features an HMI. It additionally allows the user to view the contents.
4 Programming in Detail
4.4 Automatic mode functional sequence
TFTP Entry ID: 109483258, V1.0, 05/2016 27
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
4.4 Automatic mode functional sequence
Note The automatic mechanism is part of the “Automatic” variant. The software implementation is located in the “SNMP” block of the “Automatic” variant.
Requirement
Due to the configuration of a PROFINET system, the mechanisms for diagnostics and the required information for further processing are available. Automatic loading/saving can therefore be implemented.
This requires that a number of requirements be met:
The network component must be configured as a PROFINET device on a controller.
The network component must have a device name.
If device replacement is planned in the event of an error, a topology must be configured and the “Obtain an IP address automatically” property must be selected.
4 Programming in Detail
4.4 Automatic mode functional sequence
TFTP Entry ID: 109483258, V1.0, 05/2016 28
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Sequence
If these requirements are met, a comparison between the saved (TARGET) device data and the read (ACTUAL) device data defines the next steps. If the comparison yields differences, the configuration – depending on the result of the comparison – is loaded to the CPU or transferred to the network component.
The individual functions are called via a sequencer.
Figure 4-9
Determine device data:
HW identifier, IP address,
serial no.
Save as ACTUAL
Filter active and configured
PN devices
Compare TARGET<-> ACTUAL
TARGET= empty or
TARGET<> ACTUAL
Reread configuration
Trigger: Write TFTP
address/configuration
name
Read IP address of CPU
Trigger: Set
TFTP-SAVE
Save module data as
TARGET
ACTUAL serial no.<>
TARGET serial no.
Write configuration
to device
Trigger: Write TFTP
address/configuration
name
Trigger: Set
TFTP-LOAD
Enable configuration
Device
State
GEO2LOG
GetStationInfo
GetIMData
RDREC
RDREC
4 Programming in Detail
4.4 Automatic mode functional sequence
TFTP Entry ID: 109483258, V1.0, 05/2016 29
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Description
Determine device data
When the search for active and configured PN devices has completed, the device data collection process can be started.
The first step determines the required hardware identifier with the aid of the “GEO2LOG” function. The next step reads the IP address of the device using “GetStationInfo”. It will later be needed for the SNMP functions.
The MLFB is required to filter the network components out of all PN devices. It is read out via the IM0 “maintenance” data record. The result contains two important pieces of data.
MLFB: To detect network components (MLFB: 6GK5…).
Serial number: Indicates whether the device has changed (device replacement).
Finally, the controller’s IP address is read, which is the required TFTP server address.
All this information is stored in the “StorageActualDevices” data block as ACTUAL device data.
Read configurations
When the device data has been read, a comparison is made to see whether the read (ACTUAL) device data matches the stored (TARGET) device data.
The ACTUAL device data is located in the “StorageActualDevices” data block, the TARGET device data is in the “StorageTargetDevices” data block.
If no stored data exists (no entry in the “StorageTargetDevices” data block), the configuration of all network components is read via TFTP and stored on the memory card (load memory).
If (TARGET) device data is stored but the number of network components does not match, the procedure is the same as if no stored data existed.
Load configuration back to network component
If the comparison between the stored (TARGET) device data and the read (ACTUAL) device data finds a difference in the serial number, it is assumed that the device was replaced. The network component’s configuration file saved (as a data block) is loaded back to the device.
Special aspects
Transferring data to or from the network component can have effects on the PROFINET system.
For some devices, it is necessary to disable the network component during this period. During this period, general PROFINET data traffic is not affected. If the configuration is transferred to the network component, a restart is necessary. During this period, general data traffic is interrupted, including PROFINET.
The configuration of the topology and disabling may cause diagnostic messages of the device neighbors.
Depending on the device type, a data transfer takes several seconds.
5 Valuable Information on the Configuration
5.1 Rules for running the function blocks
TFTP Entry ID: 109483258, V1.0, 05/2016 30
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
5 Valuable Information on the Configuration
5.1 Rules for running the function blocks
“Automatic” variant
The “Automatic” variant is based on a PROFINET network and requires that the following requirements be met:
All network components must be integrated into the TIA project as hardware.
All network components, as a PROFINET device, must be assigned to an IO controller.
All network components must have unique device names and IP addresses.
If device replacement is planned in the event of an error, a topology must be configured and the “Obtain an IP address automatically” property must be selected in the PN device.
Note If your PROFINET network differs from the one of this application example, change the hardware configuration in the TIA project accordingly following the above requirements.
“Manual” variant
The “Manual” variant can be used in a standard Industrial Ethernet network. The only condition for the application to function properly is a unique IP address for each network component.
Integrating the network components into the TIA project is optional.
5.2 Parts of the TIA projects
As the number of blocks and their programming differ, a separate TIA project exists for each variant.
The hardware of both variants is identical:
Table 5-1
No. Device IP address
1. CPU S7 1516-3 PN/DP 192.168.0.1
2. XB 200 192.168.0.4
3. SCALANCE W761 192.168.0.5
“Automatic” variant
Due to the implemented automatic mechanism, this variant only uses a single call of the main blocks, “SNMP” and “TFTP”. The two blocks are interlocked using input/output parameters.
“Manual” variant
In this case, each network component – that is supported by the application – can be individually triggered for “upload”/“download”.
For this reason, a separate instance of the “SNMP” block is required for each device. The “TFTP” block continues to be called once.
5 Valuable Information on the Configuration
5.3 Customizing the sample code
TFTP Entry ID: 109483258, V1.0, 05/2016 31
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Note The user must make sure that only one SNMP instance is processed at a time and not multiple instances simultaneously. Otherwise, loss of data, data inconsistency and faulty processing of the “TFTP” block may occur.
In the application example, this has already been ensured.
5.3 Customizing the sample code
If your network configuration differs from the one of the sample code, you have to make changes in the program.
5.3.1 Changes for the “Automatic” variant
Hardware configuration
If you are using network components other than the ones specified, customize the TIA project’s hardware configuration accordingly. Add more devices to the PROFINET system or delete unused ones.
Make sure to follow the rules when integrating the devices (see chapter 5.1).
Program blocks
Due to the automatic mechanism, it is irrelevant to the program blocks whether the number of PN devices or their type has changed. It always scans and filters all active and configured PN devices.
If there is a divergence, customize the “hwInterface” and “pnioSysNr” input parameters of the “SNMP” and “TFTP” blocks to your hardware configuration if necessary.
5.3.2 Changes for the “Manual” variant
Hardware configuration
As the operation is independent of PROFINET, integration into the TIA project is not required for this variant.
The only condition is a valid IP address of the network components in the network of the controller.
Program blocks
“SNMP”
As each network component can be individually triggered for “upload”/“download”, a separate “SNMP” block instance is required for each network component.
The calls are made in the “MainDeviceBlock” block.
You must ensure that only one SNMP instance is processed at a time, as otherwise conflicts with the “TFTP” block will occur.
“StorageTargetDevices”
For each network component involved, the “StorageTargetDevices” data block must contain an entry with the appropriate SNMP information. This data block includes the (TARGET) device data and information of all components actually involved and supported by the application.
Add more entries or delete unused ones.
5 Valuable Information on the Configuration
5.3 Customizing the sample code
TFTP Entry ID: 109483258, V1.0, 05/2016 32
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Customize the information within an entry. The “SNMP” block needs the following information to operate correctly:
Device number
IP address
The following screenshot shows an excerpt of the “StorageTargetDevices” data block with two nodes as an example:
Figure 5-1
The following table lists the parameters:
Table 5-2
Parameter Data type Description Comment
countDevices UInt Total number of network components.
devNumber UInt Network component number.
Any device number can be selected; however, it must be unique throughout the project. It is part of the configuration file name.
devIP USInt Array for the IP address of the network component.
ConfigName String Storage location for the configuration file name.
The name is automatically generated and stored in this location.
6 Installation and Startup
6.1 Installation
TFTP Entry ID: 109483258, V1.0, 05/2016 33
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
6 Installation and Startup This chapter describes the steps necessary to install and start up the example using the hardware list and the code from the download.
6.1 Installation
Installing the hardware
Follow the hardware list provided in chapter 2.3 and set up an Industrial Ethernet network and connect the devices using Ethernet cables.
Connect the devices to a 24 V power supply unit.
The figure below shows the hardware configuration of this application example:
S7-1500XB-200
PROFINET IE
W761
Note You can also use different hardware. Please note: The application generally supports the following network components:
S7-1500
SCALANCE of the XB-200 series
W761 access point
W722, W721 client modules
Deviations from the sample project result in changes of the configuration. Please turn to the appropriate chapters and sections.
6 Installation and Startup
6.2 Starting up the “Automatic” variant
TFTP Entry ID: 109483258, V1.0, 05/2016 34
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
Installing the software (download)
Follow the installation guide to install TIA Portal.
Download the sample code and extract the file to a directory of your choice.
The file contains two TIA projects:
SAVE_CONFIG_AUTO.ap13 (“Automatic” variant)
SAVE_CONFIG_MANUAL.ap13 (“Manual” variant)
6.2 Starting up the “Automatic” variant
Starting up the application example
To start up the example, proceed as follows:
1. Open the desired TIA Portal project.
2. Download the project to the CPU.
3. For each component, a device name is stored in the project. Use the “Assign device name” TIA function to write this name to the modules.
Starting up the application with changed hardware
To start up the “Automatic” variant with changed hardware, proceed as follows:
1. Open the SAVE_CONFIG_AUTO.ap13 project.
2. If necessary, customize the hardware configuration to your needs and follow the PROFINET guidelines to parameterize the components (device name, IO controller assignment, “Obtain an IP address automatically” property, …).
3. Configure the topology to be able to automatically assign the IP address to the replacement device in case of device replacement.
4. Make sure that the parameters of the “SNMP” and “TFTP” blocks are correct and modify them if necessary.
5. Save the project and download the project to the CPU.
6. Use the “Assign device name” TIA function to write the device names to the modules.
6 Installation and Startup
6.3 Starting up the “Manual” variant
TFTP Entry ID: 109483258, V1.0, 05/2016 35
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
6.3 Starting up the “Manual” variant
Starting up the application example
To start up the example, proceed as follows:
1. Open the SAVE_CONFIG_MANUAL.ap13 project.
2. Save the project and download the project to the CPU.
3. If desired, download the HMI project to the panel.
Starting up the application with changed hardware
To start up the “Manual” variant with changed hardware, proceed as follows:
1. Open the SAVE_CONFIG_MANUAL.ap13 project.
2. An entry in the “StorageTargetDevices” data block and a separate instance of the “SNMP” block must exist for each network component involved. Make sure that all network components involved have an entry in the “StorageTargetDevices” data block. It contains the (TARGET) device data and information for further processing.
3. In addition, change the “countDevices” variable in the same data block to the number of network components used.
4. If necessary, insert more “SNMP” block instance calls into the “MainDeviceBlock” and parameterize them.
5. Furthermore, make sure that the parameters of the “SNMP” and “TFTP” blocks are correct and modify them if necessary.
6. Save the project and download the project to the CPU.
7 Operation of the Application
7.1 “Automatic” variant
TFTP Entry ID: 109483258, V1.0, 05/2016 36
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
7 Operation of the Application
7.1 “Automatic” variant
The “Automatic” variant requires no start command – it acts automatically following the below sequence:
Table 7-1
Sequence no. Action Comment
1. Search for active and configured PN devices. Filter by network components.
The following network components are involved in the process:
SCALANCE XB-200
SCALANCE W761
SCALANCE W721/W722
2. Determine the parameters required for SNMP handling.
The information/devices can be viewed in the “StorageTargetDevices” or “StorageTargetDevices” data block.
3. Define the next steps by comparing the saved (TARGET) device data with the (ACTUAL) device data.
If the comparison yields differences, the configuration – depending on its type – is loaded to the CPU or written to the network component.
4. TFTP-SAVE: The SCALANCE transfers its configuration data to the controller.
The configuration data is stored in data blocks in the load memory and the file directory with the data block numbers is updated accordingly.
An entry in the file directory, including the appropriate data block numbers, is created for each SCALANCE.
5. TFTP-LOAD: The SCALANCE reads its configuration data from the controller.
The associated data blocks are searched for in the file directory. Their contents are provided to the SCALANCE for reading.
7 Operation of the Application
7.2 “Manual” variant
TFTP Entry ID: 109483258, V1.0, 05/2016 37
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
7.2 “Manual” variant
Requirement
To use the application in the “Manual” variant, the following requirements must be met:
1. All network components involved and supported must have an entry in the “StorageTargetDevices” data block.
2. Each of these network components must have a separate instance of the “SNMP” block in the “MainDeviceBlock” with the appropriate parameterization.
Use
How to use the application example is shown as an example using WinCC Runtime:
1. Start WinCC Runtime or download the WinCC project to the panel. The start screen is displayed and shows the configuration of two devices (see also Figure 5-1).
2. In Entry 1, select the “SAVE” command to back up the configuration data of the SCALANCE W761 in the load memory of the CPU.
7 Operation of the Application
7.2 “Manual” variant
TFTP Entry ID: 109483258, V1.0, 05/2016 38
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
3. Select “START” to start the transfer.
4. The configuration file name was generated and the data was stored in data blocks.
5. Go to the “Filemanagement” user interface.
7 Operation of the Application
7.2 “Manual” variant
TFTP Entry ID: 109483258, V1.0, 05/2016 39
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
6. It displays the following information from the file directory:
– Configuration file name
– Date created
– Number of data blocks in the load memory
– Total size of the configuration file
– Data block number with the respective size
7. In the TIA project, set up an online connection to the CPU. The “Program blocks” > “System blocks” section displays the data blocks in the load memory.
7 Operation of the Application
7.2 “Manual” variant
TFTP Entry ID: 109483258, V1.0, 05/2016 40
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
8. To load the configuration data back to the module, select the “LOAD” command in Entry 1 and then use “START” to start the transfer.
Using the configuration file name, the associated data blocks are determined in the file directory and the data content is provided to the module. After loading, the module restarts with the loaded configuration data.
8 Links & Literature
TFTP Entry ID: 109483258, V1.0, 05/2016 41
S
iem
en
s A
G 2
01
6 A
ll ri
gh
ts r
ese
rve
d
8 Links & Literature Table 8-1
Topic
\1\ Siemens Industry Online Support
https://support.industry.siemens.com
\2\ Download page of the entry https://support.industry.siemens.com/cs/ww/en/view/109483258
\3\ Updates for TIA Portal V13 SP1 https://support.industry.siemens.com/cs/en/en/view/109311724
\4\ SCALANCE W761 Configuration Manual
https://support.industry.siemens.com/cs/en/en/view/109480845
\5\ SCALANCE XB-200 Configuration Manual https://support.industry.siemens.com/cs/en/en/view/109476752
\6\ SIMATIC PROFINET with STEP 7 V13 https://support.industry.siemens.com/cs/en/en/view/49948856
9 History
Table 9-1
Version Date Modifications
V1.0 05/2016 First version
Recommended