Features - V3
- Benjamin Meyer
Key Features
- cyclic Profinet RT Communication (RT_Class_1)
- cyclic Profinet IRT Communication (RT_Class_3)
- automatic assignment of NameOfStation (based on topology information)
- support for FastStartUp IO-Devices
- interfaces for acyclic services
- interfaces for DCP services
- interface for Supervisor DeviceAccess AR
Supported Protocols
- RTC – Real time Cyclic Protocol
- RTA – Real time Acyclic Protocol
- DCP – Discovery and Configuration Protocol
- CL-RPC – Connectionless Remote Procedure Call
- LLDP – Link Layer Discovery Protocol
- SNMP – Simply Network Management Protocol (SNMP v1)
- PTCP – Precision Transparent Clock Protocol
- MRP – Media Redundancy Protocol
Technical Data
Technical data | Amount | Remark |
|---|---|---|
| Maximum number of ARs | 128 | This is the maximum number of ARs supported by the controller. |
| Maximum number of ARs for RT communication | 128 | |
| Maximum number of ARs for IRT communication | 64 | The netX supports up to 64 Input and Output IOCRs in IRT Mode |
| Process Data Input | 5652 byte | The Input Area of DPM consists of the input process data and three 16 byte status bit lists. The Process data includes the PROFINET Provider and Consumer States. |
| Output data, total | 5700 byte | The Process data includes the Profinet Provider and Consumer States. |
| Supported send clock for RT mode | 1 ms, 2 ms, 4 ms | If IRT mode is used for at least one AR, the minimum possible send clock for RT mode is additionally limited to greater or equal values than the send clock of that AR. |
| Supported send clock for IRT mode | 250 µs, 500 µs, 1 ms, 2 ms, 4 ms | |
| Performance Limits of ARs | max. 8 ARs if any Sendclock < 500 µs max. 16 ARs if any Sendclock < 1 ms max. 64 ARs if any Sendclock < 2 ms | The maximum number of possible ARs is limited by the minimum send clock value used in the configuration. |
| Maximum amount of data for acyclic read/write record access | 1024 bytes | This limit applies to Acyclic Implicit Read, Acyclic Read and Acyclic Write services. |
| Number of IOCRs per AR | 1x Input IOCR 1x Output IOCR | |
| Maximum amount of data per IOCR | 1440 | This is the physical limit of the Ethernet frame size. The IOCR's data consists of process data and the associated provider and consumer states. Thus the amount of available process data per IOCR depends on the number of submodules configured for that IOCR. |
| Maximum number of submodules | 2048 | The globally defined maximum number of submodules the controller can handle. The submodules can be arbitrarily distributed across the configured ARs and IOCRs. The number of submodules per IOCR is only limited by the IOCR data size |
| Maximum number of ARVendorBlock | 256 | The firmware supports a global number of up to 256 ARVendorBlocks which. Each ARVendorBlock is associated with an AR. There is no limitation on the number of ARVendorBlocks per AR. |
| Maximum size of ARVendorBlockData | 512 byte | The ARVendorBlockReq and the ARVendorBlockRes data are each limited to this value. |
| Maximum amount of record data per AR | 16384 byte | The maximum amount of record data to be configured for one AR. This record data is transferred to the device when the AR is established and includes beyond others: PDEV parameterization and device specific record data. |
| Time for TX data update (Time_TxUpd_Min) | 98 µs | This is the time required by the firmware to prepare the transmitt buffers from DPM output area. The time is independent from number of IOCRs, and Data length. |
| Time for RX data processing (Time_RxUpd_Max) | 74 µs + 2.3 µs per IOCR | This is the time required by the firmware to prepare the DPM input area from the receive buffers. The time depends on the number of IOCRs and their size. The given time is for 40 bytes IOCR data. |
| Device Access AR CMI Timeout | 20 s | The DA-AR uses a CMI Timeout of 20 seconds. |
| Alarm processing | yes | The PROFINET IO Controller can be configured to perform automatic alarm handling. For each alarm type it can be configured if the alarm is to be handled by the PROFINET IO Controller firmware itself or if the alarm shall be passed to the application for further processing. Using automatic alarm handling reduces the amount of indications passed to the application and can simplify application implementation. |
| DCP functions via API | Name Assignment IO-Devices (DCP SETNameOfStation) Set IO-Devices IP (DCP SET IP) Signal IO-Device (DCP SET SIGNAL) Reset IO-Device to factory settings (DCP Reset FactorySettings) Bus scan (DCP IDENTIFY ALL) DCP GET | |
| Profinet specification | implementation based on Profinet IO specification v2.3 ED2 MU3 legacy startup (communication to IO Devices according to Profinet IO specification v2.2) is supported Maximum supported CDML Parameter PNIO_Version: 2.42 (when using newest available stack/firmware version) | |
| Automatic Name Assignment | yes | The PROFINET IO Controller implements automatic name assignment. That means, that the controller can automatically assign the PROFINET name of station according a previously configured topology information to any unnamed device in the network. With that feature it is possible to e.g. exchange faulty PROFINET IO Devices without factory new devices without additional effort. |
Configuration
Two kinds of configuration are possible:
- Configuration by tool SYCON.net (Download or exported configuration).
- Configuration by packets to transfer bus and device parameters
Diagnostic
Firmware supports common and extended diagnostic (of firmware itself) in the dual-port-memory for loadable firmware.
Profinet diagnosis needs to be handled by the application. Incoming Profinet diagnosis alarms are forwarded to application by packet interface.