Application Description 03/2014. Detecting PROFINET Topologies and Activating IO Devices.

Transcription

1 Application Description 03/2014 Detecting PROFINET Topologies and Activating IO Devices

2 Siemens AG 2014 All rights reserved Warranty and Liability 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 these Application Examples and other Siemens publications e.g. Catalogs the contents of the other documents 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 a condition which goes to the root of the contract ( 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 Industry Sector. Security information Siemens provides products and solutions with industrial security functions that support the secure operation of plants, solutions, machines, equipment and/or networks. They are important components in a holistic industrial security concept. With this in mind, Siemens products and solutions undergo continuous development. Siemens recommends strongly that you regularly check for product updates. For the secure operation of Siemens products and solutions, it is necessary to take suitable preventive action (e.g. cell protection concept) and integrate each component into a holistic, state-of-the-art industrial security concept. Third-party products that may be in use should also be considered. For more information about industrial security, visit To stay informed about product updates as they occur, sign up for a productspecific newsletter. For more information, visit Entry ID: , V1.0, 03/2014 2

3 Table of Contents Table of Contents Warranty and Liability Task Solution Overview Description of the core functionality Hardware and software components Validity Components used Principle of Operation General overview The DeviceData data block Functionality of the Discover_And_Activate block Program structure Parameters Program details of the Discover_And_Activate function block Functionality of the Discover function block Program structure Parameters Program details of the Discover function block Functionality of the Act_Deact block Program structure Parameters Program details of the Act_Deact function block Installation and Startup Hardware installation Software installation Startup Filling the Device_Data data block with start values Operation of the Application Overview Operation of the application using the watch table DiscoverAndAcivate tag GetDeviceData tag ActDeactDevices tag and ActDeactMode Appendix PROFINET data record 802A References History Entry ID: , V1.0, 03/2014 3

4 1 Task 1 Task Introduction A key requirement of series machine building is to be able to manage multiple configurations of a machine or plant with a single STEP 7 program. If a machine is to be operated in different configurations of a local ET200S(P) station, the principle of configuration control (option handling) has been available for this purpose for some time. It can be used not only on a machine-internal but also on a plant-wide basis. This application allows the user to manually activate or deactivate plant parts based on PROFINET IO. Overview of the automation task The figure below shows different variants of a virtual plant that consists of a central production unit and multiple units for remachining the workpieces. The central production unit can be run in conjunction with other units or a selection of different units and even without any other units. The central production unit or its PROFINET IO controller control the units. Each unit is a PROFINET IO device. Figure 1-1 Entry ID: , V1.0, 03/2014 4

5 1 Task Description of the automation task What does the application do? Detects the connected IO devices. Activates the previously detected IO devices (and deactivates the ones that have not been detected). Manually activates and deactivates IO devices. In addition: Provides the connection information of the IO devices in a database for further processing in the user program. Entry ID: , V1.0, 03/2014 5

6 2 Solution 2.1 Overview 2 Solution 2.1 Overview Diagrammatic representation The diagrammatic representation below shows the component used in this application. The dash bus line represents an optional connection. Figure 2-1 Table 2-1 # Device Task (1) CPU 1516 Corresponds to the central component from the previous figure. (2) ET 200MP Corresponds to a production unit from the previous figure. (3) ET 200MP Corresponds to a production unit from the previous figure. (4) ET 200SP Corresponds to a production unit from the previous figure. Executes the control program, manages the topology (IO controller). IO device IO device IO device Advantages The solution presented here offers you the following advantages: The same user program is suitable for different or changing plant configurations and hardware topologies and can be extended as desired, which makes it ideal for series machines. The number of IO devices used can be changed as required and is only limited by the quantity framework of the CPU (CPU PN/DP: Max. 256 IO devices). Both ports of a CPU interface can be used to connect IO devices and therefore two lines can be set up. Entry ID: , V1.0, 03/2014 6

7 2 Solution 2.1 Overview Scope This application does not include a description of the following: Configuring the hardware and using TIA Portal. Programming SIMATIC S7. Network technology and protocols. Basic knowledge of these topics is required. Required knowledge Basic knowledge of the SIMATIC automation system and PROFINET IO. Advanced knowledge of the TIA Portal configuration software. Entry ID: , V1.0, 03/2014 7

8 2 Solution 2.2 Description of the core functionality 2.2 Description of the core functionality The basic idea of this application is mutual detection of neighborhood relationships by means of PROFINET mechanisms. Once the direct neighbor is known, you can retrieve exactly the same information about its next neighbor. In this way, you can scan all the neighbors until you reach the last neighbor in the row, i.e. until there is no longer a response. Technically, reading out PROFINET data records is suitable for this purpose. A side note on PROFINET data records & LLDP The data records are filled by the PROFINET devices themselves and contain information about the respective neighbor, including the PROFINET device names and the port names of the device. Via local multicast (LLDP), this data is requested by the device itself and returned by the neighboring PROFINET device. Then this data is stored in a so-called MIB from which the PROFINET data record is generated. Notes The principle of operation described here refers to line topologies. The aim of the details described in the last paragraphs is merely to explain the function of the application example. In-depth knowledge of the technologies described is not necessary. Sequence of the core functionality 1. All IO devices that are used in the user program have been created in a central database, including all the relevant data. 2. Depending on the currently required plant configuration, various IO devices are connected to the plant. 3. The previously described mechanisms allow you to perform topology detection before running the actual user program. 4. The topology detection results (IO device activated, deactivated) are stored in the central database. 5. Then all IO devices detected as online are activated and all IO devices that are not accessible are deactivated. 6. In the user program, you can now react to the existing IO devices, which in this case correspond to plant parts. The user program needs to call only the blocks relevant to the actually connected IO devices. Entry ID: , V1.0, 03/2014 8

9 2 Solution 2.2 Description of the core functionality Program flow The following flowchart shows the complete scenario. You additionally have the option to separately execute individual steps of this scenario. The following chapters provide more information on this option. Figure Deactivate all devices 2 Scan neighboring device Next neighbor Neighbor exists No 3 Yes 4 Neighbor active 5 Yes No Activate neighbor 6 Write neighborhood data Central database 7 React to configuration in UP Yes Neighbor exists No 3 Start/stop Table 2-2 # Action Note 1. Create a uniform start situation deactivate all IO devices. 2. Retrieve the device name of the next connected IO device. 3. If the IO device does not respond (because there is none), this information is stored in the database and the program is closed. 4. If the IO device responds (i.e. there is one), central data management checks whether the IO device has been created in it and whether it has been activated. 5. If the IO device has been activated, this information is stored in the database and the sequence starts from the beginning (step 2). 6. If the IO device has been deactivated, this IO device is activated, this information is stored in the database and the sequence starts from the beginning (step 2). 7. Depending on the configuration, the appropriate program parts are executed in the user program (UP). Optional. The CPU is the starting point. This check is not shown in the figure. Entry ID: , V1.0, 03/2014 9

10 2 Solution 2.3 Hardware and software components 2.3 Hardware and software components Validity This application is valid for: STEP 7 V12 SP1 or higher S CPU firmware version V1 or higher Any PROFINET IO components Components used The application was created with the following components: Hardware components Table 2-3 Component No. Order number Note S PN/DP 1 6ES AN00-0AB0 Or other S IM PN ST 2 6ES AA00-0AB0 Or other PN IO device DQ 32x24VDC/0.5A ST 2 6ES BL00-0AB0 Optional IM PN ST 1 6ES AU00-0BN0 Or other PN IO device DQ 8x24VDC/0.5A 1 6ES BF00-0AB0 Optional Software components Table 2-4 Component No. Order no. Note TIA Portal V12 SP1 1 6ES7822-0AA02-0YA5 Sample files and projects The following list contains all files and projects that are used in this example. Table 2-5 Component Dyn_PN_Topo_V12_SP1.zip Dyn_PN_Topo.pdf Note This file contains the STEP 7 project. This document. Entry ID: , V1.0, 03/

11 3 Principle of Operation 3.1 General overview 3 Principle of Operation 3.1 General overview Externally, the application example consists of three functions or program blocks that can be controlled via few parameters: Discover: Discovers which IO devices are connected. Act_Deact: Manually or automatically activates or deactivates the configured IO devices. Discover_And_Activate: Combination of the above functions. The Device_Data data block is used for data management (central database). This is where all the parameters necessary for the function of the individual blocks are stored. Characteristic features In the world of TIA Portal and the S used in this application example, implementation involves a number of challenges that can be solved with this application: The neighbor of a device can only be discovered if you know the hardware ID of the port whose neighbor you want to find. The data from the hardware configuration (hardware IDs and device names) cannot be accessed from the user program. The data must be maintained in a data block (DB). The data record returned by the PROFINET devices must first be split into its individual elements in order to obtain the device name in plain text (structure: See PROFINET data record 802A). Entry ID: , V1.0, 03/

12 3 Principle of Operation 3.1 General overview Program overview Figure 3-1 Startup Discover GetNext DeviceInLine GetDevice Name RDREC Device_ Control Discover_ And_Activate DBQuery S_COMP Act_Deact IO_Control Simulation Internally, the application example has a modular design. The three program blocks mentioned above use a number of other program blocks in the background. The description of these program blocks is included in the description of the previously mentioned program blocks in the next chapters. Complete overview of the program blocks Table 3-1 Symbolic name Description Type Startup OB Device_Control Discover_And_Activate Discover Creates a defined initial state in the Device_Data DB. Block to operate the application: Calls the core functions via global variables. Calls all functions for detecting, checking, activating and deactivating IO devices. Calls all functions for detecting and checking. OB SCL OB SCL FB SCL FB SCL Act_Deact Activates or deactivates IO devices. FB SCL GetNextDeviceInLine GetDeviceName RDREC DB_Query: Returns the data record number (from data management) of the next device in the PROFINET line. Uses GetDeviceName and DB_Query. Responsible for reading out the device name and port name of the neighboring port. System function for reading out the data record. Checks whether the received device name has been created in internal data management (i.e. whether the IO device has been configured). Uses S_COMP. FB SCL FC SCL SFC FB SCL S_COMP LAD auxiliary construct (S_COMP in V12 SP1 not available in SCL). FC LAD Entry ID: , V1.0, 03/

13 3 Principle of Operation 3.1 General overview Symbolic name Description Type IO_Control Simulation Provides the running light (bit pattern) of the Simulation block at the outputs of the activated IO devices. Simulates the actual automation task with a running light (bit pattern). Allows a quick visual check to see whether IO devices have been activated. OB FBD FB SCL Entry ID: , V1.0, 03/

14 3 Principle of Operation 3.2 The DeviceData data block 3.2 The DeviceData data block The DeviceData data block (DB) is the core of this application. It contains an image of the maximum hardware configuration. In this data block, the individual IO devices and the IO controller are listed with their device names and port names. The hardware ID of the device is needed to activate or deactivate a device. In order to read out the information of the neighboring IO device, you need the hardware ID of the port. This hardware ID is also maintained in the DB. In addition to the above-listed data, the DB also contains status bytes of the individual devices. They indicate whether the respective IO device can be accessed and whether or not the individual ports have partners. These status bytes are written by the user program. Overview Figure 3-2 Data block details When starting up the application example, the data block must be filled with values: Device names Port names Hardware IDs These values can be found in the device configuration or in the system constants (PLC tags > Default tag table > System constants tab). For more details, please refer to the Startup chapter. Entry ID: , V1.0, 03/

15 3 Principle of Operation 3.3 Functionality of the Discover_And_Activate block 3.3 Functionality of the Discover_And_Activate block The Discover_And_Activate function block is the main block of this application. This block and its subordinate blocks call all functions for detecting, checking, activating and deactivating IO devices Program structure Figure 3-3 Discover_ And_Activate Discover Act_Deact Parameters Figure 3-4 Block parameters Table 3-2 Name Data type Description Output busy Bool Active while the block is still running. done Bool Active when the block has finished processing Program details of the Discover_And_Activate function block The Discover_And_Activate function block calls the Discover and Act_Deact blocks in a loop, one after the other, until the physical end of the line is actually reached. Entry ID: , V1.0, 03/

16 3 Principle of Operation 3.4 Functionality of the Discover function block Figure Discover Act_Deact! 1! 2? 3? 2 Discover Act_Deact!!!? 3 Discover Act_Deact!!!! Table 3-3 Executed loop Action 1. Discover detects the neighbor of the CPU, IO devices (1), (2). Discover cannot access the neighbor of IO device (2), IO device (3), because IO device (2) is not active. Discover is stopped and Act_Deact is called, which activates IO device (2). Act_Deact will be called again in the next cycle. 2. Discover detects IO devices (1), (2), (3). Discover cannot access the neighbor of IO device (3) or the end of the line, because it cannot access IO device (3) due to the fact that it is not active. Discover is stopped and Act_Deact is called, which activates IO device (3). Act_Deact will be called again in the next cycle. 3. Discover detects IO devices (1), (2), (3) and that the line ends after IO device (3). Act_Deact is stopped and will not be called again. 3.4 Functionality of the Discover function block The Discover block runs through the PROFINET lines connected to the two ports of the CPU until it reaches the end of these lines. The block documents the IO devices of the line or their status in the Device_Data DB Program structure Figure 3-6 Discover GetNext DeviceInLine GetDevice Name RDREC DS802A DBQuery SFC S_COMP Entry ID: , V1.0, 03/

17 3 Principle of Operation 3.4 Functionality of the Discover function block Parameters The block has the following parameters: Figure 3-7 Block parameters Table 3-4 Name Data type Description Output busy Bool Active while the block is still running. done Bool Active when the block has finished processing Program details of the Discover function block The functional scope of the Discover block is limited to switching the CPU ports (one line is possible per port) and the downstream calls of the blocks described in the following. FB GetNextDeviceInLine FC GetDeviceName FB DBQuery To actually get the IO devices in the line, Discover uses the GetNextDeviceInLine block. This block is called until it returns the no partner error. Within one execution of GetNextDeviceInLine, the block uses the GetDeviceName function to get the device name and the name of the port of the next neighbor. The FC is addressed with the hardware ID of the port whose neighborhood data the user wants to determine. For this purpose, the FC uses the RDREC system function to read out the appropriate PROFINET data record (802A). This data record is then stored in DB DS802A as raw data, decrypted by the FC and the data (device name and port name) is provided at the block interface. More information on data record 802A can be found at the end of this application description. This function block checks whether the DeviceData DB contains the device name, i.e. whether the IO device was actually configured. For configured IO devices, DBQuery returns the data record number of this IO device. This allows GetNextDeviceInLine to get the next neighbor using the hardware ID stored in the DeviceData DB. Entry ID: , V1.0, 03/

18 3 Principle of Operation 3.5 Functionality of the Act_Deact block 3.5 Functionality of the Act_Deact block The Act_Deact function block is used to activate or deactivate the IO devices Program structure Figure 3-8 Act_Deact SFC D_ACT_DP Parameters The block has the following parameters: Figure 3-9 Block parameters Table 3-5 Name Data type Description Input Mode Int Mode with which the block is to be executed. See next paragraph. Output Busy Bool Active while the block is still running. Done Bool Active when the block has finished processing Program details of the Act_Deact function block The Act_Deact function block has 3 modes: Mode 1: Activate all IO devices that have been created in the DeviceData DB (regardless of whether or not they are accessible). This mode is not used in this application example. Mode 2: Deactivate all IO devices that have been created in the DeviceData DB. This mode is used in the Startup OB. Mode 3: Activate IO devices that have been detected as accessible and created in the DeviceData DB. This mode is used by the DiscoverAndActivate block. Entry ID: , V1.0, 03/

19 3 Principle of Operation 3.5 Functionality of the Act_Deact block In each mode, Act_Deact is executed in a loop until all data records of the Device_Data DB have been processed. To activate/deactivate the IO devices, Act_Deact uses the D_ACT_DP system function, which is newly called in each executed loop. For activating/deactivating, this system function requires the hardware ID of the respective IO device. These values are read out of the Device_Data DB. Entry ID: , V1.0, 03/

20 4 Installation and Startup 4.1 Hardware installation 4 Installation and Startup 4.1 Hardware installation The figure below shows the hardware configuration of the application. Figure 4-1 NOTICE Always follow the installation guidelines for all components. Table 4-1 No. Action 1. Supply power to the IO devices, the CPU and, if necessary, the PG. 2. Connect the IO devices to the CPU (RJ45) via PROFINET in any topology. Use only the two ports of interface 1 (X1) of the CPU. Entry ID: , V1.0, 03/

21 4 Installation and Startup 4.2 Software installation 4.2 Software installation This chapter describes the steps necessary to install the required software. Note It is recommended to always run the latest version of the software. TIA Portal with STEP 7 Install STEP 7 V12 SP1 on your programming unit. Follow the instructions of the program. 4.3 Startup S and IO devices Table 4-2 No. Action Note 1. Download the sample application to your programming unit and extract the archive. EntryID 2. Open the TIA Portal project. Dyn_PN_Topo_V12_SP1 3. Replace, add or, if necessary, delete IO devices to access your actual hardware configuration. To do so, use the device configuration. 4. If necessary, replace the CPU with the S CPU are using. 5. Assign the final PROFINET device names already at this point. 6. Assign the port names for all ports as follows: port-001, port Assign the PROFINET device names to the IO devices. 8. Compile and download the hardware configuration. Later changes require manual modifications to the Device_Data data block. The port names must be identical on all devices as they are processed in the program code. For details, please refer to the References chapter (SIMATIC PROFINET with STEP 7 V12) or the online help. 9. Set the CPU to RUN. If the number of IO devices you have configured exceeds the number of connected IO devices, this is detected by the CPU and the error LED lights up. For information on how to fix this error, i.e. the actual use case of this application, please refer to this chapter: DiscoverAndAcivate tag Entry ID: , V1.0, 03/

22 4 Installation and Startup 4.4 Filling the Device_Data data block with start values Note In the as-supplied state, this application works only with line topologies. However, two PROFINET lines are possible at one interface of the CPU. During runtime, the PG (or other devices that do not comply with the PROFINET specification) must not be the end point of one of the lines. For testing, it is mandatory that you use the X2 interface of the CPU for the PG. To assign the PROFINET device names, the PG must be in the same subnet as the IO devices (X1 interface). 4.4 Filling the Device_Data data block with start values The Device_Data data block is responsible for the application s central data management. However, some parameters must be assigned values during startup. If you apply the project without any changes, it is nevertheless recommended to check the hardware IDs (HW ID) as they may be reassigned by TIA Portal. Figure 4-2 Table 4-3 No. Action 1. Open the supplied TIA Portal project. 2. Open the Device_Data data block. 3. If necessary, adjust the number of IO devices, Number_of_Devices, in the DB to the number configured in the device configuration. In this context, the CPU is NOT an IO device. 4. If necessary, adjust the array limits of Device_Data to your device configuration. In this example: [0..3] Location 0 of the array always contains the CPU, i.e. the upper array limit always equals the number of IO devices (the CPU itself is the IO controller). Entry ID: , V1.0, 03/

23 4 Installation and Startup 4.4 Filling the Device_Data data block with start values No. Action 5. If necessary, change the PROFINET device names, DeviceName, to the device names assigned in the device configuration. Make sure to change all array elements accordingly! 6. If necessary, change the hardware IDs of the IO devices, Device_HW_ID. The hardware IDs can be found in the default tag table in the System constants tab. The numerical value of the hardware IDs of the ports is normally 4-5 points higher than the one of the IO device. You can recognize the IDs of your IO devices by the following notation: Name[IODevice]. Entry ID: , V1.0, 03/

24 4 Installation and Startup 4.4 Filling the Device_Data data block with start values No. Action 7. If necessary, change the hardware IDs of the Port_HW_ID ports for all devices. The hardware IDs can be found in the hardware configuration. Select the appropriate IO device. 8. Compile and load your configuration. The application is now ready to run. Entry ID: , V1.0, 03/

25 5 Operation of the Application 5.1 Overview 5 Operation of the Application 5.1 Overview To make it easier to understand and reproduce the application, it is operated using the tag or watch table. In your project, you should call the appropriate functions via the user program on an automated basis. You will find the actual FB calls made using the tags described here in the Device-Control block. Figure Operation of the application using the watch table In the watch table, all tags relevant to the operation of the application have already been created and can be conveniently controlled from this table. In addition, it allows you to monitor the values of the DeviceData DB. Figure 5-2 Entry ID: , V1.0, 03/

26 5 Operation of the Application 5.2 Operation of the application using the watch table DiscoverAndAcivate tag Activates the main scenario: Modify this tag to true to activate all accessible IO devices on a fully automated basis GetDeviceData tag Modify this tag to true to enter the just connected (and activated) IO devices and their information in the DB. The results of this action are displayed either directly in the Device_Data DB or in the watch table ActDeactDevices tag and ActDeactMode Modify this tag to true to activate or deactivate the IO devices. The operating mode of the block called during this operation is set using the ActDeactMode tag. Operating modes: 1: Activate all IO devices. Activates all IO devices that have been created in the Device_Data DB. Accessibility is not checked. Note Unavailable IO devices are also activated. Where applicable, the CPU reports a station failure. 2: Deactivate all IO devices. Deactivates all IO devices that have been created in the Device_Data DB. Accessibility is not checked. 3: Activate accessible IO devices. Activates all accessible IO devices that have been created in the Device_Data DB. Deactivates all IO devices that are not accessible and have been created in the Device_Data DB. Note Operating mode 3: Activate accessible IO devices activates only IO devices that were detected via GetDeviceData. IO devices following the first deactivated IO device in the line are not detected. This is not possible using PROFINET mechanisms. To allow detection of these IO devices, first activate all accessible IO devices and then re-run GetDeviceData. This process must be repeated until the end of the line is reached. Exactly this procedure represents the DiscoverAndActivate function described in the first chapter. Entry ID: , V1.0, 03/

27 6 Appendix 6 Appendix 6.1 PROFINET data record 802A When considering the PROFINET naming conventions according to DNS, the data record can reach a maximum length of 370 bytes. The data record is read via the hardware ID of the port whose next neighbor is required. The RDREC system function is used to read out the data record. Figure 6-1 Content of the data record Basically, the data record contains the following information: Name of the local (your own) port (not evaluated in this application) Name of the remote port Remote device name Structure of the data record In order to read out the data record, you need exact information about the structure. This relates mainly to the offsets of the respective information. They can be found in the following table. Neighborhood information Data type Value Header Block type Word 527 (dec) LLDP data of the local port Data record length following Version High Word 68 (dec) Version High Byte 1 (dec) Version Low Byte 0 (dec) Reserve Byte 0x00 Reserve Byte 0x00 Slot number Word 0x0000 0x0000 0x7FFF Number of submodules Subslot number Dword 0x x0001 0x7FFF Number of the submodule 0x8000 0x8FFF Number of the port in the submodule Port name length = x Byte 8 (dec) Entry ID: , V1.0, 03/

28 6 Appendix LLDP data of the remote port Network data of the local port Neighborhood information Data type Value Port name 1-x char port-005 Number of remote partners Byte 1 (dec) Fill up to data word limit 0-3 bytes 0x00 Remote port name length = y Byte 8 (dec) Remote port name 1-y char port-001 Remote device name length = z Byte 5 (dec) Remote device name 1-z char cp343 Fill up to data word limit 0-3 bytes 0x00 Line delay Dword 0x00 Remote MAC address Byte 0x00 Remote MAC address Byte 0x0E Remote MAC address Byte 0x8C Remote MAC address Byte 0xA4 Remote MAC address Byte 0xAA Remote MAC address Byte 0x9A Reserve Byte 0x00 Reserve Byte 0x00 MAU type transmission rate Word Reserve Byte 0x00 Reserve Byte 0x00 Reserve Byte 0x00 Reserve Byte 0x00 Reserve Byte 0x00 Reserve Byte 0x00 0x0010 default value 100BASETXFD Multicast restrictions Dword 0x Bit 0=1 block the multicast MAC address 01-0E-CF Bit 1=1 block the multicast MAC address 01-0E-CF Bit 31=1 block the multicast MAC address 01-0E-CF F LinkStatus.Link Byte 0x01 Up 0x02 Down 0x03 Testing LinkStatus.Port Byte 0x01 disable 0x02 blocking 0x04 learning 0x05 forwarding 0x06 broken Reserve Byte 0x00 Reserve Byte 0x00 Entry ID: , V1.0, 03/

29 6 Appendix Neighborhood information Data type Value Media type Dword 0x Unknown 0x Copper cable 0x Fiber-optic cable 0x Radio communication Note The bytes designated with Reserve are not used! Implementation in the code The code allows you to easily reproduce the calculated offsets. To facilitate understanding: #pos_of_lenght_lpn = 12 Figure 6-2 Entry ID: , V1.0, 03/

30 7 References 7 References Table 7-1 Subject \1\ Siemens Industry Online Support \2\ Download page of the entry \3\ Application example for option handling \4\ SIMATIC PROFINET with STEP 7 V12 Title History Table 8-1 Version Date Modifications V1.0 02/2014 First version Entry ID: , V1.0, 03/