PROFINET Controller EL6631/EL6632

BECKHOFF Fieldbus components

Documentation for

PROFINET CONTROLLER Supplement and EL6631/EL6632

Version: 1.0
Datum: 2012-06-28

EtherCAT® is registered trademark and patented technology, licensed by Beckhoff Automation GmbH, Germany.


Notes on the documentation

This description is only intended for the use of trained specialists in control and automation engineering who are familiar with the applicable national standards.
It is essential that the following notes and explanations are followed when installing and commissioning these components.

The responsible staff must ensure that the application or use of the products described satisfy all the requirements for safety, including all the relevant laws, regulations, guidelines and standards.

Disclaimer

The documentation has been prepared with care. The products described are, however, constantly under development.
For that reason the documentation is not in every case checked for consistency with performance data, standards or other characteristics.
In the event that it contains technical or editorial errors, we retain the right to make alterations at any time and without warning.
No claims for the modification of products that have already been supplied may be made on the basis of the data, diagrams and descriptions in this documentation.

Trademarks

Beckhoff®, TwinCAT®, EtherCAT®, Safety over EtherCAT®, TwinSAFE® and XFC® are registered trademarks of and licensed by Beckhoff Automation GmbH.
Other designations used in this publication may be trademarks whose use by third parties for their own purposes could violate the rights of the owners.

Patent Pending

The EtherCAT Technology is covered, including but not limited to the following patent applications and patents:
EP1590927, EP1789857, DE102004044764, DE102007017835
with corresponding applications or registrations in various other countries.

The TwinCAT Technology is covered, including but not limited to the following patent applications and patents:
EP0851348, US6167425 with corresponding applications or registrations in various other countries.

Copyright

© Beckhoff Automation GmbH.
The reproduction, distribution and utilization of this document as well as the communication of its contents to others without express authorization are prohibited.
Offenders will be held liable for the payment of damages. All rights reserved in the event of the grant of a patent, utility model or design.


Safety Instructions

Safety Rules

Consider the following safety instructions and descriptions!
Product specific safety instructions are to be found on the following pages or in the areas mounting, wiring, commissioning etc.

Disclaimer

All the components are supplied in particular hardware and software configurations appropriate for the application. Modifications to hardware or software configurations other than those described in the documentation are not permitted, and nullify the liability of Beckhoff Automation GmbH.

Personnel Qualification

This description is only intended for the use of trained specialists in control, automation and drive engineering who are familiar with the applicable national standards.

Description of symbols

The following symbols with a adjoining safety advise or notice are used in this documentation. You have to read the safety advices carefully and adhere them strictly!

DANGER 		Acute risk of injury!
If you do not adhere the safety advise adjoining this symbol, there is immediate danger to life and health of individuals!

WARNING 		Risk of injury!
If you do not adhere the safety advise adjoining this symbol, there is danger to life and health of individuals!

CAUTION 		Hazard to individuals!
If you do not adhere the safety advise adjoining this symbol, there is obvious hazard to individuals!

Attention 		Hazard to environment and devices
If you do not adhere the notice adjoining this symbol, there is obvious hazard to environment and devices.

Note 		Note or pointer
This symbol indicates information that contributes to better understanding.
UL Pointer
This symbol indicates important information about the UL-compliant.


Documentation issue status

Version | Comment
1.0 | Addenda & 1st public issue
0.4 | Addenda
0.3 | Updated Controller Documentation
0.2 | Updated Controller Documentation
0.1 | 1st version

Build- und Hardware-Versionen

Documentation Version | PROFINET CONTROLLER
 | TwinCAT Build | Hardware
1.0 | Tc 2.11R3 Build >2223 | -
0.4 | Tc 2.11R3 Build >2223 | -
0.3 | Tc 2.11R3 Build >2218 | -
0.2 | Tc 2.11R2 Build >2018 | -
0.1 | Tc 2.11 Build 1538 | -


Version identification

BECKHOFF: Foreword

Version identification of EtherCAT devices

Designation

A Beckhoff EtherCAT device has a 14-digit designation, made up of

  • family key
  • type
  • version
  • revision
Example | Family | Type | Version | Revision
EL3314-0000-0016 | EL terminal (12 mm, non-pluggable connection level) | 3314 (4-channel thermocouple terminal) | 0000 (basic type) | 0016
CU2008-0000-0000 | CU device | 2008 (8-port fast ethernet switch) | 0000 (basic type) | 0000
ES3602-0010-0017 | ES terminal (12 mm, pluggable connection level) | 3602 (2-channel voltage measurement) | 0010 (high-precision version) | 0017

Notes

  • The order identifier is made up of
    - family key
    - type
    - version
  • The revision indicates the technical progress and is managed by Beckhoff.
    In principle, a device with a higher revision can replace a device with a lower revision, unless specified otherwise.
    Each revision usually has an associated XML description (ESI, EtherCAT Slave information), which is available for download from the Beckhoff webpage.
  • Type, version and revision are read as decimal numbers.

Serial number

Beckhoff EtherCAT devices usually have an 8-digit serial number, which is printed on the device or attached to it on a sticker. This serial number indicates the construction condition on delivery.

Syntax of the serial number

Structure of the serial number: KK YY FF HH

KK - week of production (CW, calendar week)
YY - year of production
FF - firmware version
HH - hardware version

Example with ser. no.: 12 06 3A 02:

12 - week of production 12
06 - year of production 2006
3A - firmware version 3A
02 - hardware version 02

Examples of serial number data

Fig. 1: EL6688 EL Terminal

Fig. 2: CU2016 Switch

Fig. 3: EK1100 EtherCAT coupler


Introduction

The PROFINET IO controller (master) is a TwinCAT supplement that turns every Beckhoff PC-based control system into a PROFINET IO controller. By installing the supplement, a standard Ethernet interface becomes a PROFINET master. This supplement can be used on PCs and Embedded PCs.

PROFINET can be simply coupled with EtherCAT in connection with the EL663x PROFINET terminal for the EtherCAT I/O system, wherein the terminal represents a slave on the EtherCAT side but acts as a controller towards PROFINET. In this way any EtherCAT network can also exchange data with PROFINET IO devices.

There are two kinds of PROFINET: PROFINET I/O and PROFINET CBA. TwinCAT supports PROFINET I/O.

In turn, 4 kinds of cyclic communication are defined within PROFINET I/O: RTClass1 to 3 and RToverUDP. The TwinCAT PROFINET I/O controller and the EL6631 presently support RTClass1, while the EL6632 can communicate over RTClass1 and RTClass3. All cycle times defined for RTClass1 are supported, from 1 ms in power-of-2 steps (1, 2, 4, 8,… ms).

The smallest cycle time presently supported by the EL6632 is 500 µs (for RTClass3).


Technical data

Technical data | PROFINET via RT Ethernet | PROFINET via EtherCAT (EL6632) | PROFINET via EtherCAT (EL6631)
Ethernet-Hardware | Real-Time-Ethernet-Hardware | EL6632 PROFINET terminal | EL6631 PROFINET terminal
Operating system | Windows XP, XP Embedded (CE under preparation)
Software | TwinCAT I/O, PLC, NC, NC I, CNC
Target systems | PC (x86), Windows CE devices | PC (x86), Windows CE devices with EtherCAT interface | PC (x86), Windows CE devices with EtherCAT interface
Cycle time | min. 1 ms | min. 500 us | min. 1 ms
Number of possible IO devices | limited by CPU performance and memory | for IRT up to 5 devices, for RT up to 15 devices | up to 15 devices


Activation of the PROFINET Controller Supplement

Requirement:

TwinCAT 2.11 Build 1545
Hardware: Ethernet card with Intel chip set

An Ethernet card with Intel chip set is required in order to use the PROFINET Controller Supplement. Install the RT-Ethernet driver for this card (TwinCAT Ethernet driver - Installation). Once the installation of the driver has been completed you can create the PROFINET controller in the system manager and connect it to the hardware (Ethernet card).

The PROFINET controller can be scanned in Config mode (TwinCAT icon is blue) and values can be written in Freerun mode. The appropriate key must be entered in order to operate TwinCAT in Run mode.
In order to obtain the registration key, send the MAC address of the Ethernet card you are using with the order. You will then receive the activation code.

MAC address

You can read the MAC address via the system manager. To do this, append the PROFINET controller device.

Select the PROFINET I/O controller under PROFINET.

Switch to Adapter and press the search button.

If the real-time driver has been installed correctly, you will be shown the corresponding cards. If no cards are available for selection, this means that the driver has not been correctly installed.
Select the card to which your PROFINET devices are connected.

The MAC address of the card will be displayed under Adapter -> MAC address . This is now required for the key.

Switch to the PROFINET tab and press ‘Insert key…’. Now enter the key.

If the key is accepted the following appears in the Key field: valid pn-controller key.


PROFINET Controller - EL6631/EL6632

BECKHOFF PROFINET Controller: Product overview

EL6631 PROFINET IO Controller

The EL6631 PROFINET IO Controller (Master) Terminal supports the complete real-time function (RT) as well as extensive diagnostic possibilities. All services in accordance with Conformance Class B are supported.
Up to 15 PROFINET IO devices can be projected on the EL6631.

EL6632 PROFINET-IRT-Controller

The EL6632 PROFINET-IRT controller terminal offers the complete RT (real time) or IRT (isochronous real-time) functionality and a wide range of diagnostic options. All services in accordance with Conformance Class C are supported.
Depending on the cycle time, up to five PROFINET-IRT or up to 15 PROFINET RT devices can be operated at the EL6632 in a line topology.

Note 		Supplement
The TwinCAT Supplement is not required for the EL6631 and EL6632.

Note 		TwinCAT Version
The approved TwinCAT version is TwinCAT 2.11 R3. It must be ensured that the target system also corresponds to the TwinCAT version.
Older TwinCAT versions cannot be used!

.


Technical data - EL6631 PROFINET-RT-Controller

BECKHOFF PROFINET Controller: Product overview

Technical data - EL6631 PROFINET RT Controller

Technical data | EL6631
Technology | PROFINET IO
Number of ports/channels | 2
Ethernet interface | 100BASE-TX Ethernet with 2 x RJ 45
Fieldbus | PROFINET RT Controller
Cable length | up to 100 m twisted pair
Hardware diagnostics | Status LEDs
Power supply | via the E-Bus
Electrical isolation | 500 V (E-Bus/Ethernet)
Max. number of RT-capable devices | 15 (depending on the cycle time and number of data)
Minimum RT cycle | 1 ms
Conformity class | B
Protocol | RT
Drivers | TwinCAT 2.11 R3
Maximum number of process data | 1 kByte input data and 1 kByte output data
Configuration | via the EtherCAT master
E-Bus current consumption | typically 400 mA
Special features | LLDP, SNMP, conformity class B, max. 15 RT devices, min. 1 ms RT cycle
Mounting (housing with traction lever unlocking / housing with front release) | on 35 mm mounting rail according to EN 50022
Weight | approx. 75 g
Operating/storage temperature | 0 to +55 °C / -25 to +85 °C
Relative humidity | 95 % no condensation
Vibration / shock resistance | conforms to EN 60068-2-6/EN 60068-2-27/ 29
EMC immunity/emission | conforms to EN 61000-6-2 / EN 61000-6-4
Installation position | Standard installation position (an operating temperature of 45 °C applies to other installation positions), see also notice
Protection class | IP 20
Approval | CE Ex UL


Technical data - EL6632 PROFINET-IRT-Controller

Technical data | EL6632
Technology | PROFINET IO
Number of ports/channels | 2
Ethernet interface | 100BASE-TX Ethernet with 2 x RJ 45
Fieldbus | PROFINET RT / IRT Controller
Cable length | up to 100 m twisted pair
Hardware diagnostics | Status LEDs
Power supply | via the E-Bus
Electrical isolation | 500 V (E-Bus/Ethernet)
Max. number of IRT-capable Devices | 5 (depending on the cycle time and number of data)
Max. number of RT-capable Devices | 15 (depending on the cycle time and number of data)
Minimum IRT cycle | 500 µs
Minimum RT cycle | 1 ms
Conformity class | C
Protocol | RT or IRT
Drivers | TwinCAT 2.11 R3
Maximum number of process data | 1 kByte input data and 1 kByte output data
Configuration | via the EtherCAT master
E-Bus current consumption | typically 400 mA
Special features | Conformity class C, max. 5 IRT devices in series, max. 15 RT devices, min. 500 μs IRT cycle, min. 1 ms RT cycle
Dimensions (W x H x D) | approx. 26 mm x 100 mm x 52 mm (connected width: 23 mm)
Mounting (housing with traction lever unlocking / housing with front release) | on 35 mm mounting rail according to EN 50022
Weight | approx. 75 g
Operating/storage temperature | 0 to +55 °C / -25 to +85 °C
Relative humidity | 95 % no condensation
Vibration / shock resistance | conforms to EN 60068-2-6/EN 60068-2-27/ 29
Installation position | Standard installation position (an operating temperature of 45 °C applies to other installation positions), see also notice
Protection class | IP 20
Approval | CE Ex UL


Terminal Modules - Recommended mounting rails

BECKHOFF Terminal Modules: Mounting and wiring

Recommended mounting rails

Terminal Modules und EtherCAT Modules of KMxxxx and EMxxxx series, same as the terminals of the EL66xx and EL67xx series can be snapped onto the following recommended mounting rails:

  • DIN Rail TH 35-7.5 with 1 mm material thickness (according to EN 60715)
  • DIN Rail TH 35-15 with 1,5 mm material thickness

Note 		Pay attention to the material thickness of the DIN Rail
Terminal Modules und EtherCAT Modules of KMxxxx and EMxxxx series, same as the terminals of the EL66xx and EL67xx series does not fit to the DIN Rail TH 35-15 with 2,2 to 2,5 mm material thickness (according to EN 60715)!


Terminal Modules - Mounting and Demounting

BECKHOFF Terminal Modules: Mounting and Wiring

Mounting and demounting

The terminal modules are fastened to the assembly surface with the aid of a 35 mm mounting rail (e.g. DIN rail TH 35-7.5 according to EN 60715a).

WARNING 		Risk of electric shock and damage of device!
Bring the bus terminal system into a safe, powered down state before starting installation, disassembly or wiring of the Bus Terminals!
Mounting
  • Fit the mounting rail to the planned assembly location.

    and press (1) the terminal module against the mounting rail until it latches in place on the mounting rail (2).
  • Attach the cables.
Demounting
  • Remove all the cables. Thanks to the KM/EM connector, it is not necessary to remove all the cables separately for this, but for each KM/EM connector simply undo 2 screws so that you can pull them off (fixed wiring)!
  • Lever the unlatching hook on the left-hand side of the terminal module upwards with a screwdriver (3). As you do this
    • an internal mechanism pulls the two latching lugs (3a) from the top hat rail back into the terminal module,
    • the unlatching hook moves forwards (3b) and engages

  • In the case 32 and 64 channel terminal modules (KMxxx4 and KMxxx8 or EMxxx4 and EMxxx8) you now lever the second unlatching hook on the right-hand side of the terminal module upwards in the same way.
  • Pull (5) the terminal module away from the mounting surface.


Terminal Modules - Mounting and demounting

BECKHOFF Terminal Modules: Mounting and wiring

Mounting and demounting

The terminal modules are fastened to the assembly surface with the aid of a 35 mm mounting rail (e.g. mounting rail TH 35-15).

Note 		Fixing of mounting rails
The locking mechanism of the terminals and couplers extends to the profile of the mounting rail.
At the installation, the locking mechanism of the components must not come into conflict with the fixing bolts of the mounting rail.
To mount the recommended mounting rails under the terminals and couplers, you should use flat mounting connections (e.g. countersunk screws or blind rivets).

WARNING 		Risk of electric shock and damage of device!
Bring the bus terminal system into a safe, powered down state before starting installation, disassembly or wiring of the Bus Terminals!
Mounting
  • Fit the mounting rail to the planned assembly location.

    and press (1) the terminal module against the mounting rail until it latches in place on the mounting rail (2).
  • Attach the cables.
Demounting
  • Remove all the cables.
  • Lever the unlatching hook back with thumb and forefinger (3). An internal mechanism pulls the two latching lugs (3a) from the top hat rail back into the terminal module.

  • Pull (4) the terminal module away from the mounting surface.


KLxxxx, ELxxxx installation positions

BECKHOFF Fieldbus components: Installation and wiring

Installation positions

Attention 		Constraints regarding installation position and operating temperature range
Please refer to the technical data for a terminal to ascertain whether any restrictions regarding the installation position and/or the operating temperature range have been specified.

When installing high power dissipation terminals ensure that an adequate spacing is maintained between other components above and below the terminal in order to guarantee adequate ventilation!

Optimum installation position (standard)

The optimum installation position requires the mounting rail to be installed horizontally and the connection surfaces of the EL/KL terminals to face forward (see Fig. 1). The terminals are ventilated from below, which enables optimum cooling of the electronics through convection. "From below" is relative to the acceleration of gravity.

Fig. 1: Recommended distances for standard installation position

Compliance with the distances shown in Fig. 1 is recommended.

Other installation positions

All other installation positions are characterized by different spatial arrangement of the mounting rail - see Fig 2.

The minimum distances to ambient specified above also apply to these installation positions.

Fig. 2: Other installation positions


ATEX - Special conditions

WARNING 		Observe the special conditions for the intended use of
Beckhoff fieldbus components in potentially explosive areas (directive 94/9/EU)!
  • The certified components are to be installed in a suitable housing that guarantees a protection class of at least IP54 in accordance with EN 60529! The environmental conditions during use are thereby to be taken into account!
  • If the temperatures during rated operation are higher than 70°C at the feed-in points of cables, lines or pipes, or higher than 80°C at the wire branching points, then cables must be selected whose temperature data correspond to the actual measured temperature values!
  • Observe the permissible ambient temperature range of 0 - 55°C for the use of Beckhoff fieldbus components in potentially explosive areas!
  • Measures must be taken to protect against the rated operating voltage being exceeded by more than 40% due to short-term interference voltages!
  • The individual terminals may only be unplugged or removed from the Bus Terminal system if the supply voltage has been switched off or if a non-explosive atmosphere is ensured!
  • The connections of the certified components may only be connected or disconnected if the supply voltage has been switched off or if a non-explosive atmosphere is ensured!
  • The fuses of the KL92xx power feed terminals may only be exchanged if the supply voltage has been switched off or if a non-explosive atmosphere is ensured!
  • Address selectors and ID switches may only be adjusted if the supply voltage has been switched off or if a non-explosive atmosphere is ensured!

Standards

The fundamental health and safety requirements are fulfilled by compliance with the following standards:

  • EN 60079-0: 2006
  • EN 60079-15: 2005

Marking

The Beckhoff fieldbus components certified for potentially explosive areas bear one of the following markings:

II 3 G Ex nA II T4 KEMA 10ATEX0075 X Ta: 0 - 55°C

or

II 3 G Ex nA nC IIC T4 KEMA 10ATEX0075 X Ta: 0 - 55°C

Serial number

The Beckhoff fieldbus components bear a serial number that is structured as follows:

WW YY FF HH

WW - week of production (CW, calendar week)
YY - year of production
FF - firmware version
HH - hardware version

Example with ser. no.: 35 04 1B 01:

35 - week of production 35
04 - year of production 2004
1B - firmware version 1B
01 - hardware version 01


PROFINET Controller - LEDs

BECKHOFF PROFINET controller: Diagnosis

EL6631 - LEDs

LEDs for EtherCAT diagnosis

LED |  | Display | Description
RUN | green | off | State of the EtherCAT state machine: INIT = initialization of the terminal; BOOTSTRAP = function for firmware updates of the terminal
 |  | flashing 200 ms | State of the EtherCAT state machine: PREOP = function for mailbox communication and different standard-settings set
 |  | off (1 s) on (200 ms) | State of the EtherCAT state machine: SAFEOP = verification of the sync manager channels and the distributed clocks. Outputs remain in safe state
 |  | on | State of the EtherCAT state machine: OP = normal operating state; mailbox-and process data communication is possible

LED diagnosis PROFINET RUN/Err

Color green | Color red | Meaning
off | flashing 200 ms | Terminal starts
flashing 200 ms | off | No name
1s off, 200 ms on | off | No IP address
on | off | EL terminal is parameterized

LED diagnosis PROFINET Err

Color green | Color red | Meaning
off | flashing 500 ms | no AR established with any device
off | 1s off, 200 ms on | At least one device has not established an AR
1s off, 200 ms on | off | At least one device has signalled an error, e.g. that there is a module difference or that the error bit for an IO-CR is set (Problem Indicator)
flashing 200 ms | off | At least one device is signalling that its status is ‘Stop’ (Provider State Stop)
on | off | All PROFINET devices are in data exchange mode

If there are several different errors, then the error that is located at the top of (or higher in) the table is always displayed.

LEDs starting up

Run | PN Run/Err | PN Err | Meaning
off | off | off | No electrical voltage connected to E-bus. The EL6631 must be exchanged if EtherCAT terminals behind it function.
off | off | red on | EL terminal is starting up; after approx. 10 seconds, the LED should go out. If this does not happen, the EL6631 module must be exchanged.


Integration of the TwinCAT PROFINET controller protocol via a Real-Time Ethernet interface

The controller protocol is appended directly to the I/O device. The available network interfaces are directly displayed when appending and are now available for selection.
If these are to be modified or checked afterwards, this can take place on the ‘Adapter’ tab.

.


Integration of the TwinCAT PROFINET controller protocol via an EL663x interface

The controller protocol is appended directly to the I/O device. The respective protocol must be selected according to the terminal that is to be used (EL6631 or EL6632). If such a terminal is present in the projected EtherCAT strand, the associated adaptor is directly displayed when appending the protocol. If there are several terminals the corresponding one can be selected.

For the operation of several EL663x terminals the corresponding PROFINET protocol must be appended several times. If the terminal assignment is to be modified or checked afterwards, this can take place on the ‘Adapter’ tab.

.


AMS Settings

Protocol AMS NetID text field

This is the NetID via which the PROFINET controller protocol can be reached via AMS.

Protocol AMS PortNo text field

This is the PortNo via which the PROFINET controller protocol can be reached via AMS. This is always fixed to 0xFFFF.

Server AMS NetID text field

This is the NetID to which certain AMS messages (e.g. PN records within the index range 0x1000 - 0x1FFF) are forwarded by the PROFINET driver. Currently this is always the SystemNetId.

Server AMS PortNo text field

This is the PortNo to which certain AMS messages (e.g. PN records within the index range 0x1000 - 0x1FFF) are forwarded by the PROFINET driver. By default this is the PLC Port 802 of runtime system 1.


PROFINET Key

Key text field

The key to enable the PROFINET controller protocol can be entered here. If a valid key has already been entered, a corresponding message appears in the window and no further entry can be made.

Button Insert Key...

The entered key is confirmed here. The key is thereby checked to ascertain whether or not it is valid. If not, a corresponding message appears. This button is inactive if a valid key has already been entered.


Button Port settings

This feature is presently only enabled for the real-time Ethernet protocol (no EL663x). With this a second PROFINET port and an intelligent switch can thus be realized with a second network card (Intel chipset) . It is intended to repeat this feature x times; however, it is presently limited to one additional port.

In future it will be possible to enable the MRP (Media Redundancy Protocol) function via this menu; various settings can be made for this.


Button Scan PNIO Devices

This feature is comparable with the ‘ScanBoxes’ feature which, however, is available only in CONFIG mode .

After successful scanning the following dialogue opens (if devices were found).

Various settings or project planning can be carried out for the devices here. These are adopted only when the corresponding button is explicitly pressed. When setting the name, care must be taken that only PROFINET-compliant characters are used. This also applies to the IP address; only valid combinations of IP and subnet are to be used. Name and IP are checked for correctness when setting PROFINET devices. DCP_SET is acknowledged with an error If this is not the case. Changes that have been made can be read back by pressing the Rescan button.

In addition the selected device can be signalled. This functionality is PROFINET-specific, but the method by which the signalling takes place is vendor-specific. As standard, however, the signal must arrive with a frequency of 2 Hz.
For example, the Beckhoff BK9103 Bus Coupler signals itself by the alternate flashing of two LEDs at a rate of 2 Hz. This function is very helpful for identifying the devices in this list. The flashing is stopped again by pressing the button once more. The flashing is stopped by closing the ‘Scan Devices’ window.

Subsequently, one or more devices can be marked with the Ctrl button . The selected device is adopted into the project by pressing ‘Add Devices’.

Note 		GSDML devices
The associated GSDML devices must be located in the ‘..\TwinCAT\Io\ProfiNet’ folder!

Upon pressing ‘Add Devices’, the following question box opens:

‘Yes’ button:

An attempt is initially made to determine the ModuleIdentNumber of the DAP (Device Access Point) by an implicit read access. If this fails a corresponding dialog opens containing the possible DAPs, which must then be selected manually.
If all boxes have been appended, a ‘Reload Devices’ automatically takes place, i.e. the devices (adaptors) created are transmitted to the PROFINET driver. Subsequently, a distinction is made as to whether the box is a normal device or a drive with Profidrive support.
If the device is a normal device, the real module equipment (RealIdentificationData) is read out again by an implicit read access. If it is a Profidrive device, conversely, the required information is read out by a Profidrive access. A supervisor AR is established for this, within which the required write accesses can take place. The Submodule interface on the DAP is taken here as the Parameter Access Point. The parameter access takes place via data record 47, much like the case of the Profibus beforehand. When using Sinamics, however, it must be noted that such an access is only permitted from version 4.3 SP2. If an older version is used, a corresponding error message appears and the parameterization must take place manually.

Once the automatic module parameterization has been completed, a question box appears asking whether the port data should be read in automatically. Here again, the port connection for the individual devices is read out via an implicit read access.
The real port connection must be known for the various services. These may be simply diagnostic services, but the port connection is also required for the automatic device start (via alias) or for the creation of the IRT planning.
If this dialogue is acknowledged with ‘no’ or if the read access has failed, such a connection can also be made manually at the individual ports in the TwinCAT project.

If the port connection has been successfully generated, a query also appears in the case of an IRT controller (e.g. project planning on an EL6632) asking whether all devices are to be automatically connected in IRT Mode (RTClass3) (provided they support it).
If this is affirmed the cable length is additionally set to 10 m copper cable on all projected ports. The IRT algorithm requires this information for the calculation of the signal propagation delays. The precise cable length is not so important here (approx. +/-10 m), because the propagation delays tend to be small at 100 Mbit/s (5 ns/m). If the automatic switchover is not to take place immediately, these points can also be modified later either on the protocol or on the individual devices (on the interface or port submodule).

‘No’ button:

For each device a check is performed to ascertain whether the GSDML is present in the respective folder (‘..\TwinCAT\Io\ProfiNet’). If this is the case, the list of possible DAPs is read in. Subsequently a selection dialogue is opened so that the corresponding DAP can be selected.
Once the devices have been appended in the project, the API below the Box can be accessed and the modules and submodules can be manually appended via it.


Button Topology

The offline topology can be compared with the online topology via this dialogue.

It is quite possible for a device to have several partners on a port in the online view. This is the case, for example, if a switch is used in PROFINET that does not support LLDP (protocol for neighbourhood ID).

In the offline view, on the other hand, partners may have been assigned that don’t exist in the project. This takes place if the reading of the port properties was activated during automatic scanning and appending. In this case the device has a ‘neighbour’ that is adopted into the project, but the associated device box is missing from the *.tsm file. On activating this project the ‘neighbour’ which does not exist in the .tsm file is ignored in the driver.


IRT Config button

This menu is enabled only for an IRT-capable controller (at present only EL6632). A global setting can be made for all projected devices via this menu.

On the one hand the type of communication can be specified here. At present only RTClass1 (RT) and RTClass3 (IRT Top) are supported.

In addition there is an option in this dialogue to specify a general cable length (for IRT only). An approximate value or the max. cable length is sufficient here, because for the calculation of IRT communication this value tends to be lower (at 100 Mbaud and copper cable 5 ns/m). For optimization this feature can also be deactivated again later and the exact cable length can then be entered for each individual device (on the port submodules).

Furthermore there is an option here to activate an ‘automatic port assignment’. As a result of this the port connection set in the TwinCAT project is irrelevant. Before each restart of the PN communication the topology is read out and the IRT communication is calculated on the basis of this. The advantage of this is that possible cabling errors are minimized. In addition to that the ports can be simply replugged without having to change and reload the TwinCAT project. Only a restart of the PN communication is required (e.g. switch terminal to PREOP or disconnect the cable). As a result of this the bootup of the PROFINET communication can take up to 30 seconds longer. The reason for this is the TTL (TimeToLive) factor in the LLDP MIB. These are set by default to 20 seconds, i.e. only after this time can it be guaranteed that the port connection read is also the current one.

Also, an additional offset for all Ti / To values can be specified in this menu.


Task Configuration

The PROFINET controller protocol must always be linked with a task. The protocol is also processed with the set task time. Theoretically the controller can also be jointly processed, for example, via a PLC or NC task. However, if a PLC project, for example, is stopped (e.g. by restart or debugging), this results in the PROFINET part also being stopped. In order to avoid such a side effect is it advisable to always create a free-running SyncTask.

It must be ensured that the task cycle lies in a PROFINET cycle, i.e. for PROFINET the basic cycle is 31.25 µs. This cycle is then always multiplied by the SendClockFactor (SCF) to obtain the basic cycle. The SendClockFactor is usually set to 32 for RTClass1. This is also the minimum PN cycle for RTClass1 for the Beckhoff PROFINET controller and results in the smallest cycle time of 1 ms. Further reductions take place using a ReductionRatioFactor. This always corresponds to a multiple of the minimum PN cycle. For RTClass1 the smallest cycle must always be doubled (permissible cycle times (for RTC1) with an SCF of 32 are 1, 2, 4, 8,…, 512).

The SCF can and must be reduced in order to achieve faster cycle times for RTClass3 as well. This is presently at least 16 for a Beckhoff IRT controller (EL6632), which corresponds in turn to a basic cycle of 500 µs. In the case of such a decrease of the PROFINET cycle, it must be noted that the time of the triggering task must also be adapted accordingly.


PROFINET controller-specific settings

Settings that directly concern the controller can made on the ‘Settings’ tab.

An IP setting can take place here. The selection of the address range need not correspond to the network card settings. The PROFINET communication spreads its own net, which can be selected here. The IP settings shown in the above illustration are the default settings, i.e. if nothing is changed the controller uses these settings. The same applies to the controller name (system name). The corresponding button must be pressed to change either of these two settings. A check is made to ascertain that the input is correct (e.g. the format of the controller name must correspond to the PN spec.). These data are then permanently adopted. If the subnet or gateway is changed, the settings will also be adopted by possible projected devices. There is also a possibility to modify these settings via a supervisor tool.

In addition the VendorID and DeviceID of the controller can be read out in this dialogue. The server and client UDP port employed can also be set here. The default settings should, however, be adequate in most cases.

Furthermore there is a possibility in this dialogue to enable an automatic PROFINET start-up following a device exchange (including devices without removable media). For correct functioning the nominal topology must be specified once. On the basis of this information the controller can query the alias names of the individual devices. Every device that supports alias names generates such a name for each of its ports. This is composed of the neighborhood IDs (PortId.ChassisId). If this name is queried, the ‘new’ device answers. If VendorId and DeviceId are correct the device is named with the actual name and a normal PROFINET start-up can subsequently take place. With this mechanism a complete PROFINET system could also start up without having named an individual device beforehand.


Analysis of Box states

BECKHOFF PROFINET Controller: PN Controller Protocol

Analysis of the box states

Directly below the PROFINET controller protocol there is a collective PROFINET error and a collective PROFINET status. Both indicate the number of devices in which a problem has occurred or in which a diagnosis is available, i.e. the error indicates possible problems with the establishment of a connection or reasons for an abort. The diagnosis provides status information about an existing connection.

PnIoError - number of PROFINET IO devices that have an error
PnIoDiag - number of PROFINET IO devices where a diagnosis is available

It is possible to check at a glance which device or box has a problem in the protocol under Box States.

Presently the following error messages are displayed under the “PnIoState”.

Number | Text | Description | Remedial action / reason
0 | No error | No error | No error
1 | PROFINETDevice state machine is in boot mode | PROFINET Device State Machine is still in the start-up phase | Not an error, wait
2 | Device not found | Device does not reply to the Identify Request | Check connection, device connected, was the device called by its correct name?
3 | The stationname is not unique | The station name is not unique | There are two or more devices in the network with the same PROFINET name. A correct identification cannot take place.
4 | IP could not set | IP address could not be set | The PROFINET device has rejected the IP settings for some reason. Check whether the IP settings are correct.
5 | IP conflict | An IP conflict has occurred in the network | A possible cause is that several devices have the same IP address.
6 | DCP set was not successful | There was no reply or an erroneous reply to a DCP Set | Check connection, device connected, was the device called by its correct name?
7 | Watchdog error | The connection was broken off with a Watchdog error | Check the cycle time, check the connection, if necessary increase the Watchdog factor.
8 | Datahold error | The connection was broken off with a Datahold error | Frame Data status was invalid for the length of the DataHoldTimer. Restart the device if necessary.
9 | RTC3: Sync signal could not started | For IRT only: the Sync signal could not be started. | Is EtherCAT Sync signal correct or has Sync0 started?
10 | PROFINET Controller has a link error | The PROFINET controller has no link | Check cable and connection.
11 | The aliasname is not unique | The alias name is not unique | There are two or more devices in the network with the same alias name. This is made up of the neighborhood information (PortId.ChassisId). A correct identification cannot take place.
12 | The automatic name assignment isn't possible - wrong device type | The automatic name assignment is not possible | The expected PROFINET device is not in the projected position (VendorId or DeviceId does not correspond). Hence, no automatic naming and thus no device start is possible.
31 | only for EtherCAT gateways: WC-State of cyclic EtherCAT frame is 1 | For EL6631 only: EtherCAT WC State is 1 | Check the mode on the EtherCAT master & slave (OP?).

As opposed to the state, more than one status can be displayed in the “BoxPnIoDiag”, i.e. the whole thing is bit-coded and up to 16 pieces of information can be displayed. The following statuses are currently displayed.

0x0000 = No diagnosis
0xXXX1 = IOC-AR is not established
0xXXX2 = IOC-AR is established
0xXXX4 = IOC-AR is established but no ApplReady
0xXXX8 = IOC-AR is established but module difference
0xXX1X = At least one AlarmCR get diagnosis alarm
0xX1XX = At least one InputCR is invalid
0xX2XX = At least one InputCR Provider is in stop
0xX4XX = At least one InputCR Problemindicator is set
0x1XXX = At least one OutputCR is invalid
0x2XXX = At least one OutputCR Provider is in stop
0x4XXX = At least one OutputCR Problemindicator is set

On the one hand information about the status of the IO Controller Single AR is displayed here. In addition, collective statuses are formed from the Frame Data statuses of the individual CRs. This applies to the input and output CRs (currently only one CR is possible, in future several). Furthermore a PROFINET alarm is also displayed in “PnIoDiag”

Readout via ADS

The Box Status can be read out via an ADS Read.

ADS Read:

NetId = AMSNETID of the PROFINET controller

Port = BoxPort (0x1000 + BoxId)

Indexgroup = 0xF829

IndexOffset = 0

Length = sizeof(TPnIoDeviceDiagData);

where:

typedef struct
{
WORD pnioState;
WORD pnioDiag;

WORD NrOfInputCRs;
WORD NrOfOutputCRs;
WORD reserved[8];
} TPnIoDeviceDiagData, *PTPnIoDeviceDiagData;

Readout via CoE (for EL663x)

The Box Status can also be read out via CoE for the EL663x. The index 0xAyy0 (where yy is the Adaptor / Device number) and the subindex 0x001 must be taken for this.


Diagnosis history at Controller Protocol

BECKHOFF PROFINET Controller: PN Controller Protocol

Diagnosis history on the controller protocol

Logged diagnosis messages from the controller protocol can be read out on the “Diag History” tab. The diagnosis buffer operates as a ring buffer with a current maximum size of 1000 entries.

The possible errors are grouped into three types:

  • Info: e.g. information about the connection establishment
  • Warning: e.g. PROFINET diagnosis alarms
  • Error: e.g. loss of connection

“AddInfo” indicates whether additional information about the event is available. If this is marked by “Yes”, the additional information can be fetched and displayed by clicking on the respective message. In the case of a diagnosis alarm (“Diagnosis” appears), the precise diagnosis information can be fetched at the corresponding level (device, API or module).

The complete diagnosis buffer is cleared by pressing the “Clear Diag History” button.

The displayed messages can be saved in a .TXT file by pressing the “Export Diag History” button.


Cyclic data

There are several cyclic process data directly below the PROFINET controller protocol. These data are only exchanged between the PROFINET driver and the system manager. They provide general information about the status of the PROFINET communication.

The ‘DevState’ variable contains information about the physical communication status of the controller, such as the link status or whether the transmission resources are still sufficient.

The other variables are the collective PROFINET error and the collective PROFINET status. Both indicate the number of devices in which a problem has occurred or in which a diagnosis is available, i.e. the error variable indicates possible problems with the establishment of a connection or reasons for an abort. The diagnostic variable provides status information about an existing connection.

The ‘DevCtrl’ output variable currently has no function.

For further information, please also read the chapter entitled ‘Box States'.


Acyclic data

The ADS blocks are used to send acyclic data. These then access the PROFINET record data. So that acyclic data can be read or written, the PROFINET device must be in data exchange mode.

An ADSReadWrite is set.

ADS settings

AMSNetID: The AMSNetID of the Profinet controller

PORT: Port number of the device (take this from the system manager)

Index GROUP: 0x0000_F823

Index OFFSET: 0x0000_0000

DATA

typedef struct {

WORD RW;

#define PN_READ 0

#define PN_WRITE 1

WORD NrOfAR;

DWORD API;

WORD Slot;

WORD SubSlot;

PNIO_RECORD RecordData;

} PNIO_CONFIGRECORD

nRW | nNr | nAPI | InSlot | SubSlot | nIndex | nLen | nTrans | nLenA
2 bytes | 2 bytes | 4 bytes | 2 bytes | 2 bytes | 2 bytes | 2 bytes | 2 bytes | 2 bytes

Example:

Send a read request for I&M function 0

nRW | nNr | nAPI | InSlot | SubSlot | nIndex | nLen | nTrans | nLenA
00 00 | 00 00 | 00 00 00 00 | 00 00 | 01 00 | F0 AF | 00 00 | 01 00 | 00 00

Make sure that the receive data memory is large enough!


Appending a PROFINET Device

PROFINET Controller: Devices at protocol

Appending PROFINET devices

Select “Append Box” by right-clicking on the protocol. The following dialogue then opens:

There is a possibility here to select various PROFINET devices. In Beckhoff devices a search is carried out via a defined path for the GSDML (..\TwinCAT\IO\PROFINET ). These should be already present with the TwinCAT installation. If there are several GSDMLs for the same device here, the one with the latest date is taken. If no device description is found, a corresponding error message appears. Either the GSDML is copied into the folder and the menu is opened again, or the same procedure is selected as for the third-party devices. If you click on “PROFINET IO Device”, an option is offered to navigate to the corresponding GSDML in Windows Explorer. This is then integrated into the project.

The DNS name from the GSDML is taken as the default name. When appending several devices simultaneously, the default name is always supplemented by “-No.” (where No. = 1 to n). The name that was assigned (and with which the device also appears in the tree), is at the same time also the “PROFINET Station Name”, i.e. the name that must correspond to the name in the device. The device name can be checked by scanning.

The modules can be attached to the API (Application Profile Interface). The DAP (Device Access Point), which already brings along fixed properties from the GSDML (e.g. process data, interface and port submodules, etc.), is always on Slot 0.
This module is always there and cannot be deleted or shifted. Each further module is assigned to a certain API. The information regarding its identity comes from the GSDML. As standard this is always the API 0. Alternatively, an API e.g. for the PROFIDRIVE profile or a fieldbus API is also conceivable. By clicking in the API on “Append PROFINET modules…” a device catalogue is opened from which the corresponding modules can be selected and appended. If the modules support it (described in GSDML), the submodules can in turn be appended to them in the same way.


Comparison of nominal and actual configuration

If a connection exists, the project planning can be checked on the “Diagnosis” tab. At this level “Real Identification Data” returns the actually existing modules in an AR, “Expected Identification Data” indicates the expected modules (i.e. those projected in the controller) and “Module Difference” shows the differences to the device found in the nominal-actual comparison.

If you are on the “Diagnosis” tab within the API, you can select the corresponding API about which information is to be obtained. If, for example, the PROFINET device is a drive, then this usually supports the Profidrive profile, which is identified in turn via API 0x3A00. If the Real Identification Data is to be read from this API, for example, then this access takes place via the Profidrive profile.

In addition, the “Get Real Configuration” button becomes active within an API (except for drives). It is possible via this to adopt the read-in data record into the current project. Note that modules that have already been created will be overwritten when doing this. This means that the links are lost, even in the case of previously correctly created modules.

When displaying the module differences, additional information is displayed by marking the message.

Diagnosis Data

The available diagnosis can be read out by pressing the “Diagnosis Data” button. At device level all available diagnosis data for the existing AR is read out here.

A maximum of two diagnosis parameters are displayed in the list; others are marked by “…”. If the individual message is clicked, all available diagnosis information is displayed in the window below.

Cyclic diagnosis via “PnIoBoxState” and “PnIoBoxDiag”

These variables are cyclically exchanged with the process image between the PROFINET driver and the System Manager.

Presently the following error messages are displayed under the PnIoBoxState.

Number | Text | Description | Remedial action / reason
0 | No error | No error | No error
1 | PROFINET Device state machine is in boot mode | PROFINET Device State Machine is still in the start-up phase | Not an error, wait
2 | Device not found | Device does not reply to the Identify Request | Check connection, device connected, was the device called by its correct name?
3 | The stationname is not unique | The station name is not unique | There are two or more devices in the network with the same PROFINET name. A correct identification cannot take place.
4 | IP could not set | IP address could not be set. | The PROFINET device has rejected the IP settings for some reason. Check whether the IP settings are correct.
5 | IP conflict | An IP conflict has occurred in the network. | A possible cause is that several devices have the same IP address.
6 | DCP set was not successful | There was no reply or an erroneous reply to a DCP Set. | Check connection, device connected, was the device called by its correct name?
7 | Watchdog error | The connection was broken off with a Watchdog error. | Check the cycle time, check the connection, if necessary increase the Watchdog factor.
8 | Datahold error | The connection was broken off with a Datahold error. | Frame Data status was invalid for the length of the DataHoldTimer. Restart the device if necessary.
9 | RTC3: Sync signal could not started | For IRT only: the Sync signal could not be started. | Is EtherCAT Sync signal correct or has Sync0 started?
10 | PROFINET Controller has a link error | The PROFINET controller has no link. | Check cable and connection.
11 | The aliasname is not unique | The alias name is not unique | There are two or more devices in the network with the same alias name. This is made up of the neighbourhood information (PortId.ChassisId). A correct identification cannot take place.
12 | The automatic name assignement isn't possible - wrong device type | The automatic name assignment is not possible. | The expected PROFINET device is not in the projected position (VendorId or DeviceId does not correspond). Hence, no automatic naming and thus no device start is possible.
31 | only for EtherCAT gateways: WC-State of cyclic EtherCAT frame is 1 | For EL6631 only: EtherCAT WC State is 1 | Check the mode on the EtherCAT master & slave (OP?).

As opposed to the state, more than one status can be displayed in the “PnIoBoxDiag”, i.e. the whole thing is bit-coded and up to 16 pieces of information can be displayed. The following statuses are currently displayed.

0x0000 = No diagnosis
0xXXX1 = IOC-AR is not established
0xXXX2 = IOC-AR is established
0xXXX4 = IOC-AR is established but no ApplReady
0xXXX8 = IOC-AR is established but module difference
0xXX1X = At least one AlarmCR get diagnosis alarm
0xX1XX = At least one InputCR is invalid
0xX2XX = At least one InputCR Provider is in stop
0xX4XX = At least one InputCR Problemindicator is set
0x1XXX = At least one OutputCR is invalid
0x2XXX = At least one OutputCR Provider is in stop
0x4XXX = At least one OutputCR Problemindicator is set

On the one hand information about the status of the IO Controller Single AR is displayed here. In addition, collective statuses are formed from the Frame Data statuses of the individual CRs. The whole thing happens for the input and the output CRs (currently only one is possible; in future the controller will support several CRs). In addition a PROFINET alarm is also displayed in the “PnIoBoxDiag”


Project planning of the PROFINET device

When establishing a PROFINET connection the controller always assigns an IP address to the device from its own address space (if the device does not yet have one or if it has a different one). In TwinCAT the next higher address is taken for a device by default (starting from the controller adaptor class); the subnet and gateway are the same as those of the controller. Before the actual assignment of the IP address to the device by the controller, an ARP is used to test for a possible address conflict or to check whether the device already has this IP address. If there is a conflict, e.g. that the IP address is already assigned in the network, the IO driver determines this and outputs a corresponding message in the logger window. If there is no reply to the ARP, this means that no device (the projected device included) is using this IP configuration, which in turn results in the controller assigning the IP settings to the device via a DCP_SET. Setting is skipped if it is determined via the ARP that the device sought already has the projected IP address.

In addition the “InstanceID” and the “FrameID” can be changed in this window. However, the default settings are sufficient for most applications. The Instance ID is incorporated into the formation of the UUID object. A change should therefore be made only in exceptional cases. When changing the Frame ID the employed RTClass must be taken into account (e.g. for RTClass1 unicast 0xC000 - 0xFAFF). If the device is on an IRT controller and all devices have been switched automatically to RTClass3, the FrameID is managed automatically and there is no input option (marked by “Fast Config”).

In addition the current process data length can be checked in this menu, i.e. the MaxLengths indicate which process data size is supported by the respective device, while the ActLengths indicate the current process data length (incl. IOPS and IOCS). The corresponding error message appears if the maximum lengths are exceeded on appending further modules/submodules.

Various settings for the cycle time can be made on the “Features” tab. The controller cycle time for RTCLass1 must always correspond to a power of two, starting from 1 ms ( 1, 2, 4, 8…). If an incorrect base time has been selected, this is indicated by a corresponding message. For RTClass3 the 1 ms base time can be divided again and again by two (down to min. 31.25 µs). The device cycle time can be changed via the exponents. The minimum is always the Controller Cycle Time, unless a larger minimum cycle time than that of the controller is defined in the GSDML. The maximum for RTClass1 is 512 ms. The “SendClockFactor” is fixed here as the time base with the value 32 (31.25 µs * 32 = 1 ms). The “ReductionRatioFactor” is also referenced to this, i.e. an RRFactor of 4 means a cycle time of 4 ms. The transmission point can be shifted again within a cycle via the phase; i.e. where RR = 4 the phase can be 1 - 4. However, this value is only of importance in the case of a synchronized transmission.

In addition there is an option here to adjust the PROFINET Watchdog factor, i.e. each device monitors the input of the cyclic data on the basis of this factor. If the factor is set to the default value (3) this means that, with an RR of 4, three cycles require 12 ms. Hence, a device reacts after 12 ms to missing telegrams (e.g. with an alarm and/or disconnection of the AR). The limits and values are recalculated each time when adjusting the individual factors.


BK9xx3

In the case of the Beckhoff K-Bus Coupler (at present BK9103 or BK9053) that is not connected to an EL663x, an additional menu appears here.

The cyclic process data in the DAP of the Bus Coupler can be accessed easily via this menu.

In addition, a firmware update from the System Manager to the Bus Coupler can be carried out via this menu. If the update takes place by IP it is important to ensure that the IP address is obtained via the DIP switches. If this is not the case the connection breaks off during the update, since the memory area of the IP settings is also formatted and rewritten.


EL663x

If the controller protocol is operated via an EL663x, then an additional menu appears on the devices.

At present only the choice of the PDO mapping is selectable for the controller; i.e. the form in which the PROFINET process data are mapped to the PDOs on the EtherCAT side is set here.


IRT Controller

If the device is operated on an IRT-capable controller, then an additional menu appears.

It is possible to specify the Ti and To factors for IRT-capable devices via this menu. This means the time during which the data in the device are valid within a cycle, or should be set to valid. The prerequisite is that this feature is also supported. The GSMDL supplies the information about this. There is always a basic cycle here (base time). A statement about the minimum possible time comes via the GSDML on the basis of a minimum factor. The upper limit of the factor is limited by the cycle time employed. The shortest possible time in which the data could be valid over PROFINET (always in reference to the cycle) is displayed via the “Time Input Valid” or “Time Output Valid” parameter.


IRT Controller

BECKHOFF PROFINET Controller: Devices at protocol

Shared Device

The SharedDevice feature is available at TwinCAT 2 Build 22.50 or TwinCAT 3 Build 4019.

The dialog appears if the device support "shared device". The information comes from the GSDML.

Hierüber besteht die Möglichkeit dem Controller Zugriff auf die einzelnen Submodule zu Erteilen oder auch zu Entziehen. Defaultmäßig hat der Controller Zugriff auf alle Submodule, falls SharedInput unterstützt wird ist dieses ausgeschaltet.

The text messages of SharedInput have the following meaning:

  • "not supported" - SharedInput is not supported from the device (information from the GSDML)
  • "has output data" - the submodule has outputs - the activation of SharedInput ist not possible
  • "no Input data" - the submodule has no inputs (also no outputs)
  • "no access" - the access is locked
  • "true" bzw. "false" - current setting for SharedInput

Durch Doppelklick auf die einzelnen Submodule können die Einstellungen geändert werden. Wird der Zugriff an einem Port- oder Interfacesubmodul geändert so wird dieser für alle Ports bzw. Interfaces geändert.


Diagnosis at module level

The slot number of the modules always corresponds to the position in the tree, i.e. the DAP module always starts with slot number 0 and so on in order. At module level there is an option on the Diagnostic tab to compare the nominal and actual data for the respective module. In addition the existing diagnosis for the module can be read out.


Diagnosis at submodule level

PROFINET currently distinguishes between 4 types of submodule.

  • Virtual submodules:
    The virtual submodules are always permanently connected to a module, i.e. when inserting a module the virtual submodules defined with it are also always inserted in the specified subslot. This kind of submodule is presently the commonest method.
  • Real submodule:
    Here there is a possibility to select the pluggable submodules from a submodule list and to append them to the module. The necessary information is procured from the GSDML. In TwinCAT a module can be selected from such a list with the right mouse button (provided this is supported by the device).
  • Port submodule:
    The physical properties of a network port are reproduced in such a submodule.
  • Interface submodule:
    Device-specific properties are defined in the interfaces submodules. These can be, for example, additionally supported protocols, timing properties, supported MIBs etc.

In general the submodules have the same diagnostic properties as the modules, i.e. in this case also it is currently only possible to read out the nominal and actual configuration in TwinCAT. The order of the subslot numbers is not necessarily the same as the order in the TwinCAT project. Hence, for example, the order in DAP always starts with the interface submodule (ISM); however, the subslot number of the ISM is defined in the GSDML and starts at 0x8000. There are 16 possible interfaces (0x8x00), each with up to 256 ports (0x80xx). An ISM is followed by the Port submodule with the aforementioned subslot number.


Interface Submodule

The type of communication can always be set on the interface submodule (at present RTClass1 or RTClass3). The only exception is in the case that a generally valid RTClass was set via the ‘Auto Config...’ menu.

If communication takes place over RTClass3, then the PLL window can additionally be set at the interface.


Port Submodule

Port-specific settings can be made on the ‘Properties’ tab. The menu of possible settings always depends on the RTClass employed.

In addition some port properties can be read out.

The information here is subdivided into local port information and remote port properties. I.e. the LLDP protocol (IEEE Std 802.1AB) is prescribed in PROFINET from Conformance Class A (CCA). The devices exchange neighborhood IDs via this protocol, so that each port is known to its neighbor. Furthermore, the Simple Network Management Protocol (SNMP) can be used as an aid at this point. On opening the ‘Port Diagnosis’ tab, TwinCAT acts as a Network Management Station (NMS) and collects the required device information via SNMP. In the above illustration, for example, it can be seen that the local Port 1 of the BK9053 is connected to Port 2 of the BK9103. For correct topology recognition it is important that only devices are present in the strand that also support the LLDP protocol (this is also applies to switches!).


Real / virtual submodules

If these submodules have parameterization data they will be displayed as shown in the illustration below.

Selection can be made here between the individual indices. The data can be read and/or written depending on the access method. The online values are updated when reading back. If an individual index is marked, then all values within an index will be set to default; if individual values are marked, only these will be reset. Writable values are changed by double-clicking on the respective line.


PROFINET Controller - FUNCTION_BLOCK

TwinCAT PLC Library: TcProfinetDiag

Overview

There are ready-to-use function blocks for the use of the PROFINET controller. The library contains further blocks for the EL6631-0010 PROFINET device terminal, but there are not part of that documentation.

Download:

I&M functions

Block I&M functions | Meaning | Description
FB_PN_IM0_READ | Read the I&M function 0 | Supplement and EL663x
FB_PN_IM1_READ | Read the I&M function 1 | Supplement and EL663x
FB_PN_IM2_READ | Read the I&M function 2 | Supplement and EL663x
FB_PN_IM3_READ | Read the I&M function 3 | Supplement and EL663x
FB_PN_IM4_READ | Read the I&M function 4 | Supplement and EL663x
FB_PN_IM1_WRITE | Write the I&M function 1 | Supplement and EL663x
FB_PN_IM2_WRITE | Write the I&M function 2 | Supplement and EL663x
FB_PN_IM3_WRITE | Write the I&M function 3 | Supplement and EL663x
FB_PN_IM4_WRITE | Write the I&M function 4 | Supplement and EL663x

Statistics and diagnostic information

Block I&M functions | Meaning | Description
FB_PN_GET_PORT_STATISTIC | Read the port statistics | Supplement and EL663x
FB_PN_READ_PORT_DIAG | Read the port diagnosis | Supplement and EL663x

Development environment | Target platform | PLC libraries to include
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcEtherCAT.lib TcPlcIoFunction.lib TcUtilities.lib TcSystem.lib TcBase.lib


FUNCTION_BLOCK FB_PN_IM0_READ

Using this function block the PROFINET controller reads all I&M 0 data (Identification & Maintenance) from a device referenced via the Port input.
The frame structure of the I&M0 function corresponds to the index 0xAFF0 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart	: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

VAR_OUTPUT

VAR_OUTPUT
    bBusy 	: BOOL;
    IM_AFF0	: str_IM_0xAFF0;
    bError	: BOOL;
    iErrorID 	: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

IM_AFF0: Output of the I&M0 frame supplied by the device in a structure. str_IM_0xAFF0.

bError: In the event of an error during the command transfer, this output is set once the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_IM1_READ

Using this function block the PROFINET controller reads all I&M1 data (Information & Maintenance) from a device referenced via the Port input.
The frame structure of the I&M1 function corresponds to the index 0xAFF1 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart	: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    st_IM_TagFunction : STRING(32);
    st_IM_TagLocation : STRING(22);
    bError		: BOOL;
    iErrorID 		: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

st_IM_TagFunction : label read out for the function of the device.

st_IM_TagLocation : label read out for the installation site of the device.

bError: In the event of an error during the command transfer, this output is set once the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_IM1_WRITE

Using this function block the PROFINET controller writes all I&M1 data (Identification & Maintenance) data to a device referenced via the Port input.
The frame structure of the I&M1 function corresponds to the index 0xAFF1 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart		: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
    st_IM_TagFunction	: STRING(32);
    st_IM_TagLocation	: STRING(22);
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

st_IM_TagFunction : With this string the functional description is saved to the device.

st_IM_TagLocation : With this string the installation site is saved to the device.

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    bError		: BOOL;
    iErrorID 		: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

bError : If an error should occur during the transmission of the command, this output is set after the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set..

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_IM2_READ

Using this function block the PROFINET controller reads all I&M 2 data (Identification & Maintenance) from a device referenced via the Port input.
The frame structure of the I&M2 function corresponds to the index 0xAFF2 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart	: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    str_Date		: TIMESTRUCT; (*YYYY-MM-DD HH:MM*)
    bError		: BOOL;
    iErrorID 		: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

str_Date : Returns the date of installation of the device in the format < YYYY-MM-DD HH:MM >.

bError : If an error should occur during the transmission of the command, this output is set after the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_IM2_WRITE

Using this function block the PROFINET controller writes all I&M 2 data (Identification & Maintenance) data to a device referenced via the Port input.
The frame structure of the I&M2 function corresponds to the index 0xAFF2 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart	: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
    str_Date	: TIMESTRUCT;(*YYYY-MM-DD HH:MM*)
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

str_Date : Writes a date (e.g. date of installation of the device) to the device in the format < YYYY-MM-DD HH:MM >.

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    bError		: BOOL;
    iErrorID 		: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

bError : If an error should occur during the transmission of the command, this output is set after the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_IM3_READ

Using this function block the PROFINET controller reads all I&M3 data (Identification & Maintenance) from a device referenced via the Port input.
The frame structure of the I&M3 function corresponds to the index 0xAFF3 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart	: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    st_IM_Descriptor 	: STRING(54);
    bError		: BOOL;
    iErrorID 		: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

st_IM_Descriptor: Returns the manufacturer description stored for the device.

bError : If an error should occur during the transmission of the command, this output is set after the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_IM3_WRITE

Using this function block the PROFINET controller writes all I&M3 data (Identification & Maintenance) data to a device referenced via the Port input.
The frame structure of the I&M3 function corresponds to the index 0xAFF3 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart		: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
    st_IM_Descriptor 	: STRING(54);
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

st_IM_Descriptor: Returns the manufacturer description stored for the device.

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    bError		: BOOL;
    iErrorID 		: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

bError : If an error should occur during the transmission of the command, this output is set after the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_IM4_Read

Using this function block the PROFINET controller reads all I&M4 data (Identification & Maintenance) from a device referenced via the Port input.
The frame structure of the I&M4 function corresponds to the index 0xAFF4 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart	: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    st_IM_Signatur 	: STRING(54);
    bError		: BOOL;
    iErrorID 		: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

st_IM_Signature : Returns the manufacturer signature stored for the device.

bError : If an error should occur during the transmission of the command, this output is set after the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_IM4_WRITE

Using this function block the PROFINET controller writes all I&M4 data (Identification & Maintenance) data to a device referenced via the Port input.
The frame structure of the I&M4 function corresponds to the index 0xAFF4 according to PROFINET standard.

VAR_INPUT

VAR_INPUT
    bStart		: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
    st_IM_Signatur 	: STRING(54);
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

st_IM_Signature: Signature of the manufacturer is written to the device.

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    bError		: BOOL;
    iErrorID 		: UDINT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

bError : If an error should occur during the transmission of the command, this output is set after the bBusy output has been reset.

iErrorID: Supplies an ADS error number when the output bError is set.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_GET_PORT_STATISTIC

When called, this module supplies the statistical data for the ports of a PROFINET device.

VAR_INPUT

VAR_INPUT
    bStart		: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex )

VAR_OUTPUT

VAR_OUTPUT
    bBusy		: BOOL;
    str_RemotePort_1	: str_GetPortStatistic;
    str_RemotePort_2	: str_GetPortStatistic;
    bPort1		: BOOL;
    bPort2		: BOOL;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

str_RemotePort_1: This structure contains the statistical data for Port 1.

str_RemotePort_2: This structure contains the statistical data for Port 2.

bPort1: Is TRUE if the port has a link.

bPort2: Is TRUE if the port has a link.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


FUNCTION_BLOCK FB_PN_READ_PORT_DIAG

This block calls the port diagnostic information of a PROFINET device.

VAR_INPUT

VAR_INPUT
    bStart		: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
END_VAR

bStart : The block is activated by a rising edge on this input

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex )

VAR_OUTPUT

VAR_OUTPUT
    bBusy		: BOOL;
    str_RemotePort_1	: str_PortDiag;
    str_RemotePort_2	: str_PortDiag;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

str_RemotePort_1 : This structure contains the diagnostic information for Port 1.

str_RemotePort_2 : This structure contains the diagnostic information for Port 2.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcPROFINETDiag.Lib


FUNCTION_BLOCK FB_PN_ALARM_DIAG

Diagnosis alarms can be read out using this function block. Each instance of this function block makes a PLC input available (“PnIoBoxDiag”). This input must be linked to the “PnIoBoxDiag” input of the device that is to be evaluated. After successful reading of the diagnosis alarms/warnings, the alarm status of the device is reset. The function block must be called once for each PROFINET device. A running index (iNrAlarms) indicates how many diagnosis alarms have been read from the buffer.

VAR_INPUT

VAR_INPUT
    bEnable	: BOOL;
    NETID 	: T_AmsNetId;(* AMS Net ID from Controller *)
    PORT 	: T_AmsPort; (* Port used by Controller to communicate with Device *)
END_VAR

bEnable : Activation of the function block

NETID : AMS Net ID of the controller

PORT : Port via which the controller communicates with the device (port = Device ID + 1000hex)

VAR_OUTPUT

VAR_OUTPUT
    bBusy 		: BOOL;
    stAlarmDiagData	: ST_PN_AlarmDiagData;
    bError		: BOOL;
    iErrorID 		: UDINT;
    iNrAlarms		: INT;
END_VAR

bBusy : When the function block is activated this output is set. It remains set until a feedback is received. While Busy = TRUE, no new command will be accepted at the inputs.

stAlarmDiagData : Diagnosis messages are output via this structure. An alarm is output via the structure in each cycle as long as the status bit [0x0010 = at least one AlarmCR got a diagnosis alarm] is present at the PLC input.

bError : If an error should occur during the transmission of the command, this output is set after the bBusy output has been reset.

iErrorID : Supplies an ADS error number when the output bError is set.

iNrAlarms : Number of alarms last read out.

VAR

VAR
        PnIoBoxDiag AT %I* : WORD; (*Hardware Input*)
END_VAR

PnIoBoxDiag : Hardware input: this variable must be linked to the PROFINET device. A change of state of this variable indicates to the PLC program that there are new diagnosis alarms in the linked PROFINET device.

Development environment | Target platform | PLC libraries to be linked
TwinCAT v2.11.0 R3 | PC or CX (x86, ARM) | TcProfinetDiag.Lib


str_IM_0xAFF0

The data structure str_IM_0xAFF0 maps the structure of the I&M0 frame in the PLC, which contains information that is permanently stored in PROFINET devices.

TYPE str_IM_0xAFF0 :

STRUCT
    nBlockTyp 	: WORD;
    nBlockLen 	: WORD;
    nBlockVersion 	: WORD;
    nVendorID 	: WORD;
    cOrderID 		: STRING(21);
    cSerialNumber 	: STRING(17);
    nHW_Rev 		: WORD;
    strSW_Rev 	: str_SW_Rec;
    nRevCount 	: WORD;
    nProfileID 	: WORD;
    nProfileSpecType	: WORD;
    arIM_Version 	: ARRAY[0..1] OF BYTE;
    nSupport 		: WORD;
END_STRUCT

END_TYPE

str_SW_Rec

The data structure str_SW_REC contains the software version of the PROFINET device.

TYPE str_SW_Rec :

STRUCT
    cSWRevPrefix	:STRING(2);
    nSWRevFuncEnhance	:BYTE;
    nSWRevBugFix	:BYTE;
    nSWRevIntCha	:BYTE;
END_STRUCT

END_TYPE


str_IM_0xAFF1

The data structure str_IM_0xAFF1 maps the structure of the I&M1 frame in the PLC. This structure is used both for reading from, and for the writing to a PROFINET device.

TYPE str_IM_0xAFF1 :

STRUCT
    nBlockTyp 	: WORD;
    nBlockLen 	: WORD;
    nBlockVersion 	: WORD;
    st_IM_TagFunction : STRING(32);
    st_IM_TagLocation : STRING(22);
END_STRUCT

END_TYPE


str_IM_0xAFF2

The data structure str_IM_0xAFF2 maps the structure of the I&M2 frame in the PLC. This structure is used both for reading from, and for the writing to a PROFINET device.

TYPE str_IM_0xAFF1 :

STRUCT
    nBlockTyp 	: WORD;
    nBlockLen 	: WORD;
    nBlockVersion 	: WORD;
    st_IM_Date 	: STRING(16);
END_STRUCT

END_TYPE


str_IM_0xAFF3

The data structure str_IM_0xAFF3 maps the structure of the I&M3 frame in the PLC. This structure is used both for reading from, and for the writing to a PROFINET device.

TYPE str_IM_0xAFF3 :

STRUCT
    nBlockTyp 	: WORD;
    nBlockLen 	: WORD;
    nBlockVersion 	: WORD;
    st_IM_Descriptor	: STRING(54)
END_STRUCT

END_TYPE


str_IM_0xAFF4

The data structure str_IM_0xAFF4 maps the structure of the I&M4 frame in the PLC. This structure is used both for reading from, and for the writing to a PROFINET device.

TYPE str_IM_0xAFF3 :

STRUCT
    nBlockTyp 	: WORD;
    nBlockLen 	: WORD;
    nBlockVersion 	: WORD;
    st_IM_Signatur 	: STRING(54)
END_STRUCT

END_TYPE


str_GetPortStatistic

All statistical information of a device is represented in the data structure str_GetPortStatistic.

TYPE str_GetPortStatisitc :

STRUCT
    Speed 		: DWORD;
    PhyMAC 		: STRING(50);
    OperatingStatus 	: STRING(16);
    RxOctets 		: DWORD;
    RxUniCastPackets 	: DWORD;
    RxBadPackets 	: DWORD;
    RxDroppedFrames 	: DWORD;
    RxUnknownProtocol	: DWORD;
    TxOctets		: DWORD;
    TxUniCastPackets 	: DWORD;
    TxBadPackets 	: DWORD;
    TxDroppedPackets 	: DWORD;
END_STRUCT

END_TYPE


str_PortDiag

All port diagnostic information is represented in the data structure str_PortDiag.

TYPE str_PortDiag :

STRUCT
    PortId 		: STRING(128);
    PortDescription 	: STRING(128);
    SystemName 	: STRING(128);
    SystemDescription	: STRING(128);
    ChassisId 	: STRING(128);
END_STRUCT

END_TYPE


ST_PN_DiagMessage

The data structure ST_PN_DiagMessage contains the complete data stream of a diagnostic message that is sent by a PROFINET on request. This data stream is evaluated in the FB_PN_ALARM_DIAG function block and is copied to a readable structure.

TYPE ST_PN_DiagMessage :

STRUCT
    nFlags 		: WORD;
    nTextID 		: WORD;
    TimeStamp		: ARRAY[0..7] OF BYTE;
    nData 		: ARRAY[0..299] OF BYTE;
END_STRUCT

END_TYPE


ST_PN_Diag

The data structure ST_PN_Diag contains a diagnostic message from a terminal that is connected via a PN device and a controller.

TYPE str_PortDiag :

STRUCT
    strTimeStamp 		: ARRAY[0..7] OF BYTE;
    nAPI 			: DWORD;
    nSlot 			: WORD;
    nSubSlot 			: WORD;
    nAlarmType 		: WORD;
    nAlarmSpecifier 		: WORD;
    nUserStructIdentifier 	: WORD;
    nChannelNumber		: WORD;
    nChannelErrorTyp 		: WORD;
    nChannelProperties 	: WORD;
    nExtChannelErrorTyp 	: WORD;
    arSpare 			: ARRAY [1..9] OF WORD;
    arUserSpecificData 	: ARRAY [0..19] OF BYTE;
END_STRUCT

END_TYPE

The information content of the structure corresponds to that of the Diag History, which is displayed in the system manager.


ST_PN_AlarmDiagData

The data structure ST_PN_AlarmDiagData contains the alarm diagnosis data record read from a device, including a time stamp that indicates when the event occurred and a flag that indicates that ‘user-specific’ data are present.

TYPE ST_PN_AlarmDiagData :

STRUCT
    ST_TimeStamp 	: TIMESTRUCT;
    sNameOfStation	: STRING(20);
    ST_Diag 		: ST_PN_Diag;
    bUserSpecData 	: BOOL;
END_STRUCT

END_TYPE


Enumeration types for PROFINET alarms

E_PN_ALARM_TYP

The enumeration type E_PN_ALARM_TYP lists all PROFINET communication alarms.

TYPE E_PN_ALARM_TYP :
(
    PN_ALARM_RESERVE		:=0,
    PN_ALARM_DIAGNOSE_APPEARS	:=1,
    PN_ALARM_PROCESS		:=2,
    PN_ALARM_PULL 		:=3,
    PN_ALARM_PLUG 		:=4,
    PN_ALARM_STATUS 		:=5,
    PN_ALARM_UPDATE 		:=6,
    PN_ALARM_REDUNDANCY	:=7,
    PN_ALARM_Controlled_by_Supervisor 		:=8,
    PN_ALARM_Released 				:=9,
    PN_ALARM_Plug_Wrong_Submodule 		:=16#A,
    PN_ALARM_Diagnosis_Disappears 		:=16#B,
    PN_ALARM_Multicast_Communication_Mismatch 	:=16#C,
    PN_ALARM_Multicast 			:=16#D,
    PN_ALARM_STATUS_ 				:=16#E,
    PN_ALARM_Sync_ 				:=16#F,
    PN_ALARM_Isochronous_Mode_Problem_Notification :=16#10
);
END_TYPE


UL Requirements

BECKHOFF EKxxxx, ELxxxx: Appendix

UL notice

Application
Beckhoff EtherCAT modules are intended for use with Beckhoff’s UL Listed EtherCAT System only.
Examination
For cULus examination, the Beckhoff I/O System has only been investigated for risk of fire and electrical shock (in accordance with UL508 and CSA C22.2 No. 142).
For devices with Ethernet connectors
Not for connection to telecommunication circuits.

Basic principles

Two UL certificates are met in the Beckhoff EtherCAT product range, depending upon the components:

  • UL certification according to UL508
    Devices with this kind of certification are marked by this sign:

  • UL certification according to UL508 with limited power consumption
    The current consumed by the device is limited to a max. possible current consumption of 4 A. Devices with this kind of certification are marked by this sign:

Almost all current EtherCAT products (as at 2010/05) are UL certified without restrictions.

Application

If terminals certified with restrictions are used, then the current consumption at 24 V DC must be limited accordingly by means of supply

  • from an isolated source protected by a fuse of max. 4A (according to UL248) or
  • from a voltage supply complying with NEC class 2.
    A voltage source complying with NEC class 2 may not be connected in series or parallel with another NEC class 2 compliant voltage supply!

These requirements apply to the supply of all EtherCAT bus couplers, power adaptor terminals, Bus Terminals and their power contacts.


EL6631-0010 - Firmware Kompatibilität

BECKHOFF EL663x: Appendix

Firmware compatibility

Beckhoff EtherCAT devices will be equipped with the last available firmware on delivery. There are certain dependencies between firmware and hardware, not all combinations are compatible.
The overview below shows which firmware is compatible to a certain hardware status.

Notice

  • It is strictly recommended to apply the last available firmware on the particular hardware
  • There is no customer right to get a firmware update at no charge for already delivered products by the Beckhoff company.

Attention 		Damage of devices possible!
Please note the details concerning the firmware update on the special page.
If you run a device in BOOTSTRAP mode to initiate a firmware update, it it possible that there is no checking of compatibility of the firmware.
A damage of the device is possible!
Please always make sure, that the firmware is suitable for the hardware status of the device!
EL6631
Hardware (HW) | Firmware | Revision No. | Date of release
01 | 01 (V00.08) | EL6631-0000-0016 | 2012/04
EL6632
Hardware (HW) | Firmware | Revision No. | Date of release
01 | 00 (V00.26) | EL6632-0000-0016 | BETA Version

*) At the time of creation of this documentation this is the current compatible hardware status. Please check the Beckhoff website for the latest documentation.


EtherCAT - Firmware

BECKHOFF EtherCAT: Device Update

Firmware EL/ES/EM/EPxxxx

This section describes the device update for Beckhoff EtherCAT slaves from the EL/ES, EM, EK and EP series. A firmware update should only be carried out after consultation with Beckhoff support.

Table of contents
• Storage locations
• Device description ESI file/XML
• Frimware version definition
• Updating Controller firmware *.efw
• FPGA firmware update *.rbf
• Multiple update

Storage locations

An EtherCAT slave stores operating data in up to 3 locations:

  • Depending on functionality and performance EtherCAT slaves have one or several local controllers for processing I/O data. The corresponding program is the so-called firmware in *.efw format.
  • In some EtherCAT slaves the EtherCAT communication may also be integrated in these controllers. In this case the controller is usually a so-called FPGA chip with *.rbf firmware.
  • In addition each EtherCAT slave has a memory chip for storing its own device description, a so-called EEPROM. On power-up this description is loaded and the EtherCAT communication is set up accordingly. The device description is available from the download area of the Beckhoff website at http://www.beckhoff.com . All ESI files (EtherCAT Slave Information) are available in ZIP format.

Customers can access the data via the EtherCAT fieldbus and its communication mechanisms. Acyclic mailbox communication or register access to the ESC is used for updating or reading of these data.

The TwinCAT System Manager offers mechanisms for programming all 3 parts with new data, if the slave is set up for this purpose. Generally the slave does not check whether the new data are suitable, i.e. it may no longer be able to operate if the data are unsuitable.

Attention 		Risk of damage to the device!
Note the following when downloading new device files
  • Firmware downloads to an EtherCAT device must not be interrupted
  • Flawless EtherCAT communication must be ensured. CRC errors or Lost Frames must be avoided.
  • The power supply must adequately dimensioned. The signal level must meet the specification.

In the event of malfunctions during the update process the EtherCAT device may become unusable and require re-commissioning by the manufacturer.

Device description ESI file/XML

Attention 		Notice regarding update of the ESI description/EEPROM
Some slaves have stored calibration and configuration data from the production in the EEPROM. These are irretrievably overwritten during an update.

The ESI device description is stored locally on the slave and loaded on start-up. Each device description has a unique identifier consisting of slave name (9 characters/digits) and a revision number (4 digits). Each slave configured in the System Manager shows its identifier in the EtherCAT tab:

Fig. 1: Device identifier consisting of name EL3204-0000 and revision -0016

The configured identifier must be compatible with the actual device description used as hardware, i.e. the description which the slave has loaded on start-up (in this case EL3204). Generally the configured revision must be equal or lower than the version used in the terminal network.

For further information please refer to the EtherCAT System Documentation.

Note 		Update of XML/ESI description
The device revision is closely linked to the firmware and hardware used. Incompatible combinations lead to malfunctions or even final shutdown of the device.
Corresponding updates should only be carried out in consultation with Beckhoff support.

Display of ESI slave identifier

The simplest way to ascertain compliance of configured and actual device description is to scan the EtherCAT boxes in TwinCAT mode Config/Freerun:

Fig. 2: Scan the subordinate field by right-clicking on the EtherCAT device in Config/FreeRun mode

If the found field matches the configured field, the display shows

Fig. 3: Configuration is identical

otherwise a change dialog for entering the actual data in the configuration.

Fig. 4: Change dialog

In the example shown in Fig. 4. an EL3201-0000-0017 was found, while an EL3201-0000-0016 had been configured. In this case it makes sense to adapt the configuration with the Copy Before button. The Extended Information checkbox must be set in order to have the revision displayed.

Changing the ESI slave identifier

The ESI/EEPROM identifier can be updated as follows under TwinCAT:

  • The EtherCAT communication with the slave must be flawless.
  • The state of the slave is irrelevant.
  • Right-click on the slave in the online display to bring up the EEPROM Update dialog, Fig. 5

Fig. 5: EEPROM Update

Select the new ESI description in the following dialog, see Fig. 6. The ShowHiddenDevices checkbox also shows older, usually hidden slave versions.

Fig. 6: Selecting the new ESI

A progress bar in the System Manager shows the progress. Data are first written, then verified.

Note 		The change only takes effect after a restart.
Most EtherCAT devices read a modified ESI description immediately or after startup from the INIT. Some communication settings such as distributed clocks are only read during power-on.
The EtherCAT slave therefore has to be switched off briefly in order for the change to take effect.

Determining the firmware version

Determining the version on laser inscription

Beckhoff EtherCAT slaves feature serial numbers applied by laser. The serial number has the following structure: KK YY FF HH

KK - week of production (CW, calendar week)
YY - year of production
FF - firmware version
HH - hardware version

Example with ser. no.: 12 10 03 02:

12 - week of production 12
10 - year of production 2010
03 - firmware version 03
02 - hardware version 02

Determining the version via the System Manager

The TwinCAT System Manager shows the version of the controller firmware if the master can access the slave online. Click on the E-Bus Terminal whose controller firmware you want to check (in the example terminal 2 (EL3204)) and select the tab CoE Online (CAN over EtherCAT).

Note 		CoE Online and Offline CoE
Two CoE directories are available:
  • online: This is offered in the EtherCAT slave by the controller, if the EtherCAT slave does supported it.
    This CoE directory can only be displayed if a slave is connected and operational.
  • offline: The EtherCAT Slave Information ESI/XML may contain the default content of the CoE.
    This CoE directory can only be displayed if it is included in the ESI (e.g. "Beckhoff EL5xxx.xml").

The Advanced button must be used for switching between the two views.

In Fig. 7 the firmware version of the selected EL3204 is shown as 03 in CoE entry x100A.

Fig. 7: Display of EL3204 firmware version

In (A) TwinCAT 2.11 shows that the Online CoE directory is currently displayed. If this is not the case, the Online directory can be loaded via the Online option in Advanced Settings (B) and double-clicking on AllObjects.

Updating controller firmware *.efw

Note 		CoE directory
The Online CoE directory is managed by the controller and stored in a dedicated EEPROM, which is generally not changed during a firmware update.

To update the controller firmware of a slave switch to tab Online, see Fig. 8.

Fig. 8: Firmware Update

Proceed as follows, unless instructed otherwise by Beckhoff support.

  • Switch slave to INIT (A)
  • Switch slave to BOOTSTRAP
  • Check the current status (B, C)
  • Download the new *efw file
  • After the download switch to INIT, then OP
  • Switch off the slave briefly

FPGA firmware *.rbf

If an FPGA chip deals with the EtherCAT communication an update may be accomplished via an *.rbf file.

  • Controller firmware for processing I/O signals
  • FPGA firmware for EtherCAT communication (only for terminals with FPGA)

The firmware version number included in the terminal serial number contains both firmware components. If one of these firmware components is modified this version number is updated.

Determining the version via the System Manager

The TwinCAT System Manager indicates the FPGA firmware version. Click on the Ethernet card of your EtherCAT strand (Device 2 in the example) and select the Online tab.

The Reg:0002 column indicates the firmware version of the individual EtherCAT devices in hexadecimal and decimal representation.

Fig. 9: FPGA firmware version definition

If the column Reg:0002 is not displayed, right-click the table header and select Properties... in the context menu.

Fig. 10: Context menu Properties

The Advanced Settings dialog appears where the columns to be displayed can be selected. Under Diagnosis/Online View select the '0002 ETxxxx Build' check box in order to activate the FPGA firmware version display.

Fig. 11: Dialog Advanced Settings

Update

For updating the FPGA firmware

  • of an EtherCAT coupler the coupler must have FPGA firmware version 11 or higher;
  • of an E-Bus Terminal the terminal must have FPGA firmware version 10 or higher.

Older firmware versions can only be updated by the manufacturer!

Updating an EtherCAT device

In the TwinCAT System Manager select the terminal whose FPGA firmware you want to update (in this example terminal 5: EL5001) and
click on Advanced Settings in the EtherCAT tab.

Fig. 12: Select dialog Advanced Settings

The Advanced Settings dialog appears. Under ESC Access/E²PROM/FPGA click on Write FPGA button,

Fig. 13: Select dialog Write FPGA

select the file (*.rbf) with the new FPGA firmware, and transfer it to the EtherCAT device.

Attention 		Risk of damage to the device!
A firmware download to an EtherCAT device must never be interrupted!

If this process is cancelled, the supply voltage switched off or the Ethernet connection interrupted, the EtherCAT device can only be recommissioned by the manufacturer!

In order to activate the new FPGA firmware a restart (switching the power supply off and on again) of the EtherCAT device is required.

Simultaneous updating of several EtherCAT devices

The firmware and ESI descriptions of several devices can be updated simultaneously, provided the devices have the same firmware file/ESI.

Fig. 14: Multiple selection and firmware update

Select the required slaves and carry out the firmware update in BOOTSTRAP mode as described above.


Fieldbus Components - ATEX Documentation

BECKHOFF Fieldbus Components: Mounting and wiring

ATEX Documentation

Note 		Notes about operation of the Bus Terminal System in potentially explosive areas (ATEX)
Pay also attention to the continuative documentation

Notes about operation of the Bus Terminal System in potentially explosive areas (ATEX)

that is available in the download area of the Beckhoff homepage http:\\www.beckhoff.com!


Support and Service

Beckhoff and their partners around the world offer comprehensive support and service, making available fast and competent assistance with all questions related to Beckhoff products and system solutions.

Beckhoff's branch offices and representatives

Please contact your Beckhoff branch office or representative for local support and service on Beckhoff products!

The addresses of Beckhoff's branch offices and representatives round the world can be found on her internet pages:
http://www.beckhoff.com

You will also find further documentation for Beckhoff components there.

Beckhoff Headquarters

Beckhoff Automation GmbH

Huelshorstweg 20
33415 Verl
Germany

Phone: | +49(0)5246/963-0
Fax: | +49(0)5246/963-198
e-mail: | info@beckhoff.com
Beckhoff Support

Support offers you comprehensive technical assistance, helping you not only with the application of individual Beckhoff products, but also with other, wide-ranging services:

  • support
  • design, programming and commissioning of complex automation systems
  • and extensive training program for Beckhoff system components
Hotline: | +49(0)5246/963-157
Fax: | +49(0)5246/963-9157
e-mail: | support@beckhoff.com
Beckhoff Service

The Beckhoff Service Center supports you in all matters of after-sales service:

  • on-site service
  • repair service
  • spare parts service
  • hotline service
Hotline: | +49(0)5246/963-460
Fax: | +49(0)5246/963-479
e-mail: | service@beckhoff.com


RecStruct

The data structure RectStruct maps the structure of the I&M2 frame in the PLC. This structure is used both for writing to, and for reading from a PROFINET device.

TYPE str_IM_0xAFF1 :

STRUCT
    nRW		: WORD;	(* 0 = Read / 1 = Write*)
    nNrOfAR		: WORD; 	(*Number of Application Relationship*)
    nAPI		: DWORD;	(*Application Process Identifier*)
    nSlot		: WORD;	(*Coupler = 0 / Terminal > 0*)
    nSubSlot		: WORD;	(*1*)
    nIndex		: WORD;	(*Register e.g. 0xAFF0 = IM0*)
    nLenght		: WORD;	(*read = 0*)
    nTransSeq		: WORD;	(*0x0001*)
    nLenOfAlign	: WORD;  (*0*)
END_STRUCT

END_TYPE