Protocol API. SERCOS III Slave. Language: English

Transcription

1 Protocol API SERCOS III Slave Language: English

2 SERCOS III Slave 2 Revision History Rev Date Name Revisions HH/UJ/JR Created RG SERCOS slave based on specification V1.1 Firmware version V RG/JR SERCOS slave based on specification V1.1 Firmware version V0.98.0

3 SERCOS III Slave 3 All rights reserved. No part of this publication may be reproduced. The Author makes no warranty of any kind with regard to this material, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. The Author assumes also no responsibility for any errors that may appear in this document. Although this software has been developed with great care and was intensively tested, Hilscher Gesellschaft für Systemautomation mbh cannot guarantee the suitability of this software for any purpose not confirmed by us in written form. Guarantee claims shall be limited to the right to require rectification. Liability for any damages which may have arisen from the use of this software or its documentation shall be limited to cases of intent. We reserve the right to modify our products and their specifications at any time in as far as this contribute to technical progress. The version of the manual supplied with the software applies. Please notice: Windows 95/98/ME and Windows NT/2000/CE/XP/Vista are registered trademarks of Microsoft Corporation.

4 SERCOS III Slave 4 Table of Contents 1 Introduction Abstract System Requirements Intended Audience Specifications Technical Data Limitations Terms, Abbreviations and Definitions References Fundamentals General Access Mechanisms on netx Systems Accessing the Protocol Stack by Programming the AP Task s Queue Getting the Receiver Task Handle of the Process Queue Meaning of Source- and Destination-related Parameters Accessing the Protocol Stack via the Dual Port Memory Interface Communication via Mailboxes Using Source and Destination Variables correctly Obtaining useful Information about the Communication Channel Dual-Port Memory Cyclic Data (Input/Output Data) Input Process Data Output Process Data Acyclic Data (Mailboxes) General Structure of Messages or Packets for Non-Cyclic Data Exchange Status & Error Codes Differences between System and Channel Mailboxes Send Mailbox Receive Mailbox Channel Mailboxes (Details of Send and Receive Mailboxes) Status Common Status Extended Status Control Block General Topics The SERCOS III Stack Structure SERCOS III-Device AP-Task SERCOS III-Device COM-Task SERCOS III-Device RTD-Task SERCOS III-Device SVC-Task Start-up of the SERCOS III-Device Stack State Machine (Communication Phases) State Transitions Non real-time Mode (NRT Mode) Communication Phase Communication Phase Communication Phase Communication Phase Communication Phase Data Exchange Cyclic Data Exchange Acyclic Data Exchange LED Definitions Watchdog Timers The Application Interface The SERCOS III Device AP-Task SERCOSIII_SL_AP_WARMSTART_REQ/CNF - Warmstart Packet SERCOSIII_SL_AP_ACCESSIDN_IND - Access IDN SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ/CNF - Get Watchdog Time... 57

5 SERCOS III Slave SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ/CNF Set Watchdog Time SERCOSIII_SL_AP_CMD_READY_FOR_CPS_REQ/CNF - Ready for Communication Phase Switching Request SERCOSIII_SL_AP_CMD_CHANGE_SLAVE_STATE_REQ/CNF - Change Slave State request SERCOSIII_SL_AP_CMD_HOST_READY_REQ/CNF - Host-Ready Changed Request SERCOSIII_SL_AP_CMD_SET_COM_ERROR_IND Communication Error SERCOSIII_SL_AP_CMD_SET_TIMING_PARAMETER_IND Change of Timing Parameters Indication Status/Error Codes Overview Error Codes of the AP-Task Error Codes of the RTD -Task Error Codes of the SVC -Task Error Codes of the COM Task Appendix Object Dictionary General Access Procedure List of Available SERCOS III IDNs/EIDNs Example Applications CifxTestConsole Sercos3SlaveDiag Contact

6 SERCOS III Slave List of Figures 6 Figure 1: The 3 different Ways to access a Protocol Stack running on a netx System Figure 2: Use of uldest in Channel and System Mailbox Figure 3: Using ulsrc and ulsrcid Figure 4: Extended Status in DPM Figure 5: Permitted Communication Phase Transitions Figure 6: Cyclic Data in Dual-port-memory Figure 7: Screenshot of CifxTestConsole Tool Figure 8: Screenshot of Sercos3SlaveDiag Tool... 88

7 SERCOS III Slave Introduction 7 List of Tables Table 1: Terms, Abbreviations and Definitions Table 2: References Table 3: Names of Queues in EtherNet/IP Firmware Table 4: Meaning of Source- and Destination-related Parameters Table 5: Meaning of Destination-Parameter uldest Table 6: Example for correct Use of Source- and Destination-related Parameters Table 7: Address Assignment of Hardware Assembly Options Table 8: Addressing Communication Channel Table 9: Address Assignment of Communication Channels demonstrated at Communication Channel Table 10: Input Data Image Table 11: Output Data Image Table 12: General Structure of Packets for non-cyclic Data Exchange Table 13: Status and Error Codes Table 14: Channel Mailboxes Table 15: Common Status Structure Definition Table 16: Communication State of Change Table 17: Extended Status Block Table 18: Extended Status Block Device Control Table 19: Extended Status Block Device Status Table 20: Extended Status Block Topology Status Table 21: Extended Status Block Inactive Port Table 22: Extended Status Block - Timing Interrupts Table 23: Communication Control Block Table 24: Telegram Parameters Table 25: Timing Parameters Table 26: Meaning and allowed Values for Warmstart Parameters Table 27: State of STA-LED depending on Communication mode Table 28: Names of Queues in SERCOS III Slave Firmware Table 29: SERCOSIII_SL_AP_WARMSTART_REQ_T Set Warmstart Parameters Table 30: SERCOSIII_SL_AP_WARMSTART_REQ Packet Status/Error Table 31: SERCOSIII_SL_AP_ACCESSIDN_IND_T Access to IDN within Object Dictionary Table 32: SERCOSIII_SL_AP_ACCESSIDN_IND_T Packet Status/Error Table 33: Meaning of Parameter ulaccessmask Table 34: Meaning of Parameter ulerrorcode Table 35: SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_T Get Watchdog Time Table 36: SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_T Packet Status/Error Table 37: SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_T Set Watchdog Time Table 38: SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_T Packet Status/Error Table 39: SERCOSIII_SL_AP_CMD_READY_FOR_CPS_REQ - Ready for Communication Phase Switching Request Table 40: SERCOSIII_SL_AP_CMD_READY_FOR_CPS_REQ - Packet Status/Error Table 41: SERCOSIII_SL_AP_CMD_CHANGE_SLAVE_STATE_REQ - Change Slave State Request Table 42: SERCOSIII_SL_AP_CMD_CHANGE_SLAVE_STATE_REQ - Packet Status/Error Table 43: SERCOSIII_SL_AP_CMD_HOST_READY_REQ - Host-Ready Changed Request Table 44: SERCOSIII_SL_AP_CMD_HOST_READY_REQ - Packet Status/Error Table 45: SERCOSIII_SL_AP_SET_COMM_ERR_IND - Communication Error Indication Table 46: SERCOSIII_SL_AP_SET_COMM_ERR_IND -Packet Status/Error Table 47: SERCOSIII_SL_AP_CMD_SET_TIMING_PARAMETER_IND Change of Timing Parameters Indication Table 48: SERCOSIII_SL_AP_CMD_SET_TIMING_PARAMETER_IND Packet Status/Error Table 49: SERCOS III Slave AP Task Status/Error Codes Overview Table 50: SERCOS III Slave RTD Task Status/Error Codes Overview...75 Table 51: SERCOS III Slave SVC Task Status/Error Codes Overview...75 Table 52: SERCOS III Slave COM Task Status/Error Codes Overview Table 53: Available Elements of an IDN Table 54: Available Elements of an IDN - Symbolic Names and corresponding numeric Values Table 55: Read and Write Access Table 56: Coding of Attribute Information in IDN Table 57: IDNs used in SERCOS III... 86

8 SERCOS III Slave Introduction 8 1 Introduction 1.1 Abstract This manual describes the user interface of the SERCOS III Slave Device implementation on the netx chip. The aim of this manual is to support the integration of devices based on the netx chip into own applications based on driver functions or direct access to the dual-port memory. The general mechanism of data transfer, for example how to send and receive a packet or how to perform a warmstart is independent from the protocol. These procedures are common to all devices and are described in the netx DPM Interface manual 1.2 System Requirements This description has following system requirements to its environment: netx-chip as CPU hardware platform 1.3 Intended Audience This manual is suitable for software developers with the following background: Knowledge of the programming language C Knowledge of the use of the real-time operating system rcx Knowledge of the Hilscher Task Layer Reference Model

9 SERCOS III Slave Introduction Specifications The data below applies to SERCOS III Slave firmware and stack version The firmware and stack has been written in order to meet the SERCOS III V1.1 specification Technical Data Maximum number of cyclic input data 200 bytes (including Device Control and Connection Control) Maximum number of cyclic output data 200 bytes Maximum number of applicable device addresses 1 Minimum cycle time 250 µs (including Device Status and Connection Control) Topology Acyclic communication (Service Channel) Communication phases Baud rate Line and ring Read/Write/Standard Commands NRT, CP0, CP1, CP2, CP3, CP4 100 MBit/s Data transport layer Ethernet II, IEEE Supported SERCOS III version: Communication Specification Version 1.1 Configuration Configuration by packet to transfer warm start parameters. Diagnostic Firmware supports common diagnostic in the dual-port-memory for loadable firmware.

10 SERCOS III Slave Introduction Limitations NRT-Channel is not supported. Cross communication not supported. Only MDT0/1 AT0/1 in CP1 and CP2 supported. The following error codes in the Service Channel are not supported yet: 0x7006 operation data is smaller than the minimum input data 0x7007 operation data is greater than the minimum input data 0x7008 invalid operation data, invalid bit number or bit combination 0x7009 operation data is write protected by a password 0x700A operation data is write protected cause of its configured cyclically 0x700B invalid indirect addressing (e.g. list handling, data container) 0x700C operation data is write protected, due to other settings 0x7010 procedure command already active 0x7011 procedure command not interruptible 0x7012 procedure command at this time not executable 0x7013 procedure command not executable The Object Dictionary for Service Channel Data is currently located on the netx/ap-task. The Real-Time-Bits are not supported. The Error-LED not supported. Modifications of the Service-Channel Object Dictionary are volatile after reset. Hot plugging is not supported.

11 SERCOS III Slave Introduction Terms, Abbreviations and Definitions Term Description xmac x Medium-Access Controller xpec x Protocol-Execution-Controller ARM 32 Bit CPU, part of the netx SERCOS Serial Realtime Communication System CP SERCOS Communication Phase AP (-task) Application (-task) on top of the stack DPM Dual Port Memory SVC Service Channel OD (Service Channel) Object Dictionary IDN Ident number Con_Clk Controller Clock Div_Clk Divided Control Clock NRT Channel Non realtime channel MDT Master Data Telegram AT Drive Telegram t 1 t 3 t 4 t 6 t 7 Table 1: Terms, Abbreviations and Definitions AT transmission starting time Command value valid time Feedback acquisition capture point Begin of NRT channel End of NRT channel All variables, parameters, and data used in this manual have the LSB/MSB ( Intel ) data format. This corresponds to the convention of the Microsoft C Compiler. The ARM-Core of the netx is able to work in Little-Endian or Big-Endian mode. Only the Little-Endian mode is used for SERCOS III. 1.6 References This document based on the following specifications: 1 Task Layer Reference Manual, Hilscher GmbH, cifx Device Driver; Hilscher GmbH; cifx Device Driver - Driver Manual; Hilscher GmbH; DPM Interface Manual for netx based products; Hilscher GmbH; IEC Type 16 & Type 19 6 SERCOS III Communication_V IEEE CSMA/CD Table 2: References

12 SERCOS III Slave Fundamentals 12 2 Fundamentals 2.1 General Access Mechanisms on netx Systems This chapter explains the possible ways to access a Protocol Stack running on a netx system : 1. By accessing the Dual Port Memory Interface directly or via a driver. 2. By accessing the Dual Port Memory Interface via a shared memory. 3. By interfacing with the Stack Task of the Protocol Stack. The picture below visualizes these three ways: 1 2 (Extended) Status Block Send Mailbox Reveive Mailbox Output Data Image Input Data Image AP Task 3 Fieldbus Task(s) Network Abstraction Layer Network Figure 1: The 3 different Ways to access a Protocol Stack running on a netx System This chapter explains how to program the stack (alternative 3) correctly while the next chapter describes accessing the protocol stack via the dual-port memory interface according to alternative 1 (and 2, if the user application is executed on the netx chip in the context of the rcx operating system and uses the shared DPM). Finally, chapter 5 titled The Application Interface describes the entire interface to the protocol stack in detail. Depending on you choose the stack-oriented approach or the Dual Port Memory-based approach, you will need either the information given in this chapter or those of the next chapter to be able to work with the set of functions described in chapter 5. All of those functions use the four parameters uldest, ulsrc, uldestid and ulsrcid. This chapter and the next one inform about how to work with these important parameters.

13 SERCOS III Slave Fundamentals Accessing the Protocol Stack by Programming the AP Task s Queue In general, programming the AP task or the stack has to be performed according to the rules explained in the Hilscher Task Layer Reference Manual. There you can also find more information about the variables discussed in the following Getting the Receiver Task Handle of the Process Queue To get the handle of the process queue of the SERCOS III Device AP--Task the Macro TLR_QUE_IDENTIFY() needs to be used. It is described in detail within section of the Hilscher Task Layer Reference Model Manual. This macro delivers a pointer to the handle of the intended queue to be accessed (which is returned within the third parameter, phque), if you provide it with the name of the queue (and an instance of your own task). The correct ASCII-queue names for accessing the SERCOS III Device AP--Task which you have to use as current value for the first parameter (pszidn) is ASCII Queue name "QUE_S3_SL_AP Description Name of the SERCOS III Device AP-Task process queue Table 3: Names of Queues in EtherNet/IP Firmware The returned handle has to be used as value uldest in all initiator packets the AP-Task intends to send to the SERCOS III Device AP -Task. This handle is the same handle that has to be used in conjunction with the macros like TLR_QUE_SENDPACKET_FIFO/LIFO() for sending a packet to the respective task Meaning of Source- and Destination-related Parameters The meaning of the source- and destination-related parameters is explained in the following table: Variable uldest ulsrc ulsrcid Meaning Application mailbox used for confirmation Queue handle returned by TLR_QUE_IDENTIFY() as described above. Used for addressing at a lower level Table 4: Meaning of Source- and Destination-related Parameters. For more information about programming the AP task s stack queue, please refer to the Hilscher Task Layer Reference Model Manual. Especially the following sections might be of interest in this context: 1. Chapter 7 Queue-Packets 2. Section Queuing Mechanism

14 SERCOS III Slave Fundamentals Accessing the Protocol Stack via the Dual Port Memory Interface This chapter defines the application interface of the EtherNet/IP-Adapter Stack Communication via Mailboxes The mailbox of each communication channel has two areas that are used for non-cyclic message transfer to and from the netx. Send Mailbox Packet transfer from host system to netx firmware Receive Mailbox Packet transfer from netx firmware to host system For more details about acyclic data transfer via mailboxes see section 3.2. Acyclic Data (Mailboxes) in this context, is described in detail in section General Structure of Messages or Packets for Non- Cyclic Data Exchange while the possible codes that may appear are listed in section Status & Error Codes. However, this section concentrates on correct addressing the mailboxes.

15 SERCOS III Slave Fundamentals Using Source and Destination Variables correctly How to use uldest for Addressing rcx and the netx Protocol Stack by the System and Channel Mailbox The preferred way to address the netx operating system rcx is through the system mailbox; the preferred way to address a protocol stack is through its channel mailbox. All mailboxes, however, have a mechanism to route packets to a communication channel or the system channel, respectively. Therefore, the destination identifier uldest in a packet header has to be filled in according to the targeted receiver. See the following example: uldest = 0x20 uldest = 0x00 uldest = 0x01 uldest = 0x02 uldest = 0x20 uldest = 0x00 uldest = 0x01 uldest = 0x02 uldest = 0x20 uldest = 0x00 uldest = 0x01 uldest = 0x02 System Mailbox Channel 0 Mainbox Channel 1 Mailbox netx OS rcx AP Task 1 AP Task 2 Figure 2: Use of uldest in Channel and System Mailbox For use in the destination queue handle, the tasks have been assigned to hexadecimal numerical values as described in the following table: uldest Description 0x Packet is passed to the netx operating system rcx 0x Packet is passed to communication channel 0 0x Packet is passed to communication channel 1 0x Packet is passed to communication channel 2 0x Packet is passed to communication channel 3 0x Packet is passed to communication channel of the mailbox else Reserved, do not use Table 5: Meaning of Destination-Parameter uldest. The figure and the table above both show the use of the destination identifier uldest.

16 SERCOS III Slave Fundamentals 16 A remark on the special channel identifier 0x (= Channel Token). The Channel Token is valid for any mailbox. That way the application uses the same identifier for all packets without actually knowing which mailbox or communication channel is applied. The packet stays 'local'. The system mailbox is a little bit different, because it is used to communicate to the netx operating system rcx. The rcx has its own range of valid commands codes and differs from a communication channel. Unless there is a reply packet, the netx operating system returns it to the same mailbox the request packet went through. Consequently, the host application has to return its reply packet to the mailbox the request was received from How to use ulsrc and ulsrcid Generally, a netx protocol stack can be addressed through its communication channel mailbox. The example below shows how a host application addresses a protocol stack running in the context of a netx chip. The application is identified by a number (#444 in this example). The application consists of three processes identified by the numbers #11, #22 and #33. These processes communicate through the channel mailbox with the AP task of the protocol stack. Have a look at the following figure: Application #444 Process #11 Process #22 Process #33 Channel Mainbox netx Protocol stack AP Task 1 Figure 3: Using ulsrc and ulsrcid

17 SERCOS III Slave Fundamentals 17 Example: This example applies to command messages initiated by a process in the context of the host application. If the process #22 sends a packet through the channel mailbox to the AP task, the packet header has to be filled in as follows: Object Variable Name Numeric Value Explanation Destination Queue Handle uldest = 32 (0x ) This value needs always to be set to 0x (the channel token) when accessing the protocol stack via the local communication channel mailbox. Source Queue Handle Destination Identifier ulsrc = 444 Denotes the host application (#444). uldestid = 0 In this example it is not necessary to use the destination identifier. Source Identifier ulsrcid = 22 Denotes the process number of the process within the host application and needs therefore to be supplied by the programmer of the host application. Table 6: Example for correct Use of Source- and Destination-related Parameters. For packets through the channel mailbox, the application uses 32 (= 0x20, Channel Token) for the destination queue handler uldest. The source queue handler ulsrc and the source identifier ulsrcid are used to identify the originator of a packet. The destination identifier uldestid can be used to address certain resources in the protocol stack. It is not used in this example. The source queue handler ulsrc has to be filled in. Therefore its use is mandatory; the use of ulsrcid is optional. The netx operating system passes the request packet to the protocol stack's AP task. The protocol stack then builds a reply to the packet and returns it to the mailbox. The application has to make sure that the packet finds its way back to the originator (process #22 in the example) How to Route rcx Packets To route an rcx packet the source identifier ulsrcid and the source queues handler ulsrc in the packet header hold the identification of the originating process. The router saves the original handle from ulsrcid and ulsrc. The router uses a handle of its own choices for ulsrcid and ulsrc before it sends the packet to the receiving process. That way the router can identify the corresponding reply packet and matches the handle from that packet with the one stored earlier. Now the router replaces its handles with the original handles and returns the packet to the originating process.

18 SERCOS III Slave Fundamentals Obtaining useful Information about the Communication Channel A communication channel represents a part of the Dual Port Memory and usually consists of the following elements: Output Data Image is used to transfer cyclic process data to the network (normal or high-priority) Input Data Image is used to transfer cyclic process data from the network (normal or high-priority) Send Mailbox is used to transfer non-cyclic data to the netx Receive Mailbox is used to transfer non-cyclic data from the netx Control Block allows the host system to control certain channel functions Common Status Block holds information common to all protocol stacks Extended Status Block holds protocol specific network status information This section describes a procedure how to obtain useful information for accessing the communication channel(s) of your netx device and to check if it is ready for correct operation. Proceed as follows: 1) Start with reading the channel information block within the system channel (usually starting at address 0x0030). 2) Then you should check the hardware assembly options of your netx device. They are located within the system information block following offset 0x0010 and stored as data type UINT16. The following table explains the relationship between the offsets and the corresponding xc Ports of the netx device: 0x0010 0x0012 0x0014 Hardware Assembly Options for xc Port[0] Hardware Assembly Options for xc Port[1] Hardware Assembly Options for xc Port[2] 0x0016 Table 7: Address Assignment of Hardware Assembly Options Hardware Assembly Options for xc Port[3] Check each of the hardware assembly options whether its value has been set to RCX_HW_ASSEMBLY_ETHERNET = 0x0080. If true, this denotes that this xcport is suitable for running the SERCOS III slave protocol stack. Otherwise, this port is designed for another communication protocol. In most cases, xc Port[2] will be used for field-bus systems, while xc Port[0] and xc Port[1] are normally used for Ethernet communication.

19 SERCOS III Slave Fundamentals 19 3) You can find information about the corresponding communication channel (0 3) under the following addresses: 0x0050 Communication Channel 0 0x0060 Communication Channel 1 0x0070 Communication Channel 2 0x0080 Communication Channel 3 Table 8: Addressing Communication Channel 0-3 In devices which support only one communication system which is usually the case (either a single field-bus system or a single standard for Industrial-Ethernet communication), always communication channel 0 will be used. In devices supporting more than one communication system you should also check the other communication channels. 4) There you can find such information as the ID (containing channel number and port number) of the communication channel, the size and the location of the handshake cells, the overall number of blocks within the communication channel and the size of the channel in bytes. Evaluate this information precisely in order to access the communication channel correctly. The information is delivered as follows: Size of Channel in Bytes Address Data Type Description 0x0050 UINT8 Channel Type = COMMUNICATION (must have the fixed value define RCX_CHANNEL_TYPE_COMMUNICATION = 0x05) 0x0051 UINT8 ID (Channel Number, Port Number) 0x0052 UINT8 Size / Position Of Handshake Cells 0x0053 UINT8 Total Number Of Blocks Of This Channel 0x0054 UINT32 Size Of Channel In Bytes 0x0058 UINT8[8] Reserved (set to zero) Table 9: Address Assignment of Communication Channels demonstrated at Communication Channel 0 These addresses correspond to communication channel 0, for communication channels 1, 2 and 3 you have to add an offset of 0x0010, 0x0020 or 0x0030 to the address values, respectively. 5) Finally, you can access the communication channel using the addresses you determined previously. For more information how to do this, please refer to the netx DPM Manual, especially section 3.2 Communication Channel".

20 SERCOS III Slave Dual-Port Memory 20 3 Dual-Port Memory All data in the dual-port memory is structured in blocks. According to their functions, these blocks use different data transfer mechanisms. For example, data transfer through mailboxes uses a synchronized handshake mechanism between host system and netx firmware. The same is true for IO data images, when a buffered handshake mode is configured. Other blocks, like the status block, are read by the host application and use no synchronization mechanism. Types of blocks in the dual-port memory are outlined below: Mailbox transfer non-cyclic messages or packages with a header for routing information Data Area holds the process image for cyclic IO data or user defined data structures Control Block is used to signal application related state to the netx firmware Status Block holds information regarding the current network state Change of State collection of flags, that initiate execution of certain commands or signal a change of state 3.1 Cyclic Data (Input/Output Data) The input block holds the process data image received from the network whereas the output block holds data sent to the network. Process data transfer through the data blocks can be synchronized by using a handshake mechanism. For the controlled / buffered mode, the protocol stack updates the process data in the internal input buffer for each valid bus cycle. Each IO block uses handshake bits for access synchronization. Input and output data block handshake operates independently from each other. When the application toggles the input handshake bit, the protocol stack copies the data from the internal buffer into the input data image of the dual-port memory. Now the application can copy data from the dual-port memory and then give control back to the protocol stack by toggling the appropriate input handshake bit. When the application/driver toggles the output handshake bit, the protocol stack copies the data from the output data image of the dual-port memory into the internal buffer. From there the data is transferred to the network. The protocol stack toggles the handshake bits back, indicating to the application that the transfer is finished and a new data exchange cycle may start. This mode guarantees data consistency over both input and output area.

21 SERCOS III Slave Dual-Port Memory Input Process Data The input data block is used by field-bus and industrial Ethernet protocols that utilize a cyclic data exchange mechanism. The input data image is used to receive cyclic data from the network. The default size of the input data image is 5760 byte. However, not all available space is actually used by the protocol stack. Depending on the specific protocol, the area actually available for user data might be much smaller than 5760 byte. An input data block may or may not be available in the dualport memory. It is always available in the default memory map (see the netx Dual-Port Memory Manual). Input Data Image Offset Type Name Description 0x2680 UINT8 abpd0input[5760] Input Data Image Table 10: Input Data Image Cyclic Data From The Network Output Process Data The output data block is used by field-bus- and industrial Ethernet protocols that utilize a cyclic data exchange mechanism. The output data Image is used to send cyclic data from the host to the network. The default size of the output data image is 5760 byte. However, not all available space is actually used by the protocol stack. Depending on the specific protocol, the area actually available for user data might be much smaller than 5760 byte. An output data block may or may not be available in the dual-port memory. It is always available in the default memory map (see netx DPM Manual). Output Data Image Offset Type Name Description 0x1000 UINT8 abpd0output[5760] Output Data Image Table 11: Output Data Image Cyclic Data To The Network

22 SERCOS III Slave Dual-Port Memory Acyclic Data (Mailboxes) The mailbox of each communication channel has two areas that are used for non-cyclic message transfer. Send Mailbox Packet transfer from host system to firmware Receive Mailbox Packet transfer from firmware to host system The send and receive mailbox areas are used by field-bus and industrial Ethernet protocols providing a non-cyclic data exchange mechanism. Another use of the mailbox system is to allow access to the firmware running on the netx chip itself for diagnostic and identification purposes. The send mailbox is used to transfer acyclic data to the network or to the firmware. The receive mailbox is used to transfer acyclic data from the network or from the firmware. A send/receive mailbox may or may not be available in the communication channel. It depends on the function of the firmware whether or not a mailbox is needed. The location of the system mailbox and the channel mailbox is described in the netx DPM Interface Manual. Note: Each mailbox can hold one packet at a time. The netx firmware stores packets that are not retrieved by the host application in a packet queue. This queue has limited space and may fill up so new packets maybe lost. To avoid these data loss situations, it is strongly recommended to empty the mailbox frequently, even if packets are not expected by the host application. Unexpected command packets should be returned to the sender with an Unknown Command in the status field; unexpected reply messages can be discarded.

23 SERCOS III Slave Dual-Port Memory General Structure of Messages or Packets for Non-Cyclic Data Exchange The non-cyclic packets through the netx mailbox have the following structure: Structure Information Area Variable Type Value / Range Description Head Structure Information uldest UINT32 Destination Queue Handle ulsrc UINT32 Source Queue Handle uldestid UINT32 Destination Queue Reference ulsrcid UINT32 Source Queue Reference ullen UINT32 Packet Data Length (In Bytes) ulid UINT32 Packet Identification As Unique Number ulsta UINT32 Status / Error Code ulcmd UINT32 Command / Response ulext UINT32 Extension Flags ulrout UINT32 Routing Information Data Structure Information User Data Specific To The Command Table 12: General Structure of Packets for non-cyclic Data Exchange. Some of the fields are mandatory; some are conditional; others are optional. However, the size of a packet is always at least 10 double-words or 40 bytes. Depending on the command, a packet may or may not have a data field. If present, the content of the data field is specific to the command, respectively the reply. Destination Queue Handle The uldest field identifies a task queue in the context of the netx firmware. The task queue represents the final receiver of the packet and is assigned to a protocol stack. The uldest field has to be filled out in any case. Otherwise, the netx operating system cannot route the packet. This field is mandatory. Source Queue Handle The ulsrc field identifies the sender of the packet. In the context of the netx firmware (inter-task communication) this field holds the identifier of the sending task. Usually, a driver uses this field for its own handle, but it can hold any handle of the sending process. Using this field is mandatory. The receiving task does not evaluate this field and passes it back unchanged to the originator of the packet.

24 SERCOS III Slave Dual-Port Memory 24 Destination Identifier The uldestid field identifies the destination of an unsolicited packet from the netx firmware to the host system. It can hold any handle that helps to identify the receiver. Therefore, its use is mandatory for unsolicited packets. The receiver of unsolicited packets has to register for this. Source Identifier The ulsrcid field identifies the originator of a packet. This field is used by a host application, which passes a packet from an external process to an internal netx task. The ulsrcid field holds the handle of the external process. When netx operating system returns the packet, the application can identify the packet and returns it to the originating process. The receiving task on the netx does not evaluate this field and passes it back unchanged. For inter-task communication, this field is not used. Length of Data Field The ullen field holds the size of the data field in bytes. It defines the total size of the packet s payload that follows the packet s header. The size of the header is not included in ullen. So the total size of a packet is the size from ullen plus the size of packet s header. Depending on the command, a data field may or may not be present in a packet. If no data field is included, the length field is set to zero. Identifier The ulid field is used to identify a specific packet among others of the same kind. That way the application or driver can match a specific reply or confirmation packet to a previous request packet. The receiving task does not change this field and passes it back to the originator of the packet. Its use is optional in most of the cases. But it is mandatory for sequenced packets. Example: Downloading big amounts of data that does not fit into a single packet. For a sequence of packets the identifier field is incremented by one for every new packet. Status / Error Code The ulsta field is used in response or confirmation packets. It informs the originator of the packet about success or failure of the execution of the command. The field may be also used to hold status information in a request packet. Command / Response The ulcmd field holds the command code or the response code, respectively. The command/response is specific to the receiving task. If a task is not able to execute certain commands, it will return the packet with an error indication. A command is always even (the least significant bit is zero). In the response packet, the command code is incremented by one indicating a confirmation to the request packet. Extension Flags The extension field ulext is used for controlling packets that are sent in a sequenced manner. The extension field indicates the first, last or a packet of a sequence. If sequencing is not required, the extension field is not used and set to zero.

25 SERCOS III Slave Dual-Port Memory 25 Routing Information The ulrout field is used internally by the netx firmware only. It has no meaning to a driver type application and therefore set to zero. User Data Field This field contains data related to the command specified in ulcmd field. Depending on the command, a packet may or may not have a data field. The length of the data field is given in the ullen field Status & Error Codes The following status and error codes can be returned in ulsta: Status and Error Codes Code (Symbolic Constant) Numerical Value Meaning RCX_S_OK 0x SUCCESS, STATUS OKAY RCX_S_QUE_UNKNOWN 0xC02B0001 UNKNOWN QUEUE RCX_S_QUE_INDEX_UNKNOWN 0xC02B0002 UNKNOWN QUEUE INDEX RCX_S_TASK_UNKNOWN 0xC02B0003 UNKNOWN TASK RCX_S_TASK_INDEX_UNKNOWN 0xC02B0004 UNKNOWN TASK INDEX RCX_S_TASK_HANDLE_INVALID 0xC02B0005 INVALID TASK HANDLE RCX_S_TASK_INFO_IDX_UNKNOWN 0xC02B0006 UNKNOWN INDEX RCX_S_FILE_XFR_TYPE_INVALID 0xC02B0007 INVALID TRANSFER TYPE RCX_S_FILE_REQUEST_INCORRECT 0xC02B0008 INVALID FILE REQUEST RCX_S_UNKNOWN_DESTINATION 0xC UNKNOWN DESTINATION RCX_S_UNKNOWN_DESTINATION_ID 0xC UNKNOWN DESTINATION ID RCX_S_INVALID_LENGTH 0xC INVALID LENGTH RCX_S_UNKNOWN_COMMAND 0xC UNKNOWN COMMAND RCX_S_INVALID_EXTENSION 0xC INVALID EXTENSION Table 13: Status and Error Codes Differences between System and Channel Mailboxes The mailbox system on netx provides a non-cyclic data transfer channel for field-bus and industrial Ethernet protocols. Another use of the mailbox is allowing access to the firmware running on the netx chip itself for diagnostic purposes. There is always a send and a receive mailbox. Send and receive mailboxes utilize handshake bits to synchronize these data or diagnostic packages through the mailbox. There is a pair of handshake bits for both the send and receive mailbox. The netx operating system rcx only uses the system mailbox. The system mailbox, however, has a mechanism to route packets to a communication channel. A channel mailbox passes packets to its own protocol stack only.

26 SERCOS III Slave Dual-Port Memory Send Mailbox The send mailbox area is used by protocols utilizing a non-cyclic data exchange mechanism. Another use of the mailbox system is to provide access to the firmware running on the netx chip itself. The send mailbox is used to transfer non-cyclic data to the network or to the protocol stack. The size is 1596 bytes for the send mailbox in the default memory layout. The mailbox is accompanied by counters that hold the number of packages that can be accepted Receive Mailbox The receive mailbox area is used by protocols utilizing a non-cyclic data exchange mechanism. Another use of the mailbox system is to provide access to the firmware running on the netx chip itself. The receive mailbox is used to transfer non-cyclic data from the network or from the protocol stack. The size is 1596 bytes for the receive mailbox in the default memory layout. The mailbox is accompanied by counters that hold the number of waiting packages (for the receive mailbox) Channel Mailboxes (Details of Send and Receive Mailboxes) Master Status Offset Type Name Description 0x0200 UINT16 uspackagesaccepted Packages Accepted 0x0202 UINT16 usreserved Reserved Number of Packages that can be Accepted Set to 0 0x0204 UINT8 absendmbx[ 1596 ] Send Mailbox 0x0840 UINT16 uswaitingpackages 0x0842 UINT16 usreserved 0x0844 UINT8 abrecvmbx[ 1596 ] Table 14: Channel Mailboxes. Non Cyclic Data To The Network or to the Protocol Stack Packages waiting Counter of packages that are waiting to be processed Reserved Set to 0 Receive Mailbox Non Cyclic Data from the network or from the protocol stack

27 SERCOS III Slave Dual-Port Memory 27 Channel Mailboxes Structure typedef struct tagnetx_send_mailbox_block { UINT16 uspackagesaccepted; UINT16 usreserved; UINT8 absendmbx[ 1596 ]; } NETX_SEND_MAILBOX_BLOCK; typedef struct tagnetx_recv_mailbox_block { UINT16 uswaitingpackages; UINT16 usreserved; UINT8 abrecvmbx[ 1596 ]; } NETX_RECV_MAILBOX_BLOCK; 3.3 Status A status block is present within the communication channel. It contains information about network and task related issues. In some respects, status and control block are used together in order to exchange information between host application and netx firmware. The application reads a status block whereas the control block is written by the application. Both status and control block have registers that use the Change of State mechanism (see also section Getting the Receiver Task Handle of the Process Queue ) Common Status The Common Status Block contains information that is the same for all communication channels. The start offset of this block depends on the size and location of the preceding blocks. The status block is always present in the dual-port memory All Implementations The structure outlined below is common to all protocol stacks. Common Status Structure Definition Common Status Offset Type Name Description 0x0010 UINT32 ulcommunicationcos Communication Change of State READY, RUN, RESET REQUIRED, NEW, CONFIG AVAILABLE, CONFIG LOCKED 0x0014 UINT32 ulcommunicationstate Communication State NOT CONFIGURED, STOP, IDLE, OPERATE 0x0018 UINT32 ulcommunicationerror Communication Error Unique Error Number According to Protocol Stack (not supported yet)

28 SERCOS III Slave Dual-Port Memory 28 0x001C UINT16 usversion Version Version Number of this Diagnosis Structure 0x001E UINT16 uswatchdogtime Watchdog Timeout Configured Watchdog Time 0x0020 UINT16 ausprotocolclass[2] Protocol Class MASTER, SLAVE, CLIENT, SERVER, GATEWAY... 0x0024 UINT32 ulhostwatchdog Host Watchdog Joint Supervision Mechanism Protocol Stack Writes, Host System Reads 0x0028 UINT32 ulerrorcount Error Count Total Number of Detected Error Since Power-Up or Reset 0x002C UINT32 ulerrorloglnd Error Log Indicator 0x0030 UINT32 ulreserved[2] Reserved Total Number Of Entries In The Error Log Structure (not supported yet) Table 15: Common Status Structure Definition Set to 0 Common Status Block Structure Reference typedef struct NETX_COMMON_STATUS_BLOCK_Ttag { UINT32 ulcommunicationcos; UINT32 ulcommunicationstate; UINT32 ulcommunicationerror; UINT16 usversion; UINT16 uswatchdogtime; UINT16 ausprotocolclass[2]; UINT32 ulhostwatchdog; UINT32 ulerrorcount; UINT32 ulerrorlogind; UINT32 ulreserved[2]; union { NETX_MASTER_STATUS_T tmasterstatus; /* for master implementation */ UINT32 aulreserved[6]; /* otherwise reserved */ } unstackdepended; } NETX_COMMON_STATUS_BLOCK_T;

29 SERCOS III Slave Dual-Port Memory 29 Communication Change of State (All Implementations) The communication change of state register contains information about the current operating status of the communication channel and its firmware. Every time the status changes, the netx protocol stack toggles the netx Change of State Command flag in the netx communication flags register (see section of the netx DPM Interface Manual). The application then has to toggle the netx Change of State Acknowledge flag back acknowledging the new state (see section of the netx DPM Interface Manual). ulcommunicationcos - netx writes, Host reads unused, set to zero Table 16: Communication State of Change COMM_COS_READY COMM_COS_RUN COMM_COS_BUS_ON COMM_COS_CONFIG_LOCKED (not supported yet) COMM_COS_CONFIG_NEW COMM_COS_RESTART_REQUIRED COMM_COS_RESTART_REQUIRED_ENABLE Communication Change of State Flags (netx System Application) READY #define RCX_COMM_COS_READY 0x The Ready flag is set as soon as the protocol stack is started properly. Then the protocol stack is awaiting a configuration. As soon as the protocol stack is configured properly, the Running flag is set, too. RUNNING #define RCX_COMM_COS_RUN 0x The Running flag is set when the protocol stack has been configured properly. Then the protocol stack is awaiting a network connection. Now both the Ready flag and the Running flag are set. BUS ON #define RCX_COMM_COS_BUS_ON 0x The Bus On flag is set to indicate to the host system whether or not the protocol stack has the permission to open network connections. If set, the protocol stack has the permission to communicate on the network; if cleared, the permission was denied and the protocol stack will not open network connections. CONFIGURATION LOCKED #define RCX_COMM_COS_CONFIG_LOCKED 0x The Configuration Locked flag is set, if the communication channel firmware has locked the configuration database against being overwritten. Re-initializing the channel is not allowed in this state. To unlock the database, the application has to clear the Lock Configuration flag in the control block (see section of the netx DPM Interface Manual). The flag is defined, but not supported yet. CONFIGURATION NEW #define RCX_COMM_COS_CONFIG_NEW 0x The Configuration New flag is set by the protocol stack to indicate that a new configuration became available, which has not been activated. This flag may be set together with the Restart Required flag.

30 SERCOS III Slave Dual-Port Memory 30 RESTART REQUIRED #define RCX_COMM_COS_RESTART_REQUIRED 0x The Restart Required flag is set when the channel firmware requests to be restarted. This flag is used together with the Restart Required Enable flag below. Restarting the channel firmware may become necessary, if a new configuration was downloaded from the host application or if a configuration upload via the network took place. RESTART REQUIRED ENABLE #define RCX_COMM_COS_RESTART_REQUIRED_ENABLE 0x The Restart Required Enable flag is used together with the Restart Required flag above. If set, this flag enables the execution of the Restart Required command in the netx firmware (for details on the Enable mechanism, see section of the netx DPM Interface Manual). Other values are reserved. Communication State (All Implementations) The communication state field contains information regarding the current network status of the communication channel. Depending on the implementation, all or a subset of the definitions below is supported. UNKNOWN #define RCX_COMM_STATE_UNKNOWN 0x OFFLINE #define RCX_COMM_STATE_OFFLINE 0x STOP #define RCX_COMM_STATE_STOP 0x IDLE #define RCX_COMM_STATE_IDLE 0x OPERATE #define RCX_COMM_STATE_OPERATE 0x Communication Channel Error (All Implementations) This field holds the current error code of the communication channel. If the cause of error is resolved, the communication error field is set to zero (= RCX_COMM_SUCCESS) again. Not all of the error codes are supported in every implementation. Protocol stacks may use a subset of the error codes below. SUCCESS #define RCX_COMM_SUCCESS 0x Runtime Failures WATCHDOG TIMEOUT #define RCX_COMM_WATCHDOG_TIMEOUT 0xC000000C Initialization Failures (General) INITIALIZATION FAULT #define RCX_COMM_INIT_FAULT 0xC DATABASE ACCESS FAILED #define RCX_COMM_DATABASE_ACCESS_FAILED 0xC Configuration Failures (General) CONFIGURATION FAULT #define RCX_COMM_CONFIGURATION_FAULT 0xC INCONSISTENT DATA SET #define RCX_COMM_INCONSISTENT_DATA_SET 0xC DATA SET MISMATCH #define RCX_COMM_DATA_SET_MISMATCH 0xC INSUFFICIENT LICENSE #define RCX_COMM_INSUFFICIENT_LICENSE 0xC PARAMETER ERROR #define RCX_COMM_PARAMETER_ERROR 0xC

31 SERCOS III Slave Dual-Port Memory 31 INVALID NETWORK ADDRESS #define RCX_COMM_INVALID_NETWORK_ADDRESS 0xC Network Failures (General) NETWORK FAULT #define RCX_COMM_NETWORK_FAULT 0xC CONNECTION CLOSED #define RCX_COMM_CONNECTION_CLOSED 0xC CONNECTION TIMED OUT #define RCX_COMM_CONNECTION_TIMEOUT 0xC LONELY NETWORK #define RCX_COMM_LONELY_NETWORK 0xC DUPLICATE NODE #define RCX_COMM_DUPLICATE_NODE 0xC CABLE DISCONNECT #define RCX_COMM_CABLE_DISCONNECT 0xC Version (All Implementations) The version field holds version of this structure. It starts with one; zero is not defined. STRUCTURE VERSION #define RCX_STATUS_BLOCK_VERSION 0x0001 Watchdog Timeout (All Implementations) This field holds the configured watchdog timeout value in milliseconds. The application may set its watchdog trigger interval accordingly. If the application fails to copy the value from the host watchdog location to the device watchdog location, the protocol stack will interrupt all network connections immediately regardless of their current state. For details, see section 4.13 of the netx DPM Interface Manual. Protocol Class (All Implementations) This field identifies the protocol class of the communication channel. The field is split into a communication class field and communication sub class field. The first array element represents the communication class; the second element is the communication sub class. Communication Class This array element holds further information regarding the protocol stack. It is intended to help identifying the 'communication class' or 'device class' of the protocol. UNDEFINED #define RCX_COMM_CLASS_UNDEFINED 0x0000 UNCLASSIFIABLE #define RCX_COMM_CLASS_UNCLASSIFIABLE 0x0001 MASTER #define RCX_COMM_CLASS_MASTER 0x0002 SLAVE #define RCX_COMM_CLASS_SLAVE 0x0003 SCANNER #define RCX_COMM_CLASS_SCANNER 0x0004 ADAPTER #define RCX_COMM_CLASS_ADAPTER 0x0005 MESSAGING #define RCX_COMM_CLASS_MESSAGING 0x0006 CLIENT #define RCX_COMM_CLASS_CLIENT 0x0007 SERVER #define RCX_COMM_CLASS_SERVER 0x0008 IO-CONTROLLER #define RCX_COMM_CLASS_IO_CONTROLLER 0x0009 IO-Device #define RCX_COMM_CLASS_IO_Device 0x000A IO-SUPERVISOR #define RCX_COMM_CLASS_IO_SUPERVISOR 0x000B GATEWAY #define RCX_COMM_CLASS_GATEWAY 0x000C

32 SERCOS III Slave Dual-Port Memory 32 MONITOR #define RCX_COMM_CLASS_MONITOR 0x000D PRODUCER #define RCX_COMM_CLASS_PRODUCER 0x000E CONSUMER #define RCX_COMM_CLASS_CONSUMER 0x000F SWITCH #define RCX_COMM_CLASS_SWITCH 0x0010 HUB #define RCX_COMM_CLASS_HUB 0x0011 Other values are reserved. Communication Sub Class The communication sub class of a device is determined by the implementation and therefore described in a separate manual. UNDEFINED #define RCX_COMM_SUB_CLASS_UNDEFINED 0x0000 UNCLASSIFIABLE #define RCX_COMM_SUB_CLASS_UNCLASSIFIABLE 0x0001 NOT USED #define RCX_COMM_SUB_CLASS_NOT_USED 0x0002 Others are determined by the protocol stack and therefore defined in a separate manual. Host Watchdog (All Implementations) The protocol stack supervises the host system using the watchdog function. If the application fails to copy the value from the device watchdog location (section of the netx DPM Interface Manual) to the host watchdog location (section of the netx DPM Interface Manual), the protocol stack assumes that the host system has some sort of problem and shuts down all network connections. For details on the watchdog function, refer to section 4.13 of the netx DPM Interface Manual. Error Count (All Implementations) This field holds the total number of errors detected since power-up, respectively after reset. The protocol stack counts all sorts of errors in this field no matter if they were network related or caused internally. Error Log Indicator (All Implementations) Not supported yet: The error log indicator field holds the number of entries in the internal error log. If all entries are read from the log, the field is set to zero Master Implementation In addition to the common status block as outlined in the previous section, a master firmware maintains the additional structures for the administration of all slaves which are connected to the master. These are not discussed here as they are not relevant for the slave Slave Implementation The slave firmware uses only the common structure as outlined in section of the netx DPM Interface Manual for netx based Products. This is true for all protocol stacks.

33 SERCOS III Slave Dual-Port Memory Extended Status The content of the channel specific extended status block is specific to the implementation. Depending on the protocol, a status area may or may not be present in the dual-port memory. It is always available in the default memory map (see section of netx Dual-Port Memory Manual). Extended Status Block Offset Type Name Description 0x0350 UINT8 abextendedstatus[432] Extended Status Area Table 17: Extended Status Block Protocol Stack Specific Status Area Extended Status Block Structure typedef struct tagnetx_extended_status_block { UINT8 abextendedstatus[432]; } NETX_EXTENDED_STATUS_BLOC For SERCOS III, the extended status contains the current communication phase and all the complete (Real Time) Device Control and Device Status. This information is available during all Communication Phases (not only in CP4). The Device-Status contains all bits, also those which are generated by the stack. Figure 4: Extended Status in DPM Current CP This entry contains the currently active communication phase indicated by a value in the range 0 to 4. Phase switching is not indicated here.

34 SERCOS III Slave Dual-Port Memory 34 Device Control The Device Control word is sent from the master to the slaves along with the MDT. According to the SERCOS III specification, the Device Control entry has the following meaning: Extended Status Block Device Control Bit # of Device Control Description 15-8 Reserved for application profile 7 Real-time control bit 2 (corresponds to IDN S ) 6 Real-time control bit 1 (corresponds to IDN S ) 5-0 Reserved Table 18: Extended Status Block Device Control Connection Control This entry contains connection-specific data, see section 3.4. Device Status The Device Status word is sent from each slave back to the master along with its AT. According to the SERCOS III specification, the Device Status entry has the following meaning: Extended Status Block - Device Status Bit # of Device Control Description Reserved Topology status Inactive port 9 Reserved 8 Slave valid 7-0 Reserved Table 19: Extended Status Block Device Status

35 SERCOS III Slave Dual-Port Memory 35 The combinations of the topology status bits 12 and 13 have the following meaning: Bit 13 Bit 12 Meaning 0 0 Fast-forward on both ports 0 1 Loopback on P-Channel with forward 1 0 Loopback on S-Channel with forward 1 1 NRT mode Table 20: Extended Status Block Topology Status The combinations of the inactive port bits 10 and 11 have the following meaning: Bit 11 Bit 10 Meaning 0 0 No link on inactive port 0 1 Link on inactive port 1 0 P-telegram on inactive port 1 1 S-telegram on inactive port Table 21: Extended Status Block Inactive Port Connection Control This entry contains connection-specific data, see section 3.4. Timing Interrupts This entry signifies active timing interrupts. The assignment of the single bits to the interrupts is shown in the following table. Extended Status Block - Timing Interrupts Bit 31 Bit 30 Bit 29 Bits 28-0 Reserved t4 interrupt (Feedback acquisition capture point) t3 interrupt (Command value valid time) Con_Clk (Controller Clock) Table 22: Extended Status Block - Timing Interrupts

36 SERCOS III Slave Dual-Port Memory Control Block A control block is always present within the communication channel. In some respects, control and status block are used together in order to exchange information between host application and netx firmware. The control block is written by the application, whereas the application reads a status block. Both control and status block have registers that use the Change of State mechanism (see also section of the netx Dual-Port-Memory manual.) The following gives an example of the use of control and status block. The host application wishes to lock the configuration settings of a communication channel to protect them against changes. The application sets the Lock Configuration flag in the control block to the communication channel firmware. As a result, the channel firmware sets the Configuration Locked flag in the status block (see below), indicating that the current configuration settings cannot be deleted, altered, overwritten or otherwise changed. The control block of a dual-port memory features a watchdog function to allow the operating system running on the netx supervise the host application and vice versa. The control area is always present in the dual-port memory. Control Block Offset Type Name Description 0x0008 UINT32 ulapplicationcos Application Change Of State State Of The Application Program INITIALIZATION, LOCK CONFIGURATION 0x000C UINT32 uldevicewatchdog Device Watchdog Table 23: Communication Control Block Host System Writes, Protocol Stack Reads Communication Control Block Structure typedef struct tagnetx_control_block { UINT32 ulapplicationcos; UINT32 uldevicewatchdog; } NETX_CONTROL_BLOCK; For more information concerning the Control Block please refer to the netx DPM Interface Manual.

37 SERCOS III Slave General Topics 37 4 General Topics 4.1 The SERCOS III Stack Structure The stack consists of the following tasks: 1. AP-Task (Application) 2. SERCOS III-Device COM-Task (Communication) 3. SERCOS III-Device RTD-Task (Real-Time-Data) 4. SERCOS III-Device SVC-Task (Service channel) SERCOS-Parameters (IDNs) are handles by the netx. For small applications, the SERCOS-Parameters can be handled by the COM-Task. For the first step, a static parameter handling is acceptable SERCOS III-Device AP-Task The AP-Task performs the following functions: Initialization of the other SERCOS III stack tasks Initialization of the Dual-port-memory Handles the communication to the host system Provides the watchdog timer Handshake (HS modes) Diagnostic (TLR, Host) Packet with initialization parameters Access to Security EEPROM SERCOS III-Device COM-Task The COM-Task performs the following functions: Initializing the xc Initializing and starting the hardware with 100Mbit/s full duplex Topology address in CP0 Phase switching Working lists and preparation of the access to the realtime and service data Telegram handling SERCOS Telegram error handling Needs the following parameters to start: MAC-ID, Device Address Has access to xc Registers

38 SERCOS III Slave General Topics SERCOS III-Device RTD-Task The RTD-Task performs the following functions: Handles the Real-Time-Data by triple buffers (one triple buffer for input data, one triple buffer for output data) Has access to xc Registers SERCOS III-Device SVC-Task The SVC-Task performs the following functions: Handles the SERCOS III Service channel: Read/Write/Command Needs the following parameters to start: No parameter Has access to xc Registers Max one subdevice per device Status machine for SVC Channel(s) Command Packets to 'Host' (via AP-Task) Answer Packets from 'Host' (via AP-Task) 4.2 Start-up of the SERCOS III-Device Stack After power on or reset the device performs a start-up initialization. During this phase several steps are taken to bring the device from the uninitialized state into operation. The stack waits for the so called parameter-packet. This can be send using the cifx Device Driver Setup or by sending it to the mailbox in the dual-port-memory. The SERCOS III device starts after initialization in the non realtime mode: After the first MDT0 telegram with CP0 (SERCOS III) was received the realtime mode starts automatically. If there are no more real-time telegrams in communication phase 0, the device returns to the non realtime mode and waits for new telegrams. The stack handles the communication phases CP0, CP1, CP2, CP3 and CP4. From phase CP2 on, the stack is waiting for parameterization via the service channel by the master. When phase CP4 is reached the communication bit in the dual-port-memory is set and the host can exchange cyclic data. At any time the Host can access the data in the service channel Object Dictionary by using the AccessIDN-Packet. By this access it is possible to set parameters e.g. the Electronic Label (similar to Manufacturer Version) EIDN S or Minimum Feedback Processing Time S can be written before the Communication-Phase Startup occurs. With the parameters MAC address Ipv4 address SERCOS device address the stack can handle the NRT mode and CP 0, CP1 and CP2.

39 SERCOS III Slave General Topics 39 At least, the following parameters are necessary for the stack in order to handle CP3 and CP4: Telegram Parameters: Telegram Parameter IDN S IDN S IDN S EIDN S x.1 EIDN S x.2 EIDN S x.3 EIDN S x.5 Table 24: Telegram Parameters Meaning Telegram type MDT SVC offset in byte AT SVC offset in byte Connection Setup Connection Number Telegram Assignment Actual Length of Connection Timing Parameters: Timing Parameter IDN S IDN S IDN S IDN S IDN S IDN S IDN S IDN S EIDN S x.11 Table 25: Timing Parameters Meaning SERCOS Cycle time Communication timeout for CP3/CP4 Time t 1 start AT Time t 4 feedback acquisition capture point Time t 3 command value valid time Ring delay Time t 6 and t 7 NRT send time, zero if not used Synchronization jitter Allowed data logger

40 SERCOS III Slave General Topics State Machine (Communication Phases) The states which the SERCOS III slave can have during operation are called communication phases. There are communication phases numbered from 0 to 4 and, additionally, the non-real-time mode. This section shortly sketches some of the most important aspects of the various communication phases State Transitions The following illustration explains the possible transition between the states of the SERCOS III slave: Figure 5: Permitted Communication Phase Transitions When switching between two states the SERCOS III slave is temporarily in an intermediate state CPS (Communication phase switching).

41 SERCOS III Slave General Topics Non real-time Mode (NRT Mode) In this mode, the SERCOS III slave can operate as usual Ethernet node according to the Ethernet standard IEEE 802.3, i.e. standard Ethernet frames are handled and re-sent. This mode also serves as a power-up mode meaning after power has been switched on and the internal checks of the SERCOS node have successfully been finished, the SERCOS node will usually reach this state. Note: In the NRT mode, the firmware/ protocol stack just forwards the Ethernet frames from one port to the other. The Ethernet frames are not transferred to the host! Communication Phase 0 In CP0, the master performs a measurement of the ring delay time which is needed for internal timing calculations in order to adjust several timing-related settings of the SERCOS III communication network. The master also sends MDT0 telegrams to which the slave must respond with the corresponding AT0 telegram. This gives the SERCOS III master the opportunity to check the presence of slaves in the network and to collect first slave-related information. This is the only state which can be entered from any other state as it can be entered both from any higher communication phase and from NRT mode such as the topology address. The service channel for acyclic communication is not active in CP0. If the slave is in CP0 and does not receive an MDT0 telegram from the master it will fall back to NRT mode Communication Phase 1 There are two necessary conditions under which the SERCOS III network will proceed from CP0 to CP1: The master has received 100 AT telegrams with identical contents. The SERCOS III master recognizes the ring has been closed. Then the master will switch to CP1 on its own initiative. The main purpose of CP1 is the identification of slaves. So in CP1 the master checks the presence of all configured SERCOS III slaves and performs tests whether the SERCOS III slaves should be activated for the higher communication phases or not. This is usually accomplished by the SERCOS III master by sending the telegrams MDT0 and MDT1. The SERCOS III master then expects an answer from the SERCOS III slaves within telegrams AT0 and AT1. The service channel for acyclic communication is initialized in CP1.

42 SERCOS III Slave General Topics Communication Phase 2 After having decided which slaves to accept for higher communication phases the SERCOS III master will on its own switch to CP2. The main purpose of CP2 is to transmit the most important communication parameters from the SERCOS III master to the slaves via the service channel. Parameters for cyclic communication and timing of messages are set and some other initializations are performed. The service channel for acyclic communication should be completely active at the slave in CP2. Note: Slaves which were not activated in CP1 must not react in CP2 (or even higher) but issue an error message Communication Phase 3 When having done all preparations necessary in CP2, the SERCOS III master will on its own send a procedure command (IDN S-0-127) to every accepted SERCOS III slave in order to prepare switching to CP3 and to test the readiness of these slaves. If all SERCOS III slaves successfully perform the procedure command, the SERCOS III master switches to CP3. Communication Phase 3 serves as a kind of test state in which real data communication between master and slave using the mechanisms of CP4 is performed without offering the full functionality of CP4. All parameters which have not yet been configured in the earlier states are configured now. Device control bits and device status bits are activated in CP3. The service channel for acyclic communication is completely active at the slave in CP Communication Phase 4 When having done all preparations necessary in CP3, the SERCOS III master will on its own send a procedure command (IDN S-0-128) to every accepted SERCOS III slave in order to prepare switching to CP4. During processing of this procedure command the slave has to check the validity of the transmitted parameters for CP4 and to activate the synchronization. If all SERCOS III slaves successfully perform the procedure command, the SERCOS III master switches to CP4. Communication phase 4 offers the full functionality of the SERCOS III network including service channel and IP channel. For more information about the details of the SERRCOS III communication phases please refer to the SERCOS III specification.

43 SERCOS III Slave General Topics Data Exchange Cyclic Data Exchange The cyclic data exchange is used to transport real time data from the bus to the host and vice versa. The cyclic data (see netx DPM Interface Manual - Section Input/Output Data Image) is available after Communication Phase 4 is reached. The DPM-Mode Buffered, Host Controlled is used. As long as the SVC-Object Dictionary is located on the netx, only parts of the Device-Status/-Control are used by the host (e. g. the Ready to operate bits'). The RT-Valid Bit is always set by the netx. Also the real-time bits can be found in the Device-Status and Device-Control (as soon as they are supported). Figure 6: Cyclic Data in Dual-port-memory

44 SERCOS III Slave General Topics Acyclic Data Exchange Warmstart Packet The warmstart packet is used to start up and configure the SERCOS III AP-Task and stack. It can be send automatically by cifx Device Driver Setup program after downloading the firmware or later using a user specific application. It is send via the channel mailbox. If this packet is send and accepted (parameters are valid) any other warmstart packet will be rejected until channel reset. This section explains the parameters of the SERCOS III Slave firmware. The following table contains relevant information about the warmstart parameters for the SERCOS III Slave firmware such as an explanation of the meaning of the parameter and ranges of allowed values: Parameter Meaning Range of Value / Value Bus Startup I/O Status This parameter is represented by bit 0 of the system flags. The start of the device can be performed either application controlled or automatically: Automatic (0): Network connections are opened automatically without taking care of the state of the host application. Communication with a controller after a device start is allowed without BUS_ON flag, but the communication will be interrupted if the BUS_ON flag changes state to 0 Application controlled (1): The channel firmware is forced to wait for the host application to wait for the Application Ready flag in the communication change of state register (see section of the netx DPM Interface Manual). Communication with controller is allowed only with the BUS_ON flag. For more information concerning this topic see section Controlled or Automatic Start of the netx DPM Interface Manual. This parameter is represented by bits 1 and 2 of the system flags. Using this parameter you can set the status of the input or the output data. For each input and output date the following status information (in Byte) is memorized in the dual-port memory. The bits have the following meaning: Bit 1 (I/O Status Enable): 0 = Status disabled 1 = Status enabled (not yet supported) Application controlled, Automatic

45 SERCOS III Slave General Topics 45 Bit 2 (I/O Status 8/32Bit): 0 = 1 Byte mode (not yet supported) 1 = 4 Byte mode (not yet supported) Watchdog [ms] Time Watchdog time (in milliseconds) Time for the application program for retriggering the device watchdog. The application program monitoring has to be activated. [ ] ms, default = 1000 ms, A value of 0 indicates that the watchdog timer has been switched off and the application program monitoring is therefore deactivated. TCP Flag This parameter is currently not used IP Address IP address of the station Valid IP address Default value: Netmask Network mask of the station Valid mask Default value: Gateway Gateway address of the station Valid IP address Default value: DeviceAddress[0-7] Field for 8 SERCOS III Slave Device Addresses in the range from 1 to 511. A value of indicates deactivated state. Device Addresses[1 7] are reserved for future use. Set it to See explanation below Object Flag Dictionary Indicates whether a local or a remote object dictionary is used: 0/local 0: A local object dictionary is used (Object dictionary is located on the netx) 1: A remote object dictionary is located on the host (not yet supported) Table 26: Meaning and allowed Values for Warmstart Parameters. For Device Address[0], the following values are allowed: 0 No SERCOS address, the SERCOS Master can assign the SERCOS address SERCOS slave device address indicating deactivated state For Device Addresses[1 7], the following values are allowed: indicating deactivated state

46 SERCOS III Slave General Topics 46 MAC-Address The MAC Address is not included within the warmstart parameters. The MAC-Address will be read from the Security EPROM during start-up. If this does not succeed, a TLR_E_SERCOSIII_EEPROM_UNAVAILABLE error code will be written into the status code of the confirmation packet. Using a Packet The SERCOSIII_SL_AP_WARMSTART_REQ_T packet has to be sent to the protocol stack. For more information how to accomplish this, please refer to section of this manual. Using the Device Driver In order to provide your Hilscher device with the correct warmstart parameters follow the procedure described in section Setting Warmstart Parameters of the cifx Driver Installation Manual. Transfer these parameters to your Hilscher device using the method described in subsection Transferring new Warmstart Parameters. Finally, you need to reset your device in order to perform a warmstart. After the warmstart is finished without error the new parameters are active. Using the device driver you can set the parameters described in the table in the preceding section Access IDN The SERCOSIII_SL_AP_ACCESSIDN_IND packet is used to access the object dictionary where the IDNs are stored into. Accessing the object dictionary in this context includes the possibility of both reading and writing access. E.g. it is used by the COM-Task to access the communication parameters by the master and to write error counters. It is completely independent of the service channel access by the master! All elements of an IDN can be accessed with one packet sending/receiving cycle. The elements which should be accessed (either reading or writing) are coded with a bit mask in variable ulaccessmask. Error behaviour Several elements can be accessed at once. Even if the access to one element fails (e. g. the unit is requested but no unit exists) the access on the other elements is finished successfully. If one of the bits 13, 12 or 9 is set, the complete request has failed. If one item is requested (Bit 0..6 of ulaccessmask) and the corresponding bit in ulerrorcode in the confirmation is not set, the item has been retrieved successfully.

47 SERCOS III Slave General Topics Example Usage of the AccessIDN-Packet Get Name, Unit, Attribute and Data of an IDN uldest: Queue handle of the AP-Task ulsrc: Handle of own queue ullen: 124 (minimum length of packet data is size of packet minus auldatum[]) ulcmd: 0x3514 (SIII_SL_AP_CMD_ACCESSIDN_IND) ulslaveidx: 0..7 ulwritemode: 0 (read) ulaccessmask: 0x4E (SIII_SL_AP_ACCESSIDN_MASK_NAME SIII_SL_AP_ACCESSIDN_MASK_UNIT SIII_SL_AP_ACCESSIDN_MASK_ATTRIBUTE SIII_SL_AP_ACCESSIDN_MASK_DATA) ulidn: the requested IDN e. g The rest of the data part is untouched. The answer from to AP-Task according to this packet contains the requested variables. Modify the Data of an IDN (e.g. EIDN S , Vendor Name) uldest: Queue handle of the AP-Task ulsrc: Handle of own queue ullen: Length of the data part = used length of auldatum, in our example: ulcmd: 0x3514 ulslaveidx: 0 ulwritemode: 1 (write) ulaccessmask: 0x40 (SIII_SL_AP_ACCESSIDN_MASK_DATA) ulidn: 30 (S ) auldatum: contains the new datum which is a 1 byte list e. g. 0x6, 0x0, 0x6, 0x0, 0x4B, 0x42, 0x53, 0x33, 0x34, 0x30 which is a 6 Byte Identifier KBS340. The rest of the data part is untouched. The answer from the AP-Task according to this packet contains the result in ulerrorcode.

48 SERCOS III Slave General Topics LED Definitions The STA-LED signals the current communication phase. The assignment between the communication mode and the STA-LED state is as follows: Communication mode Offline-mode CP0 CP1 CP2 CP3 CP4 STA-LED off blinking single flash double flash triple flash on Back to offline Table 27: State of STA-LED depending on Communication mode off Watchdog Timers This section describes the Hilscher DPM host/device Watchdogs. If the host watchdog is used and timed out, the stack assumes the host is unavailable will interrupt the network communication. The master will fall back to CP0. For the maintenance of the watchdog timer there are two packets available: SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ - Get Watchdog Time SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ - Set Watchdog Time

49 SERCOS III Slave The Application Interface 49 5 The Application Interface The application itself has to be developed as a Task according to the Hilscher s Task Layer Reference Model. The Application-Task is named AP-Task in the following sections and chapters. The AP-Task s process queue is keeping track of all its incoming packets. It provides the communication channel for the underlying SERCOS III Slave Stack. Once, the SERCOS III Slave Stack communication is established, events received by the stack are mapped to packets that are sent to the AP-Task s process queue. On one hand every packet has to be evaluated in the AP-Task s context and corresponding actions be executed. On the other hand, Initiator-Services that are be requested by the AP-Task itself are sent via predefined queue macros to the underlying SERCOS III Slave Stack queues via packets as well. Note: The structure of confirmation packets does not differ from the structure of the corresponding request packet except otherwise indicated. 5.1 The SERCOS III Device AP-Task To get the handle of the process queue of the SERCOS III Device AP--Task the Macro TLR_QUE_IDENTIFY() needs to be used. It is described in detail within section of the Hilscher Task Layer Reference Model Manual. This macro delivers a pointer to the handle of the intended queue to be accessed (which is returned within the third parameter, phque), if you provide it with the name of the queue (and an instance of your own task). The correct ASCII-queue names for accessing the SERCOS III Device AP--Task which you have to use as current value for the first parameter (pszidn) is ASCII Queue name "QUE_S3_SL_AP Description Name of the SERCOS III Device AP-Task process queue Table 28: Names of Queues in SERCOS III Slave Firmware The returned handle has to be used as value uldest in all initiator packets the AP-Task intends to send to the SERCOS III Device AP Task. This handle is the same handle that has to be used in conjunction with the macros like TLR_QUE_SENDPACKET_FIFO/LIFO() for sending a packet to the respective task.

50 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_WARMSTART_REQ/CNF - Warmstart Packet The warmstart packet is used to start up and configure the SERCOS III AP-Task and Stack. It can be send automatically by cifx Device Driver Setup program after downloading the firmware or later using a user specific application. It is send via the channel mailbox. If this packet is send and accepted (parameters are valid) any other warmstart packet will be rejected until channel reset. Packet Structure Reference struct SERCOSIII_SL_AP_WARMSTART_REQ_DATA_Ttag /* Warmstart request data */ { TLR_UINT32 ulsystemstart; TLR_UINT32 ulwdgtime; TLR_UINT32 uliostatus; TLR_UINT32 ultcpflag; TLR_UINT32 ulipaddr; TLR_UINT32 ulnetmask; TLR_UINT32 ulgateway; TLR_UINT16 ausdeviceaddr[8]; TLR_BOOLEAN8 fobjdict; }; typedef struct SERCOSIII_SL_AP_WARMSTART_REQ_DATA_Ttag SERCOSIII_SL_AP_WARMSTART_REQ_DATA_T; struct SERCOSIII_SL_AP_WARMSTART_REQ_Ttag /* Warmstart request */ { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_WARMSTART_REQ_DATA_T tdata; /** packet data */ }; typedef struct SERCOSIII_SL_AP_WARMSTART_REQ_Ttag SERCOSIII_SL_AP_WARMSTART_REQ_T;

51 SERCOS III Slave The Application Interface 51 Packet Description structure SERCOSIII_SL_AP_WARMSTART_REQ_T Type: Request Area Variable Type Value / Range Description thead structure TLR_PACKET_HEADER_T uldest UINT32 Destination Queue-Handle ulsrc UINT32 Source Queue-Handle uldestid UINT32 Destination End Point Identifier, specifying the final receiver of the packet within the Destination Process. Set to 0 for the Initialization Packet ulsrcid UINT32 Source End Point Identifier, specifying the origin of the packet inside the Source Process ullen UINT32 27 Packet Data Length in bytes ulid UINT Packet Identification as unique number generated by the Source Process of the Packet ulsta UINT32 See Table 30: SERCOSIII_SL_AP_WARMSTART_REQ Packet Status/Error ulcmd UINT32 0x3500 SIII_SL_AP_CMD_WARMSTART_REQ - Command tdata ulext UINT32 0 Extension not in use, set to zero for compatibility reasons ulrout UINT32 x Routing, do not touch Structure Information SERCOSIII_SL_AP_WARMSTART_REQ_DATA_T ulwdgtime UINT32 0x14..0xFFFF Host-watchdog time in ms uliostatus UINT32 Is not used ultcpflag UINT32 Parameter for TCP/IP-Handling (not used yet) ulipaddr UINT32 IP-Address (not used yet) ulnetmask UINT32 Net mask (not used yet) ulgateway UINT32 Gateway-Address (not used yet) ausdeviceaddr [8] fobjdict UINT , 0xFFFF indicating device has been deactivated BOOLE AN SERCOSIII-Device Address ausdeviceaddr[0] can be freely used 0 indicates that the SERCOS Master can assign the SERCOS address represents the SERCOSIII-Device Address ausdeviceaddr[1.. 7] is reserved for future use. Set it to 0xFFFF 0,1 Storage location of object dictionary 0 = object dictionary is located on netx 1 = object dictionary is located on the host (not supported) Table 29: SERCOSIII_SL_AP_WARMSTART_REQ_T Set Warmstart Parameters

52 SERCOS III Slave The Application Interface 52 Packet Status/Error Definition / (Value) TLR_S_OK (0x ) TLR_E_SERCOSIII_EEPROM _UNAVAILABLE (0xC ) TLR_E_SERCOSIII_SL_AP_I NVALID_DEVICE_ADDRESS (0xC )) TLR_E_SERCOSIII_SL_AP_ WATCHDOG_TIME_TOO_LA RGE (0xC ) TLR_E_SERCOSIII_SL_AP_ WARMSTART_ALREADY_RE CEIVED (0xC051000D) TLR_E_SERCOSIII_SL_AP_ WATCHDOG_TIME_TOO_SM ALL (0xC051000E) TLR_E_INVALID_PACKET_L EN (0xC ) TLR_E_SERCOSIII_SL_AP_G ETTING_PACKET_FAILED (0xC ) TLR_E_SERCOSIII_SL_AP_S ENDING_PACKET_FAILED (0xC ) Description Status ok Failed to receive the MAC-Address from the Security EEPROM. At least one of the device addresses in the warmstart packet is invalid. The maximum watchdog is larger than (ms). The warmstart packet has already been successfully received. This one is ignored. The maximum watchdog is smaller than 20 (ms). Packet length is invalid. No Packet is available in pool. This is an internal error which should not occur. Packet could not be sent. This is an internal error which should not occur. Table 30: SERCOSIII_SL_AP_WARMSTART_REQ Packet Status/Error

53 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_ACCESSIDN_IND - Access IDN This packet is used to access the object dictionary where the IDNs are stored into. Accessing the object dictionary in this context includes the possibility of both reading and writing access. E.g. it is used by the COM-Task to access the communication parameters by the master and to write error counters. It is completely independent of the service channel access by the master! All elements of an IDN can be accessed with one packet sending/receiving cycle. The elements which should be accessed (either reading or writing) are coded with a bit mask in variable ulaccessmask. Error behaviour Several elements can be accessed at once. Even if the access to one element fails (e. g. a unit is requested but no unit exists) the access on the other elements is finished successfully. If one of the bits 13, 12 or 9 is set, the complete request has failed. If one item is requested (Bit 0..6 of ulaccessmask) and the corresponding bit in ulerrorcode in the confirmation is not set, the item has been retrieved successfully. For more information about the SERCOS III object dictionary see section 7.1. Packet Structure Reference struct SERCOSIII_SL_AP_ACCESSIDN_IND_DATA_Ttag /* Master SVC request indication - data */ { TLR_UINT32 ulslaveidx; TLR_UINT32 ulwritemode; TLR_UINT32 ulaccessmask; TLR_UINT32 ulidn; TLR_UINT32 ulerrorcode; TLR_UINT32 uldatastatus; TLR_UINT8 abname[64]; TLR_UINT32 ulattribute; TLR_UINT8 abunit[16]; TLR_INT64 llminimum; TLR_INT64 llmaximum; TLR_UINT32 auldatum[342]; }; /** Master SVC request indication - data */ typedef struct SERCOSIII_SL_AP_ACCESSIDN_IND_DATA_Ttag SERCOSIII_SL_AP_ACCESSIDN_IND_DATA_T; struct SERCOSIII_SL_AP_ACCESSIDN_IND_Ttag /* */ { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_ACCESSIDN_IND_DATA_T tdata; /** packet data */ }; /** Master SVC request indication - packet */ typedef struct SERCOSIII_SL_AP_ACCESSIDN_IND_Ttag SERCOSIII_SL_AP_ACCESSIDN_IND_T;

54 SERCOS III Slave The Application Interface 54 Structure SERCOSIII_SL_AP_ACCESSIDN_IND_T Type: Request Area Variable Type Value / Range Description thead Structure Information uldest UINT32 Destination Queue Handle ulsrc UINT32 Source Queue Handle uldestid UINT32 Destination Queue Reference ulsrcid UINT32 Source Queue Reference ullen UINT Packet Data Length (in Bytes) ulid UINT32 Packet Identification as Unique Number ulsta UINT32 Status ulcmd UINT32 0x Command ulext UINT32 0 Reserved ulrout UINT32 x Routing Information tdata Structure Information SERCOSIII_SL_AP_ACCESSIDN_IND_DATA_T ulslaveidx UINT32 0 Index of the device ulwritemode UINT32 0,1 Write Mode: 0 = read 1 = write ulaccessmask UINT32 See below Mask for accessing elements ulidn UINT32 Valid IDN Affected IDN ulerrorcode UINT32 See below Result of access (Bitmask) uldatastatus UINT32 Data Status of IDN abname[64] UINT8 Name of IDN ulattribute UINT32 Attribute of IDN abunit[16] UINT8 Unit of IDN llminimum INT64 Minimum of IDN llmaximum INT64 Maximum of IDN auldatum[342] UINT32 Datum of IDN Table 31: SERCOSIII_SL_AP_ACCESSIDN_IND_T Access to IDN within Object Dictionary Packet Status/Error Definition / (Value) TLR_S_OK (0x ) Description Status ok Table 32: SERCOSIII_SL_AP_ACCESSIDN_IND_T Packet Status/Error

55 SERCOS III Slave The Application Interface 55 Meaning of the ulaccessmask in the Indication Bits Name (Bitmask) Description Reserved Reserved for future use 6 SIII_SL_AP_ACCESSIDN_MASK_DA TA 5 SIII_SL_AP_ACCESSIDN_MASK_MA XIMUM 4 SIII_SL_AP_ACCESSIDN_MASK_MI NIMUM 3 SIII_SL_AP_ACCESSIDN_MASK_UN IT 2 SIII_SL_AP_ACCESSIDN_MASK_AT TRIBUTE 1 SIII_SL_AP_ACCESSIDN_MASK_NA ME 0 SIII_SL_AP_ACCESSIDN_MASK_ST ATUS Table 33: Meaning of Parameter ulaccessmask Access the data of the IDN. Access the maximum of the IDN. Access the minimum of the IDN. Access the unit of the IDN. Access the attribute of the IDN. Access the name of the IDN. Access the data status. This is only allowed in the read mode. #define SIII_SL_AP_ACCESSIDN_MASK_STATUS #define SIII_SL_AP_ACCESSIDN_MASK_NAME #define SIII_SL_AP_ACCESSIDN_MASK_ATTRIBUTE #define SIII_SL_AP_ACCESSIDN_MASK_UNIT #define SIII_SL_AP_ACCESSIDN_MASK_MINIMUM #define SIII_SL_AP_ACCESSIDN_MASK_MAXIMUM #define SIII_SL_AP_ACCESSIDN_MASK_DATA (0x0001) (0x0002) (0x0004) (0x0008) (0x0010) (0x0020) (0x0040)

56 SERCOS III Slave The Application Interface 56 Meaning of the ulerrorcode in the Response Bits Name (Bitmask) Description Reserved Reserved for future use 13 SIII_SL_AP_ACCESSIDN_MASK_IN TERNAL_ERROR 12 SIII_SL_AP_ACCESSIDN_MASK_W RONG_LENGTH Reserved Reserved for future use 9 SIII_SL_AP_ACCESSIDN_MASK_NO IDN An internal error occurred. None of the requested elements could be retrieved. The request packets has the wrong length. None of the requested elements could be retrieved. The requested IDN does not exist. None of the requested elements could be retrieved Reserved Reserved for future use 6 SIII_SL_AP_ACCESSIDN_MASK_DA TA 5 SIII_SL_AP_ACCESSIDN_MASK_MA XIMUM 4 SIII_SL_AP_ACCESSIDN_MASK_MI NIMUM 3 SIII_SL_AP_ACCESSIDN_MASK_UN IT 2 SIII_SL_AP_ACCESSIDN_MASK_AT TRIBUTE 1 SIII_SL_AP_ACCESSIDN_MASK_NA ME 0 SIII_SL_AP_ACCESSIDN_MASK_ST ATUS Table 34: Meaning of Parameter ulerrorcode Access the data was requested, but failed. Access the maximum was requested, but failed. Access the minimum was requested, but failed. Access the unit was requested, but failed. Access the attribute was requested, but failed. Access to name was requested, but failed. Access the data status was requested, but failed. #define SIII_SL_AP_ACCESSIDN_MASK_STATUS #define SIII_SL_AP_ACCESSIDN_MASK_NAME #define SIII_SL_AP_ACCESSIDN_MASK_ATTRIBUTE #define SIII_SL_AP_ACCESSIDN_MASK_UNIT #define SIII_SL_AP_ACCESSIDN_MASK_MINIMUM #define SIII_SL_AP_ACCESSIDN_MASK_MAXIMUM #define SIII_SL_AP_ACCESSIDN_MASK_DATA (0x0001) (0x0002) (0x0004) (0x0008) (0x0010) (0x0020) (0x0040) /* these additional defines are used for error handling */ #define SIII_SL_AP_ACCESSIDN_MASK_NOIDN (0x0200) #define SIII_SL_AP_ACCESSIDN_MASK_WRONG_LENGTH (0x1000) #define SIII_SL_AP_ACCESSIDN_MASK_INTERNAL_ERROR (0x2000)

57 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ/CNF - Get Watchdog Time This packet is used to read the currently valid timer interval of the internal watchdog timer (which is specified in units of milliseconds). Packet Structure Reference struct SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_DATA_Ttag { /** current Watchdog time (in ms) */ TLR_UINT32 ulwdgtime; }; typedef struct SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_DATA_Ttag SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_DATA_T; struct SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_Ttag { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_DATA_T tdata; /** packet data */ }; typedef struct SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_Ttag SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_T;

58 SERCOS III Slave The Application Interface 58 Packet Description structure SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_T Type: Request Area Variable Type Value / Range Description thead structure TLR_PACKET_HEADER_T tdata uldest UINT32 Destination Queue-Handle ulsrc UINT32 Source Queue-Handle uldestid UINT32 Destination End Point Identifier, specifying the final receiver of the packet within the Destination Process. Set to 0 for the Initialization Packet ulsrcid UINT32 Source End Point Identifier, specifying the origin of the packet inside the Source Process ullen UINT32 0 in Request 4 in Confirm. Packet Data Length in bytes ulid UINT Packet Identification as unique number generated by the Source Process of the Packet ulsta UINT32 See Table 36: SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_ T Packet Status/Error ulcmd UINT32 0x3510 SIII_SL_AP_CMD_GET_WATCHDOG_TIME_REQ Command ulext UINT32 0 Extension not in use, set to zero for compatibility reasons ulrout UINT32 X Routing, do not touch structure SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_DATA_T ulwdgtime UINT xFFFF Current Watchdog Time Table 35: SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_T Get Watchdog Time Packet Status/Error Definition / (Value) TLR_S_OK (0x ) Description Status ok Table 36: SERCOSIII_SL_AP_GET_WATCHDOG_TIME_REQ_T Packet Status/Error

59 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ/CNF Set Watchdog Time This packet is used to write a new value of the timer interval to the internal watchdog timer. The new value may not exceed the allowed range between 20 and milliseconds. Packet Structure Reference struct SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_DATA_Ttag { /** new Watchdog time (in ms) */ TLR_UINT32 ulwdgtime; }; typedef struct SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_DATA_Ttag SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_DATA_T; struct SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_Ttag { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_DATA_T tdata; /** packet data */ }; typedef struct SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_Ttag SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_T;

60 SERCOS III Slave The Application Interface 60 Packet Description structure SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_T Type: Request Area Variable Type Value / Range Description thead tdata structure TLR_PACKET_HEADER_T uldest UINT32 Destination Queue-Handle ulsrc UINT32 Source Queue-Handle uldestid UINT32 Destination End Point Identifier, specifying the final receiver of the packet within the Destination Process. Set to 0 for the Initialization Packet ulsrcid UINT32 Source End Point Identifier, specifying the origin of the packet inside the Source Process ullen UINT32 4 in Request 0 in Confirm. Packet Data Length in bytes ulid UINT Packet Identification as unique number generated by the Source Process of the Packet ulsta UINT32 See Table 38: SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_T Packet Status/Error ulcmd UINT32 0x3512 SIII_SL_AP_CMD_SET_WATCHDOG_TIME_REQ Command ulext UINT32 0 Extension not in use, set to zero for compatibility reasons ulrout UINT32 X Routing, do not touch structure SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_DATA_T ulwdgtime UINT xFFFF New Watchdog Time Table 37: SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_T Set Watchdog Time

61 SERCOS III Slave The Application Interface 61 Packet Status/Error Definition / (Value) TLR_S_OK (0x ) TLR_E_INVALID_PACKET_L EN (0xC ) TLR_E_SERCOSIII_SL_AP_ WATCHDOG_TIME_TOO_SM ALL (0xC051000E) TLR_E_SERCOSIII_SL_AP_ WATCHDOG_TIME_TOO_LA RGE (0xC ) TLR_E_FAIL (0xC ) Description Status ok Packet length is invalid. The maximum watchdog is smaller than 20 (ms). The maximum watchdog is larger than (ms). Internal error, should not occur. Table 38: SERCOSIII_SL_AP_SET_WATCHDOG_TIME_REQ_T Packet Status/Error

62 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_CMD_READY_FOR_CPS_REQ/CNF - Ready for Communication Phase Switching Request The AP-Task sends this packet to the COM-Task to propose that the COM-Task should switch to another communication phase. There are two possibilities: Change from CP2 to CP3. Change from CP3 to CP4. The variable ultargetcp is used to specify which communication phase change you intend to perform by simply taking the number of the intended communication phase as the value of this parameter. The index number by which the Hilscher SERCOS III device is accessed can be specified with variable ulslaveidx. The length of SERCOS III MDT (EIDN , formerly IDN S ) and AT (EIDN , formerly IDN S ) can be adjusted by the choice of ulmdtlength and ulatlength, respectively. These values should be chosen according to the recommendations given in section of the SERCOS III specification. Both parameters are only relevant if the SERCOS III Slave is currently in CP 2. For more information, see section of the SERCOS III specification for ulmdtlength or section for ulatlength, respectively. Note: This packet is send when the SERCOS III-Master executes the SERCOS Command S or S The three subsequent parameters concerning the control clock have the following meaning. Start (Variable ulconclkstart), here the time delay between the SERCOS III cycle clock and the begin of the control clock signal may be specified in units of microseconds. End (Variable ulconclkend), here the time delay between the SERCOS III cycle clock and the end of the control clock signal may be specified in units of microseconds. This means the width of the signal must be difference between ulconclkend and ulconclkstart. The polarity (Variable ulconclkpolarity), may be positive (=1) or negative (=0))

63 SERCOS III Slave The Application Interface 63 Packet Structure Reference struct SERCOSIII_SL_AP_READY_FOR_CPS_REQ_DATA_Ttag /* Ready For CPS Request */ { /** target communication phase (3 or 4) */ TLR_UINT32 ultargetcp; /** Index of Slave (0) */ TLR_UINT32 ulslaveidx; /** Length of MDT-Data in CP3/4 for this slave */ TLR_UINT32 ulmdtlength; /** Length of AT-Data in CP3/4 for this slave */ TLR_UINT32 ulatlength; /** Con_Clk default value = t4 */ TLR_BOOLEAN8 fconclkdefaultflag; /** Set Con_Clk polarity */ TLR_UINT32 ulcon_clk_polarity; /** Set Con_Clk start */ TLR_UINT32 ulcon_clk_start; /** Set Con_Clk end */ TLR_UINT32 ulcon_clk_end; TLR_UINT32 ult3intenable; TLR_UINT32 ult4intenable; }; typedef struct SERCOSIII_SL_AP_READY_FOR_CPS_REQ_DATA_Ttag SERCOSIII_SL_AP_READY_FOR_CPS_REQ_DATA_T; struct SERCOSIII_SL_AP_READY_FOR_CPS_REQ_Ttag { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_READY_FOR_CPS_REQ_DATA_T tdata; /** packet data */ }; typedef struct SERCOSIII_SL_AP_READY_FOR_CPS_REQ_Ttag SERCOSIII_SL_AP_READY_FOR_CPS_REQ_T;

64 SERCOS III Slave The Application Interface 64 Packet Description structure SERCOSIII_SL_AP_READY_FOR_CPS_REQ_T Type: Request Area Variable Type Value / Range Description thead tdata structure TLR_PACKET_HEADER_T uldest UINT32 Destination Queue-Handle ulsrc UINT32 Source Queue-Handle uldestid UINT32 Destination End Point Identifier, specifying the final receiver of the packet within the Destination Process. Set to 0 for the Initialization Packet ulsrcid UINT32 Source End Point Identifier, specifying the origin of the packet inside the Source Process ullen UINT32 37 Packet Data Length in bytes ulid UINT Packet Identification as unique number generated by the Source Process of the Packet ulsta UINT32 See Table 40: SERCOSIII_SL_AP_CMD_READY_FOR_CPS_REQ - Packet Status/Error ulcmd UINT32 0x3508 SIII_SL_AP_CMD_READY_FOR_CPS_REQ - Command ulext UINT32 0 Extension not in use, set to zero for compatibility reasons ulrout UINT32 x Routing, do not touch structure SERCOSIII_SL_AP_READY_FOR_CPS_REQ_DATA_T ultargetcp UINT32 3, 4 Target communication phase (3 or 4) ulslaveidx UINT32 0 Index of Slave ulmdtlength UINT32 See above Length of MDT-Data in CP3/4 for this slave ulatlength UINT32 See above Length of AT-Data in CP3/4 for this slave fconclkdefaultflag BOOLEA N8 0, 1 Set Con_Clk default value = t sync ulcon_clk_polarity UINT32 0, 1 Set Con_Clk polarity ulcon_clk_start UINT Set Con_Clk start ulcon_clk_end UINT Set Con_Clk end ult3intenable UINT32 0, 1 Set T3IntEnable ult4intenable UINT32 0, 1 Set T4IntEnable Table 39: SERCOSIII_SL_AP_CMD_READY_FOR_CPS_REQ - Ready for Communication Phase Switching Request Packet Status/Error Definition / (Value) TLR_S_OK (0x ) Description Status ok Table 40: SERCOSIII_SL_AP_CMD_READY_FOR_CPS_REQ - Packet Status/Error

65 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_CMD_CHANGE_SLAVE_STATE_REQ/CNF - Change Slave State request This packet is used to modify the (cyclic) slave status. It is only used if the Object Dictionary is located on the Host. In this case the values of the SD-Bit and CB-Bit are generated by the Host. The RealTime Status Bits are not modified by this packet. The index number can be specified with variable ulslaveidx. For more information about the states of the SERCOS III slave see section 4.3 of this document. Packet Structure Reference struct SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_DATA_Ttag /* Change Slave State request */ { TLR_UINT32 ulnewslavestate; /** the new (partial) state of one slave */ TLR_UINT32 ulslaveidx; /** Index of Slave (0)*/ }; typedef struct SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_DATA_Ttag SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_DATA_T; struct SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_Ttag /* */ { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_DATA_T tdata; /** packet data */ }; typedef struct SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_Ttag SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_T;

66 SERCOS III Slave The Application Interface 66 Packet Description structure SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_T Type: Request Area Variable Type Value / Range Description thead tdata structure TLR_PACKET_HEADER_T uldest UINT32 Destination Queue-Handle ulsrc UINT32 Source Queue-Handle uldestid UINT32 Destination End Point Identifier, specifying the final receiver of the packet within the Destination Process. Set to 0 for the Initialization Packet ulsrcid UINT32 Source End Point Identifier, specifying the origin of the packet inside the Source Process ullen UINT32 8 Packet Data Length in bytes ulid UINT Packet Identification as unique number generated by the Source Process of the Packet ulsta UINT32 See Table 42: SERCOSIII_SL_AP_CMD_CHANGE_SLAVE_STATE_ REQ - Packet Status/Error ulcmd UINT32 0x350A SIII_SL_AP_CMD_CHANGE_SLAVE_STATE_REQ - Command ulext UINT32 0 Extension not in use, set to zero for compatibility reasons ulrout UINT32 x Routing, do not touch structure SERCOSIII_SL_AP_CHANGE_SLAVE_STATE_REQ_DATA_T ulnewslavestate UINT The new (partial) state of one slave ulslaveidx UINT32 0 Index of Slave Table 41: SERCOSIII_SL_AP_CMD_CHANGE_SLAVE_STATE_REQ - Change Slave State Request Packet Status/Error Definition / (Value) TLR_S_OK (0x ) Description Status ok Table 42: SERCOSIII_SL_AP_CMD_CHANGE_SLAVE_STATE_REQ - Packet Status/Error

67 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_CMD_HOST_READY_REQ/CNF - Host-Ready Changed Request This packet is used to indicate changes of the Host-Ready status. Packet Structure Reference struct SERCOSIII_SL_AP_HOST_READY_REQ_DATA_Ttag { TLR_UINT32 ulready; /** New ready state (0 or 1) */ }; typedef struct SERCOSIII_SL_AP_HOST_READY_REQ_DATA_Ttag SERCOSIII_SL_AP_HOST_READY_REQ_DATA_T; struct SERCOSIII_SL_AP_HOST_READY_REQ_Ttag /* */ { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_HOST_READY_REQ_DATA_T tdata; /** packet data */ }; typedef struct SERCOSIII_SL_AP_HOST_READY_REQ_Ttag SERCOSIII_SL_AP_HOST_READY_REQ_T;

68 SERCOS III Slave The Application Interface 68 Packet Description structure SERCOSIII_SL_AP_HOST_READY_REQ_T Type: Request Area Variable Type Value / Range Description thead structure TLR_PACKET_HEADER_T uldest UINT32 Destination Queue-Handle ulsrc UINT32 Source Queue-Handle uldestid UINT32 Destination End Point Identifier, specifying the final receiver of the packet within the Destination Process. Set to 0 for the Initialization Packet ulsrcid UINT32 Source End Point Identifier, specifying the origin of the packet inside the Source Process ullen UINT32 4 Packet Data Length in bytes ulid UINT Packet Identification as unique number generated by the Source Process of the Packet ulsta UINT32 See Table 44: SERCOSIII_SL_AP_CMD_HOST_READY_REQ - Packet Status/Error ulcmd UINT32 0x350E SIII_SL_AP_CMD_HOST_READY_REQ - Command tdata ulext UINT32 0 Extension not in use, set to zero for compatibility reasons ulrout UINT32 x Routing, do not touch structure SERCOSIII_SL_AP_HOST_READY_REQ_DATA_T ulready UINT32 0,1 Host ready state 1 = Host ready 0 = Host not ready Table 43: SERCOSIII_SL_AP_CMD_HOST_READY_REQ - Host-Ready Changed Request Packet Status/Error Definition / (Value) TLR_S_OK (0x ) Description Status ok Table 44: SERCOSIII_SL_AP_CMD_HOST_READY_REQ - Packet Status/Error

69 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_CMD_SET_COM_ERROR_IND Communication Error This packet indicates that a communication error has been reported from the protocol stack. Packet Structure Reference struct SERCOSIII_SL_AP_SET_COMM_ERR_IND_DATA_Ttag /* */ { /** Communication error reported from protocol stack */ TLR_UINT32 ulerrorcode; }; typedef struct SERCOSIII_SL_AP_SET_COMM_ERR_IND_DATA_Ttag SERCOSIII_SL_AP_SET_COMM_ERR_IND_DATA_T; /** (Bus) Communication error*/ struct SERCOSIII_SL_AP_SET_COMM_ERR_IND_Ttag /* */ { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_SET_COMM_ERR_IND_DATA_T tdata; /** packet data */ }; typedef struct SERCOSIII_SL_AP_SET_COMM_ERR_IND_Ttag SERCOSIII_SL_AP_SET_COMM_ERR_IND_T;

70 SERCOS III Slave The Application Interface 70 Packet Description structure SERCOSIII_SL_AP_SET_COMM_ERR_IND_T; Type: Indication Area Variable Type Value / Range Description thead tdata structure TLR_PACKET_HEADER_T uldest UINT32 Destination Queue-Handle ulsrc UINT32 Source Queue-Handle uldestid UINT32 Destination End Point Identifier, specifying the final receiver of the packet within the Destination Process. Set to 0 for the Initialization Packet ulsrcid UINT32 Source End Point Identifier, specifying the origin of the packet inside the Source Process ullen UINT32 4 Packet Data Length in bytes ulid UINT Packet Identification as unique number generated by the Source Process of the Packet ulsta UINT32 See Table 46: SERCOSIII_SL_AP_SET_COMM_ERR_IND -Packet Status/Error ulcmd UINT32 0x350C SERCOSIII_SL_AP_SET_COMM_ERR_IND - Command ulext UINT32 0 Extension not in use, set to zero for compatibility reasons ulrout UINT32 x Routing, do not touch structure SERCOSIII_SL_AP_SET_COMM_ERR_IND_DATA_T ulerrorcode UINT32 Communication error reported from protocol stack Table 45: SERCOSIII_SL_AP_SET_COMM_ERR_IND - Communication Error Indication Packet Status/Error Definition / (Value) TLR_S_OK (0x ) Description Status ok Table 46: SERCOSIII_SL_AP_SET_COMM_ERR_IND -Packet Status/Error

71 SERCOS III Slave The Application Interface SERCOSIII_SL_AP_CMD_SET_TIMING_PARAMETER_IND Change of Timing Parameters Indication This packet is used for indicating changes of timing parameters. The index number of the affected slave can be specified with variable ulslaveidx. The three variables ulenableconclkint, ulenablet3int and ulenablet4int indicate whether interrupts are enabled or not enabled for these three signals: Con_Clk (Control Clock) Timer Interrupt 3 Timer Interrupt 4 t 3 provides the command value valid time according to definition of the SERCOS III specification. t 3 contains the time (specified in units of microseconds) when the drive may access the new command values. This enables the master to specify one common time from which on all drives working together in a coordinated manner use the new command values. This can be specified in CP3 or CP4. The value needs to be either positive or 0 and must not exceed the communication cycle time t scyc of your SERCOS III network. t 4 provides the feedback acquisition capture point according to definition of the SERCOS III specification. t 4 contains the time (specified in units of microseconds) when the master captures the data from the drives working together in a coordinated manner. This allows synchronized data capture for all coordinated drives. The value needs to be positive or 0 and must not exceed the communication cycle time t scyc of your SERCOS III network. The control clock Con_Clk becomes active within a communication cycle of the SERCOS III cycle clock. The following three parameters concerning the control clock are calculated by the device. Start (Variable ulconclkstart), here the time delay between the SERCOS III cycle clock and the begin of the control clock signal may be specified in units of microseconds. End (Variable ulconclkend), here the time delay between the SERCOS III cycle clock and the end of the control clock signal may be specified in units of microseconds. This means the width of the signal must be difference between ulconclkend and ulconclkstart. Polarity (Variable ulconclkpolarity), may be positive (=1) or negative (=0)) Variable ulerrorcode contains a code which allows finding the cause of a n error according to table 34 of the SERCOS III specification.

72 SERCOS III Slave The Application Interface 72 Packet Structure Reference struct SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_DATATtag /* */ { TLR_UINT32 ulslaveidx; TLR_UINT32 ulenableconclkint; TLR_UINT32 ulenablet3int; TLR_UINT32 ulenablet4int; TLR_UINT32 ulerrorcode; TLR_UINT32 ulconclkstart; TLR_UINT32 ulconclkend; TLR_UINT32 ulconclkpolarity; }; typedef struct SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_DATATtag SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_DATA_T; struct SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_Ttag /* */ { TLR_PACKET_HEADER_T thead; /** packet header */ SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_DATA_T tdata; /** packet data */ }; typedef struct SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_Ttag SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_T;

73 SERCOS III Slave The Application Interface 73 Packet Description structure SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_T Type: Indication Area Variable Type Value / Range Description thead tdata structure TLR_PACKET_HEADER_T uldest UINT32 Destination Queue-Handle ulsrc UINT32 Source Queue-Handle uldestid UINT32 Destination End Point Identifier, specifying the final receiver of the packet within the Destination Process. Set to 0 for the Initialization Packet ulsrcid UINT32 Source End Point Identifier, specifying the origin of the packet inside the Source Process ullen UINT32 32 Packet Data Length in bytes ulid UINT Packet Identification as unique number generated by the Source Process of the Packet ulsta UINT32 See Table 48: SERCOSIII_SL_AP_CMD_SET_TIMING_PARAMETE R_IND Packet Status/Error ulcmd UINT32 0x3518 SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND - Command ulext UINT32 0 Extension not in use, set to zero for compatibility reasons ulrout UINT32 x Routing, do not touch structure SERCOSIII_SL_AP_SET_TIMING_PARAMETER_IND_DATA_T ulslaveidx UINT Slave Index ulenableconclki nt UINT32 0,1 Enable Con_Clk interrupt ulenablet3int UINT32 0,1 Enable T3 interrupt ulenablet4int UINT32 0,1 Enable T4 interrupt ulerrorcode UINT32 Error code ulconclkstart UINT Con_Clk start ulconclkend UINT Con_Clk end ulconclkpolarity UINT Con_Clk polarity Table 47: SERCOSIII_SL_AP_CMD_SET_TIMING_PARAMETER_IND Change of Timing Parameters Indication Packet Status/Error Definition / (Value) TLR_S_OK (0x ) Description Status ok Table 48: SERCOSIII_SL_AP_CMD_SET_TIMING_PARAMETER_IND Packet Status/Error

74 SERCOS III Slave Status/Error Codes Overview 74 6 Status/Error Codes Overview 6.1 Error Codes of the AP-Task Definition / (Value) TLR_S_OK (0x ) TLR_E_SERCOSIII_SL_AP_CO MMAND_INVALID (0xC L) TLR_E_SERCOSIII_DPM_WATC HDOG_TIMEOUT_EXPIRED (0xC L) TLR_E_SERCOSIII_EEPROM_U NAVAILABLE (0xC L) TLR_E_SERCOSIII_SL_AP_IN VALID_DEVICE_ADDRESS (0xC L) TLR_E_SERCOSIII_SL_AP_WA TCHDOG_TIME_TOO_LARGE (0xC L) TLR_E_SERCOSIII_SL_AP_GE TTING_PACKET_FAILED (0xC L) TLR_E_SERCOSIII_SL_AP_SE NDING_PACKET_FAILED (0xC L) TLR_E_SERCOSIII_SL_AP_SV C_ACTIVITY_FAILED (0xC L) TLR_E_SERCOSIII_SL_AP_RE GISTER_COM_FAILED (0xC L) TLR_E_SERCOSIII_SL_AP_RE GISTER_SVC_FAILED (0xC051000AL) TLR_E_SERCOSIII_SL_AP_RE GISTER_RTD_FAILED (0xC051000BL) TLR_E_SERCOSIII_SL_AP_IN VALID_SLAVE_INDEX (0xC051000CL) TLR_E_SERCOSIII_SL_AP_WA RMSTART_ALREADY_RECEIVED (0xC051000DL) TLR_E_SERCOSIII_SL_AP_WA Description Status ok Invalid command received. The host watchdog has been expired. Failed to receive the MAC address from the Security EEPROM. At least one of the device addresses in the warmstart packet is invalid. The maximum watchdog is larger than (ms). An error occurred during packet preparation. An error occurred during while sending a packet. An error occurred during processing a SVC-Request. An error occurred during register to at the stack (COM-Task). An error occurred during register to at the stack (SVC-Task). An error occurred during register to at the stack (RTD-Task). The requested slave index is invalid. The warmstart packet has already been successfully received. This one is ignored. The maximum watchdog is smaller than 20 (ms).

75 SERCOS III Slave Status/Error Codes Overview 75 TCHDOG_TIME_TOO_SMALL (0xC051000EL) Table 49: SERCOS III Slave AP Task Status/Error Codes Overview 6.2 Error Codes of the RTD -Task Definition / (Value) TLR_S_OK (0x ) TLR_E_SERCOSIII_SL_RTD_C OMMAND_INVALID (0xC L) TLR_E_SERCOSIII_SL_RTD_B UFFER_FAIL (0xC050002BL) Description Status ok Invalid command received. Error during buffer calculation. TLR_E_SERCOSIII_SL_RTD_D IFFERENT_TELEGRAMS (0xC050003BL) Devices not in same telegram. Table 50: SERCOS III Slave RTD Task Status/Error Codes Overview 6.3 Error Codes of the SVC -Task Definition / (Value) TLR_S_OK (0x ) Description Status ok TLR_E_SERCOSIII_SL_SVC_C OMMAND_INVALID (0xC04F0001L) Invalid command received. Table 51: SERCOS III Slave SVC Task Status/Error Codes Overview

76 SERCOS III Slave Status/Error Codes Overview Error Codes of the COM Task Definition / (Value) TLR_S_OK (0x ) TLR_E_SERCOSIII_SL_COM_C OMMAND_INVALID (0xC04E0001L) TLR_E_SERCOSIII_SL_COM_A DDRESS_INVALID (0xC04E0002L) TLR_E_SERCOSIII_SL_COM_O FFLINE_MODE (0xC04E0003L) TLR_E_SERCOSIII_SL_COM_I NIT_WORKINGLIST (0xC04E0004L) TLR_E_SERCOSIII_SL_COM_I NIT_HARDWARE (0xC04E0005L) TLR_E_SERCOSIII_SL_COM_I NIT_CYCLEWATCHDOG (0xC04E0006L) TLR_E_SERCOSIII_SL_COM_I NIT_SYNCUNIT (0xC04E0007L) TLR_E_SERCOSIII_SL_COM_C P0_MODE (0xC04E0008L) TLR_E_SERCOSIII_SL_COM_C PS01_MODE (0xC04E0009L) TLR_E_SERCOSIII_SL_COM_C PS12_MODE (0xC04E000AL) TLR_E_SERCOSIII_SL_COM_C P1_MODE (0xC04E000BL) TLR_E_SERCOSIII_SL_COM_C PS23_MODE (0xC04E000CL) TLR_E_SERCOSIII_SL_COM_C PS34_MODE (0xC04E000DL) TLR_E_SERCOSIII_SL_COM_S ERCOS_CYCLE_WDG_TRIGGERE D (0xC04E000EL) TLR_E_SERCOSIII_SL_COM_X C_RESTART_FAILED (0xC04E000FL) TLR_E_SERCOSIII_SL_COM_C ONFIG_RTD (0xC04E0010L) Description Status ok Invalid command received. Invalid address received in warmstart. Error in offline mode. Error in Working List. Initialize hardware error. Initialize cycle watchdog error. Initialize synchronization unit error. Error in CP0. Error in CP switch 0 to 1. Error in CP switch 1 to 2. Error in CP1. Error in CP switch 2 to 3. Error in CP switch 3 to 4. SERCOS cycle time out. XC reset failed. Error in real time data configuration.

77 SERCOS III Slave Status/Error Codes Overview 77 TLR_E_SERCOSIII_SL_COM_C FG_SYSTIME (0xC04E0011L) TLR_E_SERCOSIII_SL_COM_C P2_MODE (0xC04E0012L) TLR_E_SERCOSIII_SL_COM_F IFO_INIT_FAILED (0xC04E0013L) TLR_E_SERCOSIII_SL_COM_M ULTIPLE_TEL_MISS (0xC04E0014L) TLR_E_SERCOSIII_SL_COM_P HY_INIT_FAILED (0xC04E0015L) TLR_E_SERCOSIII_SL_COM_I NTERNAL_ERROR (0xC04E0016L) TLR_E_SERCOSIII_SL_COM_C YCLE_TIME (0xC04E0017L) Wrong values in systime configuration. Error in CP2. FIFO initialization failed. Multiple telegram miss. The Initialization of the PHYs failed. Due an internal error, the startup of bus-communication is impossible. Wrong cycletime in phase 0, 1, 2. TLR_E_SERCOSIII_SL_COM_R TDTOOLONG (0xC04E0018L) Length of realtime data above 222 bytes. Table 52: SERCOS III Slave COM Task Status/Error Codes Overview

78 SERCOS III Slave Appendix 78 7 Appendix 7.1 Object Dictionary The objects within the object dictionary, which are uniquely identified by their IDNs, represent the entire parameter set of the SERCOS III system. This sections only concentrates on the most important IDNs, which represent the main parameters of the SERCOS III system and will usually be accessed often. You might wish to implement a lot of these IDNs in your application as the application should be ready to react to these, so the aim of this appendix is to describe the general access procedure and to explain some of the most important commonly used IDNs General Access Procedure The object dictionary is accessed via the SERCOS III service channel. The single objects are represented by their unique IDN. Assigned to each IDN is a data block consisting of 7 elements with the following structure: Elements of an IDN Element Name Type Mandatory/Optional 1 IDN structure 16-bit value Mandatory 2 Name (of operational data) Text (Max. 64 bytes wide) Optional 3 Attribute (of operational data) Bit mask (4 bytes wide) Mandatory 4 Unit (of operational data) Text (Max. 16 bytes wide) Optional 5 Minimum allowed input value As #2 Optional 6 Maximum allowed input value As #2 Optional 7 Data 4 different alternatives Mandatory Table 53: Available Elements of an IDN These data are described in detail below. It should be possible to process requests from the SERCOS III master with multiple elements as well as one single element when receiving the SERCOSIII_SL_AP_ACCESSIDN_IND - Access IDN indication Selection of requested Element A bit mask allows you to determine which element is requested by the master to be looked up from the object dictionary or stored into it.. The according definitions are:

79 SERCOS III Slave Appendix 79 Symbolic Name Element Numeric Value SIII_SL_AP_ACCESSIDN_MASK_STATUS IDN structure/ status 0x0001 SIII_SL_AP_ACCESSIDN_MASK_NAME Name (of operational data) 0x0002 SIII_SL_AP_ACCESSIDN_MASK_ATTRIBUTE Attribute (of operational data) 0x0004 SIII_SL_AP_ACCESSIDN_MASK_UNIT Unit (of operational data) 0x0008 SIII_SL_AP_ACCESSIDN_MASK_MINIMUM Minimum allowed input value 0x0010 SIII_SL_AP_ACCESSIDN_MASK_MAXIMUM Maximum allowed input value 0x0020 SIII_SL_AP_ACCESSIDN_MASK_DATA Data 0x0040 Table 54: Available Elements of an IDN - Symbolic Names and corresponding numeric Values This table is closely related to Table 33: Meaning of Parameter ulaccessmask in section When receiving the SERCOSIII_SL_AP_ACCESSIDN_IND - Access IDN indication, for each element the SERCOS III master wants to request simultaneously, the corresponding bit is set and allows you to react accordingly. Also you can determine whether data should be written to or read from the object dictionary depending on the value of parameter ulwritemode: Value Explanation 0 Read 1 Write Table 55: Read and Write Access IDN Structure / Data Status As already stated above each IDN is uniquely assigned to an object which can be seen as a block of data containing slave-related data. In general, SERCOS III offers a space of 2 16 allowed IDNs. However, the following rules divide this space into subspaces: There is a subdivision between standard data (S) and product-related (or manufacturer-specific) data (P). This is accomplished by setting bit 15 of the IDN 1) To 0 for standard data. 2) To 1 for product-related data. There is a further subdivision between 8 separate parameter sets (denominated as parameter sets 0 to 7). Each of these parameter sets may then contain 4096 (equivalent to 2 12 ) IDNs. The table below shows the byte assignment resulting from these rules: Within the SERCOS III telegrams, the IDNs are generally transferred as 32-bit values.

80 SERCOS III Slave Appendix Name This optional element holds the name of the operational data which are stored under the respective IDN. The length is limited to at most 64 bytes. At least 2 bytes need to be used. These bytes are structured as follows: The first two bytes contain the hexadecimally coded value of the length of the programmed text. This is the text the master proposes to the slave. If these two bytes are 0, no other data are required and a zero-length name will be defined therefore. The next two bytes contain the hexadecimally coded value of the maximum allowed length of this text if the slave is permitted to change the text. (If this length is equal to 0, the slave is not permitted to do so.) Beginning from the fifth byte there is a string consisting of up to 60 bytes (characters) space for the actual name of the object assigned to the IDN. Characters exceeding the amount specified in the length bytes should be truncated by the SERCOS III slaves. See the graphics below: Note: As the service channel transfers data in a word-aligned manner, it is recommended to use even values for the two length specifications described in this context. For more information, refer to the SERCOS III specification, chapter

81 SERCOS III Slave Appendix Attribute This mandatory element contains additional information required for administrative purposes. It is a 32-bit wide bit mask to be interpreted according to the subsequent table: Coding of Attribute Information in IDN D31 D30 D29 D28 D27- D24 D23 D22- D20 D19 D18-D16 D15-D0 Function Conversion factor used for conversion of data to display format, specified as unsigned integer. Use 1 if not required (for instance for binary, character string or floating point number data) Data length (required for correct termination of data transmission on the service channel) 000 Reserved 001 Two bytes of operation data 010 Four bytes of operation data 011 Eight bytes of operation data 100 Length is variable/1-byte data strings 101 Length is variable/2-byte data strings 110 Length is variable/4-byte data strings 111 Length is variable/8-byte data strings 0 Operation data/parameter 1 Command Coding for data type and display format Data type Display format 000 Binary value Binary 001 Unsigned integer Decimal 010 Signed integer Decimal + sign 011 Unsigned integer Hexadecimal 100 Extended character set Text 101 Unsigned integer IDN 110 ANSI floating point number (single precision) Decimal value with exponent (fraction after decimal point is not taken into account) Reserved 111 Reserved Reserved

82 SERCOS III Slave Appendix 82 Reserved Position of decimal point for input and display (not applicable to floating point data) 0000 No places following the decimal point places following the decimal point Write protection in CP2 0 Write protection not effective for operation dat 1 Write protection effective for operation data Write protection in CP3 0 Write protection not effective for operation dat 1 Write protection effective for operation data Write protection in CP4 0 Write protection not effective for operation dat 1 Write protection effective for operation data Table 56: Coding of Attribute Information in IDN The display format and the data length must match. Corresponding combinations are marked in the table below: For more information on the extended character set see the specification, appendix E Unit This optional element holds the name of unit to be applied to the operational data which are stored under the respective IDN. The length is limited to at most 16 bytes. At least 2 bytes need to be used. These bytes are structured as follows: The first two bytes contain the hexadecimally coded value of the length of the programmed text. This is the text the master proposes to the slave. If these two bytes are 0, no other data are required and a zero-length name will be defined therefore. The next two bytes contain the hexadecimally coded value of the maximum allowed length of this text if the slave is permitted to change the text. (If this length is equal to 0, the slave is not permitted to do so.) Beginning from the fifth byte there is a string consisting of up to 60 bytes (characters) space for the actual name of the object assigned to the IDN. Characters exceeding the amount specified in the length bytes should be truncated by the SERCOS III slaves. When the data type is either binary or character string, the data has no unit. See the graphics below: Note: As the service channel transfers data in a word-aligned manner, it is recommended to use even values for the two length specifications described in this context. For more information, refer to the SERCOS III specification, chapter

83 SERCOS III Slave Appendix Minimum This optional element holds the minimum value allowed for the operational data which are stored under the respective IDN. Lower values cannot be processed by the slave, i.e. when a write request occurs with a lower value, the original value will not be changed.. The length is limited to at most 64 bytes. At least 2 bytes need to be used. In the following cases this element is not applicable: Working with binary numbers Working with character strings Operation data have variable length Maximum This optional element holds the maximum value allowed for the operational data which are stored under the respective IDN. Higher values cannot be processed by the slave, i.e. when a write request occurs with a higher value, the original value will not be changed. The length is limited to at most 64 bytes. At least 2 bytes need to be used. In the following cases this element is not applicable: Working with binary numbers Working with character strings Operation data have variable length Data There are 3 formats defined in the SERCOS III standard which can be applied here: Fixed length format with 2 bytes Fixed length format with 4 bytes Variable length format with support for up theoretically up to bytes (limited to 1368 bytes in the current implementation of the SERCOS III firmware.) In case of the variable length format these bytes are structured as follows: The first two bytes contain the hexadecimally coded value of the actual length of the data. This is the text the master proposes to the slave. If these two bytes are 0, no other data are required and a zero-length datum will be defined therefore. The next two bytes contain the hexadecimally coded value of the maximum allowed length of data if the slave is permitted to change the text. (If this length is equal to 0, the slave is not permitted to do so.) Beginning from the fifth byte there is a string consisting of up to 60 bytes (characters) space for the data of the object assigned to the IDN. Characters exceeding the amount specified in the length bytes should be truncated by the SERCOS III slaves. Note: As the service channel transfers data in a word-aligned manner, it is recommended to use even values for the two length specifications described in this context.

84 SERCOS III Slave Appendix List of Available SERCOS III IDNs/EIDNs The following list contains the IDNs of the standard commands which are available according to the SERCOS III specification. Some of those are specific to SERCOS III, they can be easily recognized by their number which is larger than On the other hand, IDNs which were already present in SERCOS II have numbers less than Additionally, product and application profile-specific IDNs may be defined. IDN S S S S S S S S S S S S S S S S S S S S S S S S Name Control unit cycle time (tncyc) Communication cycle time (tscyc) Class 1 diagnostic Interface status Telegram type Configuration list of AT IDN-list of operation data for CP2 IDN-list of operation data for CP3 IDN-list of invalid operation data for CP2 IDN-list of invalid operation data for CP3 Configuration list of MDT MST error counter MDT error counter Diagnostic message Slave arrangement (SLKN) Mask class 2 diagnostic Mask class 3 diagnostic CP3 transition check CP4 transition check SERCOS Interface version Length of the configurable data record in the AT Length of the configurable data record in the MDT IDN list of configurable data in the AT IDN list of configurable data in the MDT S Real-time control bit 1 S Allocation of real-time control bit 1 S Real-time control bit 2 S Allocation of real-time control bit 2 S Real-time status bit 1 S Allocation of real-timestatus bit 1 " S Real-time status bit 2 "

85 SERCOS III Slave Appendix 85 S Allocation of real-time status bit 2 " S Bit number allocation of real-time control bit 1 " S Bit number allocation of real-time control bit 2 " S Bit number allocation of real-time status bit 1 S Bit number allocation of real-time status bit 2 S SERCOS III: SCP type and revision S SERCOS III: Control unit cycle time (t Ncyc ) S SERCOS III: Communication cycle time (t Scyc ) S S S S S S S S S S S S S S S S S S S S S S S S S S S SERCOS III: Number of successive MDT errors SERCOS III: Feedback value computation time (t5) SERCOS III: AT transmission starting time (t1) SERCOS III: Synchronization time (t8) SERCOS III: Command value valid time (t3) SERCOS III: RTC offset in MDT SERCOS III: Length of MDT SERCOS III: RTC offset in AT SERCOS III: Length of AT SERCOS III: SVC offset in MDT SERCOS III:SVC offset in AT SERCOS III: Ring delay SERCOS III: Slave delay (SYNCCNT-P, SYNCCNT-S) SERCOS III: Transmission starting time IP channel SERCOS III: SYNC delay (P-Count,S-Count) SERCOS III: MAC address SERCOS III: IP address SERCOS III: Network mask SERCOS III: Gateway address SERCOS III: Sync jitter SERCOS III: Ring control node control SERCOS III: Ring status node status SERCOS III: Hardware identification SERCOS III: Maximum Transmission Unit (MTU) SERCOS III: Error counter MDT0 MST (P and S channels) SERCOS III: Error counter MDT0 3 (P and S channels) SERCOS III: Error counter AT0 3 (P and S channels) S SERCOS III: Error counter Port 1 & Port 2

86 SERCOS III Slave Appendix 86 S S S S S S S S S S SERCOS III: SERCOS address SERCOS III: List of SERCOS addresses in device SERCOS III: SERCOS III connections SERCOS III: SERCOS III connection classes SERCOS III: Device control SERCOS III: Device status SERCOS III: Electronic label SERCOS III: GDP type and revision SERCOS III: Resource structures of sub-device SERCOS III:Diagnostic number structure S SERCOS III: IO_Channel 0 S SERCOS III: IO_Channel 1 S SERCOS III: IO_Channel 2 S SERCOS III: IO_Channel 3 S SERCOS III: IO_Channel 4 S SERCOS III: IO_Channel 5 S SERCOS III: IO_Channel 6 S SERCOS III: IO_Channel 7 S SERCOS III: IO_Channel 8 S SERCOS III: IO_Channel 9 S SERCOS III: IO_Channel 10 S SERCOS III: IO_Channel 11 S SERCOS III: IO_Channel 12 S SERCOS III: IO_Channel 13 S SERCOS III: IO_Channel 14 S SERCOS III: IO_Channel 15 S SERCOS III: IO_Channel 16 Table 57: IDNs used in SERCOS III

87 SERCOS III Slave Appendix Example Applications CifxTestConsole The cifxtestconsole is a sample console-application for Win32. It was created using Microsoft Visual Studio 6. cifxtestconsole uses the cifx Device Driver. It demonstrates several tasks: SendReceiveWarmstartPacket() shows the usage of the Warmstart packet. ReadWriteIOData() reads and writes cyclic data. BenchmarkAccessIDN() tests the packet communication. The IDN S is read several times. getcompleteod() receives the complete OD from the device. Also the functionality of reading/writing of the watchdog time is covered by the functions GetWatchdogTime()/SetWatchdogTime(). Please close the application before download the firmware with the cifxsetup again. Figure 7: Screenshot of CifxTestConsole Tool

88 SERCOS III Slave Appendix Sercos3SlaveDiag Sercos3SlaveDiag is a graphical application which shows the status of a cifx50 device. It was created with Microsoft Visual Studio.NET Although this application needs the cifx Device Driver. Please close the application before downloading the firmware with the cifxsetup. Figure 8: Screenshot of Sercos3SlaveDiag Tool