DP Base Programming Interface for CP 5613/CP 5614 · Preface DP Base Programming Interface for CP 5613/CP 5614 C79000-G8976-C139-09 5 Preface Purpose of the Manual This manual supports

SIMATIC NET

DP Base Programming Interface for CP 5613/CP 5614

Manual

Preface, Contents

Basic Steps in Creating a DP Application

1

Overview of PROFIBUS DP 2

Overview of the DP Base Interface

3

Description of the DP Functions, Data, and Error Codes

4

Description of the Sample Programs

5

FAQ (Frequently Asked Questions)

6

Glossary, Index

C79000-G8976-C139-09

Release 04/2009

Copyright Siemens AG, 1999 to 2009, All rights reserved The reproduction, transmission or use of this document or its contentsis not permitted without express written authority. Offenders will beliable for damages. All rights, including rights created by patent grant or registration of a utility or design, are reserved.

Disclaimer We have checked the contents of this manual for agreement with the hardware and software described. Since deviations cannot be precluded entirely, we cannot guarantee full agreement. However, the data in this manual are reviewed regularly and any necessary corrections included in subsequent editions. Suggestions for improvement are welcome.

Siemens AG Automation and Drives Industrial Communication Postfach 48 48, D-90327 Nuernberg

C79000-G8976-C139-09 © Siemens AG 1999 to 2009 Subject to technical change.

Siemens Aktiengesellschaft Printed in the Federal Republic of Germany 2

Classification of Safety-Related Notices

This document contains notices which you should observe to ensure your own personal safety, as well as to protect the product and connected equipment. These notices are highlighted in the manual by a warning triangle and are marked as follows according to the level of danger:

! Danger indicates that death or severe personal injury will result if proper precautions are not taken.

! Warning indicates that death or severe personal injury can result if proper precautions are not taken.

! Caution with warning triangle indicates that minor personal injury can result if proper precautions are not taken.

Caution

without warning triangle indicates that damage to property can result if proper precautions are not taken.

Notice

indicates that an undesirable result or status can occur if the relevant notice is ignored.

Note

highlights important information on the product, using the product, or part of the documentation that is of particular importance and that will be of benefit to the user.

DP Base Programming Interface for CP 5613/CP 5614 C79000-G8976-C139-09 3

Trademarks

SIMATIC®, SIMATIC NET® and SINEC® are registered trademarks of Siemens AG.

Third parties using for their own purposes any other names in this document which refer to trademarks might infringe upon the rights of the trademark owners.

Safety Instructions Regarding your Product

Before you use the product described here, read the safety instructions below thoroughly.

Qualified Personnel

Only qualified personnel should be allowed to install and work on this equipment . Qualified persons are defined as persons who are authorized to commission, to ground, and to tag circuits, equipment, and systems in accordance with established safety practices and standards.

Correct Usage of Hardware Products

Please note the following regarding the correct usage of hardware products:

Caution

This device and its components may only be used for the applications described in the catalog or the technical description, and only in connection with devices or components from other manufacturers which have been approved or recommended by Siemens. This product can only function correctly and safely if it is transported, stored, set up, and installed correctly, and operated and maintained as recommended. Before you use the supplied sample programs or programs you have written yourself, make certain that no injury to persons nor damage to equipment can result in your plant or process. EU Directive: Do not start up until you have established that the machine on which you intend to run this component complies with the directive 2006/42/EEC.

DP Base Programming Interface for CP 5613/CP 5614 4 C79000-G8976-C139-09

Correct Usage of Software Products

Please note the following regarding the correct usage of software products:

Caution

This software may only be used for the applications described in the catalog or the technical description, and only in connection with devices or software products from other manufacturers which have been approved or recommended by Siemens. Before you use the supplied sample programs or programs you have written yourself, make certain that no injury to persons nor damage to equipment can result in your plant or process.

Prior to Startup

Before putting the product into operation, note the following warning:

Caution

Prior to startup you must observe the instructions in the relevant documentation. For ordering data of the documentation, please refer to catalogs or contact your local Siemens representative.

Preface


Preface

Purpose of the Manual

This manual supports you when creating DP user programs for the "DP Base Programming Interface", the programming interface of the CP 5613/CP 5614. It provides you with a comprehensive overview. The structure of DP user programs and the individual language elements are explained.

It is assumed that you are familiar with writing user programs in the "C" programming language in Windows.

How the SIMATIC CPs are named in this manual

Some SIMATIC CPs have one PROFIBUS connector and can be operated either as a DP master or DP slave; these are: CP 5603, CP 5613 A2, CP 5623. Unless stated otherwise, these are called "CP 5613" in this document.

Other SIMATIC CPs have two PROFIBUS connectors and can therefore be oper-ated both as a DP master or/and as a DP slave; these are: CP 5614 A2, CP 5624. Unless stated otherwise, these are called "CP 5614" in this document.

Scope of this Manual

This manual is valid as of the CD "SIMATIC NET PC Software, Edition 2008, Ser-vice Pack 2".

This manual is valid for the following communications processors: CP 5603, CP 5613 A2, CP 5614 A2, CP 5623, CP 5624

Recommendation

Read the following chapters to familiarize yourself with PROFIBUS DP, the DP Base programming interface, and the methods of creating a user program:

Preface


Chapter Content Chapter 1 Explains step-by-step how to create your DP user program. Chapter 2 Provides you with an overview of PROFIBUS DP. Chapter 3 Provides an overview of the DP Base programming interface and

outlines its advantages. Chapter 4 Describes the function calls of the DP Base programming interface

and the mechanisms for accessing the dual-port RAM. Chapter 5 Describes the supplied sample programs. Chapter 6 Provides useful information on the general aspects of writing user

programs.

Structure of the Documentation

You will find information on the use of this product in the following sources:

• Supplied paper documentation

• Text, PDF, and HTML files of the SIMATIC NET CDs (some available as bound volumes)

• Internet (http://www.ad.siemens.de/net)

• SIMATIC NET Product Catalog "IK PI"

Certification

The products and systems listed in this document are manufactured and marketed using a quality management system complying with DIN ISO 9001 and certified by DQS (certificate registration no. 2613). The DQS certificate is recognized in all IQNet countries (Reg. No.: 2613).

http://www.ad.siemens.de/net

Contents


Contents

1 Basic Steps in Creating a DP Application....................................................................... 11

2 Overview of PROFIBUS DP............................................................................................... 15

2.1 Where Does PROFIBUS DP Fit In? ....................................................................... 16 2.2 The Master-Slave-Concept of PROFIBUS DP ....................................................... 18 2.3 DP Communication Mechanisms............................................................................ 22 2.3.1 Cyclic Polling by the Master.................................................................................... 23 2.3.2 Acyclic Services and Alarms................................................................................... 25 2.4 CP 5613 Communications Processor..................................................................... 26 2.5 CP 5614 Communications Processor..................................................................... 27 2.5.1 The Transfer Software ............................................................................................ 28 2.5.2 The Configuration for the Transfer Software .......................................................... 29 2.6 Access to Process Data.......................................................................................... 30 2.7 Startup and Operational Phase of a DP System .................................................... 32 2.8 Modes of the DP Master ......................................................................................... 33 2.8.1 How a DP Master Starts Up.................................................................................... 35 2.8.2 How a DP Master Shuts Down ............................................................................... 36 2.9 Separation of the Slave Data from the DP Master User Program.......................... 37 2.10 Reliability of DP....................................................................................................... 39 2.11 Control Frames to One or More Slaves.................................................................. 40 2.12 The Importance of Configuration ............................................................................ 42 2.13 DP-V1 as an Extension of DP................................................................................. 44

3 Overview of the DP Base Interface .................................................................................. 47

3.1 Ways of Accessing the CP 5613/CP 5614 Communications Processor ................ 48 3.2 Special Features of the CP 5613/CP 5614............................................................. 51 3.2.1 Hardware and Software Events .............................................................................. 52 3.2.2 Fast Logic ............................................................................................................... 58 3.2.3 Timeout Monitoring ................................................................................................. 60 3.2.4 Constant Bus Cycle Time Mode ............................................................................. 61 3.2.5 Access to Operating Data in the Dual-port RAM.................................................... 62 3.3 How Does a DP Master User Program Access Process Data? ............................. 64 3.3.1 Reading DP Slave Input Data................................................................................. 65 3.3.2 Reading DP Slave Diagnostic Data ........................................................................ 67 3.3.3 Writing DP Slave Output Data ................................................................................ 70 3.3.4 Coordination in Multi-Thread Operation.................................................................. 71 3.4 How Does a DP Master User Program Recognize Changed Input Data and New

Diagnostic Data?..................................................................................................... 73 3.4.1 Recognizing Changes in the DP Slave Input Data ................................................. 74

Contents


3.4.2 Recognizing New DP Slave Diagnostic Data ......................................................... 75 3.5 Typical Sequences for the Master of the CP 5613/CP 5614.................................. 78 3.5.1 Initialization Phase, Productive Operation, and Shutdown Phase in DP Master

Operation ................................................................................................................ 79 3.5.2 DP Master Mode Polling ......................................................................................... 81 3.5.3 DP Master Operation with Hardware and Software Events.................................... 83 3.5.4 Acyclic Services Without Using Software Events ................................................... 86 3.5.5 Acyclic Services Using Software Events ................................................................ 88 3.6 Properties of the DP Slave on the CP 5613/CP 5614 ............................................ 90 3.6.1 Two Modes of the DP Slave on the CP 5613/CP 5614.......................................... 91 3.7 Basic Structure of a DP Slave User Program......................................................... 92 3.7.1 Typical Sequences in the "Simple Slave" Mode..................................................... 93 3.7.2 Typical Sequences in the "Dynamic Slave" Mode without Software Event............ 98 3.7.3 Typical Sequences in the "Dynamic Slave" Mode with Software Event............... 101 3.8 Multiple Protocols, DP User Programs, CPUs...................................................... 105

4 Description of the DP Functions, Data, and Error Codes............................................ 107

4.1 List of Functions of the CP 5613 and CP 5614 .................................................... 108 4.1.1 Overview of the Functions .................................................................................... 110 4.1.2 DP_start_cp .......................................................................................................... 113 4.1.3 DP_reset_cp ......................................................................................................... 115 4.1.4 DP_open ............................................................................................................... 116 4.1.5 DP_get_pointer ..................................................................................................... 118 4.1.6 DP_release_pointer .............................................................................................. 120 4.1.7 DP_close............................................................................................................... 121 4.1.8 DP_get_err_txt...................................................................................................... 123 4.1.9 DP_set_mode ....................................................................................................... 124 4.1.10 DP_slv_state......................................................................................................... 127 4.1.11 DP_read_slv_par .................................................................................................. 130 4.1.12 DP_global_ctrl....................................................................................................... 132 4.1.13 DP_ds_read .......................................................................................................... 135 4.1.14 DP_ds_write.......................................................................................................... 138 4.1.15 DP_fetch_alarm .................................................................................................... 141 4.1.16 DP_alarm_ack ...................................................................................................... 146 4.1.17 DP_get_actual_cfg................................................................................................ 149 4.1.18 DP_enable_event ................................................................................................. 152 4.1.19 DP_disable_event................................................................................................. 158 4.1.20 DP_get_result ....................................................................................................... 159 4.1.21 DP_get_cref .......................................................................................................... 162 4.1.22 DP_init_sema_object ............................................................................................ 163 4.1.23 DP_delete_sema_object....................................................................................... 165 4.1.24 DP_fast_logic_on.................................................................................................. 166 4.1.25 DP_fast_logic_off.................................................................................................. 170 4.1.26 DP_watchdog........................................................................................................ 172 4.1.27 DP_write_trc ......................................................................................................... 175 4.2 DP slave functions ................................................................................................ 184 4.2.1 Overview of the Slave Module Functions ............................................................. 185 4.2.2 DPS_open............................................................................................................. 187 4.2.3 DPS_close ............................................................................................................ 194 4.2.4 DPS_start.............................................................................................................. 196 4.2.5 DPS_stop.............................................................................................................. 197 4.2.6 DPS_get_baud_rate ............................................................................................. 198

Contents


4.2.7 DPS_get_gc_command........................................................................................ 200 4.2.8 DPS_get_state...................................................................................................... 203 4.2.9 DPS_set_diag ....................................................................................................... 205 4.2.10 DPS_get_ind......................................................................................................... 208 4.2.11 Structure Elements of DPS_C2_INITIATE_REQ ................................................. 220 4.2.12 DPS_set_resp....................................................................................................... 223 4.2.13 DPS_calc_io_data_len ......................................................................................... 231 4.3 Access to the Process Image of the CP 5613/CP 5614....................................... 232 4.3.1 Reading the Input Data of a DP Slave.................................................................. 233 4.3.2 Reading the Diagnostic Data of a DP Slave......................................................... 235 4.3.3 Writing the Output Data of a DP Slave ................................................................. 237 4.3.4 Checking the Slaves for Changed Data................................................................ 238 4.3.5 Querying the State of a DP Slave......................................................................... 240 4.3.6 Querying Information about the DP Master .......................................................... 241 4.3.7 Querying the Current Bus Parameters of the Master ........................................... 243 4.3.8 Querying Information about DP Slaves ................................................................ 245 4.3.9 Reading PROFIBUS Statistical Data .................................................................... 246 4.3.10 Querying the Fast Logic Status ............................................................................ 248 4.3.11 Reading and Triggering User Watchdog in the Dual-Port RAM ........................... 250 4.3.12 Activating/Deactivating the Generation of Hardware Events................................ 252 4.3.13 Sending Data with the CP 5614 as DP Slave....................................................... 255 4.3.14 Receiving Data with the CP 5614 as DP Slave .................................................... 256 4.3.15 Sending Diagnostic Data with the CP 5614 as DP Slave..................................... 257 4.3.16 Using the Constant Bus Cycle Time Mode........................................................... 258 4.3.17 Typical Phases in the Constant Bus Cycle Time Mode........................................ 264 4.3.18 Checking the Life Counter .................................................................................... 268 4.4 Error Handling....................................................................................................... 270 4.4.1 Entries in the error_decode, error_code_1 and error_code_2 structure

elements in Error Class DP_ERROR EVENT ...................................................... 274 4.4.2 Error Codes........................................................................................................... 277 4.5 Formats of the Slave Data .................................................................................... 292 4.6 Formats of the Slave Diagnostic Data .................................................................. 293 4.6.1 Overview of the Entire Structure........................................................................... 294 4.6.2 Format of the Diagnostic Data Header ................................................................. 295 4.6.3 Format of the Device-Related Diagnostic Data (Standard DP Slave) .................. 299 4.6.4 Format of the Device-Related Diagnostic Data (Slaves with DP-V1

Extensions) ........................................................................................................... 300 4.6.5 Format of ID-Related Diagnostics......................................................................... 305 4.6.6 Format of Channel-Related Diagnostics............................................................... 306 4.6.7 Format of the Revision Number............................................................................ 309 4.7 Format of the Slave Parameter Data .................................................................... 311 4.7.1 Structure of the General Slave Parameters.......................................................... 312 4.7.2 Structure of the Parameter Assignment Data....................................................... 315 4.7.3 Structure of the Configuration Data ...................................................................... 320 4.7.4 Meaning of GSD Files........................................................................................... 324

5 Description of the Sample Programs ............................................................................ 337

5.1 Starting the Simple Sample Program ................................................................... 338 5.2 Starting the Complete Sample Program............................................................... 340 5.3 Starting the "Fast Logic" Sample Program ........................................................... 342

Contents


5.4 Starting the Transfer Sample Program for the CP 5614....................................... 344 5.5 Configuring the Transfer for the CP 5614 Transfer Sample Program.................. 347

6 FAQ (Frequently Asked Questions)............................................................................... 349

6.1 FAQs about the Range of Functions of the Product............................................. 350 6.2 FAQs about Structuring the DP User Program..................................................... 352 6.3 FAQ Check List for Programmers......................................................................... 355 6.4 FAQs about Debugging and Starting Up Your Program....................................... 358 6.5 FAQs Miscellaneous Programming Questions..................................................... 359

7 Glossary ........................................................................................................................... 362

8 Index.................................................................................................................................. 370


Basic Steps in Creating a DP Application 1

This chapter recommends a step-by-step procedure for creating a DP user program based on the DP programming interface of the CP 5613 and CP 5614 known as "DP Base". The steps begin with the basics of PROFIBUS DP and are completed when you test your application.

The DP Base programming interface allows direct access to the DP process image in the dual-port RAM of the CP 5613/CP 5614. The DP Base programming inter-face is therefore not compatible with the DP programming interface of the CP 5511, the CP 5611 and the CP 5711.

Since the DP Base interface is a high-speed interface, it cannot be operated at the same time as the DP interface mentioned above on a CP 5613/CP 5614.



Procedure

The steps outlined below represent the fastest and simplest way of achieving your aims:

Step Description 1 Familiarize yourself with the basic principles of PROFIBUS DP. Read

the following Chapter 2 "Overview of PROFIBUS DP". 2 Familiarize yourself with the basic characteristics of the DP Base

programming interface of the CP 5613 and CP 5614. Read Chapter 3 "Overview of the DP Base interface".

3 Check through the contents of the subfolder "prog" in your installation folder so that you know what it contains and the purpose of the components for the subsequent steps. The subfolder contains the following: ● The "readme.rtf" file with the latest additional information and most

recent modifications.

● The C header file "dp_5613.h", dps_5614.h with the functions and data structures of the DP base interface and "5613_ret.h and 5614_ret.h" with the return codes.

● The import libraries "dp_base.lib" and "dps_base.lib" for linking to your DP user program.

● The sample programs and corresponding databases in the "examples" subfolder.

4 Now work through the source text of the sample program "ExamEasy" and read through the functions and data accesses in Chapter 4 ("Description of the DP Functions, Data, and Error Codes").

5 Adapt the "ExamEasy" sample program to suit your plant configuration, for example by using additional or other slaves. Compile and link the sample program and try it out. You may need to extend the "ExamEasy" sample database.

6 Now work through the source text of the sample program "ExamComp", modify the program and try it out with an extended sample database.

7 If you want to use the slave functions of the CP 5614, you should also work through the "transfer" sample, modify it to your requirements and try it out with an extended sample database.

8 Please read the FAQs in Chapter 6, particularly the check list for programmers and the information on structuring your DP user program.

Table continued on next page



Continued

Step Description 9 Now create your own DP user program. You can use the "ExamComp"

sample as a basis. 10 Test your application. Refer to the information and tips in the FAQ list in

Chapter 6 and the diagnostic options described in the readme file of the SIMATIC NET CD.




Overview of PROFIBUS DP 2

This chapter will familiarize you with the basic principles of PROFIBUS DP.

Overview of PROFIBUS DP


2.1 Where Does PROFIBUS DP Fit In?

PROFIBUS - The Worldwide Fieldbus Strategy

The trend towards reducing costs in automation engineering has meant that programmable controllers (PLCs), PCs, drives, transducers, and sensors are being networked more and more. This has resulted in greater distribution of these field devices using a fieldbus as the common communications medium for exchanging information.

The demand for an open, heterogeneous fieldbus system representing a safe and long-term investment for the user has been met by PROFIBUS. PROFIBUS is a bus system for communication between programmable controllers or PCs and field devices based on the European standard EN 50 170, Volume 2. This means that both users and manufacturers can be certain about long-term investments and guarantees "openness" for all applications conforming with the standard worldwide.

Created in 1989 by a consortium of companies and institutions, PROFIBUS has become the world’s most popular fieldbus in discrete manufacturing and process control. It is mature, proven technology that is ideal for supporting modern automa-tion systems. With over 25 million installed devices, it is a significant driving force for the world’s production plants. By continuously enhancing the technology, PROFIBUS International has ensured that PROFIBUS remains the dominant field-bus solution. The ongoing commitment of the world’s automation major suppliers ensures that investments today are fully protected for the lifetime of any plant. PROFIBUS is unique in offering a fully integrated solution for discrete and process applications, a major benefit in the process industries where upstream, mainstream and downstream processes have to work together. Industries using PROFIBUS range from critical petrochemical operations and high volume robotic manufactur-ing plants, right across the spectrum to food and drink, water/waste treatment plants.

Siemens has supported PROFIBUS for many years as an optimized fieldbus solution and reliable investment for the user and supplies both products and complete systems. Apart from the programmable controllers (PLCs), devices such as network components, PC communications processors, and field devices for PROFIBUS are also included in the wide range of products.

The Role of the PC in PROFIBUS

Apart from the trend towards distribution, the standard PC is also becoming more important as an automation tool particularly in control tasks and for plant visualization thanks to its increased performance and widespread availability.



The Advantages of DP

PROFIBUS-DP is intended for fast data exchange in the fieldbus area.

Distributed peripheral devices collect the input signals locally and transfer them via the fieldbus to the central controller in the PG/PC. In the opposite direction, the central controller sends the output data to the distributed peripheral devices.

The use of PROFIBUS DP means a considerable reduction in cabling compared to previous direct wiring of components.



2.2 The Master-Slave-Concept of PROFIBUS DP

Description

The master-slave concept of PROFIBUS DP describes the communications mechanisms between active and passive nodes on PROFIBUS.

Distributed I/Os

The distributed (peripheral) I/O allows you to use a variety of analog and digital input/output modules over PROFIBUS with a distributed configuration in close proximity to the process. This is normally abbreviated to DP.

Node Types

PROFIBUS DP defines two types of bus node:

• DP master DP masters are active nodes and control DP slaves.

A distinction is made between class 1 and class 2 DP masters.

• DP slaves DP slaves are normally passive nodes (distributed I/O devices).

A distinction is made between DP-V0 and DP-V1 slaves.



DP masters

DP Master Class 1 A DP master class 1 communicates cyclically with the DP slaves assigned to it. Cyclic communication means that during the data transfer phase the DP master constantly sends the latest output data to the DP slaves and receives the latest input data in the response frame. With a DP master class 1, communication involves central functions such as:

• Assignment of parameter values and configuration of the DP slaves during startup

• Cyclic data transfer to the DP slaves

• Monitoring the DP slaves

• Preparing diagnostic information

Depending on the application, these tasks can, for example, also be handled by a SIMATIC S7 programmable controller. In the follow text , the DP master class 1 is simply known as the DP master.

DP Master Class 2 A DP master class 2 is a DP master that does not operate cyclically and is used for special functions such as online diagnostics in a PROFIBUS DP system. A DP master class 2 can also establish additional connection-oriented DPC2 communication relations with DP-V1 slaves. The DP-V1 slaves must support these DPC2 additional functions. Essentially, these include connection establishment, connection termination, reading data records, writing data records, and data transfer. This programming interface supports the DPC2 functions with the slave submodule of the CP 5614.



DP Slave

A DP slave is a peripheral device from which the DP master reads in input information and to which it sends output information cyclically. There are also DP slaves that provide only input or only output information.

DP slaves are generally inexpensive since passive participation on the bus is simple to implement.

DP-V0 Slave A DP-V0 slave is a simple device that becomes active only when requested by the DP master. Essentially, it provides the following standard functions:

• Sends input data from the process to the DP master.

• Transfers diagnostic data to the DP master.

• Passes on output data from the DP master to the process.

DP-V1 Slave A DP-V1 slave has the functionality of a DP-V0 slave with the following additional functions:

• Processing data records Data records contain special additional information specified using the slot and index. A data record can be sent via a DP master class 1 (DPC1 connection) or via a DP master class 2 (DPC2 connection). A DP master can send data records to a DP-V1 slave (write data record) or request a data record from it (read data record).

• Alarm handling DP-V1 slaves with alarm capability can send alarms to the master. Alarms are special diagnostic data containing important events. The DP master must acknowledge alarms by sending alarm acknowledge frames to the DP slave.

Overview of the Communication

Section 2.13 shows how DP-V1 communication fits in to PROFIBUS DP.

Configuration

Operating a DP system requires a configuration. Using configuration software, you create a "database" that is required by the DP master.

Configuration tools are available for the CP 5613/CP 5614. For more detailed information on the tools (for example SIMATIC NCM PC, SIMATIC STEP 7) and on how to configure, please refer to the supplied documentation.



Basic Structure of a DP System

The following diagram illustrates how to implement a process control with DP slaves using a PC and a CP 5613/CP 5614 communications processor.

DP slaves

PC as DP master withCP 5613/CP 5614

PROFIBUS

Process

Process input/output data



2.3 DP Communication Mechanisms

Description

Communication between a DP master (class 1) and DP slaves uses two basic mechanisms:

• Cyclic polling by the master This mode is the basic communication mode and is supported by all slave types (DP-V0 and DP-V1 slaves).

● Acyclic services and alarms This mode is an expansion of the basic communication. It is supported only by DP-V1 slaves.



2.3.1 Cyclic Polling by the Master

Description

The basic communication between a DP master and the distributed I/O stations takes the form of polling. Polling means that the DP master sends cyclic calls to the DP slaves assigned to it. A separate call frame is sent to each DP slave.

In one polling cycle, all the operational DP slaves are addressed. The next polling cycle starts after the last slave has been addressed. This ensures that the data is up to date.

Polling is handled automatically and independently by the firmware of the CP 5613/CP 5614.

DP master

Input data(diagnostic datawhen necessary)

Output data

DP slaves

Figure 1 Schematic Representation of Polling

Output Data

The call frame contains the current output data that the DP slave will apply to its output ports. The data belonging to this area are specified by the DP user program. If a DP slave does not have output ports, an "empty frame" is sent to it instead.

Input Data

The reception of a call frame must be confirmed by the DP slave by returning a confirmation frame. The confirmation frame contains the current input data that are applied to the input ports of the DP slave. If a DP slave does not have input ports, an "empty frame" is returned instead.



Diagnostic Data

Diagnostic data is generated when the slave detects an error. This is signaled to the master which then fetches the diagnostic data using a special call frame.



2.3.2 Acyclic Services and Alarms

Acyclic Services

Using acyclic services, the DP user program can send special data records to DP-V1 slaves or read them from the slaves. Within a DP-V1 slave, the data records are addressed using a slot number and an index. The significance of the data records is specific to the particular slave. In contrast to the input/output data, data records are not transferred cyclically but only once per job.

Alarms

Alarms are a particular form of diagnostic data that must be acknowledged specifically by the DP master program in contrast to standard diagnostic frames. Only DP-V1 slaves can send alarms to the DP master. When the DP master user program confirms reception of an alarm, the DP master reacts by sending an alarm acknowledge frame to the DP-V1 slave.



2.4 CP 5613 Communications Processor

Description

The CP 5613 communications processor in conjunction with the DP user program that uses the functions of the DP base programming interface together form a PROFIBUS DP master class 1.

DP slave

PROFIBUS DP

CP 5613

Masteruser program

DP slave

This DP base programming interface describes how to create your own DP master class 1 applications for the CP 5613/CP 5614.



2.5 CP 5614 Communications Processor

Description

The CP 5614 consists of a master section that is identical to the CP 5613. It has an additional slave submodule (piggyback module) that allows attachment to a further PROFIBUS network. With the slave submodule, a CP 5614 can be operated as a DP slave on a PROFIBUS network. The slave is controlled by a remote DP master, for example a CP 5613 or SIMATIC S7 programmable controller.

DP slave

PROFIBUS DP (II)

PROFIBUS DP (I) R

S48

5CP 5614

RS

485

Slave

Master

Control systemDP master

Slaveapplication

Masterapplication

PC

DP slave

This DP base programming interface describes how to create your own DP slave applications for the CP 5614.



2.5.1 The Transfer Software

To operate the CP 5614 with both master and slave functionality, you can use, for example the transfer software supplied (see Section 5.4). The transfer software transfers data between the master and slave section of the CP 5614.

The transfer software includes an access with which additional input, output or diagnostic jobs can be executed. Your DP user program can use this access to add extra functionality to the transfer program (in the sample program, a counter is activated on the CP 5614 slave submodule).

The example illustrates how a separate transfer function with a local application can access the process image of the CP 5614 (slave and master components of the CP 5614).

PROFIBUS DP (II)

PROFIBUS DP (I)

RS

485CP 5614

RS

485

Slave

Master

Transfersoftware

PC

Control systemDP master

DP slave DP slave

Access



2.5.2 The Configuration for the Transfer Software

To allow you to specify the separate transfer function, a configuration tool and a configured transfer file are also shipped as an example.

Using the configuration tool, you can specify how data is copied from master to slave and vice-versa.



2.6 Access to Process Data

Description

A distinction must be made between two general types of process data:

• Input/output data and standard diagnostic data

• Slave data records and alarms



Access to Input/Output Data and Standard Diagnostic Data

Input/output data and standard diagnostic data is stored on the DP master (CP 5613/CP 5614) in the dual-port RAM. This data represents the process image. There are three different data areas for each configured DP slave:

• Input data from the DP slave

• Output data to the DP slave

• Standard diagnostic data from the DP slave

The DP user program accesses the input and output data in the dual-port RAM of the CP 5613/CP 5614 directly using C pointers; in other words without needing function calls. Standard diagnostic data can be read directly or using the function calls of the DP Base programming interface.

Slave data

DP master

Slave nSlave 2Slave 1

DP application program

PROFIBUS

Output data Diagn. dataInput data

Access to Slave Data Records and Alarms

Slave data records are fetched or sent directly using the function calls of the DP Base programming interface.

Alarms are special diagnostic data that is buffered and managed by the firmware of the CP 5613/CP 5614. The DP user program must read out this alarm data with a function call of the DP Base programming interface and acknowledge it.



2.7 Startup and Operational Phase of a DP System

Functions of the DP Master during Startup and Operation

The DP master handles the following tasks independently:

• Initialization of the DP slaves

• Data transfer in the operational phase

• Monitoring the DP slaves

Initialization of the DP Slaves

The DP master can only exchange process data with the DP slaves when it has previously assigned parameter values and configured the DP slaves using special frames. The parameter assignment/configuration is contained in the database and is performed as follows:

• During the startup phase of the DP master.

• Following any temporary failure of a DP slave during the productive phase

The parameter assignment frame provides the DP slave with global operating parameters (for example Group_Ident, Watchdog on/off).

The configuration frame is sent after the DP slave has been assigned parameters. This frame contains the defined configuration of the DP slave. The configuration includes the number and type of input/output ports. The DP slave compares the received configuration frame with the values that it determined itself during the startup phase. If the values match, the DP slave confirms the configuration and changes to the operational phase.

Data Transfer in the Operational Phase

During the operational phase, the cyclic data transfer between the DP master and DP slaves takes place. The DP user program can also send acyclic data and fetch and acknowledge alarms during this phase.

Monitoring the DP Slaves

If a DP slave detects an error/fault, it can signal this to the DP master in the form of diagnostic data (standard diagnostic data or diagnostic data in the form of alarms). The received diagnostic data is then available on the DP master and must be evaluated by the DP user program.



2.8 Modes of the DP Master

Overview

During communication with the DP slaves, the DP master can adopt the following four modes:

• OFFLINE

• STOP

• CLEAR (or AUTOCLEAR)

• OPERATE

Each of these modes is characterized by defined actions between the DP master and the DP slaves.

OFFLINE

No communication between the DP master and DP slaves. This is the startup mode of the DP master.

STOP

In this mode, there is also no communication between the DP master and the DP slaves. In contrast to the OFFLINE mode, a DP diagnostic station (DP master class 2) can read out diagnostic information from the DP master.

CLEAR

All the DP slaves entered and activated in the database are assigned parameters and configured in this mode. This is followed by the cyclic data exchange between the DP master and DP slaves. In this CLEAR mode, the value 0 or empty frames are sent to all slaves with a process output; in other words, process output is deactivated. The input data of the slaves are known and can be read out.

If a slave fails, for example no longer answers, the DP master automatically attempts to reassign parameters and configure the slave and return it to the polling cycle.



AUTOCLEAR

The behavior of the DP master in the AUTOCLEAR mode is the same as in the CLEAR mode.

With certain errors, the DP master automatically changes to the AUTOCLEAR mode; for more detailed information, refer to Section 2.10, "Reliability of DP".

OPERATE

The cyclic, productive data transfer to the DP slaves takes place in the OPERATE mode. In this mode, the DP slaves are addressed one after the other by the DP master. The call frame transfers the actual output data and the corresponding response frame transfers the actual input data.

If a slave fails, for example no longer answers, the DP master automatically attempts to reassign parameters and configure the slave and return it to the polling cycle.



2.8.1 How a DP Master Starts Up

Description

When the CP 5613/CP 5614 starts up, the DP master must run through the following modes in the specified order controlled by the DP user program: OFFLINE -> STOP -> CLEAR -> OPERATE.

Stage Mode Typical Actions of the DP User Program 1 OFFLINE The DP user program initiates the change to the STOP

mode. Reaction: The DP master changes to the STOP mode.

2 STOP The DP user program queries the STOP mode. Once the STOP mode is reached, the program initiates the change to the CLEAR mode. Reaction: The DP master changes to the CLEAR mode.

3 CLEAR The DP user program queries the CLEAR mode. If the CLEAR mode is reached, the program can enter the output data in the process image. The program then initiates the change to the OPERATE mode. Reaction: The DP master changes to the OPERATE mode.

4 OPERATE The DP user program queries the OPERATE mode. Once the OPERATE mode is reached, productive data exchange with the slaves begins.



2.8.2 How a DP Master Shuts Down

Description

When the CP 5613/CP 5614 shuts down, the DP master must run through the modes in the following order controlled by the DP user program: OPERATE -> CLEAR -> STOP -> OFFLINE

Stage Mode Typical Actions of the DP User Program 1 OPERATE The DP user program initiates the change to the CLEAR

mode. Reaction: The DP master changes to the CLEAR mode.

2 CLEAR The DP user program queries the CLEAR mode. Once the CLEAR mode is reached, the program initiates the change to the STOP mode. Reaction: The DP master changes to the STOP mode.

3 STOP The DP user program queries the STOP mode. Once the STOP mode is reached, the program initiates the change to the OFFLINE mode. Reaction: The DP master changes to the OFFLINE mode.

4 OFFLINE The DP user program queries the OFFLINE mode.



2.9 Separation of the Slave Data from the DP Master User Program

The process image is separate from the DP master user program and the slaves

To increase efficiency, the DP standard does not include flow control. The timing of the cyclic updating of the process image of the DP master is connected neither to the DP slaves nor to the DP master user program. Examples of different situations are shown below:

Example: Slave input data changes extremely quickly

If, for example, an analog slave modifies its output data more quickly than it can be fetched in the polling cycle of the DP master (sample sequence 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, ...), the DP master only receives a sequence of "snapshots" that it enters in the process image (sequence 1.1, 1.3, 1.5, 1.8, ...).

Example: The DP master user program reads very quickly

If the DP master user program reads the process image more quickly than it can be updated within the polling cycle of the DP master, values will be obtained more than once. Based on the example above, the DP master user program then, for example, reads a sequence 1.1, 1.1, 1.1, 1.1, 1.2, 1.2, 1.2, 1.2, 1.3, 1.3, 1.3, 1.3, 1.4, 1.4 ...

Example: DP master user program writes very quickly

If the DP master user program writes output data to the process image faster than this can be transferred to the slave within the polling cycle of the DP master, only a series of "snapshots" will be transferred the slave (sample sequence 1, 4, 6, ...)

Example: DP master user program reads very slowly

If the DP master user program only reads the process image occasionally, for example because it has other tasks to perform in the meantime, it is possible that some values will be skipped. A sequence such as 1.1, 1.2, 1.3, 1.4 in the process image then becomes, for example, 1.1, 1.3 etc. in the DP master user program.



Remedy

If the DP master user program requires a better link to the slave than described above, there are a number of options available:

• With the hardware events of the CP 5613/CP 5614, the DP master user program can be informed of changes on the slave. Under certain circumstances, this results in a faster reaction of the DP master user program to a change in the input data.

• With user-specific implementations on the DP master and DP slave, flow controls can be achieved to link the DP master with the DP slaves and to avoid loss of data.

• If the polling cycle is too slow, it may be possible to increase the update rate of the process image by increasing the data transmission rate.

• The hardware event at the beginning of the cycle and end of the cycle of the CP 5613/CP 5614 can be used to synchronize the DP master user program with the polling cycle. These events are only supported in the constant bus cycle time mode. It is only possible to set parameters for the constant bus cycle time with STEP 7/NCM.



2.10 Reliability of DP

Reliability Concept

The DP programming interface provides various mechanisms to limit the effects of the failure of a communication connection or the DP master.

• A watchdog function can be configured for the DP slave so that if a DP slave is not accessed for a longer period of time it can change automatically to a safe state.

• The AUTOCLEAR function can be activated to ensure that if DP slaves are not accessible, the DP master automatically changes from OPERATE to the (AUTO)CLEAR mode.

• A sign-of-life monitoring function can be activated on the CP 5613/CP 5614 to detect inactivity of a DP user program (failure) and to change the DP slaves to a safe operating mode.

The AUTOCLEAR function

The AUTOCLEAR option can be set during configuration.

How it works: If an error occurs on one or more DP slaves during the productive phase, the DP master changes automatically from the OPERATE mode to the AUTOCLEAR mode (switches to a safe mode). In the AUTOCLEAR mode, the DP master behaves just as in the CLEAR mode. The DP master then sends data in the output direction with the value 0 or empty frames to the DP slaves. The DP master can no longer exit the AUTOCLEAR mode automatically; in other words, the change to the OPERATE mode must be triggered explicitly by the user.



2.11 Control Frames to One or More Slaves

Purpose of Control Frames

For particular applications, there are four control commands available with which a control frame can be sent. In standard applications, these are not required.

A control frame is a frame that the master sends to one slave, a group, several groups, or to all slaves. These frames are not acknowledged by the slaves.

Control frames are used to transfer control commands (known as global controls) to the selected slaves to allow synchronization. A control command contains three components:

• Identifier indicating whether one or more DP slaves are being addressed

• Identification of the slave group

• Control command

Creating Groups

During configuration, you can assign a group identifier to a slave; in other words, it is possible to include several slaves in one group.

Which slaves belong to a group is specified when you create the database. During this phase, each DP slave can be assigned a group number. The DP slave is informed of this group number during the parameter assignment phase. You can specify a maximum of eight groups.



Control Commands

The following control commands can be sent to DP slaves when necessary during operation:

Control Commands

Description

FREEZE After receiving the FREEZE command, the DP slaves freeze the current states of all inputs. In the read cycles that follow, the DP master receives this frozen input data. The current input data is available to the DP master only after an UNFREEZE command or a further FREEZE command; with the additional FREEZE command this only applies to the current cycle.

UNFREEZE After receiving the UNFREEZE command, the freezing of the inputs is canceled. The DP slaves once again provide the DP master with the current input data.

SYNC When the DP slaves receive the SYNC command, they freeze the current states of all outputs. The output data sent by the DP master following this is initially not accepted by the DP slaves. The current output data is accepted by the DP slaves only following an UNSYNC command or a further SYNC command; with the additional SYNC command, this applies only to the current cycle.

UNSYNC After receiving the UNSYNC command, the freezing of the outputs is canceled. The current output data is accepted by the DP slaves again cyclically.



2.12 The Importance of Configuration

Using the DP Database

The DP database contains information about the bus parameters of PROFIBUS and about the slaves on the network. This information is evaluated when the CP 5613/CP 5614 starts up.

Configuring Slave Data Areas

During configuration, you specify the number and type (input, output, analog, digital) of the data areas of all the slaves. This configuration data is sent to the slave during startup and is then checked by the slave. If the configuration data does not match the actual properties of the slave, the slave enters this in the diagnostic data and it is not included in cyclic operation.

Activating the Watchdog

If the watchdog of a DP slave is activated in the configuration, the DP master must communicate with the DP slave within a selected time.

If there is no communication within this time, the DP slave switches its outputs to a safe state and no longer takes part in data transfer with the DP master section since the DP slave assumes that a serious problem has occurred, for example wire break or failure of the DP master.

The DP master must then assign parameter values to the DP slave and configure it again. Following this, the exchange of productive data can be resumed.

The values adopted by the outputs can be found in the descriptions of the DP slaves.

Configuring the AUTOCLEAR Property

If one of the activated slaves does not take part in the data transfer and if the AUTOCLEAR function is set, the DP master automatically changes to the CLEAR mode (with the coding AUTOCLEAR).



Configuring Direct Data Exchange

The CP 5613/CP 5614 supports direct data exchange during cyclic polling. Only specially designed DP slaves (publishers/subscribers) are capable of direct data exchange. In direct data exchange, the publisher (transmitting slave) sends the response data with a special identifier and special timing so that not only the DP master but also the other DP slaves (subscribers) can listen in. You configure direct data exchange with STEP 7/NCM.

Configuring the "Min_Slave_Interval"

The "Min_Slave_Interval" is the minimum time between the DP master addressing a DP slave in two consecutive polling cycles. This is calculated automatically based on the GSD data of the slaves.

Meaning of GSD Files

Project engineering tools for the PROFIBUS DP master interpret the GSD files of the various DP slave types and generate the database of the DP master based on this information. To be able to use the slave module of the CP 5614, a suitable GSD file must be available. For more detailed information on this topic, refer to Section 4.7.4.



2.13 DP-V1 as an Extension of DP

Overview of the DP Protocol with DP-V1 Extensions

Apart from cyclic DP master operation (see Section 2.3.1), two further extensions are defined as DP-V1: DPC1 and DPC2. The paragraphs below contain an overview of these extensions:

DPC1 DP DPC2

DP slave with DP-V1additional functions

User program User program

DP/DPC1 progr.interface

DPC2 progr.interface

PG/PCDP master class 1

PG/PCDP master class 2

Acyclic modeMSAC_C2

Cyclic modeMSCY_C1

AcyclicmodeMSAC_C1

DP-V1 Master Class 1 (DPC1)

With DPC1, a cyclic DP master can also send or read slave data records and receive and acknowledge alarms. This data is not process data but slave-specific additional data (for example, data records for reassignment of parameter values).



DP-V1 Master Class 2 (DPC2)

An additional DP master that is not operating cyclically can establish connections to DP-V1 slaves using DPC2 initiate calls and send or read data records to or from the slaves, for example for reassigning parameter values or diagnostics.




Overview of the DP Base Interface 3

The programming interface of the CP 5613/CP 5614 is known as the DP Base programming interface.

This chapter explains the basic characteristics of the DP Base programming interface including typical call and access sequences to prepare you for creating your own DP applications.

For a detailed description of the function calls and data access, please refer to Chapter 4.



3.1 Ways of Accessing the CP 5613/CP 5614 Communications Processor

Overview

There are basically two mechanisms with which you can access the CP 5613/CP 5614 communications processor:

• Function calls (DP Base programming interface)

• Access to the dual-port RAM of the CP 5613/CP 5614 (process image) using pointers

The DP user program uses the functions of the supplied DLLs. These are passed on to the CP 5613/CP 5614 communications processors by the drivers.

The DP user program can also access the process image on the communications processor with a C pointer .

CP 5613/CP 5614

DP user program

Process image

dp_base.dlldps_base.dll

Drivers

C pointer



Access Using Pointers

While your DP user program is running, data of the CP 5613 and CP 5614 that is required regularly is available directly in the dual-port RAM .

Most importantly, this data includes the process image (input, output, and diagnostic data of the DP slaves) along with a variety of status and configuration data and control registers.

The "DP_get_pointer" function call provides the base address (C pointer) for the DPR_CP5613_DP_T structure. With this C pointer, your DP user program can access the process image and the other data areas in the dual-port RAM efficiently.

The DPR_CP5613_DP_T structure describes the structure of the data above in the dual-port RAM of the CP 5613 and CP 5614.



Function Calls

Your user program can execute administrative tasks and make use of less commonly required communication properties of the CP 5613 and CP 5614 during run time by calling functions of the DP Base programming interface.

The DP Base programming interface is a C programming interface and consists of two DLLs. The table below describes the two DLLs:

DLL Name Description Function Name dp_base.dll Contains DP master

functions of the CP 5613/CP 5614.

Function names start with "DP_".

dps_base.dll Contains DP slave functions of the CP 5614.

Function names start with "DPS_" (the S stands for slave submodule).

The DP Base programming interface also includes the following header files and import libraries:

• Header Files

– dp_5613.h (definitions for DP master)

– dps_5614.h (definitions for DP slave)

– 5613_ret.h (error codes for DP master)

– 5614_ret.h (error codes for DP DP slave)

• Import Libraries

– dp_base.lib (master functions)

– dps_base.lib (slave functions)



3.2 Special Features of the CP 5613/CP 5614

Overview

The CP 5613/CP 5614 has a series of special additional functions and properties that allow the implementation of highly efficient and reliable DP user programs. Since the CP 5613/CP 5614 generally has special hardware control logic for these functions, execution is extremely fast.

The special characteristics of the CP 5613/CP 5614 are as follows:

• Hardware and software events

• Fast Logic

• Timeout monitoring

• Constant bus cycle time mode

• Access to operating data in the dual-port RAM



3.2.1 Hardware and Software Events

Hardware Events

The CP 5613/CP 5614 can monitor important process data and operating states independently controlled by the DP user program.

If the monitored event occurs, a control register is set in the dual-port RAM. This control register can be checked quickly and efficiently by DP user program using a pointer to access it.

Using the Hardware Events

By checking the control registers in the dual-port RAM, the DP user program can recognize whether or not the CP 5613/CP 5614 has detected a particular event. Since the event is monitored by a hardware control logic, certain events (for example changes to the process image) can be detected quickly and efficiently.

Software Events

With certain events of the CP 5613/CP 5614, a Windows DP user program can be informed interrupt-controlled using a Windows semaphore .

Using the Software Events

Software events allow synchronization between the DP user program and the CP 5613/CP 5614 using Windows semaphores.

If a selected event occurs on the CP 5613/CP 5614, the corresponding Windows semaphore is activated and the DP user program is resumed (where this was waiting at a synchronization object).

Using software events can, in some situations, also reduce CPU load because, for example, the DP user program does not need to check the process image constantly but is informed of changes in the process image interrupt-controlled by the CP 5613/CP 5614.



Using a Combination of Hardware and Software Events

With certain events, a combination of hardware and software events is possible providing the advantages of both mechanisms: High performance and low CPU load.

How the Mechanism Works If a hardware event is detected by the CP 5613/CP 5614, the corresponding control register is set and an interrupt to the driver of the CP 5613/CP 5614 is triggered. The driver then informs the Windows DP user program using a Windows semaphore.

Example The input data of a DP slave change. The change is signaled by the hardware event "Change in input data" by setting the corresponding control register in the dual-port RAM. In addition to this, the software event also activates the Windows DP user program that is waiting at a synchronization object using a Windows semaphore. By evaluating the control register, this recognizes the DP slave on which the change took place and then reads its input data.

Events that Trigger Hardware Events

The overview below shows the possible criteria for triggering hardware events:

• The input data of a DP slave have changed. The hardware event "Change in slave input data" can be activated for each DP slave separately.

• A DP slave sends new diagnostic data (regardless of whether it has changed or not). The hardware event "New slave diagnostic data" can be activated for each DP slave separately.

• A Fast Logic trigger condition was detected.

• A new DP cycle begins in the constant bus cycle time mode.

• The cyclic part of the DP cycle ends in the constant bus cycle time mode.



Events that Trigger Software Events

The overview below shows the possible criteria for triggering software events:

• The acknowledgment of an asynchronous function call of the DP Base programming interface has been received.

• The "Change in slave input data" hardware event was triggered.

• The "New slave diagnostic data" hardware event was triggered.

• A Fast Logic trigger condition was detected.

• A new DP cycle begins in the constant bus cycle time mode.

• The cyclic part of the DP cycle ends in the constant bus cycle time mode.

Note 1 To be able to trigger a software event, a suitable Windows semaphore must be initialized once using the DP_init_sema_object function.

Note 2 With software events, the corresponding hardware events must also be activated. Exception: The "Acknowledgment of an asynchronous function call of the DP programming interface has been received" event.

Implementing Filter Mechanisms with Events

The DP user program can activate hardware or software events selectively. This allows you to implement a simple filter mechanism .

Example You only want the changes in the input data of a particular DP slave to be reported as an event.

The DP user program therefore only enables the "Change in slave input data" event for this DP slave and not for the other DP slaves. As a result, there is a filter for data changes only on this DP slave.



Further Information on Hardware Events

The table below names the hardware events and indicates the section in which the event is described in detail.

Hardware Events Reference to Function Calls, Direct Access, General Information

"Change in slave input data"

Sections 4.3.4 and 4.3.12 describe how to check whether input data of DP-slaves has changed by directly accessing control registers. These sections also describe how the event must be enabled again following a change in the input data.

"New slave diagnostic data" Section 4.3.12 describes how to check whether diagnostic data have been received by direct access to control registers. This section also describes how to enable the event again after receiving new diagnostic data.

"Fast Logic trigger condition was triggered"

Section 4.1.24 describes the DP_fast_logic_on function call with which a trigger condition is activated. Section 4.1.25 describes the DP_fast_logic_off function call with which a trigger condition is deactivated. Section 4.3.10 describes how to query the Fast Logic status and how to acknowledge a Fast Logic trigger event by direct access to control registers.

● "A new DP cycle begins in the constant bus cycle time mode" and

● "The cyclic part of the DP cycle ends in the constant bus cycle time mode".

Section 4.3.16 describes the principle and handling of the constant bus cycle time mode.



Further Information on Software Events

The following table names the software events and indicates the sections where these events are described in detail:

Software Events Reference to Function Calls, Direct Access, General Information

Software events in general

Section 4.1.22 describes the DP_init_sema_object function call with which various Windows semaphores can be initialized. Section 4.1.23 describes the DP_delete_sema_object function call with which a Windows semaphore can be removed again.

Software event "Acknowledgment of an asynchronous function call has been received".

Section 4.1.20 describes the DP_get_result function call that returns the acknowledgments of various asynchronous function calls.

Other software events

These software events are linked to corresponding hardware events. For more detailed information, see the references in the above table of hardware events.

Note For events relating to input data and diagnostic data, the release (in the "req_mask" element) of the semaphore is implemented with the DPR_DATA_INT_CLEAR_AND_UNMASK constant so that the corresponding semaphore (interrupt-controlled) can be activated).



Overview of the Sequence of Events that can be Signaled Using Windows Semaphores

The following diagram shows the basic structure of a Windows DP master user program that is informed of various software events of the DP master.

Activate other hardwareevents:• Const. bus cycle: start,

end of DP cycle• DP_fast_logic_on

When the program starts up, initialize the required semaphores withDP_init_sema_object and activate the hardware events “Change inslave input data“ and “New diagnostic data“ 1) for the first time.

Send asynchronousfunction call:• DP_ds_read/write

• DP_alarm_ack

Wait at semaphore 2)

• DP_enable_event

• DP_get_actual_cfg

When program complete, release semaphorewith DP_release_sema_object.

Check control register:• If input/diagnostic event:

activate event again 1) andthen read out data.

• Other events: Evaluateevent.

Fetch result withDP_get_result andevaluate it

1) When the hardware event is activated, the triggering of an interrupt (by writing the constant DPR_DATA_INT_CLEAR_AND_UNMASK in the "req_mask" control register) must be enabled so that the CP 5613/CP 5614 can signal the event as a software event.

2) The DP user program can wait at Win32 API functions (for example WaitForMultipleObjects, WaitForSingleObject, MsgWaitForMultipleObjects) at the semaphores.



3.2.2 Fast Logic

Description

Fast Logic is an automatic function on the CP 5613/CP 5614: DP slave input data is monitored automatically by the CP 5613/CP 5614. If a trigger condition set by the DP master user program occurs, the CP 5613/CP 5614 automatically sets the relevant DP slave output data. Up to four trigger conditions can be activated at the same time.

Uses

With the Fast Logic property of the CP 5613/CP 5614, you can set parameters for the DP-master so that it automatically monitors data of DP slaves and triggers specific reactions on other DP slaves.

This has the following advantages:

• The DP master user program does not need to read out and monitor input data constantly. The control logic is handled by the CP 5613/CP 5614. This can reduce the CP load.

• Very fast reaction to changes in plant states.



Further Information on Fast Logic

The following table names the Fast Logic functions and indicates the sections where these are described in detail:

Fast Logic Functions Reference to Function Calls, Direct Access, General Information

Activate Fast Logic Section 4.1.24 describes the DP_fast_logic_on function call with which a trigger condition is activated.

Deactivate Fast Logic Section 4.1.25 describes the DP_fast_logic_off function call with which a trigger condition is deactivated.

Query status in dual-port RAM Section 4.3.10 describes how the Fast Logic status can be queried and a Fast Logic trigger event acknowledged using direct access to control registers in the dual-port RAM.

Activate software event for Fast Logic Refer to "Further Information on Software Events" on Page 56.



3.2.3 Timeout Monitoring

Description

Timeout monitoring is a programmable, automatic watchdog function of the CP 5613/CP 5614. The CP 5613/CP 5614 monitors the DP master user program to check whether it retriggers the watchdog in the dual-port RAM within a selectable time.

Uses

The timeout monitoring (watchdog) of the CP 5613/CP 5614 detects a permanent or sporadic failure of the DP master user program on the PC and automatically changes the DP master from OPERATE to CLEAR (safe plant state).

Further Information on the Watchdog

The following table names the watchdog functions and indicates the sections where these are described in detail:

Watchdog Functions Reference to Function Calls, Direct Access, General Information

Watchdog on/off Section 4.1.26 describes the DP_watchdog function with which the monitoring function can be activated and deactivated.

Trigger watchdog and query status Section 4.3.11 describes how to trigger the watchdog and read the status using direct access to the dual-port RAM.



3.2.4 Constant Bus Cycle Time Mode

Description

The constant bus cycle time mode is a mode that can be selected for special applications in which the transfer of user data between the DP master and the DP slaves takes place at constant (equidistant) intervals. The DP master user program can also synchronize itself with the constant bus cycle time bus cycle using hardware or software events.

Uses

The constant bus cycle time mode allows the implementation of applications that require bus cycles of a constant length and a very close link between the DP master user program cycle and the bus cycle; for example clocked controls in motion control.

Further Information on the Constant Bus Cycle Time Mode

The following table names the functions of the constant bus cycle time mode and indicates the sections where these are described in detail:

Constant Bus Cycle Time Functions Reference to Function Calls, Direct Access, General Information

Using the constant bus cycle time mode.

Section 4.3.16 describes the principle and handling of the constant bus cycle time mode.

Additional Functions for the CP 5623/CP 5624

Section 4.1.28 describes how the cycle start interrupt can be delayed with the DP_delay_irq function. Section 4.1.29 describes how the re-maining cycle time can be queried with the DP_cycle_time function.



3.2.5 Access to Operating Data in the Dual-port RAM

Description

Operating data is important information in the dual-port RAM of the CP 5613/CP 5614 relating to the DP master and its DP slaves. The operating data can be divided up as follows:

• general operating data (for example bus parameters)

• configuration information of the DP slaves (for example amount of input and output data)

• current mode of the DP master

• operability of the DP slaves

Uses

All the operating data required when the DP master user program executes are updated automatically by the CP 5613/CP 5614 and can be queried extremely efficiently using direct access to the dual-port RAM.

Example: The "Operability of the DP slaves" information indicates whether or not each DP slave is involved in cyclic data transfer. Based on this, a DP master user program can easily recognize whether the input/output data of the DP slave in the process image are valid.



Overview of the Operating Data

The following table names the operating data types and indicates the section in which they are described in detail:

Type of Data Reference to Direct Access, General Information

Current status of the DP slaves: • READY • NOT READY

Section 4.3.5 describes how to query the operating state of DP slaves

Information on the DP master: ● Current mode of the DP master:

OFFLINE, STOP, CLEAR, AUTOCLEAR, OPERATE

● Identification number of the certification

● Hardware and firmware version

Section 4.3.6 describes how to query important information on the DP master.

Configured bus parameters Section 4.3.7 describes how to query the current bus parameters of the DP master.

Further information on the DP slave: ● Slave type ● Number of configured input and

output bytes ● Configured/not configured

Section 4.3.8 describes how to query further important information on DP slaves.

PROFIBUS statistics counter (error counter)

Section 4.3.9 describes how to query important statistics and error counters.



3.3 How Does a DP Master User Program Access Process Data?

Overview

The following sections explain how a DP master user program accesses this process data:

• Read DP slave input data

• Read DP slave diagnostic data

• Write DP slave output data

These sections also explain points to note when using the multitask mode (several tasks access the CP 5613/CP 5614 at the same time).



3.3.1 Reading DP Slave Input Data

Description

DP slave input data is located in the dual-port RAM. Each DP slave has its own data area. If a DP slave sends new input data to the DP master, the old data is overwritten.

The DP slave input data in the dual-port RAM is accessed using a C pointer. The C pointer is obtained using the "DP_get_pointer" function. This points to the "DPR_CP5613_DP_T" structure that describes the image of the dual-port RAM.

Dynamic Access to the Dual-Port RAM

When reading the input data, the DP master user program has the choice between two types of access:

• Consistent reading

• Non consistent reading

Consistent Reading

Consistent reading means that all the input data of a slave originate from the same bus cycle.

By selecting "Consistent reading", a DP master user program can interlock the input data of a DP slave for the duration of the access. During this time, the DP master cannot overwrite the current input data of this DP slave in the dual-port RAM.

Consistency can be guaranteed up to a maximum data length of 244 bytes.

Consistent reading involves three steps:

Step Description 1 Interlocking the input data of the DP slave 2 Reading the input data of the DP slave 3 Releasing the input data of the DP slave



Non Consistent Reading

Non consistent reading means that the DP master can overwrite the DP slave input data of the old cycle while the DP master user program is reading. This is somewhat faster than consistent reading.

Caution If the DP slave input data involves more than two bytes there is no guarantee that all the data comes from the same cycle. It is therefore possible that part of the data originates from the current and the rest of the data from the previous bus cycle. If this possibility is unacceptable for your application, you must read "Consistently".

Note It may, for example, be useful to do without consistent reading if the input data of the DP slave to be evaluated can only be a maximum of two bytes long. Inconsistency can only occur with longer data.

Example of an Application with Detailed Information

You will find an example of an application for reading DP slave input data in Section 4.3.1 and in Section 4.3.4.



3.3.2 Reading DP Slave Diagnostic Data

Description

DP slave diagnostic data is located in the dual-port RAM. Each DP slave has its own data area and an additional diagnostic counter. This counter is activated whenever a diagnostic message is received from the DP slave. A new diagnostic message overwrites the old values in the dual-port RAM.

When reading the diagnostic data, the DP master user program has the choice of two mechanisms:

Access to the diagnostic data in the dual-port RAM using a C pointer. The C pointer is obtained with the "DP_get_pointer" function. This points to the "DPR_CP5613_DP_T" structure that describes the image of the dual-port RAM.

Access using the DP_fetch_alarm function call DP_fetch_alarm returns standard diagnostic information or diagnostic information with alarm data.

Caution 1 Direct access to the diagnostic data of DP-V1 slaves with alarm capability in the dual-port RAM is not permitted. Instead, the DP_fetch_alarm function must be used.

Reason The diagnostic data of DP-V1 slaves with alarm capability can include alarms that must be confirmed explicitly by the DP master user program with "Alarm Acknowledge" (see DP_alarm_ack function in Section 4.1.16). Diagnostic data with alarms (just as standard diagnostic data without alarms) are written to the dual-port RAM and also buffered in the firmware. This buffering makes sure that diagnostic data containing alarms is not overwritten by new diagnostic data. In contrast to direct access that only ever returns the last diagnostic entry, the DP_fetch_alarm function accesses the buffered diagnostic data. This makes sure that no alarm is lost.

Caution 2 Direct access to the dual-port RAM and DP_fetch_alarm calls must not be combined because the same diagnostic data of a DP slave would otherwise be displayed more than once.



Caution 3 If the DP master user program reads the diagnostic data (assuming this is permitted) directly from the dual-port RAM, the type of access "Consistent reading" must be selected (see below). Without consistent reading, there is no guarantee that the diagnostic data will be interpreted correctly.

Note 1 If you use the DP_fetch_alarm function due to DP-V1 slaves, you can also use this function for any DP-V0 slaves in your system.

DP_fetch_alarm returns not only diagnostic data with alarms but also standard diagnostic data.

Advantage You only need to implement one uniform access mechanism for DP-V0 and DP-V1 slaves in your DP master user program.

Note 2 The DP master user program is intended to interpret the diagnostic data that have been read out by evaluating individual elements assuming they exist; these elements are as follows: Header, device-related diagnostics, ID-related diagnostics, channel-related diagnostics, revision number. This is the only way in which error situations can be detected (see also Section 4.6 and the documentation of the DP slaves).



Consistent Reading

Consistent reading means that all the diagnostic data of a slave originate from the same cycle.

By selecting "Consistent reading", a DP master user program must interlock the diagnostic data of a DP slave for the duration of the access. During this time, the DP master cannot overwrite the current diagnostic data of this slave in the dual-port RAM.

Consistency can be guaranteed up to a maximum data length of 244 bytes.

Consistent reading involves three steps:

Step Description 1 Locking the diagnostic data of the DP slave 2 Reading the diagnostic data and diagnostic counter of the DP slave 3 Releasing the diagnostic data of the DP slave

Non consistent reading

Note the following warning about reading diagnostic data:

Caution Non-consistent reading of diagnostic data is not permitted. Otherwise the uniqueness of the diagnostic data cannot be guaranteed.

Example of an application with detailed information

You will find an example of an application for reading consistent DP slave diagnostic data in Section 4.3.2.



3.3.3 Writing DP Slave Output Data

Description

DP slave output data are located in the dual-port RAM. Each DP slave has its own data area.

This is accessed directly in the dual-port RAM using a C pointer. The C pointer is obtained using the "DP_get_pointer" function. This points to the "DPR_CP5613_DP_T" structure that describes the image of the dual-port RAM.

Dynamic Access to the Dual-Port RAM

If the DP master user program writes the output data of a DP slave directly to the dual-port RAM, it always uses the "Consistent writing" access mechanism.

Consistent writing means that all output data of a slave originate from the same cycle.

Writing Output Data

Writing output data to the dual-port RAM involves two steps:

Step Description 1 Writing output data to the data area of the DP slave. 2 Triggering transfer of the output data.

Example of an Application with Detailed Information

You will find an example of an application for writing DP slave output data in Section 4.3.3.



3.3.4 Coordination in Multi-Thread Operation

Description

If your DP user program consists of more than one thread, make sure that it is not possible for more than one thread to access the process image of the CP 5613/CP 5614 at the same time.

Reason The control registers that you use for consistent access can be overwritten by other threads if access is not coordinated. This can lead to the current access to the data in the process image failing.

For example, the consistency of the data currently being read by a thread cannot be guaranteed.

Remedy

To avoid access conflicts as described above, you must implement a common interlock mechanism so that threads cannot interrupt each other when accessing the process image. You can achieve this with synchronization mechanisms such as semaphores, mutex etc. from Windows.



Example of a Sequence

The following diagram illustrates the principle of the sequence of a thread (X) that interlocks access to the dual-port RAM (DPR) using a common Windows semaphore. A further thread (not shown in the diagram) that is competing with thread X to access the dual-port RAM must do this in exactly the same way as thread X. If the common semaphore is not obtainable, the thread waits until it is released again.

Access to DPRnecessary?

yes

no

no

yes

Thread X

Semaphore free?

Access to DPR

Occupy semaphore

Release semaphore



3.4 How Does a DP Master User Program Recognize Changed Input Data and New Diagnostic Data?

Overview

This section describes various ways in which a DP master user program can recognize changes in the process image.

The following detection mechanisms are explained:

• Recognizing changes in the DP slave input data

• Recognizing new DP slave diagnostic data



3.4.1 Recognizing Changes in the DP Slave Input Data

Description

To recognize changes in the DP slave input data, the following basic mechanisms are available:

• Reading DP slave input data cyclically

• "Change in slave input data" hardware event

• "Change in slave input data" software event

Reading DP Slave Input Data Cyclically

Your DP master user program reads out all the input data cyclically using direct access to the dual-port RAM (see Section 3.3.1) and checks whether this data has changed compared with the last read access.

"Change in slave input data" hardware event

Your DP master user program activates the "Change in slave input data" hardware event and checks the corresponding control register in the dual-port RAM cyclically.

If the value of a control register indicates that the input data of a DP slave has changed, the DP master user program must reactivate the corresponding control register and then read out the input data of this DP slave using direct access to the dual-port RAM.

"Change in slave input data" software event

This mechanism can be used by Windows DP master user programs. The DP master user program uses the relevant Windows semaphore to get information on changes in the DP slave input data.

If the input data changes, the event is signaled to the DP master user program by setting the semaphore. The DP master user program then checks the corresponding control register in the dual-port RAM.

If the value of a control register indicates that the input data of a DP slave has changed, the DP master user program must reactivate the relevant control register and then read out the input data of this DP slave using direct access to the dual-port RAM.



3.4.2 Recognizing New DP Slave Diagnostic Data

Description

To recognize whether or not new diagnostic data have been received, your DP master user program can use the following basic mechanisms:

• Querying the diagnostic counter cyclically

• "New diagnostic data" hardware event

• "New diagnostic data" software event

• Acknowledgment of the "DP_enable_event" notification function

Querying the diagnostic counter cyclically

If a DP slave sends new diagnostic data to the master, the corresponding diagnostic counter in the dual-port RAM is incremented.

The DP master user program checks the value of the diagnostic counter cyclically. If the value has changed compared to the last query, there are new diagnostic data available.

The DP master user program then reads the diagnostic data by direct access or using DP_fetch_alarm.

"New diagnostic data" hardware event

Your DP master user program activates the "New slave diagnostic data" hardware event and checks the corresponding control register cyclically.

If the value of a control register signals that new diagnostic data have been received, the DP master user program must reactivate the control register again and then read out the diagnostic counter and the diagnostic data of this slave (by direct access or using DP_fetch_alarm).



"New diagnostic data" software event

This mechanism can be used by Windows DP master user programs. The DP master user program uses the relevant Windows semaphore to get information on the reception of diagnostic data.

When new diagnostic data is received, the event is signaled to the DP master user program by setting the semaphore. The DP master user program then checks the corresponding control register in the dual-port RAM.

If the value of a control register signals that new diagnostic data have been received for a DP slave, the DP master user program must release the control register again and then read out the diagnostic counter and the diagnostic data of this DP slave (by direct access or using DP_fetch_alarm).

Acknowledgment of the "DP_enable_event" notification function

The asynchronous notification function "DP_enable_event" (see Section 4.1.18) can signal various, selectable events as an asynchronous acknowledgment to a DP master user program. Among other things, new diagnostic data can also be signaled.

The DP_enable_event function is acknowledged automatically when new diagnostic data have been received from one or more DP slaves. This indicates which DP slaves have signal diagnostic data. The DP master user program then reads out this diagnostic data (by direct access or using DP_fetch_alarm, see Section 3.3.2).

The arrival of the acknowledgment of the DP_enable_event function must be checked using the DP_get_result function (see Section 4.1.20). DP_get_result is a function with which asynchronous acknowledgments are read out. For each asynchronous function call (for example DP_enable_event), the corresponding acknowledgment must be fetched by this function.

The DP_get_result call is possible under the following conditions:

• The DP master user program calls DP_get_result (cyclically) until the expected acknowledgment is received.

• The DP master user program is activated by a Windows semaphore using the "The acknowledgment of an asynchronous call has been received" software event and then reads out the acknowledgment with the DP_get_result function.



Overview of Using DP_enable_event

The following diagram illustrates the basic procedure with which the arrival of new diagnostic data is signaled to the DP master user program using the DP_enable_event function and the "The acknowledgment of an asynchronous call has been received" software event.

When program starts up, initialize the semaphore“DP_OBJECT_TYPE_ASYNC” (asynchronous acknowledgment)with DP_init_sema_object.

Send asynchronousfunction callDP_enable_event withDP_DIAG_ALARM selector

Wait at semaphore 1)

Fetch acknowledgment ofDP_enable_event call withDP_get_result.

On completion of program, release thesemaphore with DP_release_sema_object

Read out diagnostic data

1) The DP master user program can wait at Win32 API functions (for example WaitForMultipleObjects, WaitForSingleObject, MsgWaitForMultipleObjects) at the semaphore.



3.5 Typical Sequences for the Master of the CP 5613/CP 5614

Basic Structure of the DP Master User Program

A DP master user program can be divided into the following sections:

• Initialization phase

• Productive operation

• Shutdown phase

Depending on the access mechanisms used, the sequence of the program will differ.



3.5.1 Initialization Phase, Productive Operation, and Shutdown Phase in DP Master Operation

Initialization phase

The typical initialization phase of a CP 5613/CP 5614 activates the CP and brings the DP master to the OPERATE mode. The following steps are necessary:

Step Action Meaning 1 DP_start_cp CP is initialized. 2 DP_open Logon at the CP. 3 DP_get_pointer Exclusive access to the process image. 4 DP_set_mode (STOP) Change the master to the STOP mode. 5 Query the master status

in the dual-port RAM (see Section 4.3.6)

Using direct access to the dual-port RAM, check whether the master status STOP has been reached. Continue at step (6) only when this status has been reached.

6 DP_set_mode (CLEAR) Change the master to the CLEAR mode, slaves are included in cyclic operation according to the information in the database.

7 Query the master status in the dual-port RAM (see Section 4.3.6)

Using direct access to the dual-port RAM, check whether the master status CLEAR has been reached. Continue at step (8) only when this status has been reached.

8 DP_set_mode (OPERATE)

Bring the master to the OPERATE mode.


Using direct access to the dual-port RAM, check whether the master status OPERATE has been reached. Change to productive operation only after this status has been reached.



Productive Operation

The DP master user program can access the data in the process image, trigger DP-V1 jobs, and fetch their confirmations as well as trigger other DP functions. The sequences are described in greater detail in the following sections.

• DP master mode polling (see Section 3.5.2).

• DP master mode with hardware/software events (see Section 3.5.3).

• Acyclic services without using software events (see Section 3.5.4).

• Acyclic services using software events (see Section 3.5.5).

Shutdown Phase

Shutting down the CP 5613/CP 5614 changes the DP master to the OFFLINE mode and is completed when the CP 5613/CP 5614 stops. This requires the following steps:

Step Action Meaning 1 DP_set_mode

(CLEAR) Bring the DP master to the CLEAR mode, the slaves are reset.


Using direct access to the dual-port RAM, check whether the master status CLEAR has been reached. Continue at step 3 only when this status has been reached.

3 DP_set_mode (STOP) Bring the master to the STOP mode, cyclic operation is terminated.


Using direct access to the dual-port RAM, check whether the master status STOP has been reached. Continue at step 5 only when this status has been reached.

5 DP_set_mode (OFFLINE)

Bring the master to the OFFLINE mode.


Using direct access to the dual-port RAM, check whether the master status OFFLINE has been reached. Continue at step 7 only when this status has been reached.

7 DP_release_pointer Enable access to the process image. 8 DP_close Logoff at the CP 9 DP_reset_cp Stop the CP.



3.5.2 DP Master Mode Polling

Description

After the CP 5613/CP 5614 has been initialized as described above, the DP master user program can use the CP by polling; in other words, using cyclic direct access without waiting mechanisms.

A cycle for reading and writing the process data can be implemented with the tools described below.



Typical Sequence of Steps in a Polling Cycle

All the steps described below are achieved by direct access to the process image using the C pointer returned by the "DP_get_pointer" function. Taken together, they represent an example of a polling cycle.

Step Action Meaning 1 Query the master status in

the dual-port RAM (see Section 4.3.6).

Input data is only valid in the OPERATE and CLEAR modes. Output data can only be sent in the OPERATE mode.

2 Check the status of the slaves in the process image (see Section 4.3.5).

Communication functions only when the DP slaves are in the READY mode.

3 As an option: Check whether data has changed on a slave (see Section 4.3.4), if yes: release the "req_mask" control register.

Your DP master user program can recognize whether or not input data from a DP slave has changed.

4 Read consistent input data from the slaves (see Section 4.3.4).

For further processing in the DP master user program.

5 Check for new diagnostic data of the DP slaves, evaluate the diagnostic counter (see Section 4.3.2).

If the diagnostic counter has changed since the last cycle, there is new diagnostic data.

6 If it is present, read the diagnostic data of the DP slaves (see Section 4.3.2, 4.1.15).

For further processing in the DP master user program.

7 Write output data of the slaves (see Section 4.3.3).

As a result of processing the input and diagnostic data.



3.5.3 DP Master Operation with Hardware and Software Events

Description

After initializing the CP 5613/CP 5614 as described above, the DP master user program can activate hardware events and wait until they arrive with semaphores. Using hardware events can replace or supplement the polling described in Section 3.5.2.

The sections below describe the following:

• Initializing the semaphores

• Using hardware events

• Logging off the semaphore

Initializing the Semaphores

Before you can use hardware events, semaphores must be created as follows:

Step Action Meaning 1 Initialize a semaphore

for hardware events (function DP_init_sema_object).

The DP base DLL provides semaphores for the following tasks:

● Changing input data

● Receiving diagnostic information

● Cycle start

● Cycle end

● Fast Logic

The selector for data change is, for example DP_OBJECT_TYPE_INPUT_CHANGE.



Using Hardware Events

After getting the required semaphores, steps 1 and 2 can be executed followed by steps 3 to 7 to activate and fetch events cyclically:

Step Action Meaning 1 Optional: Activate

hardware event "Change in slave input data" (see Section 4.3.4, release control register "req_mask").

With this, the DP master user program indicates that it requires a semaphore to activate if input data change.

2 Optional: Activate hardware event "New diagnostic data" (see Section 4.3.12, release control register "req_mask" in "ef.diag[ ]").

With this, the DP master user program indicates that it requires a semaphore to activate if diagnostic data arrive.

3 Optional: DP_fast_logic_on

Send fast logic job.

4 Wait for semaphore (for example, WaitForMultipleObjects).

The DP master user program or the calling thread waits until one of the events occurs. "WaitForMultipleObjects" is a Windows 32-bit API function.

5 Detect the type of event. The semaphore identifies the type of event, for example change in the input data.

6 Detect the source of the event (which slaves?) and, if applicable, release the control register; also check whether Fast Logic was triggered.

Check the dual-port RAM for the following: ● Set data change flags (see Section

4.3.4)

● Changed diagnostic counters (see Section 4.3.2)

● Fast Logic trigger (see Section 4.3.10)

7 Read and process the slave data that has changed.

Read and evaluate the process image (input/diagnostic data); see Section 3.3, "How Does a DP master User Program Access Process Data".



Clearing the Semaphores

After the last use of the hardware events, clear your semaphores as follows:

Step Action Meaning 1 Clear semaphores for

events (function DP_delete_sema_object).

Releases the previously initialized semaphore.



3.5.4 Acyclic Services Without Using Software Events

Description

After initializing the CP 5613/CP 5614 as described above, the DP master user program can use DPC1 functions at the same time as the cyclic operation to exchange DPC1 data with DP slaves and to respond to alarms.

This section describes how acyclic services can be used for polling without using software events; in other words,when continuously querying slaves without waiting mechanisms.

Individual pairs of jobs and confirmations can be used parallel to each other.

"Write data record" (DPC1)

Write data record (DPC1), can be used as follows:

Step Action Meaning 1 Send the write job

(DP_ds_write). On completion of the function, the job is active.

2 Poll the result (DP_get_result) until the job is completed.

The result can be recognized by the order_id in the request field.

"Read data record" (DPC1)

Read data record (DPC1) can be used as follows:

Step Action Meaning 1 Send read job

(DP_ds_read). On completion of the function, the job is active.





Receiving and Responding to an Alarm

An alarm can be received and responded to as follows:

Step Action Meaning 1 Check whether an alarm

is present (DP_fetch_alarm).

If there is no alarm, this is indicated by the function result.

2 If received: Send alarm acknowledgment (DP_alarm_ack).

On completion of the function, the job is active.





3.5.5 Acyclic Services Using Software Events

Description

The polling mode described in Section 3.5.2 for DPC1 can also be replaced by operation with semaphores (software event "The acknowledgment of an asynchronous job has arrived").

The sections below describe the following:

• Initializing the semaphore

• The elements of continuous operation

• Logging off

Initializing the Semaphore

Before it is used, the semaphore must be created as follows:

Step Action Meaning 1 Initialize a semaphore for

acknowledging asynchronous jobs (function DP_init_sema_object).

The DP Base DLL provides a semaphore for all asynchronous jobs (type DP_OBJECT_TYPE_ASYNC).



Using the Semaphore Based on the Example "Write data record" (DPC1)

The following sequence illustrates how the semaphore can be used based on the example "write data record" (DPC1).

Step Action Meaning 1 Send the write job

(DP_ds_write). On completion of the function, the job is active.

2 Wait for semaphore (for example, WaitForMultipleObjects).

The DP master user program or the calling thread waits until the event occurs. "WaitForMultipleObjects" is a Windows 32-bit API function.

3 Fetch result (DP_get_result).

The DP_get_result function reads out the asynchronous acknowledgment. Based on the Order-id parameter, the acknowledgment can be assigned to the correct job.

The other asynchronous services (DPC1) function analogously.

Clearing the Semaphore

After the last use, clear your semaphore as follows:


events (function DP_delete_sema_object).




3.6 Properties of the DP Slave on the CP 5613/CP 5614

DP Slave Functions

The properties of the DP slave on the CP 5613/CP 5614 depend on the DP configuration and the mode set by the DP slave user program. The DP slave on the CP 5614 can be used in different variants (modular, non-modular, different I/O lengths).

DP Slave and DP Master

The CP 5613 can be used either as a DP master or as a DP slave.

The DP master and DP slave on the CP 5614 can be operated independent of each other. Data transfer between the two DP user programs (for DP master and DP slave) and therefore between the two bus segments is, of course, also possible.

Transfer Software with CP 5614

The package includes sample software with which the data can be routed between various DP slaves of the master section and the slave submodule.

This is particularly advantageous in applications in which the master section is used to control a separate bus and the PC is connected, for example, via the slave module with a host computer.



3.6.1 Two Modes of the DP Slave on the CP 5613/CP 5614

Overview

The DP slave on the CP 5613/CP 5614 can be initialized in two modes:

• "Simple slave" mode

• "Dynamic slave" mode

The two modes differ in the way in which the slave module reacts to the parameter assignment and configuration frames of the controlling DP master. The DP master sends these frames when it initializes the DP slave, for example when it first starts up or restarts following a longer problem.

"Simple Slave" Mode

In this mode, all the data necessary to include the slave submodule in the data exchange is transferred to the CP 5613/CP 5614 when the DPS_open (... slave_mode=DPS_SM_SIMPLE ...) function is called.

The advantage of this is that the DP slave user program can read outputs and write inputs without first needing to check the validity (in other words whether they match the set values) of the received parameter assignment and configuration data. This is checked automatically by the firmware of the slave submodule.

"Dynamic Slave" Mode

In the "Dynamic Slave" mode, the DP slave user program must explicitly confirm whether or not it accepts the received parameter assignment and configuration data. This allows greater flexibility in the DP slave user program.

Example: A DP slave user program reacts flexibly to the initialization of a DP master, in other words, the DP slave adapts itself to the settings sent by the DP master dynamically (particularly in terms of the number of input and output bytes).

Disadvantage The structure of the DP slave user program is more complicated because the reception of new parameter assignment and configuration frames must be queried permanently. The received values must also be evaluated by the DP slave user program itself.



3.7 Basic Structure of a DP Slave User Program

Overview

A DP slave user program can be divided up as follows:

• Initialization Phase

• Productive operation

• Shutdown phase

Depending on the mode of the DP slave on the CP 5614 and the access mechanisms used, the program will be executed differently.



3.7.1 Typical Sequences in the "Simple Slave" Mode

Description

In the "Simple Slave" mode, the user provides all the information required with DPS_open. Without any further interaction with the DP slave user program, the DP master can then bring the DP slave into productive operation.

Initialization Phase

A typical initialization is described below:

Step Action Meaning 1 DP_start_cp CP is initialized. 2 DPS_open Initialization of the slave submodule:—

The "DPS_SM_SIMPLE" bit is set in the "slave_mode" parameter, the expected parameter assignment and configuration data is in the "init_data" parameter.

3 DPS_start Start the slave submodule. 4 DP_get_pointer Exclusive access to the process image.



Productive operation of a standard DP slave (without DPC1 or DPC2 requests, without alarms)

The DP slave user program can read and write data in the process image.

In productive operation, the DP slave can receive new parameter settings and be configured by the controlling DP master at any time due to a problem, for example a bus fault. In the "Simple Slave" mode, this is handled by the slave submodule; in other words without any action on the part of the DP slave user program.

During productive operation, step 1 is repeated cyclically.

Step Action Meaning 1 Access to the process

image Read and write data in the process image (access as necessary)



Productive operation of a DP slave with DP-V1 capability, with DPC1 or DPC2 requests or alarms


In productive operation, a DP slave with DP-V1 capability can receive new parameter settings and be configured by the controlling DP master at any time due to a problem, for example a bus fault. In the "Simple Slave" mode, this is handled by the slave submodule; in other words without any action on the part of the DP slave user program.

During productive operation, steps 1 through 5 are repeated cyclically.

Step Action Meaning 1 As an option: DPS_get_ind Only if DPC1/DPC2 functions are

used, check whether indications have arrived. The following indications are possible: (a) DPS_C1_READ_REQ (b) DPS_C1_WRITE_REQ (c) DPS_C1_ALARM_REQ (d) DPS_INITIATE_REQ (e) DPS_C2_READ_REQ (f) DPS_C2_WRITE_REQ (g) DPS_C2_XPORT_REQ (h) DPS_C2_ABORT_REQ

2 When the indication ( ) arrives,

perform the following action:

(a) DPS_set_resp Read data record request has arrived; Reaction: 1. Check request. 2. Add requested data and

acknowledge positively or negatively.

(b) DPS_set_resp Write data record request has arrived; Reaction: 1. Check request. 2. Accept transmitted data and

acknowledge positively or negatively.




Continued

Step Action Meaning (c) — Alarm acknowledge frame has arrived;

Reaction: Check parameters. (d) DPS_set_resp Initiate request of a DPC2 master has

arrived; Reaction: 1. Check the connection parameters. 2. Enter own connection parameters and

acknowledge positively or negatively. (e) DPS_set_resp Read data record request has arrived;

Reaction: 1. Check request. 2. Add requested data and acknowledge

positively or negatively. (f) DPS_set_resp Write data record request has arrived;

Reaction: 1. Check request. 2. Accept transmitted data and

acknowledge positively or negatively. (g) DPS_set_resp Data transport request has arrived;

Reaction: 1. Check request. 2. Accept transmitted data, add requested

data and acknowledge positively or negatively.

(h) — If an abort request has arrived: Check con_id and reason_code.

3 If an alarm needs to be sent to the DP master: Trigger the alarm with DPS_set_diag

Send alarm (coding: "Device-related diagnostics").

4 Access to the process image

Read and write data in the process image (access as necessary)

5 Go to Step 1. DPS_get_ind must be called cyclically (only if DPC1/DPC2 functions are being used).



Shutdown Phase

To shut down the CP 5614, the slave submodule changes to the OFFLINE mode and finishes by stopping the CP:

Step Action Meaning 1 DPS_stop Bring the slave to the OFFLINE state. 2 DP_release_pointer Enable access to the process image. 3 DPS_close Log off on the slave submodule. 4 DP_reset_cp Stop the CP.



3.7.2 Typical Sequences in the "Dynamic Slave" Mode without Software Event

Description

In the "Dynamic Slave" mode without using software events, the DP slave user program must constantly use the DPS_get_ind function to check whether (new) parameter assignment and configuration frames have been received from the DP master. It must then fetch this data and acknowledge.


A typical initialization phase is described below:

Step Action Meaning 1 DP_start_cp CP is initialized. 2 DPS_open Initialization of the slave module –

The "DPS_SM_DYNAMIC" bit is set in the "slave_mode" parameter, the "init_data" parameter contains the default configuration.






In productive operation, the DP slave can receive new parameter settings and be configured by the controlling DP master at any time due to a problem, for example a bus fault. In the "Dynamic Slave" mode, the parameter assignment or configuration must be confirmed explicitly by the DP slave user program. As a result, the DP slave user program must be prepared to receive parameter assignment and configuration frames at any time. Execution of the DP slave user program in productive operation is different from that in the "Simple Slave" mode.

Step Action Meaning 1 DPS_get_ind Query whether indications have

arrived. The following indications are possible: (a) DPS_CHK_PRM (b) DPS_CHK_CFG

2 When the indication ( ) arrives,


(a) DPS_set_resp New parameter assignment has arrived: Reactions: 1. Check the parameter assignment data. 2. Acknowledge positively or

negatively. (b) DPS_set_resp New configuration has arrived:

Reactions: 1. Check configuration data and 2. Acknowledge positively or

negatively. 3. If the configuration data is

acknowledged positively, initialize the input data of the DP slave using pointer access. The slave takes part in data exchange only after this action.

3 Access to the process image Read and write data in the process image (access as necessary).

4 Go to Step 1. DPS_get_ind must be called cyclically.

Notice After positive confirmation of configuration data, the input data in the process image table of the slave module must be written at least once (initialization), before the slave module can exchange data.



Shutdown Phase

To shut down the CP, the slave module changes to the OFFLINE mode and the CP is stopped:




3.7.3 Typical Sequences in the "Dynamic Slave" Mode with Software Event

Description

In the "Dynamic Slave" mode with software event, the DP slave user program can find out whether (new) parameter assignment and configuration frames were received from the DP master using a software event. It must then fetch this data and acknowledge.


A typical initialization phase is described below:

Step Action Meaning 1 DP_start_cp CP is initialized. 2 DPS_open Initialization of the slave module

The "DPS_SM_DYNAMIC" bit is activated in the "slave_mode" parameter, the "init_data" parameter contains the default configuration.





In productive operation, the DP slave user program is informed whether the frames listed above have been received using the "Asynchronous acknowledgment" software event.

Initializing the Semaphore Before it is used, the semaphore must be created as follows:

Step Action Meaning 1 Initialize a semaphore for

acknowledging asynchronous jobs (function DP_init_sema_object).

The DP Base Lib provides a semaphore for all asynchronous jobs (type: DP_OBJECT_TYPE_ASYNC).

Using the Semaphore in Productive Operation The DP slave user program can read and write data in the process image.

In productive operation, the DP slave can receive new parameter settings and be configured by the controlling DP master at any time due to a problem, for example a bus fault. In the "Dynamic Slave" mode, the parameter assignment or configuration must be confirmed explicitly by the DP slave user program. As a result, the DP slave user program must be prepared to receive parameter assignment and configuration frames at any time. The sequence of the DP slave user program execution in productive operation is different compared with the "Simple Slave" mode.

Step Action Meaning 1 Wait for semaphore (for

example, WaitForMultipleObjects)

The DP slave user program or the calling thread waits until an event occurs. "WaitForMultipleObjects" is a Windows 32-bit API function.

2 DPS_get_ind Fetch and evaluate arrived indications. The following indications are possible: (a) DPS_CHK_PRM (b) DPS_CHK_CFG




Continued

Step Action Meaning 3 When the

indication ( ) arrives,


(a) DPS_set_resp New parameter assignment has arrived: Reactions: 1. Check user parameter data. 2. Acknowledge positively or

negatively. (b) DPS_set_resp New configuration has arrived:

Reactions: 1. Check configuration data. 2. Acknowledge positively or

negatively. 3. If the configuration data is

acknowledged positively, initialize the input data of the DP slave using pointer access. The slave takes part in data exchange only after this action.

4 Access to the process image Read and write data in the process image (access as necessary).

5 Go to Step 1. Repeat cyclically during productive data exchange.

Notice After positive confirmation of configuration data, the input data in the process image table of the slave module must be written at least once (initialization), before the slave module can exchange data.

Clearing the Semaphore After the last use, clear your semaphore as follows:


events (function DP_delete_sema_object)




Shutdown Phase

To shut down the CP, the slave module changes to the OFFLINE mode and the CP is stopped:




3.8 Multiple Protocols, DP User Programs, CPUs

Multiple CP Operation

Operation of several CPs in one PC is supported.

Multiple DP User Programs

The simultaneous operation of several DP user programs is supported.

Please read the information in Chapter 6 if you create DP user programs for the CP 5613/CP 5614.

Section 6.5 contains extra information on more than one DP user program accessing the same CP 5613/CP 5614 at the same time.

Multiple CPUs in one PC

Operation in PCs with multiple CPUs is supported.




Description of the DP Functions, Data, and Error Codes 4

This chapter describes the individual functions and options for accessing data in the process image of the CP 5613 and CP 5614.

The chapter also explains the significance of the possible error codes.

The data formats for I/O data and for diagnostics are also described.

The chapter is primarily intended as a source of reference when you are writing your DP user programs.



4.1 List of Functions of the CP 5613 and CP 5614

Conventions in the Text

In the descriptions in this chapter, the following conventions are used in the function declaration:

Notation Meaning // in The value is provided by the DP user program as input for

the function. // out The value is returned to the DP user program by the

function. // inout The value must be initialized and is updated on completion

of the function.

Uniform Call Structure of the Functions of dp_base.dll

The functions have a uniform structure, as follows:

Error class = DP_... ( Job-defining parameter 1, ... Job-defining parameter n,

DP_ERROR_T *error);

Each function returns one of the error classes described below. If an error occurs, then depending on the error class, the DP_ERROR_T structure contains detailed error information (see Section 4.4). How the error is evaluated and the function DP_get_err_txt are explained in the sample programs supplied.

In the descriptions of the functions, the return values are described in tables as shown below based on the example of the DP_reset_cp function call:

• If the return value is DP_OK, this means that the function was executed successfully. In the example, this means that the CP was actually reset.

• If the return value is DP_ERROR_CI, and the component error_code in the error structure DP_ERROR_T has the value CI_RET_RESET_CP_USED, this means that the CP was not reset since other applications are still using the CP. Your DP user program should be prepared to react to such specific error codes.



• In other situations, the error only occurs in exceptional cases.

You will find a list of error codes in Section 4.4.2 "Error Codes".

Header Files

The C header files dp_5613.h and dps_5614.h with the detailed C description of the functions and data structures is in the "prog" subfolder of your software installation.

Synchronous and Asynchronous Functions

Unless explicitly indicated, the execution of a task is completed at the end of the function (in other words,the function is synchronous). Some functions (for example DP_ds_read), on the other hand, only start the processing and then terminate themselves. The actual result of the function must then be fetched with the DP_get_result function (in other words,the functions are asynchronous).



4.1.1 Overview of the Functions

Administrative Functions

Name Purpose DP_start_cp Downloads the firmware and the database to the

CP 5613/CP 5614. DP_open Logs on a DP user program, assigns a user handle. DP_get_pointer Requests a pointer to the process image. DP_init_sema_object This function initializes a Windows semaphore at

which your DP user program can wait for the arrival of events.

DP_delete_sema_object This function clears a semaphore again. DP_release_pointer Releases the pointer to the process image. DP_close The DP user logs off. DP_reset_cp Stops the CP firmware.

Standard DP Functions

Name Purpose DP_set_mode This function sets the required DP mode (OFFLINE,

STOP, CLEAR, OPERATE). DP_slv_state This function activates or deactivates a slave

explicitly and can be used to change the AUTOCLEAR property.

DP_read_slv_par This function reads out the parameters of a DP slave from the database.

DP_global_ctrl This function sends a global control command to one or more slaves.



Functions for the DP-V1 Master Class 1 (DPC1)

Name Purpose DP_alarm_ack This function sends an "Alarm Acknowledge" call to a

DP-V1 slave. DP_ds_read This function sends a "Read Data Record" call to a DP-V1

slave. DP_ds_write This function sends a "Write Data Record" call to a DP-V1

slave. DP_fetch_alarm This function fetches a DPC1 alarm, a DPC1 status

message or other diagnostic data. DP_get_actual_cfg This function reads out the current configuration data of a

slave. DP_get_cref This function obtains the communication reference (c_ref)

from the slave address and the user ID for DP-V1 jobs.

Auxiliary Functions

Name Purpose DP_get_err_txt This functions gets the error information and returns it as

plain text. DP_enable_event This function activates the waiting for status changes or

diagnostic information on slaves. DP_get_result This function fetches the confirmation of an asynchronous

call and other software events. DP_disable_event This function cancels DP_enable_event. DP_watchdog This function starts or stops the sign-of-life monitoring

(watchdog) of the DP master user program. DP_write_trc With this function, a DP user program can write its own

trace outputs to a trace file.



Fast Logic

Name Purpose DP_fast_logic_on This function assigns parameters to the CP 5613/CP 5614

for automatic monitoring of a slave and data transfer to another slave.

DP_fast_logic_off This function cancels the parameter assignment made with DP_fast_logic_on.

Constant bus cycle time

Name Purpose DP_delay_irq As an option, the cycle start interrupt can be delayed on

the CP 5623/CP 5624 with this function. DP_cycle_time With this function, the remaining cycle time can be queried

on the CP 5623/CP 5624.



4.1.2 DP_start_cp

Purpose

This function initializes the CP 5613/CP 5614. The CP firmware and the database are downloaded.

Syntax

DPR_DWORD DP_start_cp

(const DPR_STRING *cp_name, // in

const DPR_STRING *database, // in

DP_ERROR_T *error ); // out

Parameters

Name Description cp_name Logical name of the CP (for example, "CP_L2_1:") database Enter a null pointer.

Only in the special situation Development Kit "Dev-Kit 5613": path and name of the database

error Address of a structure provided by the DP user program of the type DP_ERROR_T - If an error occurred, the structure contains details for troubleshooting (see Section 4.4).



Return Value

Name Description DP_OK Successful completion of function. The

green token LED is lit. DP_ERROR_CI

and error->error_code == CI_RET_START_ALREADY_ DATABASE

Error: The CP has already been started with a different database.

DP_ERROR_CI and error->error_code == CI_RET_START_ALREADY_ DONE

Error: The CP has already been started with the same database. This error can be ignored.

Others Unsuccessful completion of function.



4.1.3 DP_reset_cp

Purpose

This function resets the CP 5613/CP 5614. Following this, the CP is no longer active on the bus (Token LED is off). If other applications use the CP, this function does not reset it.

Note To use the CP again, your DP user program must use the DP_start_cp call.

Syntax

DPR_DWORD DP_reset_cp (const DPR_STRING *cp_name, // in DP_ERROR_T *error ); // out

Parameters

Name Description cp_name Access point of the CP (for example, "CP_L2_1:") error Address of a structure provided by the DP user program of

the type DP_ERROR_T - If an error occurred, the structure contains details for troubleshooting (see Section 4.4).

Return Value

Name Description DP_OK Successful completion of function

DP_ ERROR_CI and error->error_code ==

CI_RET_RESET_CP_USED

Unsuccessful because other applications are still using the CP.

other Unsuccessful completion of function



4.1.4 DP_open

Purpose

This function logs on a DP user program for communication. If successful, the function returns a user handle. The user handle must be included in all further function calls.

Syntax

DPR_DWORD DP_open ( const DPR_STRING *cp_name, // in DPR_DWORD *user_handle, // out DP_ERROR_T *error ); // out

Parameters

Name Description cp_name Logical name of the CP (for example, "CP_L2_1:") user_handle Pointer to the user handle variable - if successful, the user

handle assigned to the DP user program is entered here. error Address of a structure provided by the DP user program of




Return Value

Name Description DP_OK Successful completion of function. DP_ ERROR_CI and

error->error_code == CI_RET_OPEN_CP_NOT_STARTED

CP was not started earlier with DP_start_cp.

DP_ERROR_EVENT_NET and error->error_code ==

DP_RET_CP USR_NOT_ COMPATIBLE

The dplib.dll and the dp_base.dll cannot register on the same CP.

DP_ERROR_RES and error->error_code ==

DP_RET_CP_TOO_MANY_USR

No further DP instances can log on at the CP.


DP_RET_CP_NO_DP_PAR

There are no DP parameters in the database of the CP.




4.1.5 DP_get_pointer

Purpose

With this function, a DP user program obtains the exclusive pointer to the process data of the CP 5613/CP 5614. Using this pointer, the DP user program can then access the data image of the CP 5613/CP 5614.

Note 1 Only one program can be in possession of a pointer to the process image at any one time. This avoids conflict accessing the registers controlling consistency in the process image (see, for example, D_lock_in_slave_adr in Section 4.3.1).

Note 2 Note that access to the dual-port RAM without a valid pointer leads to an access violation under Windows. The reason for this is as follows: The DP_get_pointer was not called, the DP_get_pointer is terminated with an error message or the pointer was released again with DP_release_pointer.

Note 3 This function requires a relatively long run-time and, if it is called often, can be detrimental to the real-time properties of your DP user program.

Note 4 The CP must already have been started with DP_start_cp.

Syntax

DPR_DWORD DP_get_pointer ( DPR_DWORD user_handle, // in DPR_DWORD timeout, // in DPR_CP5613_DP_T volatile **dpr, // out DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DP_open call. timeout Duration of the maximum wait time (in milliseconds) until

the function returns.

Limit values: 0: No wait time (function returns immediately)

0x7FFFFFFE: Maximum wait time

DP_TIMEOUT_FOREVER: "Endless" wait time

dpr Address of a pointer provided by the DP user program. If successful, the address for access to the process image of the CP 5613/CP 5614 is entered here - using this pointer, the DP user program can then access the data image of the CP 5613/CP 5614 directly.


Return Value

Name Description DP_OK Successful completion of function DP_ERROR_EVENT_NET and

error->error_code == DP_RET_TIMEOUT

The pointer to the process data could not be obtained within the specified waiting time. Cause: Another program had exclusive access to the process data during this time.




4.1.6 DP_release_pointer

Purpose

With this function, a DP user program releases the pointer to the process data. Following this, the DP user program can no longer access the data image of the CP 5613/CP 5614 directly.

Note This function requires a relatively long run-time and if it is called often, can be detrimental to the real-time properties of your DP user program.

Syntax

DPR_DWORD DP_release_pointer( DPR_DWORD user_handle, // in DP_ERROR_T *error); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. error Address of a structure provided by the DP user program of

the type DP_ERROR_T. If an error occurred, the structure contains details for troubleshooting (see Section 4.4).

Return Value

Name Description DP_OK Successful completion of function other Unsuccessful completion of function



4.1.7 DP_close

Purpose

With this function, a DP user program logs off for communication at the CP.

Note 1 If the logoff was successful, the user handle is no longer valid and must not continue to be used. The pointer to the dual-port RAM obtained with the DP_get_pointer function is also no longer valid.

Note 2 To shut down the DP master, your DP user program should first change the master to the OFFLINE mode with the DP_set_mode function.

Note 3 To disconnect the CP completely from the bus, your application can then use the DP_reset_cp function.

Syntax

DPR_DWORD DP_close (DPR_DWORD user_handle, // in DP_ERROR_T *error ); // out

Parameters





Return Value




4.1.8 DP_get_err_txt

Purpose

This function obtains detailed error information from the return values of the DP_ERROR_T error structure in plain language. For a detailed description of the possible error codes, refer to Section 4.4, Errors.

Syntax

DPR_DWORD DP_get_err_txt ( DP_ERROR_T *error, // in const DPR_STRING *language, // in DPR_STRING text[DP_ERR_TXT_SIZE] ); // out

Parameters

Name Description error Address of a structure provided by the DP user program of

the type DP_ERROR_T. The structure contains the error values of a previously called DP function (see Section 4.4).

language Language of the error text to be displayed:

● "German"

● "English"

text Pointer to the data area in which the error text including the terminating zero byte is stored.

Return Value


Note If a string other than "German" or "English" is entered in the "language" parameter, the error text is displayed in English.



4.1.9 DP_set_mode

Purpose

This function sets the required DP mode (OFFLINE, STOP, CLEAR, OPERATE).

! Warning If you want the master to change from DP_CLEAR to DP_OPERATE, but AUTOCLEAR (see 2.10) is configured and one or more slaves have failed, it cannot change to the DP_OPERATE mode. Instead of this, it changes to DP_AUTOCLEAR which has the identical significance to DP_CLEAR. Your DP user program must therefore not query whether or not the DP_OPERATE mode has been reached endlessly but must also check whether the master has changed to the DP_AUTOCLEAR mode as a result of a slave problem (USIF_state, see Section 4.3.6).

Note 1 Since it can take some time to reach a new mode (depending on the data transmission rate, number of slaves etc.), the function does not wait until the new mode has been reached. This prevents the DP user program being delayed unnecessarily long.

Note 2 When a new mode is set, no other modes can be skipped. Starting from the current mode, the modes must be run through in the specified (ascending or descending) order OFFLINE - STOP - CLEAR - OPERATE. Following a DP_set_mode call, the "Master Info" area of the process image (USIF_state, see Section 4.3.6) a check must be made to find out whether or not the new state was reached. Only then can a new mode be set.

Note 3 If your DP master changed to the AUTOCLEAR mode instead of the OPERATE mode, because a slave with the AUTOCLEAR property could not change to productive operation, you can nevertheless change the DP master to OPERATE. To do this, first deactivate the slave or its AUTOCLEAR property (in each case using the DP_set_slv_state call).



Syntax

DPR_DWORD DP_set_mode (DPR_DWORD user_handle, // in DPR_WORD mst_mode, // in DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. mst_mode New mode to be set. The following constants can be used:

DP_OFFLINE: OFFLINE mode DP_STOP: STOP mode DP_CLEAR: CLEAR mode DP_OPERATE: OPERATE mode

error Address of a structure provided by the DP user program of the type DP_ERROR_T. If an error occurred, the structure contains details for troubleshooting (see Section 4.4).



Return Value

Name Description DP_OK The change in the DP mode was

activated. DP_ERROR_EVENT_NET and

error->error_code ==

● DP_RET_CP_SET_MODE_CLR_ACT

● DP_RET_CP_SET_MODE_OFFL_ACT

● DP_RET_CP_SET_MODE_OPR_ACT

● DP_RET_CP_SET_MODE_STOP_ACT

A DP_set_mode call is still active.


● DP_RET_CP_WRONG_MODE_CLR

● DP_RET_CP_WRONG_MODE_OFL

● DP_RET_CP_WRONG_MODE_OPR

● DP_RET_CP_WRONG_MODE_STP

The selected master mode is not permitted (a master mode has been skipped).

Others Unsuccessful completion of function



4.1.10 DP_slv_state

Purpose

With this function, you can change the state of a DP slave while the DP user program is running. The slave can either be taken out of processing or can be activated again. You can also change the AUTOCLEAR property of a slave.

Using the slave address 0xFF and slv_mode == DP_AUTOCLEAR_ON/ DP_AUTOCLEAR_OFF, you can activate or deactivate the AUTOCLEAR property.

As an option, selected single slaves (slv_add != 0xFF) can be included or removed from the AUTOCLEAR processing.

Note 1 If the AUTOCLEAR property is configured in the database, the AUTOCLEAR property of all slaves is already activated.

Note 2 If the AUTOCLEAR property was not configured in the database and you want to activate it you must first activate the AUTOCLEAR property generally (slave address 0xFF) and then activate or deactivate the AUTOCLEAR property selectively for the individual slaves.

Note 3 The use of the parameters DP_SLV_ACTIVATE and DP_SLV_DEACTIVATE is not normally necessary in a DP user program since a DP slave is activated or deactivated automatically by the communications processor (depending on the mode of the master). These parameters should only be used in exceptional situations to take a slave out of the DP cycle and to include it again regardless of the mode of the DP master.



Note 4 If the call is made with the DP_SLV_RESTART parameter, the slave is reinitialized (closed down and assigned new parameters and reconfigured). A restart is necessary when one of the asynchronous DPC1 calls (DP_ds_read, DP_ds_write, DP_alarm_ack) is terminated with a communication error or when the DP_fetch_alarm function signals a data error when the master is in the Clear or Operate mode. Running a restart can take a certain amount of time. Using the DP_enable_event function, the DP user program can be informed when the restart is completed. The restart is fully completed when the DP_enable_event function signals the DP_SLAVE_ENTER event for the relevant slave.

Syntax

DPR_DWORD DP_slv_state(DPR_DWORD user_handle, // in DPR_WORD slv_add; // in DPR_WORD slv_mode, // in DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. slv_add Address of the slave or 0xFF with the meaning: Activate or

deactivate AUTOCLEAR for all. slv_mode Required slave state:

● DP_SLV_ACTIVATE Activate the slave

● DP_SLV_DEACTIVATE Deactivate the slave

● DP_SLV_RESTART Close down slave and restart

AUTOCLEAR setting:

● DP_AUTOCLEAR_ON Activate

● DP_AUTOCLEAR_OFF Deactivate

The values can also be ORed. error Address of a structure provided by the DP user program of




Return Value



DP_RET_CP_REQ_ACTIV

A DP_slv_state request is still active. Possible reaction of the DP user program: Call DP_slv_state again after a short wait time.




4.1.11 DP_read_slv_par

Purpose

This function queries the parameters of a currently active DP slave of the CP 5613/CP 5614. The parameters originate from the database.

Syntax

DPR_DWORD DP_read_slv_par (DPR_DWORD user_handle,// in DPR_WORD slv_add, // in DPR_WORD type, // in DPR_WORD *data_len; // out DPR_BYTE *data; // out DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. slv_add Address of the slave type Required data type (see Section 4.7):

DP_SLV_TYP: General slave parameters DP_SLV_PRM: Parameter assignment data DP_SLV_CFG: Configuration DP_SLV_USR: User parameter assignment data Normally, no data is supplied for the last type.

data_len Address of a length variable - the number of valid bytes in the data buffer is entered here.

data Pointer to a data area - the data area must be at least DP_PAR_SIZE long (see Section 4.7).




Return Value


error->error_code == DP_RET_CP_ADR_NOT_IN_DB

Error: The specified slave does not exist in the database.




4.1.12 DP_global_ctrl

Purpose

With this function, a global control command can be sent to one or more slaves.

Note Slaves are assigned to a slave group when the DP database is configured. A slave evaluates the global control command only when it is assigned to one of the addressed groups by the configuration.

Syntax

DPR_DWORD DP_global_ctrl(

DPR_DWORD user_handle, // in DPR_WORD slv_add, // in DPR_BYTE command, // in DPR_BYTE group, // in DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DP_open call. slv_add Address of the slave or group address

(DP_BROADCAST_ADR) command Here, the following global control commands can be

specified (they can also be ORed):

● DP_SYNC: freeze the output bytes

● DP_UNSYNC: cancel the DP_SYNC command

● DP_FREEZE: the states of the inputs are read in and frozen

● DP_UNFREEZE: cancel the DP_FREEZE command

group The slave groups to be addressed, where bit 0 means group 1, bit 1 means group 2 etc. The bits can be logically ORed. At least one bit must be set.




Return Value



DP_RET_CP_ADR_NOT_IN_DB

Slave address not in the database.


DP_RET_CP_REQ_NOT_ALLOWED

The service is not permitted.


DP_RET_CP_SLV_NOT_ACTIV

The relevant slave is not activated.


DP_RET_CP_TOO_MANY_CTRL_CMD

Too many global control commands currently being processed.

DP_ERROR_REQ_PAR and error->error_code ==

DP_RET_CP_WRONG_ FREEZE_GRP

Only with single addressing. The addressed slave does not belong to any of the specified groups (command was FREEZE or UNFREEZE).


DP_RET_CP_WRONG_SYNC_GRP

Only with single addressing. The addressed slave does not belong to any of the specified groups (command was SYNC or UNSYNC).


DP_RET_CP_WRONG_GC_GRP

At least one of the specified groups is empty.


DP_RET_CP_WRONG_GC_CMD

Illegal global control command.

Others Unsuccessful completion of function



4.1.13 DP_ds_read

Purpose

This function sends a "Read Data Record" call to a DP-V1 slave. The DP-V1 data is read parallel to cyclic operation. This is, however, not slave input data but an additional data packet addressed using the slot and index of a slave. The structure and significance of the data varies depending on the slave type and is described in the documentation of the slave.

Note Reading is executed asynchronously (DP_OK_ASYNC). The result must be fetched with DP_get_result.

Syntax

DPR_DWORD DP_ds_read (DPR_DWORD user_handle, // in DPC1_REQ_T *request, // in DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DP_open call. request Pointer to DP-V1 structure DPC1_REQ_S with entries for

the read data record job.

typedef struct DPC1_REQ_S { DPR_WORD order_id; // in DPR_DWORD c_ref; // in union { DP_DS_READ_T dp_ds_read; DP_DS_WRITE_T dp_ds_write; DP_ALARM_ACK_T dp_alarm_ack; DP_ENABLE_EVT_T dp_enable_evt; DP_GET_CFG_T dp_get_cfg; }req; } DPC1_REQ_T;

where

typedef struct DP_DS_READ_S { DPR_BYTE slot_number; // in DPR_BYTE index; // in DPR_BYTE length_s; //inout DPR_BYTE data_s[DPR_DPC1_MAX_LENGTH]; // out } DP_DS_READ_T;




Continued

Name Description "Request"

continued The order_id is a job identifier assigned by the DP user program. The identifier is returned unchanged in the asynchronous confirmation and can be used to identify the job to which the confirmation belongs. The c_ref element specifies the slave. The value of c_ref can be obtained using the function DP_get_cref(user_id, slv_add). For information on the elements slot_number and index, please refer to the slave description. The length_s element specifies the length of the data to be read. After receiving the DP_ds_read confirmation, length_s contains the actual number of data received from the slave. The received data is entered in data_s.


Return Value

Name Description DP_OK_ASYNC Execution of the function was activated

successfully. DP_ERROR_EVENT_NET and

error->error_code == DP_RET_REQ_ACTIV

There is still a DP_ds_read or DP_ds_write request active. Calling DP_ds_read again, is only permitted when the result of the previous call has been fetched with DP_get_result.




4.1.14 DP_ds_write

Purpose

With this function, the master can send data to a slave. The data is sent parallel to cyclic operation.

This is, however, not slave output data but an additional data packet addressed using the slot and index of a slave. The structure and significance of the data varies depending on the slave type and is described in the documentation of the slave.

Note Writing is executed asynchronously. The result must be fetched with DP_get_result.

Syntax

DPR_DWORD DP_ds_write ( DPR_DWORD user_handle, // in DPC1_REQ_T *request // in DP_ERROR_T *error ); // out



Parameters


the write data record job. typedef struct DPC1_REQ_S { DPR_WORD order_id; // in DPR_DWORD c_ref; // in union { DP_DS_READ_T dp_ds_read; DP_DS_WRITE_T dp_ds_write; DP_ALARM_ACK_T dp_alarm_ack; DP_ENABLE_EVT_T dp_enable_evt; DP_GET_CFG_T dp_get_cfg; }req; } DPC1_REQ_T;

where typedef struct DP_DS_WRITE_S { DPR_BYTE slot_number; // in DPR_BYTE index; // in DPR_BYTE length_m; // in DPR_BYTE data_m[DPR_DPC1_MAX_LENGTH]; // in } DP_DS_WRITE_T;

The order_id is a job identifier assigned by the DP user program. The identifier is returned unchanged in the asynchronous confirmation and can be used to identify the job to which the confirmation belongs. The c_ref element specifies the slave. The value of c_ref can be obtained using the function DP_get_cref(user_id, slv_add). For information on the elements slot_number and index, please refer to the slave description. The length_m element specifies the length of the data to be sent to the slave in data_m.




Return Value




There is still a DP_ds_write or DP_ds_read request active. Calling DP_ds_write again, is only permitted when the result of the previous call has been fetched with DP_get_result.




4.1.15 DP_fetch_alarm

Purpose

DP slaves can send important events in the form of diagnostic data. The diagnostic data of slaves with DPC1 capability can also include alarms or status messages. The diagnostic data is buffered on the DP master and can be read out by this function. The function can be used both for DPC1 slaves with alarm capability as well as for standard DP slaves. The entire diagnostic data is always returned.

Note 1 All the diagnostic frames with alarms are buffered by the CP 5613/CP 5614 and are therefore not lost. However, only the last diagnostic frame with a status message and the last "other" diagnostic frame without alarm or status message of each slave is kept (if it exists).

Note 2 Regardless of the slave type and configuration a DP slave can send up to 32 diagnostic frames with alarm data to the CP 5613/CP 5614. The DP user program must acknowledge every alarm with a DP_alarm_ack call (this does not apply to status messages). The structure and the meaning of the alarms or status message can vary depending on the slave type. For more information, refer to the documentation of the relevant slave.

Note 3 The function returns the stored events with the following priority:

1. Buffer diagnostic data with alarms (if they exist).

2. Last diagnostic data with/without status message (if it exists)

After it has have been read out, the stored data is deleted. If the slave drops out of the processing phase, all buffered alarms or status data is discarded. In this case, the relevant alarms must not be acknowledged by DP_alarm_ack calls.



Note 4 If the value "DP_MSG_TYPE_FAIL" is entered in the "msg" return parameter, a serious error has occurred in alarm handling. In this case, the DP user program must restart the slave if the error_decode structure element of the DP_ERROR_T structure also has the value 0xFF (see Section 4.1.10).

Note 5 Using the DP_enable_event function, the DP user program can be informed whether new diagnostic data or alarms/status messages exist that can be fetched with DP_fetch_alarm. Calling DP_enable_event has the advantage that only diagnostic messages are signaled during the operating phase of the slave. With the exception of certain error situations, standard diagnostic messages during the initialization phase are not signaled explicitly to improve efficiency (refer to the description of DP_enable_event).

Syntax

DPR_DWORD DP_fetch_alarm ( DPR_DWORD user_handle, // in DPR_WORD slv_add, // in DP_ALARM_EXT_T *alarm, // inout DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DP_open call. slv_add Address of the slave (0-126) Alarm Pointer to the DP_ALARM_EXT_S structure with the

diagnostic data (including alarm data or status data).

typedef struct DP_ALARM_EXT_S { DPR_WORD msg_filter; // in DPR_WORD msg; // out DPR_WORD next_msg; // out DPR_WORD diag_count // out DPR_WORD reserved; // inout DPR_BYTE length_s; // out DPR_BYTE data_s[DPR_SLAVE_DATA_SIZE]; // out } DP_ALARM_EXT_T;

The "msg_filter" parameter specifies the type of data to be read out. In this version, the ID DP_MSG_FILTER_ALL must be entered. The "msg" parameter contains the type of data read: ● DP_MSG_NONE No entry exists

● DP_MSG_ALARM_DIAG Diagnostic data with alarm

● DP_MSG_STATUS_DIAG Diagnostic data with status data

● DP_MSG_DIAG Other diagnostic data

● DP_MSG_FAIL Error in alarm handling; the error->errorcode parameter contains the cause of the error in greater detail (see below DP_RET_CP_ALARM_STATE_xx)

The "next_msg" parameter indicates whether further diagnostic messages are stored. ● next_msg = 0: No further diagnostic messages are

stored.

● next_msg = 1: Further diagnostic messages exist that must be read out with DP_fetch_alarm calls.



The "diag_count" parameter indicates the value of the diagnostic counter in the dual-port RAM at the time when the event occurred. The value is relevant only when the function returns diagnostic data. The "reserved" parameter is intended for future extensions. It must have the value 0. The "length_s" parameter contains the number of diagnostic data entered in the "data_s" array.




Return Value

Name Description DP_OK Successful completion of function; the

entry in DP_ALARM_EXT_T is valid. DP_ERROR_EVENT_NET and

error->error_code == DP_RET_CP_ADR_NOT_IN_DB

Error: The specified slave does not exist in the database; the entry in DP_ALARM_EXT_T is invalid.

DP_ERROR_EVENT_NET and error->error_code == DP_RET_CP_ ALARM_STATE_OVERFLOW

Error: The maximum number of configured alarms has been exceeded by the slave.

DP_ERROR_EVENT_NET and error->error_code == DP_RET_CP_ ALARM_STATE_INCONSISTENT

Error: The slave has sent more than one alarm of the same type.

DP_ERROR_EVENT_NET and error->error_code == DP_RET_CP_ ALARM_STATE_WRONG_TYPE

The slave has sent an alarm but the alarm type is not configured.

DP_ERROR_EVENT_NET and error->error_code == DP_RET_CP_ ALARM_STATE_PDU_LENGTH

The slave has sent an alarm or a status message with a length greater than specified.

DP_ERROR_EVENT_NET and error->error_code == DP_RET_CP_ ALARM_STATE_PDU_FORMAT

The slave has sent diagnostic data with format errors so that it is not possible to decode the alarm or status correctly.

other Unsuccessful completion of function; the entry in DP_ALARM_EXT_T is invalid.



4.1.16 DP_alarm_ack

Purpose

In certain situations, slaves with DPC1 functionality can signal alarms. These alarms are received by the DP master as part of the diagnostic data and buffered. Each alarm must be acknowledged by the master DP user program explicitly using the DP_alarm_ack function.

Note Sending is executed asynchronously. The result must be fetched with DP_get_result.

Syntax

DPR_DWORD DP_alarm_ack(DPR_DWORD user_handle, // in DPC1_REQ_T *request, // in DP_ERROR_T *error ); // out



Parameters


the acknowledge alarm job.


where

typedef struct DP_ALARM_ACK_S { DPR_BYTE slot_number; // in DPR_BYTE alarm_type; // in DPR_BYTE specifier; // in } DP_ALARM_ACK_T;

The order_id is a job identifier assigned by the DP user program. The identifier is returned unchanged in the asynchronous confirmation and can be used to identify the job to which the confirmation belongs.

The c_ref element specifies the slave. The value of c_ref can be obtained using the function DP_get_cref(user_id, slv_add).

The slot_number, alarm_type, and specifier elements are taken from the received slave alarm.




Return Value




There is still a DP_alarm_ack request being processed. Calling DP_alarm_ack again, is only permitted when the result of the previous call has been fetched with DP_get_result.




4.1.17 DP_get_actual_cfg

Purpose

This function can be used to read out the current configuration data from a slave. The data is requested from the slave using a special DP frame. With this function, you can check whether the expected configuration (database) matches the actual configuration.

The function can be used with modular slaves to detect the actual module configuration.

Note Reading is executed asynchronously. The result must be fetched with DP_get_result.

Syntax

DPR_DWORD DP_get_actual_cfg (DPR_DWORD user_handle, // in DPC1_REQ_T *request, // in DP_ERROR_T *error ); // out



Parameters


the DP_get_actual_cfg job.


where

typedef struct DP_GET_CFG_S { DPR_BYTE length_s; // out DPR_BYTE data_s[DPR_SLAVE_DATA_SIZE]; // out } DP_GET_CFG_T;

The order_id is a job identifier assigned by the DP user program. The identifier is returned unchanged in the asynchronous confirmation and can be used to identify the job to which the confirmation belongs.

The c_ref element specifies the slave. The value of c_ref can be obtained using the function DP_get_cref(user_id, slv_add).

The length_s element specifies the length of the data received from the slave. The received data is entered in data_s (see Section 4.7).




Return Value




There is still a DP_get_actual_cfg request active. Calling DP_get_actual_cfg again, is only permitted when the result of the previous call has been fetched with DP_get_result.




4.1.18 DP_enable_event

Purpose

Calling this function means that the following important events on the DP master can be signaled explicitly to the DP application:

• Diagnostic data, alarms and status messages can be fetched

• Slaves are included in the cyclic DP processing (operational) or have dropped out

• The mode of the master has changed

The function does not wait for the events but simply registers its program for notification. To fetch the events, use DP_get_result.

Note 1 By calling this function, your DP user program simply indicates that it is ready to receive the specified event type. The actual event message must be fetched with DP_get_result.

Note 2 When a DP_enable_event confirmation is received (see DP_get_result), the DP_enable_event function must be called again, if the DP user program wants to be informed of new events. The events DP_DIAG_ALARM and DP_SLV_STATE are buffered in the time between receiving the confirmation and calling DP_enable_event again so that they are not lost.

Note 3 When you first call DP_enable_event with the DP_SLV_STATE selector activated, note the following points:

● If slaves are operable at the time of the call (READY state), the event message DP_SLAVE_ENTER is triggered immediately for these slaves.

● If no slaves are operable at the time of the call (NOT READY state), no DP_SLAVE_EXIT event message is triggered.



Note 4 If the event DP_SLAVE_ENTER or DP_SLAVE_EXIT is signaled in consecutive DP_enable_event confirmations (with no DP_SLAVE_EXIT or DP_SLAVE_ENTER in the meantime), this means the following:

● Multiple DP_SLAVE_ENTER: The slave changed to the NOT READY state and back to the READY state.

● Multiple DP_SLAVE_EXIT: The slave changed to the READY state and then back to the NOT READY state.

Note 5 If the slave is in the NOT_READY state (in other words, in the initialization phase) and the DP_DIAG_ALARM selector is activated, diagnostic information is only signaled when the slave signals Diag.Prm_Fault, Diag.Cfg_Fault or Diag.Ext_Diag in its diagnostic frame (for more information on the formats see Section 4.6).

Note 6 If the DP master is not in the state to be monitored (mst_state) at the point when DP_enable_event is called with the DP_MST_STATE selector, the event is triggered immediately.

Note 7 The DP_ALARM_STATUS event is signaled in consecutive DP_enable_event confirmations until all alarm or status data have been read out with DP_fetch_alarm.

Syntax

DPR_DWORD DP_enable_event (DPR_DWORD user_handle,// in DPC1_REQ_T *request, // in DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DP_open call. request Pointer to DP-V1 structure DPC1_REQ_S with entries for the

event mechanism.

typedef struct DPC1_REQ_S { DPR_WORD order_id; // in DPR_DWORD c_ref; // reserved union { DP_DS_READ_T dp_ds_read; DP_DS_WRITE_T dp_ds_write; DP_ALARM_ACK_T dp_alarm_ack; DP_ENABLE_EVT_T dp_enable_evt; DP_GET_CFG_T dp_get_cfg; }req; } DPC1_REQ_T;

The order_id is a job identifier assigned by the DP user program. The identifier is returned unchanged in the asynchronous confirmation and can be used to identify the job to which the confirmation belongs. Here, the c_ref element is reserved. In the "req" union, only the "dp_enable_event" variant is relevant and is described below.




Structure of the request->req.dp_enable_evt Structure Element

typedef struct DP_ENABLE_EVT_S { DPR_DWORD selector; // in DPR_BYTE mst_state; // in DPR_BYTE event [DPR_MAX_SLAVE_ADDR]; // out DPR_BYTE mst_event; // out DPR_BYTE new_mst_state; // out } DP_ENABLE_EVT_T;

Description of the Elements of request->req.dp_enable_evt

Element Description selector The selector element selects the type of events to be

signaled. The values can be specified singly or “ORed".

● DP_DIAG_ALARM notify if diagnostic information or alarms occur

● DP_SLAVE_STATE notify when the slave enters or exits processing

● DP_MST_STATE notify when the master has or changes to a status other than that in the parameter mst_state.

mst_state The mst_state element is relevant only when the identifier DP_MST_STATE is entered in selector. This contains a master state. If the master has or changes to a different state from that entered here, the DP_enable_event signals the DP_MST_STATE_CHG event. You can select one of the following values:

● DP_OFFLINE

● DP_STOP

● DP_CLEAR

● DP_AUTOCLEAR

● DP_OPERATE




Continued

Element Description event On completion of the job, the event array contains an element

for every slave address with the events involving the specific slave. event[5] for example, contains information on slave 5. The following event IDs can be returned per slave address, and if required, several can be “ORed".

● 0 no event

● DP_DIAG Diagnostic information has arrived and can be read out with DP_fetch_alarm.

● DP_ALARM_STATUS Diagnostic information with alarm or status data has been buffered and must be read out with DP_fetch_alarm.

● DP_SLAVE_ENTER the slave was included in processing.

● DP_SLAVE_EXIT the slave has dropped out of processing.

mst_event The mst_event element contains the DP_MST_STATE_CHG identifier, if the value DP_MST_STATE is entered in selector and the master state has changed compared with the value in mst_state; otherwise the value 0.

new_mst_state new_mst_state contains the current master state.



Return Value




A DP_enable_event request is still active. Calling DP_enable_event again is only permitted when

● a DP_enable_event confirmation was received

● the call was canceled by calling DP_disable_event




4.1.19 DP_disable_event

Purpose

With this function, an earlier DP_enable_event call can be canceled. This ends the previous ready to receive state without the relevant event having occurred. The result of the terminating call must be fetched with DP_get_result. Following this, DP_enable_event can be called again, for example with modified conditions.

Syntax

DPR_DWORD DP_disable_event (DPR_DWORD user_handle,// in DP_ERROR_T *error ); // out

Parameters



Return Value

Name Description DP_OK Execution of the function was executed


error->error_code == DP_RET_CP_NO_EVT_PENDING

No DP_enable_event request is still active.




4.1.20 DP_get_result

Purpose

This function fetches the confirmation (result) of an asynchronous job. The result of every asynchronous job must be fetched with this function.

Depending on the transferred timeout time, the function returns immediately or after the monitoring time has elapsed. If the timeout time "forever" is entered, DP_get_result waits until the confirmation has arrived.

Note 1 If a function is still waiting for asynchronous confirmations when DP_close is sent, DP_get_result is terminated with the error class DP_ERROR_USR_ABORT.

Note 2 The confirmations can arrive in any order. Below, there is an example of a sequence:

● The DP user program sends a DP_enable_event call so that it will be notified of alarms.

● The DP user program sends a DP_ds_write call, for example to reassign parameters to slave 10.

● The DP user program then calls the DP_get_result function in a second thread and obtains a confirmation for the DP_ds_write job.

● Only after DP_get_result has been called again, does the DP_enable_event confirmation signal that there is an alarm for slave 10.

Note 3 If the error_decode structure element of the DP_ERROR_T structure is set to the value 0xFF in the DP_ERROR_EVENT_NET, a communication error has occurred.With a DPC1 job (req_type = DP_DS_READ, DP_DS_WRITE or DP_ALARM_ACK), a slave with DPC1 capability must then be initialized again by the DP_slv_state call (restart) if the master is in the Operate or Clear state.



Syntax

DPR_DWORD DP_get_result(DPR_DWORD user_handle, // in DPR_DWORD timeout, // in DPR_WORD *req_type, // out DPC1_REQ_T *result, // out DP_ERROR_T *error // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. timeout Duration of the maximum wait time (in milliseconds) until the

function returns. Limit values: 0: no wait time - the function returns immediately 0x7FFFFFFE: maximum wait time DP_TIMEOUT_FOREVER: "Endless" wait time

req_type Address of a variable for the job type. After receiving a confirmation, the job type is entered here:

● DP_NO_CNF: No confirmation received

● DP_DS_READ: Confirmation for DP_ds_read

● DP_DS_WRITE: Confirmation for DP_ds_write

● DP_ALARM_ACK: Confirmation for DP_alarm_ack

● DP_ENABLE_EVENT Confirmation for DP_enable_event

● DP_GET_CFG Confirmation for DP_get_actual_cfg

result The result parameter points to a structure of the type DPC1_REQ_T. When a confirmation is received, the confirmation parameters are entered in the relevant substructures of this structure (according to the entry in req_type).




Return Value

Name Description DP_OK A confirmation was received. The values

in req_type and result identify the job. The corresponding job was completed without errors.


DP_RET_TIMEOUT

No confirmation available.


DP_RET_CP_REQ_NEG

Communication error (slave not responding or the access point on the slave is not ready); see Note 3 (above).


DP_RET_CP_TIME_OUT

Communication error (slave does not respond within the timeout time.); see Note 3 (above).


DP_RET_CP_REQ_RE or DP_RET_CP_MM_xx (xx = AD, DI, EA, FE, IP, LE, NC,

NE, NI, RE, SC, SE)

Communication error (local or remote DP error); see Note 3 (above).


DP_RET_CP_SLV_NOT_IN_DATA

The job cannot be sent since the slave is not ready.

DP_ERROR_EVENT A return message was received from a DP-V1 slave. The evaluation of such return messages is described in Section 4.4.1.

DP_ERROR_EVENT_NET, other or DP_ERROR_RES

A confirmation was received. The corresponding job was terminated with an error. The return structure contains details of the cause of the error.

DP_ERROR_CI, DP_ERROR_USR_ABORT

The function call was terminated with an error. No confirmation was received. The result parameter is not valid. The return structure contains details of the cause of the error.



4.1.21 DP_get_cref

Purpose

This function obtains the c_ref for DPC1 functions and the user_handle from the slave address. The c_ref must be entered in these functions in the DPC1_REQ_S structure as a job-defining parameter.

Note The c_ref for a slave only needs to be obtained once. It is not necessary to call DP_get_cref again before each DPC1 function.

Syntax

DPR_DWORD DP_get_cref (DPR_DWORD user_handle, // in DPR_WORD slv_add, // in DPR_DWORD *c_ref, // out DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. c_ref After successful completion of function *c_ref contains the

required reference. slv_add Slave address error Address of a structure provided by the DP user program of


Return Value

Name Description DP_OK c_ref was obtained. other Unsuccessful completion of function, no result available



4.1.22 DP_init_sema_object

Purpose

This function initializes a semaphore for an event from the CP 5613/CP 5614. With Win32 API functions (WaitForMultipleObjects, WaitForSingleObject, MsgWaitForMultipleObjects), a DP user program can wait at these semaphores until an event arrives.

Semaphores are synchronization objects that Win32 API interface also supports. Using semaphores, it is possible to wait for the arrival of events in threads or processes.

Note 1 If you want to use semaphores for CP 5614 master and slave modes at the same time, initialize a master semaphore of the type DP_OBJECT_TYPE_ASYNC with the user handle of the DP_open call and then initialize a further semaphore of the type DP_OBJECT_TYPE_ASYNC but with the user handle of the DPS_open call.

Note 2 A semaphore initialized with DP_init_sema_object must only be deleted with the DP_delete_sema_objet function. Never use Win32 API functions to delete such semaphores.

Syntax

DPR_DWORD DP_init_sema_object( DPR_DWORD user_handle, // in DPR_DWORD sema_type, // in DPR_DWORD *sema_handle, // out DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DP_open call. sema_type Type of semaphore:

• DP_OBJECT_TYPE_INPUT_CHANGE - Hardware event when slave input data changes.

• DP_OBJECT_TYPE_DIAG_CHANGE - Hardware event when diagnostic data changes.

• DP_OBJECT_TYPE_CYCLE_INT - Hardware event at the start of a new DP cycle

• DP_OBJECT_TYPE_CYCLE_END - Hardware event at the end of a new DP cycle

• DP_OBJECT_TYPE_ASYNC - Software event on completion of an asynchronous call, can be fetched with DP_get_result.

• DP_OBJECT_TYPE_FAST_LOGIC - Hardware event for fast logic.

Apart from DP_OBJECT_TYPE_ASYNC, the semaphores can be initialized only once per CP.

sema_handle Address of a variable for the semaphore object. The returned semaphore object must be used with the Win32 API functions.


Return Value

Name Description DP_OK The semaphore could be initialized. DP_ ERROR_CI and

error->error_code == CI_RET_SEMA_TWICE

There is already a semaphore object for this user handle.




4.1.23 DP_delete_sema_object

Purpose

This function deletes a previously initialized semaphore.

Syntax

DPR_DWORD DP_delete_sema_object ( DPR_DWORD user_handle, // in DPR_DWORD sema_handle, // in DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. sema_handle Semaphore handle error Address of a structure provided by the DP user program of


Return Value

Name Description DP_OK The semaphore could be removed. other Unsuccessful completion of function.



4.1.24 DP_fast_logic_on

Purpose

With this function, a DP master user program can activate the "Fast Logic" functionality of the CP 5613/CP 5614. With this function, an input byte of a slave X can be linked with an output byte of a slave Y. When the specified trigger condition occurs, the CP 5613/5614 firmware automatically writes a specified output value to the output byte of a slave Y.

The reaction time of the "Fast Logic" functionality does not depend on the speed and load of the computer being used. It can therefore be used to control time-critical tasks.

Up to four fast logic trigger conditions per CP 5613 / CP 5614 can be activated.

! Warning 1 Fast logic functions correctly only when the DP is the OPERATE mode and the slaves involved are in the READY state. A fast logic trigger should therefore only be activated by the DP user program when the DP user program has brought the DP master to the OPERATE mode.

! Warning 2 Remember that as long as fast logic triggers are active, NO DP user program may write to the output bytes linked to input bytes with fast logic.

Note 1 After a fast logic trigger has been triggered, it is automatically deactivated again afterwards. Activating the trigger with DP_fast_logic_on is only possible when this was previously acknowledged by the DP user program in the dual-port RAM (refer to the example in Section 4.3.10 "Querying the Fast Logic Status"). The fast logic is also automatically deactivated when the DP user program logs off with the DP_close function.

Note 2 When working with multiple applications, only one DP master user program can use the fast logic functionality of the CP 5613/CP 5614 at any one time.



Note 3 Section 4.3.10 "Querying the Fast Logic Status" describes how the DP user program can query the current status of the Fast Logic triggers. Just as with other events, there is a semaphore for fast logic that is switched to enable when a fast logic trigger occurs. See Section 4.1.22, "DP_init_sema_object".

Note 4 Once a fast logic trigger has been triggered by the CP 5613/CP 5614, the user program should check whether the slave whose output byte was written by the fast logic is still in the READY state. If this is not the case, the slave accepts the modified byte only when changes back to the READY state. (See Section 4.3.5 "Identifying the Status of a DP Slave")

Note 5 The time between the change in the process image of the CP 5613 for the selected input byte and setting the selected output byte is approximately 40 µs.

Syntax

DPR_DWORD DP_fast_logic_on ( DPR_DWORD user_handle, // in DPR_WORD fast_logic_id, // in DP_FAST_LOGIC_T *fast_logic, // in DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. fast_logic_id Selects the fast logic trigger

Range of values: 0 to (DPR_MAX_FASTLOGIC_CNT – 1) -DPR_MAX_FASTLOGIC_CNT is set to 4.




Continued

fast_logic Pointer to the DP_FAST_LOGIC_S structure with which the trigger condition can be set. typedef struct DP_FAST_LOGIC_S { DPR_BYTE slave_addr_in_byte; // in DPR_BYTE index_in_byte; // in DPR_BYTE cmp_value_in_byte; // in DPR_BYTE mask_in_byte; // in DPR_BYTE slave_addr_out_byte; // in DPR_BYTE index_out_byte; // in DPR_BYTE value_out_byte; // in DPR_BYTE mask_out_byte; // in } DP_FAST_LOGIC_T; slave_addr_in_byte specifies the address of the slave whose inputs are selected for the trigger. index_in_byte specifies the index of the input byte of the trigger. cmp_value_in_byte specifies the comparison value for the input byte. With mask_in_byte, you can mask individual bits in the input byte so that they are ignored in the comparison. They are masked by a 1 in the corresponding bit; in other words,if mask_in_byte == 0x00, all the bits of cmp_value_in_byte are used in the comparison. The trigger is triggered when all unmasked bits in the selected input byte match the bits in cmp_value_in_byte. slave_addr_out_byte selects the slave whose output byte will be changed when the trigger condition occurs. index_out_byte specifies the index of the output byte. value_out_byte specifies the value to be written to the output byte. With mask_out_byte, you can mask individual bits in the output byte so that they are not changed if the trigger condition occurs. They are masked by a 1 in the corresponding bit; in other words,if mask_out_byte == 0x00, all bits of value_out_byte are written to the selected output byte.




Return Value

Name Description DP_OK The fast logic trigger was activated. DP_ ERROR_CI and

error->error_code == CI_RET_FL_INV_ID

The fast_logic_id parameter is invalid.


CI_RET_FL_INV_ADDR_IN_BYTE

Invalid address of the input slave.


CI_RET_FL_INV_ADDR_OUT_BYTE

Invalid address of the output slave.


CI_RET_FL_SLAVE_IN_NOT_IN_DB

Input slave not in the database.


CI_RET_FL_SLAVE_OUT_ NOT_IN_DB

Output slave not in the database.

DP_ ERROR_CI and Error->error_code ==

CI_RET_FL_INV_INDEX_IN_BYTE

Invalid input byte.


CI_RET_FL_INV_INDEX_OUT_BYTE

Invalid output byte.


CI_RET_FL_ALREADY_ON

Fast Logic is already active.


CI_RET_FL_INV_IN_MASK

Invalid mask for the input byte.


CI_RET_FL_INV_OUT_MASK

Invalid mask for the output byte.


CI_RET_FL_DOUBLE_USER

A second user is not permitted.


CI_RET_FL_NOT_CLEAR

The activated_fast_logic field is not zero.




4.1.25 DP_fast_logic_off

Purpose

This function deactivates a fast logic trigger of the CP 5613/CP 5614 again.

Syntax

DPR_DWORD DP_fast_logic_off ( DPR_DWORD user_handle, // in DPR_WORD fast_logic_id, // in DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. fast_logic_id Fast logic trigger

Range of values: 0 to (DPR_MAX_FASTLOGIC_CNT - 1); DPR_MAX_FASTLOGIC_CNT is set to 4.




Return Value

Name Description DP_OK The fast logic trigger was deactivated. DP_ ERROR_CI and

error->error_code == CI_RET_FL_ALREADY_OFF

Fast Logic is already deactivated.


CI_RET_FL_DOUBLE_USER

A second user is not permitted.


CI_RET_FL_INV_ID

The fast_logic_id parameter is invalid.




4.1.26 DP_watchdog

Purpose

This function starts or stops a watchdog on the CP 5613/CP 5614 that monitors the activity of the DP master user program. If the DP master user program no longer accesses the watchdog element in the dual-port RAM - after calling the function - due to an error (for example endless loop), this is detected by the CP 5613/CP 5614 when the timeout expires. The CP reacts by changing from the OPERATE DP mode to the CLEAR DP mode. This brings the slaves to a defined state. For more information on CLEAR refer to Section 2.8 "Modes of the DP Master"

Note 1 The watchdog can be used to prevent dangerous plant statuses that might occur as a result of the failure of the DP master user program. Without the watchdog, the DP master would remain the OPERATE mode and continue to send the last output data to the DP slaves, although the DP master user program is no longer functioning correctly. If this is unacceptable, the DP_watchdog function must be called with a monitoring time set to suit the application.

Note 2 The watchdog of a DP master user program is off following DP_open or after DP_close. If the value 0 is transferred in the "timeout" parameter, an active watchdog is deactivated again.

Note 3 The value 1 set for the monitoring time (10 ms) is always rounded up to 2 (20 ms) internally. The shortest selectable monitoring time is therefore 20 ms.



Note 4

The timing out of the watchdog can be queried at the wd_state structure element of the DPR_WD_S structure (wd_state == DP_WD_TIMEOUT; see Section 4.3.11 "Reading and Triggering the User Watchdog in the Dual-port RAM"). DP_WD_TIMEOUT is reset to DP_WD_STOPPED by calling DP_watchdog or DP_close.

Note 5 If you use multiple applications, each DP master user program that calls the DP_watchdog function is assigned its own watchdog. If one of these watchdogs elapses, then (depending on the status of the other watchdogs), the DP master is automatically changed from the OPERATE to the CLEAR mode.

Syntax

DPR_DWORD DP_watchdog ( DPR_DWORD user_handle, // in DPR_DWORD timeout, // in DPR_WORD *wd_index, // out DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DP_open call. timeout Monitoring time (in 10 milliseconds).

Values: 0: deactivate watchdog 1 to 65535: activate watchdog

wd_index Index of a structure DPR_WD_S within the user_watchdog array in the dual-port RAM. The returned index must be used to access the watchdog in the dual-port RAM. For more detailed information on triggering and reading out the watchdog, refer to Section 4.3.11 "Reading and Triggering the User Watchdog in the Dual-Port RAM".




Return Value

Name Description DP_OK The watchdog was activated or

deactivated successfully other Unsuccessful completion of function.



4.1.27 DP_write_trc

Purpose

This function allows the DP user program to write a user-defined text entry to the DP trace file for testing and debugging. As an option, it is also possible to output the hex dump of a memory area.

Requirements To allow the trace entry to be written to the trace file, the following conditions must be met:

1. The DP trace file is activated by the "Configuration Console" program. 2. The function "DP_write_trc" is enabled in the trace selection. 3. The recording level matches the setting. The recording level is selected in

the trc_depth call parameter (see below).

Caution The DP Trace file slows down the execution times and the dynamics of the DP user program. It should therefore only be used to test and debug the DP user program.

Note The DP Trace is designed as a ring buffer. This means that old trace entries are overwritten when the trace has reached the end of the ring buffer.

Syntax

DPR_DWORD DP_write_trc ( const DPR_STRING trc_text[DP_ERR_TXT_SIZE],// in DPR_WORD trc_depth, // in DPR_WORD *trc_active, // out const DPR_BYTE *buf, // in DPR_BYTE buf_len); // in



Parameters

Name Description trc_text Output string written to the trace file. The string must not

include escape sequences (line feed etc.). trc_depth This parameter specifies the recording depth of the trace

entry. The value DP_USR_TRC_DEPTH_MAX or DP_USR_TRC_DEPTH_ERR can be entered. DP_USR_TRC_DEPTH_MAX: A trace entry is always made as long as requirements 1. and 2. are met. DP_USR_TRC_DEPTH_ERR: A trace entry is only made when the above conditions 1. and 2. are met and the option "Errors" in the "Configuration Console" is selected.

trc_active NULL or address of a variable provided by the DP user program. On completion of the function, the variable has an ID indicating whether the DP Trace was activated (1) or not (0). Based on this variable, the DP user program can decide whether trace entries should be made or not during runtime.

buf NULL or pointer to a data area with the length buf_len. The content of the data area is output in addition to the trc_text string as a memory dump in the trace file.

buf_len Number of bytes to be output in the memory area addressed by buf.

Return Value

Name Description DP_OK Trace call without errors. The trace entry

was written if the conditions mentioned above were met.

DP_ERROR_REQ_PAR Parameter error



Example of User-Specific Trace Outputs

At the beginning of the program, the program checks whether the DP Trace is activated. There is a local buffer (buf) that contains the input data (4 bytes) of slave no. 5. If the DP Trace is activated and byte 0 is not equal to 0, a DP Trace entry is made for test purposes during the productive phase.

DPR_WORD IsTrcActive = 0;

/* Check whether trace is activate at program start */

if(DP_write_trc("Program Start", DP_USR_TRC_DEPTH_MAX, &IsTrcActive, NULL, 0) != DP_OK) { /* Parameter error!! */ }

...

/* Productive phase */

/* Read in input data of slave no. 5 to buf */

/* (see Section 4.3.1) */

/* Trace output if DP_Trace is activated */ if (IsTrcActive) { if(buf[0] != 0) { DP_write_trc("Slave 5: Input Bytes 0-3", DP_USR_TRC_DEPTH_MAX, NULL, buf, 4); } } ....



4.1.28 P_delay_irq

Purpose

When working in the constant bus cycle time mode and if the cycle start interrupt is used for synchronization between the DP user program and DP cycle, the DP_delay_irq function can be used to delay the triggering of the cycle start inter-rupt by a defined time.

Section 4.3.16 ("Using the Constant Bus Cycle Time Mode") describes in detail the constant bus cycle time mode and the general interaction between the CP and the DP application.

Constant DP cycle

Among other things, a constant DP cycle time consists of a cyclic and an acyclic part. Within the constant DP cycle, the DP application may only access I/O data in the dual-port RAM in the acyclic part of the DP cycle.

Optionally either at the start or end of the cyclic part, the DP application can syn-chronize itself with the DP cycle using the cycle start or cycle end interrupt.

Setting a delay time allows precise timing for applications that synchronize them-selves using the cycle start interrupt and want to make optimal use of the time be-tween the cycle start interrupt and the start of the acyclic part, for example for the internal preprocessing of data.

Interaction between the DP application and the CP

The following schematic is a simplified illustration of how the interaction between the DP application and the CP works when the synchronization is established using the start interrupt. This diagram is based on the following assumptions:

• In the initialization phase, the DP application has set the delay time T1 of the cycle start interrupt by calling DP_delay_irq.

• In the initialization phase, the DP application has set up the semaphore for the cycle start interrupt by calling DP_init_sema_object with the selector DP_OBJECT_TYPE_CYCLE_INT. This allows the DP application to wait at the API function WaitForSingleObject for the arrival of the (delayed) start interrupt.

• In the initialization phase, the DP application has released the interrupts for cy-cle start and cycle end for the first time by entering 0 in the cells D_cycle_start_mask and D_cycle_end_mask.



Description of the diagram In the cyclic part of the DP cycle, the cycle start interrupt is delayed by the time T1. The DP application that waits at the "WaitForSingleObject" function, is then acti-vated again (Sx, Sx+1). It releases the cycle start interrupt again for the next DP cycle (entry of 0 in bit 0 of the cell D_cycle_start_mask; for more detailed information, refer to Section 4.3.16 ("Using the Constant Bus Cycle Time Mode"). The preprocessing of the data then starts (period T2). When T2 has elapsed, the DP application checks whether the cy-cle end interrupt has already arrived by evaluating bit 0 of the cell D_cycle_end_mask. The cycle end interrupt signals the start of the acyclic DP part. In the example, T2 extends into the acyclic part of the DP cycle. Due to this, the end interrupt has al-ready arrived (bit 0 of D_cycle_end_mask = 1). The DP application releases the cycle end interrupt again for the next DP cycle (entry of 0 in bit 0 of the cell D_cycle_end_mask) and begins the access to the I/O data of the dual-port RAM.

Note If the cycle end interrupt has still not arrived when the time T2 elapses (not shown in the schematic), the DP application must wait until the cycle end interrupt arrives. Only then is the DP application allowed to access the I/O data in the dual-port RAM.

Explanations

GC Global Control frame before the start of the cyclic DP part

DE1,2..n Data exchange with the DP slave1,2..n

TDP Constant DP cycle

T1 Delay time of the start interrupt



Sx, Sx+1 Start interrupt delayed by the time T1 (cycle x and cycle x+1)

Sx*, Sx+1* Detection of the time of the delayed start interrupt (cycle x and cycle x+1) by the device driver.

Ex Cycle end interrupt

Note 1

If the delay time set in the "*delay_us" parameter is too high, the CP uses the maximum permitted delay time. In this case, the "delay_us" parameter uses the corrected value of the delay on completion of the function.

Note 2

If the function is not used, the CP uses the default setting (no delay of the cycle start interrupt).

Note 3

The delay time should be set by the DP application in the initialization phase before the first access to the I/O data.

Note 4

If the DP application wants to wait for the arrival of the (delayed) cycle start inter-rupt using the API functions "WaitForSingleObject" or "WaitForMultipleObjects", it must call the DP_init_sema_object function with the selector DP_OBJECT_TYPE_CYCLE_INT in the initialization phase. It must also release the cycle start interrupt for the first time (entry of 0 in the cell D_cycle_start_mask).

Note 5

By evaluating the D_cycle_end_mask (Bit 0 = 1) cell, the DP application can check whether the acyclic part of the DP cycle has started. To allow this, it must release the cycle end interrupt the first time during the initialization phase (entry of 0 in the cell D_cycle_end_mask).

Note 6

After the arrival of the cycle start or cycle end interrupt, these must be released again for the next DP cycle (entry of 0 in bit 0 of D_cycle_start_mask or D_cycle_end_mask).



Notice

If the set delay time is greater than the current cyclic part of a DP cycle, the cycle end interrupt will be signaled before the delayed cycle start interrupt. This must be taken into account in the design of the DP application.

Syntax

DPR_DWORD DP_delay_irq (DPR_DWORD user_handle, // in DPR_WORD req_type; // in DPR_DWORD* delay_us; // inout DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle that was assigned at the DP_open call. req_type Type of delay. The value must be 0 (start interrupt). delay_us Pointer to value with required delay time of the cycle start

interrupt in microseconds. If the function completes without error (DP_OK), the actual delay time is entered.

ERROR Address of a structure of the type DP_ERROR_T provided by the DP user program. If an error occurs, the structure contains details on the cause of the error; see Section 4.4 “Error handling”.

Return value

Name Description DP_OK Successful completion of the function DP_ERROR_REQ_PAR and

error -> error_code == DP_RET_PAR_REQ_TYPE

Function is not supported, for example, be-cause the CP is not a CP 5623/CP 5624.

Other (see Section 4.4 “Error handling“)

Incorrect completion of the function



4.1.29 DP_cycle_time

Purpose

When using the delayed cycle start interrupt, this function returns the remaining time of the constant DP bus cycle.

The DP application can compare the calculated time value with the period that the DP application requires to access the I/O data of all slaves in the dual-port RAM. If the remaining time is less than the access time for the I/O data in the dual-port RAM, the DP application can react by skipping access to the I/O data.

Section 4.3.16 ("Using the Constant Bus Cycle Time Mode") describes in detail the constant bus cycle time mode and the general interaction between the CP and the DP application. Among other things, a constant DP cycle time consists of a cyclic and an acyclic part. Within the constant DP cycle, the DP application may only ac-cess I/O data in the dual-port RAM in the acyclic part of the DP cycle.

Note 1 The function is intended particularly for constant bus cycle time errors caused by the DP application accessing the I/O data in the dual-port RAM outside the acyclic part of the DP cycle.

Note 2

The calculation of the time remaining of the constant DP cycle should ideally be made in the acyclic part of the DP cycle and before access to the I/O data in the current DP cycle.



Syntax

DPR_DWORD DP_cycle_time (DPR_DWORD user_handle, // in DPR_WORD req_type; // in DPR_DWORD *time_us; // out DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle that was assigned at the DP_open function

call. req_type Type of time. The value 0 must be entered (remaining time

of the constant DP cycle). time_us Pointer to the value of the calculated remaining time of the

constant cycle in microseconds ERROR Address of a structure of the type DP_ERROR_T provided

by the DP user program. If an error occurs, the structure contains details of the cause of the error; see Section “4.4, “Error handling”.

Return value

Name Description DP_OK Successful completion of the function DP_ERROR_REQ_PAR and

error -> error_code == DP_RET_PAR_REQ_TYPE

Function is not supported, for example CP is not a CP 5623/CP 5624.

Other (see Section 4.4, “Error handling“)

Incorrect completion of the function



4.2 DP slave functions

This section describes the additional functions required for the slave module.

The functions of the slave module are located in "dps_base.dll", the prototypes and data structures are in the file "dps_base.h" in the "simatic.net\cp5613_5614\prog" subfolder of your software installation.

Functions that begin with "DP_" have general and master module functionality. Functions that are only relevant for the slave module begin with "dps_" (the s stands for slave module).



4.2.1 Overview of the Slave Module Functions

Administrative Functions

The following table lists the functions common to the master and slave modules. These begin with DP_ .

Name Purpose DP_start_cp

(Section 4.1.2) Downloads the firmware and the database to the CP 5614 - Use the function of the master.

DPS_open (Section 4.1.4)

Logs on a DP slave user program, assigns a user handle.

DP_get_pointer (Section 4.1.5)

Requests pointer to the process image - Use the function of the master.

DP_release_pointer (Section 4.1.6)

Releases pointer to the process image - Use the function of the master.

DPS_close The DP slave user logs off. DP_reset_cp

(Section 4.1.3) Stops the CP firmware - Use the function of the master.

DP_get_err_txt (Section 4.1.8)

This function outputs error information in plain language. Use the function of the master.

DP_init_sema_object (Section 4.1.22)

This function initializes a semaphore at which your DP user program can wait for the arrival of events.

DP_del_sema_object (Section 4.1.23)

This function clears a semaphore again.

Initialization Functions

Name Purpose DPS_start This function activates the slave module. DPS_stop This function deactivates the slave module. It then no

longer reacts on the bus.



Standard DP Functions

Name Purpose DPS_get_baud_rate This function queries the current data transmission

rate. DPS_get_gc_

command This function queries the last received global control command.

DPS_get_state This function queries the current slave state. DPS_set_diag This function sets new diagnostic data. DPS_get_ind Receive asynchronous events. DPS_set_resp Confirm asynchronous events. DPS_calc_io_data_len Calculate I/O data length based on the configuration

data.



4.2.2 DPS_open

Purpose

With this function, a DP slave user program logs on at the CP 5614 and sets the slave parameters. If successful, the function returns a user handle. The user handle must be included in all further function calls.

Note 1 In the DPS_SM_DYNAMIC mode, the input data of the slave module must be initialized after receiving the positive confirmation of a configuration frame (in other words written) so that the slave module takes part in data exchange.

Note 2 DP-V1 services (DPS_SM_V1_ENABLE) are supported only in the DPS_SM_SIMPLE slave mode.

Note 3 In the DP-V1 mode, the slave submodule of the CP 5614 supports one DPC2 connection.

Note 4 Refer to the notes on GSD files in Section 4.7.4.



Syntax

DPR_DWORD DPS_open ( const DPR_STRING *cp_name, // in DPR_DWORD *user_handle, // out DPR_DWORD slave_mode, // in DPR_WORD station_addr, // in DPR_WORD addr_change, // in DPR_WORD pno_ident_nr, // in DPR_WORD user_wd, // in DPS_INIT_DATA_T *init_data, // in DPS_MAX_DATA_T *max_data, // in DPR_WORD baud_rate, // in DP_ERROR_T *error); // out



Parameters

Name Description cp_name Access point of the CP 5614 (for example, "CP_L2_1:") user_handle Pointer to the user handle variable - if successful, the user

handle assigned to the DP user program is entered here. slave_mode Setting for the slave mode (the individual flags are logically

linked in bits):

● DPS_SM_SIMPLE simple slave with automatic checking of the parameter assignment and configuration data

● DPS_SM_V1_ENABLE activate DP-V1 services

● DPS_SM_DYNAMIC parameter assignment and configuration data of the slave are checked dynamically.

station_addr Station address of the slave module on the CP 5614. This parameter is irrelevant on the CP 5613.

addr_change 1 means: allow address change on the bus. 0 means: do not allow address change on the bus

pno_ident_nr Unique number for the slave assigned by the PROFIBUS Users Organization (for example 0x80B4 for the sample user program) during certification. This number is represented in Intel format. This can generally be taken from the device description data file (GSD file) of the slave.

user_wd Formula: User_wd*10ms = monitoring time of the DP user program If the watchdog is not restarted in this time, the slave drops out of productive operation (Data_Ex). The value 0 deactivates the watchdog. As long as the watchdog is not supported by the CP 5614, this parameter must be set to 0.




Continued

Name Description init_data Pointer to a union with information on the extended slave

data. The DPS_SIMPLE_S structure must be used in the slave mode DPS_SM_SIMPLE, otherwise the DPS_DYNAMIC_S structure.

The DPS_SIMPLE_S structure contains the values set for the user parameter assignment data and for the configuration data. These values must match the values that the master sends to the slave during the parameter assignment and configuration phase. This is verified automatically by the slave firmware. Note: If DP-V1 services are not activated (bit DPS_SM_V1_ENABLE is not set), the first user parameter assignment data byte is reserved for the slave controller! If DP-V1 services are activated (bit DPS_SM_V1_ENABLE is set), the first three user parameter assignment data bytes are reserved!

The DPS_DYNAMIC_S structure contains the default configuration of the slave submodule. The DP master can read out these values at any time. During the configuration phase, the master can, however, send other configuration data (desired configuration) to the slave. The slave must read out this configuration data using DPS_get_ind and confirm explicitly with DPS_set_resp.




Continued

Name Description Typedef union DPS_INIT_DATA_S

{ struct DPS_SIMPLE_S { DPR_WORD user_prm_data_len; // in DPR_BYTE user_prm_data [DPS_MAX_PDU_LEN]; // in DPR_WORD cfg_data_len; // in DPR_BYTE cfg_data[DPS_MAX_PDU_LEN]; // in }simple; struct DPS_DYNAMIC_S { DPR_WORD def_cfg_data_len; // in DPR_BYTE def_cfg_data [DPS_MAX_PDU_LEN]; // in }dynamic; }DPS_INIT_DATA_T

user_prm_data_len: length of the specified user parameter assignment data <= 237 bytes

user_prm_data: specified user parameter assignment data

cfg_data_len: length of the specified configuration data <= 244 bytes

cfg_data: specified configuration data (format see Section 4.7.3)

def_cfg_data_len: length of the default configuration data <= 244 bytes

def_cfg_data: default configuration data




Continued

Name Description max_data Pointer to a structure with the maximum buffer lengths.

This parameter is reserved and must have the value NULL set.

baud_rate Data transmission rate to be set. This parameter is reserved and must be set to DPS_BD_AUTO_DETECT (automatic detection of the data transmission rate).


Return Value

Name Description DP_OK Successful completion of function. DP_ ERROR_CI and

error->error_code == CI_RET_OPEN_CP_NOT_STARTED

CP is not started.


DPS_RET_DOUBLE_OPEN

DPS_open was already executed.


DPS_RET_NOT_OFFLINE

The slave module is not offline.


DPS_RET_INV_SLAVE_ADDR

The specified slave address is invalid.


DPS_RET_DIN_DOUT_LEN

Max. input/output incorrect.


DPS_RET_DIAG_LEN

Max_user_diag_len incorrect.


DPS_RET_PRM_LEN

Max_user_prm_data_len incorrect.


DPS_RET_CFG_LEN

Max_cfg_data_len incorrect.




Continued

Name Description DP_ERROR_REQ_PAR and

error->error_code == DPS_RET_SSA_LEN

Bad max_user_ssa_data_len.


DPS_RET_INV_CFG

Invalid default configuration.


DPS_RET_PAR_SLAVE_MODE

Bad slave_mode.


DPS_RET_PAR_SLAVE_MODE_V1

DP-V1 operation not possible.


DP_RET_TOO_MANY_USR

No more DP instances can log on at the CP.


DPS_RET_NO_SLAVE_MODULE

DP slave functions are not available since this is a CP 5613 (without a slave module).


DPS_RET_LESS_MEM

The requested buffers are too large.

other Unsuccessful completion of function.



4.2.3 DPS_close

Purpose

With this function, a DP user program logs off for communication at the slave module.

Note 1 If the logoff was successful, the user handle is no longer valid and must not continue to be used.

Note 2 To shut down the DP slave, your DP user program should first change the slave module to the OFFLINE mode with the DPS_stop function.

Syntax

DPR_DWORD DPS_close (DPR_DWORD user_handle, // in DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DPS_open call. error Address of a structure provided by the DP user program of




Return Value


error->error_code == DPS_RET_SEQUENCE_ERROR

The DPS_close command is not permitted in the current status.




4.2.4 DPS_start

Purpose

This function can be used to switch the slave ONLINE. This is necessary after initialization.

Syntax

DPR_DWORD DPS_start( DPR_DWORD user_handle, // in DP_ERROR_T *error); // out

Parameters



Return Value



The DPS_start command is not permitted in the current status.




4.2.5 DPS_stop

Purpose

This function is used to switch the slave module OFFLINE. The slave module then no longer reacts on the bus.

Syntax

DPR_DWORD DPS_stop (DPR_DWORD user_handle, // in DP_ERROR_T *error ); // out

Parameters



Return Value



The DPS_stop command is not permitted in the current status.




4.2.6 DPS_get_baud_rate

Purpose

Using this function, your DP user program can query the current data transmission rate of the slave module.

Syntax

DPR_DWORD DPS_get_baud_rate( DPR_DWORD user_handle // in DPR_WORD *state, // out DPR_WORD *baud_rate, // out DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DPS_open call. state ● DPS_BAUD_SEARCH: no data transmission rate

found.

● DPS_BAUD_FOUND: data transmission rate found, bus watchdog not activated.

● DPS_BAUD_FOUND_WD: data transmission rate found, bus watchdog activated.

baud_rate ● DPS_BD_9K6 9600.00 Kbps

● DPS_BD_19K2 19.20 Kbps




● DPS_BD_500K 500.00 Kbps

● DPS_BD_1M5 1.50 Mbps

● DPS_BD_3M 3.00 Mbps

● DPS_BD_6M 6.00 Mbps

● DPS_BD_12M 12.00 Mbps error Address of a structure provided by the DP user program of


Return Value

Name Description DP_OK Successful completion of function DP_ERROR_RES and

error->error_code == DPS_RET_NO_DPR_PTR

No access possible to the dual-port RAM.




4.2.7 DPS_get_gc_command

Purpose

This function informs you of the last global control frames sent by the DP master to the DP slave. The following is displayed:

• Whether the DP master has influenced the response of the inputs and outputs of the DP slave with control commands (see also Section 2.11 in the manual "Control Frames to one or more Slaves").

• Whether the DP master has exited the OPERATE state.

Notes on Usage

• As long as the DP slave does not receive any new global control information, the function returns the old values. Due to reasons of performance, a DP user program can now only call the DPS_get_gc_command function, when the dps_get_ind function signals the DPS_NEW_GC event.

• No reaction is necessary by the DP user program to "Freeze" or "Enable" the inputs/outputs if a Sync/Unsync or a Freeze/Unfreeze command is received.

• If the DP master exits the OPERATE state, this is indicated by setting the DPS_CLEAR bit. When the DP master changes to the OPERATE state, this bit is reset to zero. The DPS_CLEAR bit remains set when the DP master changes to the STOP or OFFLINE state.

• The bit combination DPS_FREEZE/DPS_UNFREEZE is mutually exclusive. Only the last control command received is displayed. Example: The DP master sends a FREEZE command to the DP slave. As a reaction, the DPS_FREEZE bit is set. Following this, the DP master sends an UNFREEZE command to the DP slave. As a reaction, the DPS_FREEZE bit is reset and the DPS_UNFREEZE bit is set.

• The bit combination DPS_SYNC/DPS_UNSYNC is mutually exclusive. Only the last control command received is displayed. Example: The DP master sends a SYNC command to the DP slave. As a reaction, the DPS_SYNC bit is set. Following this, the DP master sends an UNSYNC com-mand to the DP slave. As a reaction, the DPS_SYNC bit is reset and the DPS_UNSYNC bit is set.



Syntax

DPR_DWORD DPS_get_gc_command( DPR_DWORD user_handle, // in DPR_WORD *gc_cmd, // out DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DPS_open call. gc_cmd Last received global control command

The global control information is represented in bits. It is possible that more than one bit is set at the same time:

● DPS_CLEAR master is in the CLEAR mode.

● DPS_FREEZE inputs are adopted and frozen. (inputs mean data of the DP slave to the DP master)

● DPS_UNFREEZE inputs are updated cyclically again. (inputs mean data of the DP slave to the DP master)

● DPS_SYNC outputs are updated once. (outputs mean data of the DP master to the DP slave)

● DPS_UNSYNC outputs are updated cyclically again. (outputs mean data of the DP master to the DP slave)




Return Value

Name Description DP_OK Successful completion of function DP_ERROR_RES and






4.2.8 DPS_get_state

Purpose

This function queries the current DP slave state. The function simply provides information for the DP user programs.

Note 1 During operation, the slave runs through the states: OFFLINE, waiting for parameter assignment data, waiting for configuration data and finally data exchange.

In its default state it is OFFLINE. After DPS_start, it first expects a parameter assignment frame (DPS_WAIT_PRM). This must be followed by a configuration frame (DPS_WAIT_CFG). If these two frames are confirmed as being correct, the slave changes to productive operation (DPS_DATA_EX).

Note 2 If the slave is not operated in the DPS_SM_SIMPLE mode, the input data of the slave module must be written after receiving the positive confirmation of a configuration frame. The slave can only change to productive operation after the input data have been initialized.

Syntax

DPR_DWORD DPS_get_state( DPR_DWORD user_handle, // in DPR_WORD *dps_state, // out DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DPS_open call. dps_state • DPS_OFFLINE the slave module has not started up.

• DPS_WAIT_PRM the slave module is waiting for a parameter assignment frame from the remote master.

• DPS_WAIT_CFG the slave module is waiting for a configuration frame from the remote master.

• DPS_DATA_EX the slave module is taking part in data exchange (productive phase).


Return Value




4.2.9 DPS_set_diag

Purpose

This function transfers diagnostic data to the DP slave module. The CP 5614 slave module passes on the data to the master that controls it.

Note 1 The 6 standard diagnostic bytes (diagnostic header) are managed by the CP 5614 slave module itself.

For more information on The structure of diagnostic information and the diagnostic formats, see Section 4.6.

Note 2 If the CP 5614 is operated as a slave with DP-V1 capability (see DPS_open, mode DPS_SM_V1_ENABLE), it can send one alarm to the master. The alarm is coded in the "Device-related diagnostics" format. For more detailed information on the structure of alarms, refer to Section 4.6.4. You should note the following points: • With DP slaves with DP-V1 capability, the DP master sets important values for

handling alarms in the user parameter assignment data (bytes 8-10, see Section 4.7.2). The DP slave user program should take these default values into account. In particular, you should keep in mind the following points: – Check the bit DPV1_Enable in DPV1_Status_1. The DP master can only

process the alarm if this bit is set. – Check the enabled alarms in DPV1_Status_2. The DP slave should only

send alarms to the DP master if they are enabled. • Within a diagnostic frame, only one alarm may be coded. • The alarm must be inserted as the last block of the diagnostic frame. • The alarm must not be sent if the diag_state parameter contains the identifiers

DPS_STAT_DIAG or DPS_EXT_DIAG_OV. • After triggering the alarm, the DP slave user program must check

(DPS_get_ind function) whether the master has confirmed the alarm by sending an Alarm Acknowledge frame. A further alarm can only be sent to the DP master after this acknowledgment. Remember that in certain other situations (for example assignment of new parameters to the DP slave due to connection aborts) the master discards a received alarm and does not therefore acknowledge it.

• When the slave sends an alarm, it must be in the DPS_DATA_EX state (productive phase). Otherwise, the alarm is discarded.



Syntax

DPR_DWORD DPS_set_diag(DPR_DWORD user_handle, // in DPR_BYTE *user_diag_data, // in DPR_WORD user_diag_len, // in DPR_WORD diag_state, // in DP_ERROR_T *error ); // out

Parameters

Name Description user_handle User handle assigned with the DPS_open call. user_diag_data Pointer to the user diagnostic data starting at the seventh

byte The first six bytes contain the standard section (byte 1 to 6), that the CP 5614 inserts automatically. (Format see Section 4.6).

user_diag_len Length of the user diagnostic data. diag_state The standard section of the diagnostic data can be

logically combined with the following values (the individual flags are logically combined bit by bit):

• DPS_EXT_DIAG if set, this is error information, otherwise a status message.

• DPS_EXT_DIAG_OV there is more diagnostic data than can be represented in the diagnostic buffer.

• DPS_STAT_DIAG a serious error has occurred and no more useful data can be supplied.

If no flag is used, the value 0 must be entered. error Address of a structure provided by the DP user program of




Return Value

Name Description DP_OK Successful completion of

function DP_ERROR_RES and




DPS_RET_PAR_DIAG_DATA_FMT

The format of the diagnostic data is invalid.


DPS_RET_SEQUENCE_ERROR

The diagnostic frame cannot be sent at present.


DPS_RET_PAR_ALARM

The diagnostic frame with alarm cannot be sent due to parameter errors.


DPS_ALARM_NOT_ALLOWED_ERROR

The diagnostic frame with alarm cannot be sent because the DP slave is not configured as a slave with DP-V1 capability.


DPS_RET_ALARM_NOT_ACK_ERROR

The diagnostic frame with alarm cannot be sent because the last alarm has not yet been acknowledged by the DP master with Alarm Acknowledge.


DPS_ALARM_WRONG_STATE_ERROR

The diagnostic frame with alarm cannot be sent because the DP slave is not in the DPS_DATA_EX state.


DPS_ALARM_DIAG_STATE_ERROR

The diagnostic frame with alarm cannot be sent because DPS_EXT_DIAG_OV or DPS_STAT_DIAG is set in the diag_state parameter.




4.2.10 DPS_get_ind

Purpose

With this function, the user program can fetch indications triggered by a DP master with DP-V0/DP-V1 functionality. The function can also report DPC2-specific indications. These originate from a DP master that communicates with the slave over a DPC2 connection.

Note 1 In the call, name the indications you want to receive. You will then receive exactly one indication as the result. DPS_CHK_PRM is also signaled when the user-specific part of the parameter assignment data of the remote master has the length 0. This therefore gives the DP slave submodule the option of refusing a parameter assignment if this does not contain any user-specific information.

Note 2 If there is no indication at the time of the function call and the monitoring time has elapsed, DPS_get_ind returns the value DPS_NO_IND in the indication parameter. Depending on whether the expected indication arrives in the meantime, the next DPS_get_ind call behaves as follows: ● The previously (unsuccessfully) expected indication has taken place:

The indication expected in the previous DPS_get_ind function call is returned. The current values set in the indication parameter are adopted.

● The previously (unsuccessfully) expected indication did not take place: The new value set in the parameter are adopted. If a suitable indication exists during the monitoring time, this is returned, otherwise DPS_NO_IND.

Note 3 If a function is still waiting for asynchronous indications when DPS_close is sent, DPS_get_ind is terminated with error class DP_ERROR_USR_ABORT.



Note 4 The DPS_get_ind function must only be sent a total of once at any one time.

Note 5 An address change of the slave (DPS_NEW_SSA indication) is only possible as long as the slave is still waiting for parameter assignment data. Once a parameter assignment frame has been received, it is no longer possible to change the slave address.

Note 6 After the DPS_open call, all indications are enabled as default. If you want to change this setting, you must call DPS_get_ind with the required values set in the indication parameter before switching the DP slave ONLINE by calling DPS_start.

Syntax

DPR_DWORD DPS_get_ind( DPR_DWORD user_handle, // in DPR_DWORD *ind_ref, // out DPR_DWORD timeout, // in DPR_DWORD *indication, // inout DPR_WORD *data_len // inout DPR_BYTE *data_blk // out DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DPS_open call. timeout Duration of the maximum wait time (in milliseconds) until the

function returns. Limit values: 0 No wait time ( function returns immediately) 0x7FFFFFFE Maximum wait time DP_TIMEOUT_FOREVER "Endless" wait time

ind_ref Address of the reference number of the indication. Must be included again with DPS_set_resp.

indication Pointer to a control variable for specifying indications. Before calling the function, the DP slave user program enters the indication types about which it wants to be informed. The DP slave user program can select more than one indication at the same time using OR logic operations. With slaves with DP-V1 capability, the DPC1 and DPC2-specific indications are always enabled. On return of the function, the variable contains the currently returned indication type (there is only ever one indication reported). For the set and return values, the following constants are used:




Continued

Name Description General DP Indications (Set and Return Values)

● DPS_NO_IND no indication occurred (return value only)

● DPS_CHK_PRM a new parameter assignment frame was received and must be checked by the DP slave user program and acknowledged with DPS_set_resp (only in the "Dynamic Slave" mode; refer to the DPS_SM_DYNAMIC slave mode with the DPS_open call).

● DPS_CHK_CFG A new configuration frame was received from the DP master and must be checked by the DP slave user program (only for the "Dynamic Slave" mode; see DPS_SM_DYNAMIC slave mode with the DPS_open call).

● DPS_NEW_SSA set slave address — frame was received and must be checked by the DP slave user program (only when an address change over the bus is permitted).

● DPS_BAUD_CHANGED The data transmission rate information has changed (see function DPS_get_baud_rate).

● DPS_GO_LEAVE_ The slave has entered the state DPS_DATA_EX DPS_DATA_EX or has left it (see

function DPS_get_state).

● DPS_NEW_GC A new (modified) global control frame was received (see function DPS_get_gc_command).




Continued

Name Description DPC1-Specific Indications (Return Values Only)

● DPS_C1_READ_REQ A "Read data record" frame was received and must be acknowledged with DPS_set_resp.

● DPS_C1_WRITE_REQ A "Write data record" frame was received and must be acknowledged with DPS_set_resp.

● DPS_C1_ALARM_ACK An "Alarm acknowledge" frame was received. With this, the remote DP master confirms the reception of an alarm sent previously with DPS_set_diag. The alarm acknowledge must not be acknowledged with DPS_set_resp.




Continued

Name Description DPC2-Specific Indications (Return Values Only)

● DPS_C2_INITIATE_REQ: The initiate frame for establishing a DPC2 connection was received and must be acknowledged by the user program with DPS_set_resp.

● DPS_C2_READ_REQ: A "Read Data Record" frame sent over a DPC2 connection was received and must be acknowledged by the user program with DPS_set_resp.

● DPS_C2_WRITE_REQ: A "Write Data Record" frame sent over a DPC2 connection was received and must be acknowledged with DPS_set_resp.

● DPS_C2_XPORT_REQ: A "Data Transport" frame (combination of read/write data record) sent over a DPC2 connection was received and must be acknowledged by the user program with DPS_set_resp.

● DPS_C2_ABORT_REQ The abort frame for terminating a DPC2 connection was received. This service must not be acknowledged with DPS_set_resp.




Continued

Name Description data_len Value set: Maximum length of the data_blk array when the

function is called. The constant DPS_MAX_PDU_LEN should be used. Return value: Number of bytes entered after the return of the function.

data_blk The indication data is entered in this array depending on the type of indication (see next section: Data Structure).

error Address of a structure provided by the DP slave user program of the type DP_ERROR_T. If an error occurred, the structure contains details for troubleshooting (see Section 4.4).



Data Structure (for data_blk parameter)

The content of the data_blk data structure depends of the type of indication returned.

Indication Content of the data_blk Data Structure DPS_CHK_PRM DPR_BYTE user_prm_data[ ];

User parameter assignment data section within the parameter assignment data of the DP master, see Section 4.7.2.

DPS_CHK_CFG DPR_BYTE cfg_data[ ];

Configuration data of the DP master, see section 4.7.3. DPS_NEW_SSA DPR_WORD new_address;

DPR_WORD ident_number; DPR_WORD no_addr_chg; DPR_BYTE user_data[ ];

Data structure containing the new station address, the identification number, the enabling of address changes, and user-specific data.

All information is represented in the Intel format. DPS_BAUD_

CHANGED DPR_WORD state; DPR_WORD transmission rate;

Data structure, see DPS_get_baud_rate (see Section 4.2.6).

DPS_GO_ LEAVE_DATA_ EX

DPR_WORD dps_state;

See DPS_get_state parameter (see Section 4.2.8).

DPS_NEW_GC DPR_WORD gc_command;

See DPS_get_gc_command parameter (see Section 4.2.7). DPS_C1_READ_

REQ DPR_BYTE con_id; DPR_BYTE slot_number; DPR_BYTE index;

DPR_BYTE user_data_len;

Con_id contains the connection reference that can be used for internal purposes. For DPC1 services, the value is always 0. The parameters slot_number and index identify the module and the area on the module from which the data will be read. User_data_len specifies the data length to be read.




Continued

DPS_C1_WRITE_REQ

DPR_BYTE con_id; DPR_BYTE slot_number; DPR_BYTE index; DPR_BYTE user data[ ];

Con_id contains the connection reference that can be used for internal purposes. For DPC1 services, the value is always 0. The parameters slot_number and index identify the module and the area on the module into which the data will be written. The user_data array contains the data to be written. The length of the data is data_len-3.

DPS_C1_ ALARM_ACK

DPR_BYTE alarm_type; DPR_BYTE slot_number; DPR_BYTE specifier;

The parameters alarm_type, slot_number, and specifier identify the received alarm acknowledgment.




Continued

DPS_C2_ INITIATE_REQ

DPR_BYTE con_id; DPR_BYTE send_timeout_high; DPR_BYTE send_timeout_low; DPR_BYTE features_supported_1; DPR_BYTE features_supported_2; DPR_BYTE profile_features_supported_1; DPR_BYTE profile_features_supported_2; DPR_BYTE profile_ident_number_high; DPR_BYTE profile_ident_number_low;

ADD_ADDR_PARAM_T add_address_param;

Con_id contains the current connection reference of this C2 indication. It can be used for internal purposes. The send_timeout parameter specifies the monitoring time for this connection. Within this time, the master must fetch the data provided by the slave. The unit is 10 ms. The parameters features_supported, profile_features_supported, and profile_ident_number identify the performance of the master. These are explained in greater detail in the Section "Structure Elements of DPS_C2_INITIATE_REQ".

ADD_ADDR_PARAM_T describes additional address parameters and has the following structure: typedef struct add_address_param { DPR_BYTE s_type; DPR_BYTE s_len; DPR_BYTE d_type; DPR_BYTE d_len; ADD_ADDR_T s_add; ADD_ADDR_T d_add; } ADD_ADDR_PARAM_T;

where typedef struct add_address { DPR_BYTE api; DPR_BYTE scl; DPR_BYTE network_address[6]; DPR_BYTE mac_address[MAX_MAC_ADDR_LEN]; } ADD_ADDR_T;

The meaning of the address parameters is explained in the section "Structure Elements of DPS_C2_INITIATE_REQ".




Continued

DPS_C2_READ_REQ

DPR_BYTE con_id DPR_BYTE slot_number DPR_BYTE index DPR_BYTE user_data_len

Con_id contains the current connection reference of this C2 indication. It can be used for internal purposes. The parameters slot_number and index identify the module and the area on the module from which the data will be read. User_data_len specifies the data length to be read.

DPS_C2_WRITE_REQ

DPR_BYTE con_id; DPR_BYTE slot_number; DPR_BYTE index; DPR_BYTE user data[ ];

Con_id contains the current connection reference of this C2 indication. It can be used for internal purposes. The parameters slot_number and index identify the module and the area on the module into which the data will be written. The user_data array contains the data to be written. The length of the data is data_len-3.

DPS_C2_XPORT_REQ

DPR_BYTE con_id DPR_BYTE slot_number DPR_BYTE index DPR_BYTE user data[ ]

Con_id contains the current connection reference of this C2 indication. It can be used for internal purposes. The parameters slot_number and index identify the module and the area on the module into which the data will be written. The user_data array contains the data. The length of the data is data_len-3.

DPS_C2_ABORT_REQ

DPR_BYTE con_id DPR_BYTE subnet DPR_BYTE reason_code

Con_id contains the current connection reference of this C2 indication. It can be used for internal purposes. The parameters subnet and reason_code contain additional information on the connection termination.



Return Value

Name Description DP_OK Successful completion of function. DP_ERROR_EVENT_NET and


The DPS_get_ind command is not permitted in the current status.


DPS_RET_BUF_LEN

The buffer length is invalid.

DP_ERROR_REQ_PAR and code = DP_RET_PAR_USR_HANDL

User_handle bad

DP_ERROR_REQ_PAR and code = DP_RET_PAR_DATA_LEN

data_len parameter bad

others Unsuccessful completion of function



4.2.11 Structure Elements of DPS_C2_INITIATE_REQ

Description

The general meaning of the parameters for DPS_C2_INITIATE_REQ is explained below. For further information and details, refer to the documentation of the DP master.

Parameters Description max_pdu_len Maximum data length supported by the slave on this

connection. Constant for default value: DPS_C2_MAX_PDU_LEN.

features_ supported_1

The parameter indicates whether certain services are supported by the DPC2 component of the firmware. ● Bit 0 (DP V1 RW):

This bit is set when the read data record and write data record services are supported.

● Bit 1: (data transport)

● Bit 2-7: reserved

Constant for default value (DPS_set_resp): DEF_FEATURES_SUPPORTED_1 (0x03)

features_ supported_2

Bit 0-7: reserved Constant for default value (DPS_set_resp): DEF_FEATURES_SUPPORTED_2 (0x00)

profile_features_ supported_1/2

The parameter indicates whether certain services are supported by the DPC2 user program. Bit 0-7: The meaning of the bits depends on the profile or vendor. Constants for default values (DPS_set_resp): DEF_PROFILE_FEATURES_SUPPORTED_1 (0x00) DEF_PROFILE_FEATURES_SUPPORTED_2 (0x11)

profile_ident_ number_high/low

The parameter profile_ident_number identifies a profile definition uniquely. The profile numbers are taken from a list of identification numbers managed by the PROFIBUS users' organization. Constants for default values (DPS_set_resp): DEF_PROFILE_IDENT_NUM_HIGH (0x80) DEF_PROFILE_IDENT_NUM_LOW (0xb4)



Parameters in ADD_ADDR_PARAM_T

Parameters Description s_type The parameter indicates the type of source address.

Possible values: 0 or 1 If this parameter is set to 1, the source (s_add structure) has an additional Network/MAC Address (for Inter-Network Addressing). Constant for default values (DPS_set_resp): DEF_S_TYPE (0x00)

s_len This parameter specifies the length (number of valid bytes) of the s_add subparameter. Possible values: No inter-network addressing: 2 (Api + Scl) Internetwork addressing: 8 (api + Scl + Network address) + number of valid bytes in mac_address. Constant for default values (DPS_set_resp): DEF_S_LEN (0x02)

d_type This parameter indicates the type of the destination address. Possible values: 0 or 1 If this parameter is set to 1, the destination (d_add structure) has a Network/MAC Address (for internetwork addressing). Constant for default values (DPS_set_resp): DEF_D_TYPE (0x00)

d_len This parameter specifies the length (number of valid bytes) of the d_add subparameter. Possible values: No internetwork addressing: 2 (Api + Scl) Intern-network addressing: 8 (api + Scl + Network address) + number of valid bytes in mac_address. Constant for default values (DPS_set_resp): DEF_D_LEN (0x02)

s_add, d_add Refer to the section below, parameters in ADD_ADDR_T.



Parameters in ADD_ADDR_T

Parameters Description api This subparameter indicates the Application Process

Instance of the source or destination. Possible values: 0 to 255 Constant for default values (DPS_set_resp): DEF_API (0x00)

scl Indicates the access level of the source or destination. Possible values: 0-255 (0 means no access level is used). Constant for default values (DPS_set_resp): DEF_SCL (0x00)

network_ address[6] ;

This subparameter identifies the network address according to ISO-OSI network addresses. This parameter is only relevant when s_type or d_type has the value"1".

mac_address[MAX_MAC_ADDR_ LEN]

Mac address of the sender or receiver — the parameter is only relevant when s_type or d_type has the value "1".



4.2.12 DPS_set_resp

Purpose

With this function, the DP user program provides the response data of an indication obtained previously with DPS_get_ind. This is necessary for the indications that require return messages or information from the user to control internal processing.

Note The following indications must not be acknowledged: ● DPS_BAUD_ CHANGED ● DPS_C1_ALARM_ACK ● DPS_C2_ABORT_REQ ● DPS_GO_ LEAVE_DATA_ EX ● DPS_NEW_GC ● DPS_NO_IND

Syntax

DPR_DWORD DPS_set_resp( DPR_DWORD user_handle, // in DPR_DWORD ind_ref, // in DPR_WORD data_len, // in DPR_BYTE *data_blk, // in DP_ERROR_T *error ); // out



Parameters

Name Description user_handle User handle assigned with the DPS_open call. ind_ref Reference number returned by DPS_get_ind. data_len Length of the data in data_blk data_blk Address of the response data error Address of a structure provided by the DP user program of


Data Structure (for data_blk parameter)

Indication Content of the data_blk Data Structure DPS_CHK_PRM DPR_WORD status;

Value Meaning

DPS_PRM_OK Parameter assignment data accepted.

DPS_PRM_FAULT Parameter assignment not accepted, the slave does not enter data exchange.

DPS_CHK_CFG DPR_WORD status;

Value Meaning

DPS_CFG_OK Configuration data accepted.

DPS_CFG_FAULT Configuration not accepted, slave does not enter data exchange.

DPS_NEW_SSA DPR_WORD status;

Value Meaning

DPS_SSA_OK Set slave address completed.




Continued

DPS_C1_READ_REQ

DPR_WORD status;

Value Meaning

DPS_RESP_OK The read data record frame was accepted. The following bytes in data_blk contain the requested data record. The value for data_len is obtained from: sizeof(DPR_WORD) + length of the data record.

DPS_RESP_ FAULT

The read data record frame was not accepted. The following bytes contain the DPS_ERROR_RESP_T error structure with additional detailed error information. The value for data_len is obtained from: sizeof(DPR_WORD) + sizeof (DPS_ERROR_RESP_T). If the default error values are required instead (see Section DPS_ERROR_RESP_T), the value for data_len is obtained from: sizeof(DPR_WORD).

DPS_C1_WRITE_REQ

DPR_WORD status;

Value Meaning

DPS_RESP_OK The write data record frame was accepted. The value for data_len is obtained from: sizeof(DPR_WORD)

DPS_RESP_ FAULT

The write data record frame was not accepted. The following bytes contain the DPS_ERROR_RESP_T error structure with additional detailed error information. The value for data_len is obtained from: sizeof(DPR_WORD) + sizeof (DPS_ERROR_RESP_T). If the default error values are required instead (see Section DPS_ERROR_RESP_T), the value for data_len is obtained from: sizeof(DPR_WORD).




Continued

DPS_C2_ INITIATE_REQ

DPR_WORD status;

Value Meaning

DPS_RESP_OK The connection establishment request is accepted. The following bytes contain slave-specific values (for the meaning refer to the Section 4.2.10). DPR_BYTE max_pdu_len; DPR_BYTE features_ supported_1; DPR_BYTE features_ supported_2; DPR_BYTE profile_ features_ supported_1; DPR_BYTE profile_ features_ supported_2; DPR_BYTE profile_ ident_ number_high; DPR_BYTE profile_ ident_ number_low;

ADD_ADDR_PARAM_T add_address_ param;

The value of data_len is obtained from: sizeof(DPR_WORD) + C2_INITIATE_RESP_LEN

DPS_RESP_ FAULT

The connection establishment request is not accepted. The following bytes contain the DPS_ERROR_RESP_T error structure with additional detailed error information. The value for data_len is obtained from: sizeof(DPR_WORD) + sizeof (DPS_ERROR_RESP_T). If the default error values are required instead (see Section DPS_ERROR_RESP_T), the value for data_len is obtained from: sizeof(DPR_WORD).




Continued

DPS_C2_READ_REQ

DPR_WORD status;

Value Meaning

DPS_RESP_OK The read data record frame was accepted. The following bytes in data_blk contain the requested data record. The value for data_len is obtained from: sizeof(DPR_WORD) + length of the data record.

DPS_RESP_ FAULT

The read data record frame was not accepted. The following bytes contain the DPS_ERROR_RESP_T error structure with additional detailed error information. The value for data_len is obtained from: sizeof(DPR_WORD) + sizeof (DPS_ERROR_RESP_T).

DPS_C2_WRITE_REQ

DPR_WORD status;

Value Meaning

DPS_RESP_OK The write data record frame was accepted. The value of data_len is obtained from: sizeof(DPR_WORD).

DPS_RESP_ FAULT

The write data record frame was not accepted. The following bytes contain the DPS_ERROR_RESP_T error structure with additional detailed error information. The value for data_len is obtained from: sizeof(DPR_WORD) + sizeof (DPS_ERROR_RESP_T). If the default error values are required instead (see Section DPS_ERROR_RESP_T), the value for data_len is obtained from: sizeof(DPR_WORD).




Continued

DPS_C2_ XPORT_REQ

DPR_WORD status;

Value Meaning

DPS_RESP_OK The write/read data record frame was accepted. The following bytes in data_blk contain the requested data record. The value for data_len is obtained from: sizeof(DPR_WORD) + length of the data record.

DPS_RESP_ FAULT

The write/read data record frame was not accepted. The following bytes contain the DPS_ERROR_RESP_T error structure with additional detailed error information. The value for data_len is obtained from: sizeof(DPR_WORD) + sizeof (DPS_ERROR_RESP_T). If the default error values are required instead (see Section DPS_ERROR_RESP_T), the value for data_len is obtained from: sizeof(DPR_WORD).



Return Value



The command is not permitted in the current mode.

other Unsuccessful completion of function DP_ERROR_REQ_PAR and

error->error_code == DP_RET_PAR_USR_HANDL

User_handle bad


DP_RET_PAR_DATA_LEN

data_len parameter bad


DPS_RET_PAR_DECODE

Bad error_decode parameter


DPS_RET_PAR_CODE_1

Bad error_code_1 parameter



DPS_ERROR_RESP_T

This structure contains additional error information of the Slave user program that can be returned to the master if an error occurs. The structure contains the following:

typedef struct dps_error_resp_s { DPR_BYTE error_decode; /* DPC1-Decode */ DPR_BYTE error_code_1; /* DPC1-Code_1 */ DPR_BYTE error_code_2; /* DPC1-Code_2 */ } DPS_ERROR_RESP_T;

For a description of the parameters, refer to Section 4.4.1. As defaults, the CP 5614 uses the following settings. The default values are used when the user program enters an error coding in the status and also enters the value "sizeof(DPR_WORD)" in data_len.

Parameters Value Description

error_decode 128 The parameters error_decode_1/2 are DP-V1-specific values.

error_code_1 169 Error class: Application: Error code: The feature is not supported.

error_code_2 1 user-specific



4.2.13 DPS_calc_io_data_len

Purpose

Based on any configuration frame, this function calculates the number of input bytes (in_data_len) that the DP slave sends to the DP master and the number of output bytes (out_data_len) that the DP master sends to the DP slave. This function is intended to provide information for the DP user program, so that it does not need to evaluate the ID bytes of the configuration frame itself. Any configuration frame can be evaluated.

Syntax

DPR_DWORD DPS_calc_io_data_len ( DPR_WORD cfg_len, // in DPR_BYTE *cfg_data, // in DPR_WORD *in_data_len, // out DPR_WORD *out_data_len, // out DP_ERROR_T *error ); // out

Parameters

Name Description cfg_len Length of the configuration data cfg_data Pointer to the configuration data in_data_len Pointer to the calculated input data length out_data_len Pointer to the calculated output data length error Address of a structure provided by the DP user program of


Return Value




4.3 Access to the Process Image of the CP 5613/CP 5614

Overview of the Existing Data

The following table provides you with an overview of the data available to your DP user program in the process image of the CP 5613/CP 5614.

Category Data DP process data ● Input data of the slaves

● Output data of the slaves

● Diagnostic data of the slaves, including diagnostic counter

● Slave data change indicator

● Input data of the slave module of the CP 5614

● Output data of the slave module of the CP 5614

Other information ● Information on the DP master

● Information on a slave

● Slave states

● Current bus parameters

● Bus statistics

● Watchdog of the DP user program

Hardware events ● Control of event generation at start of cycle

● Control of event generation at end of cycle

● Control of event generation if input data of slaves changes

● Control of event generation if data of the slave module on the CP 5614 changes

● Control of event generation when diagnostic data is received from slaves

● Query the Fast Logic status (for information on controlling Fast Logic hardware events, refer to Sections 4.1.24 and 4.1.25)

The formats of the I/O data and the diagnostic data are described in Sections 4.5 and 4.6.



4.3.1 Reading the Input Data of a DP Slave

Consistent Reading

There is a fixed data area in the process image of the CP 5613/CP 5614 for the input data of each individual slave.

To allow the input data of a slave to be read consistently, your DP user program first locks this data area to prevent it being updated by the DP master, then accesses the area, and releases it again.

The program locks the area by writing the slave address to a control register in the process image. The program releases the area by writing the value DPR_DP_UNLOCK or a different slave address to the same register.

Example of Consistent Reading

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. Then 200 bytes of slave no. 5 are copied to a local buffer "buf":

/* Lock the data area against updating */ p->ctr.D_lock_in_slave_adr = 5; /* Copy data */ memcpy(buf, &p->pi.slave_in[5].data[0], 200); /* Cancel lock again */ p->ctr.D_lock_in_slave_adr = DPR_DP_UNLOCK;



! Warning The lock is canceled: ● When another slave is locked to allow its input data to be read. ● When any DP slave is locked to allow its diagnostic data to be read (Section

4.3.2). ● When a write job is triggered for any DP slave to allow its output data to be

written via the corresponding control register (Section 4.3.3)

Note 1 The data is only valid when the master is in the OPERATE or CLEAR/ AUTOCLEAR mode and the slave is in the READY state.

Note 2 The input data is not updated as long as the slave reports static diagnostic data (Section 4.6.2, byte 2 - station status_2, bit 1).

Note 3 The memory area with index 127 contains the data of the slave module of the CP 5614 and the CP 5603, CP 5613 A2, CP 5623 if they are being used as a slave (not possible with the CP 5613).



4.3.2 Reading the Diagnostic Data of a DP Slave

Consistent Reading of the Diagnostic Data

Each individual slave has a fixed data area in the process image of the CP 5613/CP 5614 (for more information on the data format see Section 4.6).

To allow the diagnostic data of a slave to be read consistently, your DP user program first locks this data area to prevent it being updated by the DP master, then accesses the area, and releases it again. The program locks the area by writing the slave address to a control register in the process image. The data area is released again by writing the value DPR_DP_UNLOCK to the same register.

There is also a counter that counts the diagnostic data of the relevant slave.

Example of Consistent Reading of the Diagnostic Data

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. Then 200 bytes of the diagnostic data of slave no. 5 are copied to a local buffer "buf":

/* Lock the diagnostic data area against updating */ p->ctr.D_lock_diag_slave_adr = 5; /* Evaluate the counter */ count = p->pi.slave_diag[5].diag_count; /* Copy current data */ memcpy(buf, &p->pi.slave_diag[5].data[0],

p->pi.slave_diag[5].diag_len);/* Cancel lock again */ p->ctr.D_lock_diag_slave_adr = DPR_DP_UNLOCK;



General Notes

! Warning 1 The lock is canceled:

● When any DP slave is locked to allow its input data to be read (Section 4.3.1).

● When another DP slave is locked to allow its diagnostic data to be read.

● When a write job is triggered for any DP slave to allow its output data to be written via the corresponding control register (Section 4.3.3).

! Warning 2 Diagnostic data can only be read with data consistency.

Note 1 The data is only valid when the DP master is in the STOP, OPERATE, or CLEAR/ AUTOCLEAR mode and the DP slave is configured in the current database.

Note 2 Based on the diagnostic counter, you can recognize whether or not new diagnostic data have been received. The diagnostic counter is incremented each time a diagnostic message is received.




4.3.3 Writing the Output Data of a DP Slave

Writing is always consistent

There is a fixed data area in the process image of the CP 5613/CP 5614 for the output data of each individual slave.

To write the output data of a slave consistently, your DP user program writes the data to the data area and then triggers the acceptance of the data in the next DP cycle by writing the slave number to a control register in the process image of the CP.

Since the data transfer is triggered explicitly, the written output data is always consistent.

Example of Consistent Writing

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. Then 200 bytes from a local buffer "buf" are written to slave 5 as follows:

/* Copy data */ memcpy(&p->pi.slave_out[5].data[0], buf, 200); /* Trigger transfer */ p->ctr. D_out_slave_adr = 5;

Note 1 The output data is only transferred to the DP slave when the master is in the OPERATE mode and the slave is in the READY state.

Note 2 The output data is not sent to the slave as long as the slave reports static diagnostic data (Section 4.6.2, byte 2 - station status_2, bit 1).




4.3.4 Checking the Slaves for Changed Data

Uses of the Data Changed Information

The process image of the CP 5613/CP 5614 contains a memory area where you can see which slave data have changed. You can use this property to quickly check where data have changed without having to use semaphores.

Example

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. To count how many slave have changed data, you would write a program like that shown below, where "sum" contains the result:

unsigned short sum = 0; unsigned short i; for (i = 0; i< DPR_MAX_SLAVE_ADDR; i++) { if ( (p->ef.input[i].req_mask | 1) == DPR_DATA_CHANGE ) { /* Changed data found on slave i */ /* See also description below */ /* Mask released again: */ p->ef.input[i].req_mask = DPR_DATA_INT_CLEAR_AND_UNMASK;

/* Lock the data area against updating */ p->ctr.D_lock_in_slave_adr = i; /* Read data: */ memcpy(...);

/* Cancel locking of the data area: */ p->ctr.D_lock_in_slave_adr = DPR_DP_UNLOCK; sum++; } }



General Notes

! Warning If data changes, your DP user program must execute the following steps: 1. Reset the “req_mask" field (DPR_DATA_INT_CLEAR_AND_UNMASK or

DPR_DATA_INT_CLEAR_AND_MASK, see Note 1). 2. Lock the input data of a slave (D_lock_in_slave_addr, Section 4.3.1). 3. Read data. 4. Cancel the locking of the data area. If this order is not kept to, an unfavorable overlapping of events could mean that the next data change is missed.

Note 1 Your DP user program must reset the event mask itself. To achieve this, the user program can use DPR_DATA_INT_CLEAR_AND_UNMASK (when using semaphores) or DPR_DATA_INT_CLEAR_AND_MASK (polling) (see also Section 4.3.12 "Enabling and Disabling Creation of Hardware Events").

Note 2 In the dp_5613.h file, DPR_DATA_CHANGE is defined with the value 0xFF. During operation, however, the req_mask field can adopt the values 0xFF or 0xFE. For this reason, the least significant bits should not be checked (see sample program).

Note 3 To achieve a defined initial status, the events should be activated during the startup of the user program for the slaves to be monitored and deactivated for the other slaves.

Note 4 The memory area with index 127 contains the data of the slave module of the CP 5614.



4.3.5 Querying the State of a DP Slave

Uses of the Slave State

Before accessing data, your DP user program should check the state of a slave, to find out whether or not the data to be read are valid.

Example

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. To find out how many slaves are in the READY state, you would write a program like that shown below, where "sum" contains the result:

unsigned short sum = 0; unsigned short i; for (i=0; i < DPR_MAX_SLAVE_ADDR;i++) { if (p->info_watch.slave_info[i].slave_state == DPR_SLV_READY) { sum++; /* found */ } }

There is also the DPR_SLV_NOT_READY state that also includes non-configured slaves.

Note 1 The DP master automatically attempts to reinitialize slaves in the NOT READY state and to include them in cyclic processing.

Note 2 The DP user program must not overwrite the slave_state variable.

Note 3 If the slave is in the READY state, this does not necessarily mean that its data is valid. Diagnostic data may mean that the validity of the data is restricted.



4.3.6 Querying Information about the DP Master

Uses of the DP Master Information

The process image of the CP 5613/CP 5614 contains a memory area where you can read out the following information about the DP master:

• Mode (OFFLINE, STOP, CLEAR, AUTOCLEAR, OPERATE)

• Identification number of the certification

• Hardware version

• Firmware version

Description of the Hardware Version Memory Area

The info_watch.master_info.hw_version element consists of two bytes (word) and obtains the type of the queried CP in the high byte and the hardware version in the low byte.

The table below explains the significance of the high byte:

High Byte Meaning 01 CP 5613 (electrical PROFIBUS port) 02 CP 5613 FO (optical PROFIBUS port) 03 CP 5614 (electrical PROFIBUS port) 04 CP 5614 FO (optical PROFIBUS port) 05 CP 5614 FO (optical PROFIBUS port)

with connected external power supply 06 CP 5613 FO (optical PROFIBUS port)

with connected external power supply 07 CP 5613 A2 (electrical PROFIBUS port) 08 CP 5614 A2 (electrical PROFIBUS port)



Example

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. To display this information in a simple DP user program, you would write a program similar to that below:

printf("master state -> %ld", p->info_watch.master_info.USIF_state);

/* 0 means OFFLINE */ /* 1 means STOP */ /* 2 means CLEAR */ /* 3 means AUTOCLEAR */ /* 4 means OPERATE */ printf("master ident number -> %lx",

p->info_watch.master_info.ident_number); /* in Motorola format */ printf("master HW version -> %lx",

p->info_watch.master_info.hw_version); /* e.g. 0x00000104 for CP 5613 (electrical PROFIBUS port) with hardware version 4 */ printf("master FW version -> %lx",

p->info_watch.master_info.fw_version); /* e.g. 0x0600 for firmware version V6.0 */

Note Writing these values is not permitted and does not change the master data.



4.3.7 Querying the Current Bus Parameters of the Master

Uses of the Bus Parameter Query

In the process image of the CP 5613/CP 5614, there is a memory area in which you can read out the current bus parameters, for example, to display them in your DP user program.

Note Writing these values is not permitted and does not change the bus parameters actually used.

Example


printf("Baudrate -> %d", p->info_watch. aspc2_buspara.baud_rate);

The parameters are bytes, words or double words. Refer to the header file for the formats, structure DPR_ASPC2_BUSPARA_T.



Description of the Bus Parameters

Name Meaning ts Local station address baud_rate Data transmission rate

Value Meaning

DP_M_BAUDRATE_9K6 9.6 Kbps DP_M_BAUDRATE_19K2 19.2 Kbps DP_M_BAUDRATE_93K75 93.75 Kbps DP_M_BAUDRATE_187K5 187.5 Kbps DP_M_BAUDRATE_500K 500 Kbps DP_M_BAUDRATE_750K 750 Kbps DP_M_BAUDRATE_1M5 1.5 Mbps DP_M_BAUDRATE_3M 3 Mbps DP_M_BAUDRATE_6M 6 Mbps DP_M_BAUDRATE_12M 12 Mbps DP_M_BAUDRATE_31K25 31.25 Kbps DP_M_BAUDRATE_45K45 45.45 Kbps tsl Slot time (in bit times) min_tsdr Minimum station delay (in bit times) max_tsdr Maximum station delay (in bit times) tqui Modulator quiet time (in bit times) tset Setup time (in bit times) ttr Target rotation time (in bit times) g GAP update factor hsa Highest (station) PROFIBUS address max_retry_limit Maximum number of call retries station_type 1 (active station); 0 (passive station) trdy READY time (in bit times) BpFlag ● Bit 7=0 means: no mode change if an error occurs

● Bit 7=1 means: mode change if error occurs (AUTOCLEAR)

● Bit 6 to 0: reserved MinSlaveInterval see Section 2.12 (unit: 1 ms). PollTimeout Monitoring time for communication with a master class 2

(unit: 10 ms) DataControlTime see Section 2.12 (unit: 1 ms).

Within this time, the DP master informs the assigned slaves of its mode.



4.3.8 Querying Information about DP Slaves

Uses of the DP Slave Information

In the process image of the CP 5613/CP 5614, there is a memory area from which you can read out the configuration data for DP slaves, for example, to display it in your DP user program.

Example


printf("Slave type -> %d", p->info_watch.slave_info[5].slave_type);

/* 0 means slave is not configured */ /* 1 means slave is configured */ /* 2 means DP-V1-compliant slave is configured */ printf("number of output bytes -> %d",

p->info_watch.slave_info[5]. slave_out_byte);printf("number of input bytes -> %d",

p->info_watch.slave_info[5]. slave_in_byte);printf("In database -> %d",

p->info_watch.slave_info[5]. slave_in_database);



4.3.9 Reading PROFIBUS Statistical Data

Overview

In the process image of the CP 5613/CP 5614, there is a memory area in which the CP stores statistical data about the attached PROFIBUS network, for example, so that they can be read by diagnostic programs.

Example of Access

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. For example, to output the counter for the bus short-circuits detected up to now, you would write a program like the following:

/* Output counter for bus short-circuits */ printf("bus ctrl err =%u\n",

p->info_watch.aspc2_event.bus_control_error);



Description of the Available Statistics Counters

All elements are unsigned 16-bit counters that count the occurrences of a specific event. The first four events are particularly important.

Counter Name Meaning off_ts_adr_error Another station with the same name was detected. in_ring Indicates how often the CP entered the ring of the

active PROFIBUS master. out_of_ring Indicates how often the CP dropped out of the ring of

the active PROFIBUS master (the CP is currently in the ring when in_ring > out_ring).

bus_control_error Number of bus-short circuits - These adversely affect the functioning of the PROFIBUS and must be eliminated.

on_double_token Indicates how often duplicate tokens or token loss was detected.

on_timeout Indicates how often the token was lost and was generated again by this CP.

on_syni_error Indicates how often sporadic problems occurred on the PROFIBUS cable.

on_hsa_error Indicates how often a station address higher than the HSA configured on this CP was detected on the bus.

off_hsa_error reserved on_response_error Indicates how often errors occurred receiving a

response. on_las_useless reserved on_rec_frame_

overflow reserved

on_fifo_error reserved on_req_length_error reserved off_pass_token_error Indicates how often the token was corrupted when it

was passed on.



4.3.10 Querying the Fast Logic Status

Overview

In the process image of the CP 5613/CP 5614, there is a memory area in which you can check whether a fast logic trigger was triggered.

DP master user programs can use the fast logic semaphore (see function DP_init_sema_object) to be informed of the triggering of a fast logic trigger. When you install the product, a sample program is also installed that demonstrates the use of fast logic with the fast logic semaphore.



Example of Querying a Fast Logic Trigger

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. To monitor the fast logic trigger in your DP user program, you require a program section similar to that shown below:

/* Check whether fast logic trigger 0 is activated */ if(p->info_watch.activated_fast_logic[0] == DP_FASTLOGIC_ACTIVATED) { /* Trigger is activated */ /* To deactivate it, the function DP_fast_logic_off() must be used */ } /* Check whether fast logic trigger 0 is was triggered */ if(p->info_watch.activated_fast_logic[0] == DP_FASTLOGIC_TRIGGERED) { /* Trigger was activated */ /* Acknowledge trigger so that it can be activated again with DP_fast_logic_on() */ p->info_watch.activated_fast_logic[0] = DP_FASTLOGIC_CLEAR; /* Actions for specific application */ }

Note 1 The array p->info_watch.activated_fast_logic[i] may only be written to when p->info_watch.activated_fast_logic[i] has the value DP_FASTLOGIC_TRIGGERED .

Note 2 It is not permitted to enter a value in p->info_watch.activated_fast_logic[i] other than DP_FASTLOGIC_CLEAR.



4.3.11 Reading and Triggering User Watchdog in the Dual-Port RAM

Overview

The process image of the CP 5613/CP 5614 contains a memory area where you can trigger and check the user watchdog. The user watchdog is initialized by the DP_watchdog call (see Section 4.1.26 "DP_watchdog"). If successful, the function returns an index that points to a watchdog structure (DP_WD_S) within the user_watchdog array in the dual-port RAM.

The DP_WD_S structure consists of the elements wd_state, wd_start, wd_counter and wd_trigger. A DP user program is only allowed to read the elements wd_state, wd_start and wd_counter. The DP user program can both read and write the wd_trigger element.

Structure element

Meaning

wd_state The wd_state structure element indicates the current status of the user watchdog. It can have the following values:

● DP_WD_STOPPED Watchdog deactivated.

● DP_WD_STARTED Watchdog started, monitoring active.

● DP_WD_TIMEOUT Watchdog elapsed because it was not triggered in time by the DP user program.

wd_start The structure element indicates the rounded up monitoring time in units of 10 milliseconds transferred with the DP_watchdog call.

wd_counter The structure element indicates the elapsed monitoring time of the watchdog in units of 10 milliseconds. It is incremented cyclically by the DP master.

wd_trigger The structure element triggers the user watchdog. It must be incremented by the DP master user program at cyclic intervals (at least once within the watchdog monitoring time). Triggering sets the wd_counter element back to the value 0 and the watchdog is restarted. An overflow of the range of values of wd_trigger is irrelevant and does not need to be checked.



Example of Access

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. The parameter idx is the value that the DP_watchdog function returned as the index. For example, to read out the current count of the watchdogs and to trigger the watchdog, you require a program section like that shown below:

/* Output current count of the watchdog */ printf("watchdog time =%u\n", p->info_watch.user_watchdog[idx].wd_counter); /* Watchdog elapsed? */ if(p->info_watch.user_watchdog[idx].wd_state == DP_WD_TIMEOUT) { // Timeout -> user-specific reaction !! } else { /* Trigger watchdog */ p->info_watch.user_watchdog[idx].wd_trigger++; }



4.3.12 Activating/Deactivating the Generation of Hardware Events

Overview

In the process image of the CP 5613/CP 5614 there is a memory area assigned to the following hardware events:

• Start of a new DP cycle (see header file DP_5613.H via D_cycle_start_mask and cycle_start_NT_PerformanceCounter)

• End of the cyclic part of the DP cycle (see header file DP_5613.H via D_cycle_end_mask and cycle_end_NT_PerformanceCounter)

• Data changed in the DP process image

• Arrival of diagnostic data

The triggering of these hardware events must be activated by the user. When one of these events occurred, this is automatically deactivated.

Hardware events for changes in slave input data and diagnostic data can be set separately for each individual slave.

All the events listed above can also be indicated by semaphores.



Example of Activation

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. To activate events at the start of the cycle, when data changes and when diagnostic data arrive, you would write a program like the one below:

/* Activate event at the start of the cycle */ p->ctr.D_cycle_start_mask = 0; /* Activate event if slave 5 data changes 5 */ p->ef.input[5].req_mask = DPR_DATA_INT_CLEAR_AND_UNMASK; /* Activate event if diagnostic data arrive

from slave 5 */p->ef.diag[5].req_mask = DPR_DATA_INT_CLEAR_AND_UNMASK;

Afterwards, when events arrive, the semaphores initialized by your DP user program with DP_init_sema_object are activated. The other possible values for "req_mask" are:

• DPR_DATA_INT_CLEAR_AND_MASK – Waiting for an event, but then no setting of the semaphore (software event).

• DPR_DATA_CHANGE – If an event has arrived, "req_mask" has the value DPR_DATA_CHANGE or 0xFE (see Section 4.3.4).



Example of Deactivation

The activation sequence above would be canceled by your DP user program as follows:

/* Deactivate event for slave 5 data change */ p->ef.input[5].req_mask = DPR_DATA_INT_CLEAR_AND_MASK; /* Deactivate event if diagnostic data arrive

from slave 5 */p->ef.diag[5].req_mask = DPR_DATA_INT_CLEAR_AND_MASK;

Note 1 If your DP user program has not yet passed through a semaphore, it will not be activated again. When the program passes through a semaphore, you should therefore always check whether multiple events have already occurred.

Note 2 When a hardware event is received, the corresponding control condition is reset so that your DP user program must set it again. This avoids overload on your PC when your DP user program does not process hardware events quickly enough. If you set a control condition again, make sure that the data area of the assigned slave is locked so that it cannot be updated; consistent reading (Section 4.3.1 or Section 4.3.2).

Note 3 The use of hardware events for a lot of active slaves at the same time puts greater load on the PC than polling; refer to the suggestions in the FAQ list.

Note 4 In the constant scan mode, the user cannot deactivate the hardware event at the start of the cycle and at the end of the cyclic part of the DP cycle.



4.3.13 Sending Data with the CP 5614 as DP Slave

Integration in the Process Image of the CP 5613/CP 5614

The send data of the slave module are in the output image with slave index 127. Writing the output data area with slave index 127 supplies the slave module with new data that the controlling master reads as inputs.

Example of Consistent Writing

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. Then 200 bytes from a local buffer "buf" are written to the slave module as send data as follows:

/* Copy data */ memcpy(&p->pi.slave_out[127].data[0], buf, 200); /* Trigger transfer */ p->ctr. D_out_slave_adr = 127;

The data is now transferred to the slave module. Here, the controlling master can read the data as inputs.

Note 1 The send data is only accepted by the master when the slave module of the CP 5614 is in the READY state and the master is in the CLEAR, AUTOCLEAR or OPERATE mode.

Note 2 The p->ctr.D_out_slave_adr cell can only be written.



4.3.14 Receiving Data with the CP 5614 as DP Slave

Integration in the Process Image of the CP 5613/CP 5614

The received data of the slave module are stored in the input image with slave index 127. This allows the DP user program to read the data sent by the controlling master as outputs to the slave module by reading the input data area with slave index 127.

Example of Consistent Reading

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. Then 200 bytes of the received data of the slave module are copied to a local buffer "buf":

/* Lock the data area against updating */ p->ctr.D_lock_in_slave_adr = 127; /* Copy data */ memcpy(buf, &p->pi.slave_in[127].data[0], 200); /* Cancel lock again */ p->ctr.D_lock_in_slave_adr = DPR_DP_UNLOCK;

The copied data is the received data of the slave module that the controlling master sent as outputs.

Reading without Consistency

To read without consistency, the locking and release of the data area are simply omitted.

General Notes

Note The data is only valid when the slave module of the CP 5614 is in the READY state and the master controlling the slave is in the OPERATE mode.



4.3.15 Sending Diagnostic Data with the CP 5614 as DP Slave

Integration in the CP 5613/CP 5614

The slave module of the CP 5614 can transfer its diagnostic data to the controlling master. For this, it is not the diagnostic data area with slave index 127 that is used, but rather the DPS_set_diag function (see Section 4.2.9).

For information on the format of the diagnostic data, see Section 4.6.

Example of Sending Diagnostic Data

"h" is the user handle obtained by your DP user program with the DPS_open call. Then 10 bytes of the user diagnostic data of the slave module are sent as follows from a local buffer "buf":

/* Transfer diagnostic data to the slave module */ DPS_set_diag(h, diag_buf, 10, 0, &err);

Note The diagnostic data is only accepted by the master when the slave module of the CP 5614 is in the READY state and the master controlling the slave is in the CLEAR, AUTOCLEAR or OPERATE mode.



4.3.16 Using the Constant Bus Cycle Time Mode

Overview

As an option, the CP 5613/CP 5614 can be operated in the constant bus cycle time mode.

In this mode, the transfer of user data between the master and slaves takes place at constant, identical intervals. This achieves a high degree of synchronization between the DP master and the assigned slaves as required, for example, in the control algorithms of clocked drive couplings.

In the constant bus cycle time mode, a DP user program can generally only access the data image in the dual-port RAM in the sections of a DP cycle in which no user data is being exchanged with the slaves. At the end of the cyclic part, all the input data of all the addressed slaves is available. At this point, the CP 5613/CP 5614 triggers a cycle end interrupt. This informs the DP user program of the time after which data access to the dual-port RAM is permitted according to these conditions.

Requirements

Below, you will see some of the most important requirements for using the constant bus cycle time mode (for further information, refer to the STEP 7 configuration tool):

• If you want to use the constant bus cycle time mode, you must use the STEP 7 configuration tool version 5.1 or higher to create the database. Using this tool, you can configure DP operation with constant bus cycle times.

• It is only possible to maintain the constant bus cycle time cycle on the bus when operating in the mono master mode.

The mono master mode means that there are no other active stations on PROFIBUS.

• Apart from the DP user programs, there should be no other DP user programs started on the CP at the same time.

• Make sure that the computer performance is adequate for the exacting timing requirements of the constant bus cycle time mode.

• Make sure that defined reaction times are available for the DP user program.

• Make sure that the DP user program cannot be disabled for longer periods by the operating system, for example due to other processes or device drivers.



Basic Sequence of a Constant Bus Cycle Time DP Cycle

The simplified schematic below shows the structure of a constant bus cycle time DP cycle and the basic interaction between the CP 5613 device driver and a DP user program.

In the figure, it is assumed that the DP user program is synchronized by the cycle end interrupt each time at the start of the acyclic part.

Synchronization is achieved with the "Hardware Event for Cycle End" (see also Section 3.5.5, "Acyclic Services Using Software Events"). The CP triggers a cycle end interrupt to the device driver which then activates a semaphore. This reactivates the DP user program that is waiting for this semaphore at the API function "WaitForSingleObject" or "WaitForMultipleObjects".

Ex*

Time stamp Time stamp, Activate semaphore

... DE n GC DE 1

TDP

DP V1, others, active/passive pause

DP cyclic DP acyclic + pause

Ex Sx+1

Dual-port RAM access

...

TDpx

DP cyclic

Wait with WaitForSingleObject

User program is activated

Time stamp Sx

Sx*

GC DE 1 DE 2CP 5613/ CP 5614

Device drivers

User program

Wait with WaitForSingleObject

Sx+1*

Figure 2 Structure of the Constant Scan DP Cycle

GC Global control frame before the start of the cyclic DP part

DE1,2..n Data exchange with DP slaves1,2..n

TDP Constant bus cycle time DP cycle

Sx, Sx+1 Start interrupt, cycle x and cycle x+1

Sx*, Sx+1* Time of the start interrupt (cycle x and cycle x+1) recorded by the device driver

Ex End interrupt, cycle x

Ex* Time of the end interrupt and activating the cycle end semaphore (cycle x) recorded by the device driver



Explanations

Each constant bus cycle time DP cycle is made up of a cyclic and an acyclic part (DP cyclic, DP acyclic).

In the cyclic part, user data is transferred between the DP master and the DP slaves.

DP-V1 and other frames are sent in the acyclic part, for example, GAP queries. This part is also padded with a pause if necessary. At the end of the acyclic part of a constant time scan cycle, a global control frame is sent to synchronize the DP slaves.

At the end of the cyclic part, the cycle end interrupt is triggered and can be indicated to the DP user program by the driver (following a certain delay) by activating a common semaphore (time Ex*). Up to this time, the DP user program was waiting with the "WaitForSingleObject" or "WaitForMultipleObjects".

Note From the time Ex* onwards, the DP user program can access the input and output data in the dual-port RAM until the next cycle start interrupt at time Sx+1 which is the start of the next cyclic part (see duration DPR access). Following this, the DP user program can wait again for the next cycle end interrupt.

Constant Bus Cycle Time Elements in the Dual-Port RAM

The dual-port RAM of the CP 5613/CP 5614 has several cells available for the constant bus cycle time mode and these can be accessed by the user program. This access is necessary to allow the following:

• Enabling of start and end interrupts on the CP

• Detection of timing violations on PROFIBUS (configured constant cycle time is not maintained)

• Running statistical and timing checks (for example evaluation of the time stamp)

The cells are in various structures in the dual-port RAM and are listed in the dp_5613.h header file.



DPR_CP5613_CTR_T Structure

The following table explains the DPR_CP5613_CTR_T structure:

Structure element

Meaning

D_cycle_start_ mask

This element enables the cycle start interrupt on the CP 5613/CP 5614 or indicates whether or not the cycle start interrupt has already arrived. After each cycle start interrupt, the DP user program must enable the interrupt again.

Enable To enable the constant bus cycle time mode, the value 0 must be written to the structure element.

Read Based on bit 0, it is possible to check whether the cycle start interrupt has arrived.

Bit Meaning

0 Cycle start interrupt not arrived

1 Cycle start interrupt arrived (see time Sx or Sx+1)

D_cycle_end_ mask

This element enables the cycle end interrupt on the CP 5613/CP 5614 or indicates whether or not the cycle end interrupt has already arrived. After each cycle end interrupt, the DP user program must enable the interrupt again.

Enable To enable the constant bus cycle time mode, the value 0 must be written to the structure element.

Read Based on bit 0, it is possible to check whether the cycle end interrupt has arrived.

Bit Meaning

0 Cycle end interrupt not arrived

1 Cycle end interrupt arrived (see time Ex)



DPR_CP5613_EQU_ERROR_T Structure

The following table explains the DPR_CP5613_EQU_ERROR_T structure:

Structure element

Meaning

count Counter for timing violations on PROFIBUS - if the CP 5613/CP 5614 cannot maintain the configured constant bus cycle time cycle during productive operation, this counter is incremented.

last_diff_tbit Last deviation (in bit times) from the configured constant bus cycle time cycle - this structure element is only significant if "count" has changed compared with the last access.



DPR_CP5613_EQU_T Structure

The following table explains the DPR_CP5613_EQU_ERROR_T structure:

Structure element

Meaning

cycle_start_NT_ Performance Counter

Time stamp of the cycle start interrupt - the CP 5613/CP 5614 device driver calculates this value after receiving the cycle start interrupt using the Win32 function "QueryPerformanceCounter" (see time Sx* or Sx+1*). The value can be evaluated for statistical purposes and time measurements by the DP user program or can be reset. Remember that between the cycle start interrupt and writing the time stamp there is a time offset (resulting from program execution times on the PC).

cycle_end_NT_ Performance Counter

Time stamp of the cycle end interrupt. The CP 5613/CP 5614 device driver calculates this value after receiving the cycle end interrupt using the Win32 function "QueryPerformanceCounter" (see time Ex*). The value can be evaluated for statistical purposes and time measurements by the DP user program or can be reset. Remember that between the cycle end interrupt and writing the time stamp there is a time offset (resulting from program execution times on the PC).

cycle_start_ counter, cycle_end_ counter

Counters that are incremented by the driver when processing a cycle start interrupt or cycle end interrupt. These counters can be read out by the DP user program for statistical purposes.

tmsi_in_us Configured constant cycle time in microseconds. The value can be evaluated for statistical purposes and time comparisons by the DP user program.

Value Meaning

0 Constant bus cycle time mode not supported

FFFF FFFF No constant time scan cycle configured

Misc. Configured cycle time in micro seconds



4.3.17 Typical Phases in the Constant Bus Cycle Time Mode

Definition

After initialization and start up of the CP, the DP user program can activate the hardware event for the cycle end interrupt and wait for its arrival using a Windows semaphore. Following this, access to the dual-port RAM is possible. The basic operation and access to the constant bus cycle time cells in the dual-port RAM is explained below.

Note In the subsequent phases, monitoring of the "count" cell simply checks whether the constant cycle could be maintained on PROFIBUS. There is, however, no evaluation of the time stamp, for example, to detect timing violations of the DP user programs or illegal delays caused by the operating system.

Caution The reaction to a detected constant bus cycle time error depends on the application and is not described in greater detail here. If errors occur, the DP user program must be capable of executing suitable error handling.



Initialization Phase: Cycle End Semaphore is Initialized

Before the hardware events are used for the first time, the cycle end semaphore should be created and the start and end interrupts of the CP 5613/CP 5614 must be enabled for the first time:

Stage Action Meaning 1 Get the semaphore for the

hardware event "Cycle End Interrupt" (see DP_init_sema_object)

The value DP_OBJECT_TYPE_CYCLE_END must be specified in the function as the selector.

2 Enable hardware interrupts for cycle start and cycle end interrupt (write the value 0 to D_cycle_start_mask, D_cycle_end_mask)

The DP user program is designed so that interrupts are triggered at the start of the cycle and end of the cycle (both interrupts are enabled on the CP). The semaphore mentioned above is also activated when the cycle end interrupt is triggered.



Productive Phase: Hardware Event "Cycle End Interrupt" is Used

After fetching the cycle end semaphore, the following actions belonging to the constant bus cycle time mode can be repeated:

Stage Action Meaning 1 Wait for semaphore

(Windows API functions "WaitForMultipleObjects" or "WaitForSingleObject").

The DP user program (or a thread of the DP user program) waits until the cycle end interrupt arrives. "WaitForSingleObject" and "WaitForMultipleObjects" are Windows 32-bit API functions.

2 Check for timing violation on PROFIBUS.

If the "count" cell of the DPR_CP5613_EQU_ERROR_T structure has been incremented since the last cycle, the configured constant bus cycle time cycle could not be maintained.

3 Enable start and end interrupts again.

By writing the value 0 to the cells D_cycle_start_mask or D_cycle_end_mask, the interrupts are enabled again for the next cycle.

4 Access to the dual-port RAM If no errors occurred previously, the DP user program can access the data image in the dual-port RAM.

Closedown Phase: Delete Semaphore

After the last use of the hardware events, the semaphore must be deleted.

Action Meaning Delete semaphore for

events (function DP_delete_sema_object)




Causes of Timing Violations

The table below lists several typical causes of constant bus cycle time violations and possible solutions to the problem.

Type Cause Suggestion Timing violation on Profibus (constant bus cycle time could not be maintained).

● Frequent problems on the bus

● Overload due to other active stations on bus

Problems: Eliminate the cause of the problems on the bus. Misc.

● Check configuration; if necessary, increase constant cycle time.

● Reduce the number of active stations on the same bus.

Timing violation on the PC (runtime effects)

● Runtimes on the PC too high.

● DP user program activated too late by the cycle end semaphore

● The DP user program cannot execute all dual-port RAM accesses during the cyclic part.

● Check configuration; if necessary, increase constant cycle time.

● Increase the computing power (for example faster CPU, optimizations in the operating system)

● Make sure that the DP user program is not interrupted for longer periods, for example by increasing the program or task priority etc.



4.3.18 Checking the Life Counter

Overview

The process image of the CP 5613/CP 5614 contains a memory area with a life counter. This life counter is incremented approximately every 5 ms after the firmware is loaded. Your user program can check this memory area cyclically to monitor the CP 5613/CP 5614. If the value of the life counter does not change within a specified period that must be a multiple of 5 ms for safety reasons (at least 1 second), this indicates a failure of the CP.



Example of Access

"p" is a pointer to the process image that your DP user program obtained with the "DP_get_pointer" call. The last_value parameter of the type DPR_DWORD is the value of the life counter obtained the last time it was accessed. The last_error parameter of the type boolean indicates whether or not the error was also detected in the previous cycle (refer to the note below). To detect a failure of the CP 5613/CP 5614, you would program a sequence similar to that below that is called cyclically. The period between two consecutive calls of the sequence must be a multiple of 5 ms (for example 1 second).

// Compare life counter with previous value if(p->info_watch.cp_life_counter == last_value) { // Counts identical if(last_error) { // Error was also detected in the previous cycle // Failure of the CP -> user specific reaction!! } else { last_error = true; // check again in next // cycle } } else { // Counts different // Store the current life counter value last_value = p->info_watch.cp_life_counter; last_error = false; }

Note Please note that Windows timers can be pushed out by the operating system so that the corresponding timer routines can be called twice, one immediately after the other even though the program interval is set, for example, to 1 second. As a result, the same value can be read twice without any failure of the CP. To make sure that an error has really occurred, you must therefore run the sequence above at least twice.



4.4 Error Handling

Uniform Error Structure DP_ERROR_T

The error identifiers for the individual jobs have a uniform structure DP_ERROR_T. If an error occurs, the various elements return the exact description of the error.

typedef struct DP_ERROR { DPR_DWORD error_class; DPR_DWORD error_code; DPR_BYTE error_decode; DPR_BYTE error_code_1; DPR_BYTE error_code_2; } DP_ERROR_T;



error_class Structure Element

The error_class structure element specifies the general error class. The entry in error_class is identical to the return value of the function call.

A DP application can therefore evaluate either the error_class structure element or the return value of the function call.

The table describes the possible error classes and shows which of the other structure elements of DP_ERROR_T are valid for the individual error classes.

Error Class Description DP_OK No error, the job was executed and the results

are available. DP_OK_ASYNC Job was execution was triggered successfully,

the confirmation is not yet available. The result must be fetched later by a DP_get_result call. This result is only possible with asynchronous jobs.

DP_ERROR_EVENT The slave sends an error code in the response frame to one of the following DPC1 requests:

● DP_ds_write

● DP_ds_read

● DP_alarm_ack

DP_ERROR_EVENT_NET Error in PROFIBUS communication, for example connection breakdown

DP_ERROR_REQ_PAR Incorrect transferred parameter for a call or call illegal.

DP_ERROR_CI Error accessing the CP. DP_ERROR_RES Not enough resources available. DP_ERROR_USR_ABORT Active jobs aborted because the DP user

program has logged off (only possible with DP_get_result).



error_code Structure Element

The error_code structure element is relevant in the error classes:

• DP_ERROR_EVENT_NET

• DP_ERROR_REQ_PAR

• DP_ERROR_CI

• DP_ERROR_RES

• DP_ERROR_USR_ABORT

In the DP_ERROR_EVENT_NET error class, the error_decode structure element must also be evaluated with some function calls.

error_decode, error_code_1, error_code_2

The error_decode, error_code_1 and error_code_2 structure elements are only relevant in the DP_ERROR_EVENT error class. In this case, all three elements must be evaluated. They contain an error coding that a DP-V1 slave can return in the response frame after a DP-V1 request.

Description of the Error Classes

The following Figure 3 shows how a DP user program evaluates errors when a DP function is called.

ErrClass = DP_xxx

Fetch confirmationwith DP_get_result

Job executed,evaluate return

parameters

Evaluateerror_decode,error_code1/2

Evaluateerror_code/decode(DP_get_err_txt)

ErrClass?

DP_OK DP_OK_ASYNC

DP_ERROREVENT

Others

Figure 3 Evaluation of the Return Values



Meaning of the Errors

You will find an overview of the individual error codes and their grouping into the error classes described above in a table in Section 4.4.2 "Error Codes". There is a brief description with each error code. You can also obtain this description by calling the DP_get_err_txt function after an error has occurred.



4.4.1 Entries in the error_decode, error_code_1 and error_code_2 structure elements in Error Class DP_ERROR EVENT

Description

This section describes the entries in the following structure elements:

• error_decode

• error_code_1

• error_code_2

All three parameters must be evaluated together.

They contain error information sent by the DP-V1 slave.

error_decode

The error_decode parameter specifies the meaning of the parameters error_code_1 and error_code_2. The following table shows the range of values:

Values Meaning 0 to 127 reserved 128 DP-V1 129 to 253 reserved 254 PROFIBUS-FMS 255 HART®



Error_Decode = PROFIBUS_FMS, HART®

The Error_Decode values PROFIBUS FMS and HART® indicate that the parameters Error_Code_1 and Error_Code_2 must be interpreted as defined in the relevant protocols.

With PROFIBUS FMS:

Error_Code Parameter Meaning Error_Code_1 Error_Class_FMS Error_Code_2 Error_Code_FMS

With HART®:

Error_Code Parameter Meaning

Error_Code_1 see HART specification

Error_Code_2 see HART specification

Error_Decode = DP-V1

The parameters Error_Code_1 and Error_Code_2 contain the error information specific to DP-V1.

Structure of Error_Code_1 with DP-V1

The error coding strategy of DP-V1 uses Error_Code_1 to classify the error (class) and to specify an additional error code.

MSB LSB

7 6 5 4 3 2 1 0

CodeClass



Error_Code_1

The possible values of code and class are shown in the following table:

Byte Structure Meaning

Class Code Class Code

0 to 9 any reserved reserved

10 0 application read error

1 write error

2 module failure

3 to 7 reserved

8 version conflict

9 feature not supported

10 to 15 user specific

11 0 access invalid access

1 write length error

2 invalid slot

3 type conflict

4 invalid area

5 state conflict

6 access denied

7 invalid range

8 invalid parameter

9 invalid type


12 0 resource read constrain conflict

1 write constrain conflict

2 resource busy

3 resource unavailable

4 to 7 reserved


13 to 15 any user specific user specific

Structure of Error_Code_2 with DP-V1

The Error_Code_2 parameter is user-specific.



4.4.2 Error Codes

Overview

This section contains an alphabetical list of all possible error codes and a brief description of each error code for the following error classes:

• DP_ERROR_EVENT_NET

• DP_ERROR_REQ_PAR

• DP_ERROR_CI

• DP_ERROR_RES

DP_ERROR_EVENT_NET Class

DP_ERROR_EVENT_NET Class Error Codes

Meaning

DP_RET_CP_ADR_NOT_IN_DB The slave address is not included in the database of the CP.

DP_RET_CP_ ALARM_STATE_OVERFLOW

Error: The maximum number of configured alarms has been exceeded by the slave.

DP_RET_CP_ ALARM_STATE_INCONSISTENT

Error: The slave has sent more than one alarm of the same type.

DP_RET_CP_ ALARM_STATE_WRONG_TYPE

The slave has sent an alarm but the alarm type is not configured.

DP_RET_CP_ ALARM_STATE_PDU_LENGTH

The slave has sent an alarm or a status message with a length greater than specified.

DP_RET_CP_ ALARM_STATE_PDU_FORMAT

The slave has sent diagnostic data with format errors so that it is not possible to decode the alarm or status correctly.

DP_RET_CP_CLOSED The execution instance in the firmware was closed earlier and no longer exists.

DP_RET_CP_CONTROL_COMMAND Control command is invalid. DP_RET_CP_DATABASE_ADR

There is an invalid slave address in the database of the CP.

DP_RET_CP_INIT_INSTANCE Error in DP Setup. DP_RET_CP_L2_REQ Unknown opcode in the confirmation.




Meaning

DP_RET_CP_MEMORY_DPMC Internal memory error on the CP.

DP_RET_CP_NO_DATABASE No (valid) database was downloaded to the CP.

DP_RET_CP_REQ_ACTIV DP request already being executed.

DP_RET_CP_REQ_INVALID_LEN The job was terminated by an error (invalid data length).

DP_RET_CP_REQ_INVALID_PAR The job was terminated by an error due to invalid parameters.

DP_RET_CP_REQ_NEG Negative acknowledgment when sending the job via Profibus. Possible causes: Slave does not respond or the service access point on the slave is not activated.

DP_RET_CP_REQ_NOT_ ALLOWED The service is not permitted.

DP_RET_CP_REQ_NOT_FOUND The corresponding job field of the request was not found.

DP_RET_CP_REQ_RE Format error in a response frame. Source: local DP instance (Direct Data Link Mapper).

DP_RET_CP_MM_FE Format error in a request frame Source: remote DP instance (Direct Data Link Mapper).

DP_RET_CP_MM_NI Function not implemented. Source: remote user

DP_RET_CP_MM_AD Access denied Source: remote user

DP_RET_CP_MM_EA Area too large (up/download) Source: remote user

DP_RET_CP_MM_LE Data field too long (up/download) Source: remote user

DP_RET_CP_MM_RE Format error in a response frame Source: local DP instance (Direct Data Link Mapper).

DP_RET_CP_MM_IP Invalid parameter. Source: remote user

DP_RET_CP_MM_SC Sequence conflict Source: remote user

DP_RET_CP_MM_SE Sequence error Source: remote DP instance (Direct Data Link Mapper).

DP_RET_CP_MM_NE Area does not exist Source: remote user




Meaning

DP_RET_CP_MM_DI Data incomplete Source: remote user

DP_RET_CP_MM_NC Master parameter record not compatible Source: remote user

DP_RET_CP_REQ_WITHDRAW The job was withdrawn and can therefore not be processed.

DP_RET_CP_RESET_INSTANCE Error in DP reset.

DP_RET_CP_RESET_RUNNING Reset already activated.

DP_RET_CP_SET_MODE_CLR_ACT The DP_set_mode call could not be made because a previous DP_set_mode call (change to the clear status) is still being processed.

DP_RET_CP_SET_MODE_FAIL Error occurred executing DP_set_mode.

DP_RET_CP_SET_MODE_OFFL_ACT The DP_set_mode call could not be executed because a previous DP_set_mode call (change to the offline status) is still being processed.

DP_RET_CP_SET_MODE_OPR_ACT The DP_set_mode call could not be executed because a previous DP_set_mode call (change to the operate status) is still being processed.

DP_RET_CP_SET_MODE_STOP_ACT The DP_set_mode call could not be made because a previous DP_set_mode call (change to the stop status) is still being processed.

DP_RET_CP_SLV_NOT_ACTIV The slave is not activated.

DP_RET_CP_SLV_NOT_IN_DATA The slave is (currently) not ready for data exchange.

DP_RET_CP_STARTED The execution instance was already started.

DP_RET_CP_STATE_UNKNOWN The execution instance is in an undefined state.

DP_RET_CP_STOPPED The execution instance is already stopped.

DP_RET_CP_TIMEOUT Note: The job was terminated by a timeout.

DP_RET_CP_TIMER Internal timer error on the CP.

DP_RET_CP_TOO_MANY_ CTRL_CMD Too many global control commands being processed.

DP_RET_CP_UNKNOWN_SLV_TYPE Slave type unknown.

DP_RET_CP_USR_NOT_COMPATIBLE The dplib.dll and the dp_base.dll cannot register on the same CP.

DP_RET_CP_WRONG_INSTANCE Access by an invalid user instance.




Meaning

DP_RET_CP_WRONG_MODE_CLR Illegal mode when setting the mode. Current mode: DP_CLEAR Permitted mode: DP_STOP, DP_OPERATE

DP_RET_CP_WRONG_MODE_OFL Illegal mode when setting the mode. Current mode: DP_OFFLINE Permitted mode: DP_STOP

DP_RET_CP_WRONG_MODE_OPR Illegal mode when setting the mode. Current mode: DP_OPERATE Permitted mode: DP_CLEAR

DP_RET_CP_WRONG_MODE_STP Illegal mode when setting the mode. Current mode: DP_STOP Permitted mode: DP_OFFLINE, DP_CLEAR

DP_RET_REQ_ACTIV A corresponding request is already being executed. After fetching the result with DP_get_result, a further request of this type is possible: With DP_ds_write, DP_ds_read and DP_get_actual_cfg one of these requests is possible as well as an additional DP_alarm_ack per slave. With DP_enable_event, several requests cannot be executed at the same time.

DP_RET_TIMEOUT Note: The set timeout time has expired. Meaning for DP_get_result: No confirmation was received. Meaning for DP_get_pointer: The pointer could not be obtained, possible cause: Other application are using the pointer.



DP_ERROR_EVENT_NET Class Error codes for the slave module

function of the CP 5614

Meaning

DPS_ALARM_DIAG_STATE_ ERROR

The diagnostic frame with alarm cannot be sent because DPS_EXT_DIAG_OV or DPS_STAT_DIAG is set in the diag_state parameter.

DPS_ALARM_NOT_ALLOWED_ERROR The diagnostic frame with alarm cannot be sent because the DP slave is not configured as a slave with DP-V1 capability.

DPS_ALARM_WRONG_STATE_ ERROR

The diagnostic frame with alarm cannot be sent because the DP slave is not in the DPS_DATA_EX state.

DPS_RET_ALARM_NOT_ACK_ ERROR

The diagnostic frame with alarm cannot be sent because the last alarm has not yet been acknowledged by the DP master with Alarm Acknowledge.

DPS_RET_DOUBLE_OPEN DPS_open was already executed.

DPS_RET_NOT_OFFLINE The slave module is not offline.

DPS_RET_SEQUENCE_ERROR The command is not permitted in the current mode.

DPS_RET_UNKNOWN_ERROR Unknown error.



DP_ERROR_REQ_PAR Class

DP_ERROR_REQ_PAR Class Error Codes

Meaning

DP_RET_CP_WRONG_FREEZE_GRP The global control call (freeze/unfreeze) was terminated with an error because the addressed DP slave does not belong to any of the specified groups.

DP_RET_CP_WRONG_GC_CMD The job was terminated with an error (invalid global control command).

DP_RET_CP_WRONG_GC_GRP The job was terminated by the CP due to an error (invalid global control group).

DP_RET_CP_WRONG_SYNC_GRP The global control call (sync/unsync) was terminated with an error because the addressed DP slave does not belong to any of the specified groups.

DP_RET_PAR_ALARM The alarm parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_ALARM_TYPE The alarm_type parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_CP_NAME The cp_name parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_CREF The c_ref parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_CTRL_CMD The control_command parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_DATA The data parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_DATA_LEN The data_len parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_DPR The dpr (dual-port ram) parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_FL The fast_logic parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_INDEX The index parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_LENGTH_M The length_m parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_LENGTH_S The length_s parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_MSG_FILTER The msg_filter parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_MST_MODE The mst_mode parameter is invalid. The job was rejected by the DP_BASE library.



DP_ERROR_REQ_PAR Class Error Codes

Meaning

DP_RET_PAR_REQ_TYPE The req_type parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_REQUEST The request parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_RESERVED The reserved parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_RESULT The result parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_SELECTOR The selector parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_SEMA_TYPE The sema_type parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_SLOT_NUMBER The slot_number parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_SLV_ADD The slv_add parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_SLV_MODE The slv_mode parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_TIMEOUT The timeout parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_TYPE The type parameter is invalid. The job was rejected by the DP_BASE library.

DP_RET_PAR_USR_HNDL The user_handle parameter is invalid or undefined. The job was rejected by the DP_BASE library.

DP_RET_PAR_WD_INDEX The wd_index parameter is invalid. The job was rejected by the DP_BASE library.



DP_ERROR_REQ_PAR Class Error codes for the slave module

function of the CP 5614

Meaning

DPS_RET_BUF_LEN The buffer length is invalid.

DPS_RET_CFG_LEN Max_cfg_data_len incorrect.

DPS_RET_DIAG_LEN Max_user_diag_len incorrect.

DPS_RET_DIN_DOUT_LEN Max. input/output incorrect.

DPS_RET_INV_CFG Invalid default configuration.

DPS_RET_INV_SLAVE_ADDR slave_addr parameter incorrect.

DPS_RET_INV_TIMEOUT The timeout parameter is invalid.

DPS_RET_NOT_IMPLEMENTED The service is not yet implemented.

DPS_RET_PAR_ALARM The diagnostic frame with alarm cannot be sent due to parameter errors.

DPS_RET_PAR_ASYNC_HDL The AsyncHandle parameter is invalid.

DPS_RET_PAR_BAUD_RATE Baud_rate incorrect.

DPS_RET_PAR_CFG_DATA Cfg_data incorrect.

DPS_RET_PAR_CFG_LEN The cfg_len parameter is incorrect.

DPS_RET_PAR_DATA_BLK Data_blk incorrect.

DPS_RET_PAR_DIAG_DATA Diag_data incorrect.

DPS_RET_PAR_DIAG_DATA_FMT The format of the diagnostic data is invalid.

DPS_RET_PAR_DIAG_LEN Diag_len incorrect.

DPS_RET_PAR_DIAG_STATE Diag_state incorrect.

DPS_RET_PAR_GC Gc incorrect.

DPS_RET_PAR_IN_DATA_LEN In_data_len incorrect.

DPS_RET_PAR_IND_REF Ind_ref incorrect.

DPS_RET_PAR_INDICATION Bad indication.

DPS_RET_PAR_INIT_DATA Init_data incorrect.

DPS_RET_PAR_OUT_DATA_LEN Out_data_len incorrect.

DPS_RET_PAR_SLAVE_MODE Bad slave_mode.

DPS_RET_PAR_SLAVE_MODE_V1 DP-V1 operation not possible.

DPS_RET_PAR_STATE State incorrect.

DPS_RET_PAR_SYNC_HDL The SyncHandle parameter is invalid.

DPS_RET_PRM_LEN Max_user_prm_data_len incorrect.

DPS_RET_SSA_LEN Max_user_ssa_data_len incorrect.



DP_ERROR_CI Class

DP_ERROR_CI Class Error Codes

Meaning

CI_RET_ALREADY_CONNECTED User already has access.

CI_RET_BLINK_INV_LED1_MS Invalid time for LED1.

CI_RET_BLINK_INV_LED2_MS Invalid time for LED2.

CI_RET_BLINK_INV_MODE Invalid mode.

CI_RET_BUF_NOT_VALID Invalid user buffer.

CI_RET_CANCEL_NO_RECEIVE Note: Nothing there to abort.

CI_RET_CIB_CLOSE_ALREADY Double close.

CI_RET_CIB_HOST_READY Data semaphore does not have a plausible state.

CI_RET_CIB_INV_FILL_LENGTH_1 Fill_length is invalid.

CI_RET_CIB_INV_NEXT_BLOCK Next_block is invalid.

CI_RET_CIB_INV_NEXT_REQUEST Next_request is invalid.

CI_RET_CIB_MAX_INDEX Index invalid.

CI_RET_CIB_NEXT_BLOCK Bad request chaining.

CI_RET_CIB_NEXT_INDEX Bad request chaining.

CI_RET_CIB_OPEN_ALREADY Double open.

CI_RET_CIB_OPEN_HANDLE Invalid handle.

CI_RET_CIB_SUB_NOT_IMP Subsystem not implemented.

CI_RET_CIB_SUBSYSTEM Subsystem is invalid.

CI_RET_CONNECT_DOWN Internal error.

CI_RET_CONNECT_DPR Internal error.

CI_RET_CONNECT_MAX Maximum CI_connect_cp number exceeded.

CI_RET_CONNECT_NO_CP Internal error.

CI_RET_CONNECT_PLX Internal error.

CI_RET_CONNECT_TWICE Internal error.

CI_RET_CP_NAME_00 Internal error.

CI_RET_CP_NAME_NOT_FOUND Invalid CP name.

CI_RET_CP_NAME_TOO_LONG CP name is too long.

CI_RET_CP_NOT_HERE CP does not exist.

CI_RET_CP561X_ROOT Entry missing in the registry -> error during installation.

CI_RET_DISCONNECT_NOT_CONNECTED_0 No mapping created -> internal error.



CI_RET_DUMP_FILENAME_TOO_LONG File name too long.




Meaning

CI_RET_DUMP_OPEN_FILE The file for the dual-port RAM dump cannot be opened.

CI_RET_EXCP_ALERTED CI_RET_EXCP_APPEND_0 CI_RET_EXCP_APPEND_1 CI_RET_EXCP_CIB CI_RET_EXCP_CLOSE_0 CI_RET_EXCP_CLOSE_1 CI_RET_EXCP_CRITICAL_0 CI_RET_EXCP_CYCLE_0 CI_RET_EXCP_CYCLE_1 CI_RET_EXCP_E_LIST_0 CI_RET_EXCP_E_LIST_1 CI_RET_EXCP_GET_DP_ACCESS CI_RET_EXCP_KE_WAIT CI_RET_EXCP_LIFE_COUNTER CI_RET_EXCP_OPEN CI_RET_EXCP_QUEUE_DPA_0 CI_RET_EXCP_QUEUE_DPA_1 CI_RET_EXCP_REL_DP_ACCESS_0 CI_RET_EXCP_REL_DP_ACCESS_1 CI_RET_EXCP_RETURN_0 CI_RET_EXCP_RETURN_1 CI_RET_EXCP_RETURN_2 CI_RET_EXCP_USER_APC

Exceptions -> Internal error states of the driver or software. Remedy -> reset CP or reboot PC.

CI_RET_FL_ALREADY_OFF Fast Logic already deactivated.

CI_RET_FL_ALREADY_ON Fast Logic already activated.

CI_RET_FL_DOUBLE_USER A second user is not permitted.

CI_RET_FL_INV_ACTION Internal error.

CI_RET_FL_INV_ADDR_IN_BYTE Invalid address of the input slave.

CI_RET_FL_INV_ADDR_OUT_BYTE Invalid address of the output slave.

CI_RET_FL_INV_ID Invalid fast_logic_id parameter -> 0...3.

CI_RET_FL_INV_IN_MASK Invalid mask for the input byte.

CI_RET_FL_INV_INDEX_IN_BYTE Invalid input byte.

CI_RET_FL_INV_INDEX_OUT_BYTE Invalid output byte.

CI_RET_FL_INV_OUT_MASK Invalid mask for the output byte.

CI_RET_FL_NOT_CLEAR activated_fast_logic[id] field is not zero.




Meaning

CI_RET_FL_SLAVE_IN_NOT_IN_DB Input slave not in the database.

CI_RET_FL_SLAVE_OUT_NOT_IN_DB Output slave not in the database.

CI_RET_GET_CFG_INV_NAME Internal error.

CI_RET_GET_CFG_WRONG_NAME Internal error.

CI_RET_GET_MAX_PENDING Maximum number per CI_open exceeded.

CI_RET_GET_TIMEOUT Note: Timeout

CI_RET_HANDLE_CLOSING Handle being closed.

CI_RET_HANDLE_CP_RESET The CP was reset -> close the application.

CI_RET_HANDLE_INVALID Invalid value for user handle.

CI_RET_HANDLE_NOT_OPEN Handle unknown.

CI_RET_INV_SEMA_TYPE Invalid sema type.

CI_RET_INV_USR_BUF_FILL_LENGTH Fill_length > buf_length.

CI_RET_INV_USR_BUF_LENGTH Buffer too long.

CI_RET_INV_USR_OPCODE Invalid subsystem.

CI_RET_NO_CP_NAME With this function, the CP name must be specified.

CI_RET_NO_DRIVER Driver not loaded.

CI_RET_NOT_IMPLEMENTED Function not implemented.

CI_RET_OPEN_CP_NOT_STARTED CP not started.

CI_RET_OPEN_MAX Maximum CI_open number exceeded.

CI_RET_OPEN_REG Internal error.

CI_RET_OPEN_TEMP_LOCKED Service not currently possible.

CI_RET_RCV_EVENT_INV_OPC Internal error.

CI_RET_RECEIVE_BUF_TOO_SMALL_0 User buffer too small.

CI_RET_RECEIVE_BUF_TOO_SMALL_1 User buffer too small.

CI_RET_RECEIVE_MAX_PENDING Too many receives with timeout per CI_open.

CI_RET_RECEIVE_TIMEOUT_CANCEL Note: Receive was aborted.

CI_RET_RECEIVE_TIMEOUT_NO_DATA Timeout elapsed.

CI_RET_RECEIVE_TIMEOUT_USER_APC Internal error.

CI_RET_RELEASE_NO_ACCESS User did not have access.

CI_RET_RESET_ALREADY_DONE Note: CP is already in the reset state.




Meaning

CI_RET_RESET_CP_NOT_FOUND CP was not found.

CI_RET_RESET_CP_USED Reset not currently possible.

CI_RET_RESET_INVALID_CP_NAME Invalid CP name.

CI_RET_RESET_INVALID_MODE Invalid reset mode.

CI_RET_SCP_BUF_FILL_LENGTH_INV Buf_fill_length invalid.

CI_RET_SCP_FILL_LENGTH_1_TOO_BIG Fill_length_1 > seg_length_1.

CI_RET_SCP_FILL_LENGTH_2_TOO_BIG Fill_length_2 > seg_length.

CI_RET_SCP_OFFSET_1_INVALID Offset_1 != 80.

CI_RET_SCP_OFFSET_2_INVALID Offset_2 out of range.

CI_RET_SCP_OPEN_MAX Maximum number of SCP_open reached.

CI_RET_SCP_PARAM Invalid parameter.

CI_RET_SCP_SEG_LENGTH_1_TOO_BIG Seg_length_1 > 260.

CI_RET_SCP_SEG_LENGTH_2_TOO_BIG Seg_length_2 > 260.

CI_RET_SCP_WRONG_SUBSYSTEM Subsystem is not 0x22.

CI_RET_SEMA_NOT_INITIALIZED Semaphore not initialized.

CI_RET_SEMA_TWICE An object of this type already exists for the user handle.

CI_RET_SEND_BUF_TOO_SMALL User buffer for the response is too small.

CI_RET_SEND_NO_BUFFER_AVAILABLE Lack of resources in the DPR.

CI_RET_SET_HWND_MSG Error in the SetSinecHWndMsg function.

CI_RET_START_ACTION_ERR Internal error.

CI_RET_START_ALREADY_DATABASE Second start with a different database.

CI_RET_START_ALREADY_DONE Note: CP already started.

CI_RET_START_CP_NO_REACTION Internal error -> CP not reacting.

CI_RET_START_CP_NOT_FOUND CP was not found.

CI_RET_START_CP_RESOURCES_INT Internal error -> resource problem.

CI_RET_START_DOWN_1 Internal error.

CI_RET_START_ERROR_ERR Internal error.

CI_RET_START_FN_DB_TOO_LONG Database path too long.

CI_RET_START_FN_FW_TOO_LONG Firmware path too long.

CI_RET_START_FW_INIT_EXCP Internal error -> firmware indicating exception.

CI_RET_START_FW_INIT_TIMEOUT Internal error -> firmware not responding.

CI_RET_START_INVALID_CP_NAME Invalid CP name.

CI_RET_START_INVALID_MODE Invalid start mode.

CI_RET_START_LEN_DATABASE Database file too long.




Meaning

CI_RET_START_LEN_FIRMWARE Firmware file too long.

CI_RET_START_MAP Internal error.

CI_RET_START_MAX_CP Maximum number of CPs already reached.

CI_RET_START_NO_VIEW Internal error.

CI_RET_START_OK_ERR Internal error.

CI_RET_START_OPEN_DATABASE Database file could not be opened.

CI_RET_START_OPEN_FIRMWARE Firmware file could not be opened.

CI_RET_START_REG_DATABASE Internal error - no database entered.

CI_RET_START_REG_DOWNLOAD Internal error - no firmware entered.

CI_RET_START_REG_gc_data_0 CI_RET_START_REG_gc_data_1 CI_RET_START_REG_gc_group CI_RET_START_REG_tmsi CI_RET_START_REG_tmsi_reserve CI_RET_START_REG_ttr_div_256 CI_RET_START_REG_tth_div_256_equ_dis

Entry missing in the registry -> error during installation.

CI_RET_START_REG_NO_SWITCH_OUTPUT Bad registry entry.

CI_RET_START_TEMP_LOCKED Service not currently possible.

CI_RET_START_TRANSLATE Internal error.




Meaning

CI_RET_CmResourceTypeDefault CI_RET_CmResourceTypeDeviceSpecific CI_RET_CmResourceTypeDma CI_RET_CmResourceTypePort CI_RET_HalAssignSlotResources CI_RET_InterruptMode CI_RET_IoReportResourceUsage CI_RET_MAP_00 CI_RET_MAP_01 CI_RET_MAP_02 CI_RET_MAP_03 CI_RET_MAP_DOWN_0 CI_RET_MAP_DOWN_1 CI_RET_MAP_DPR_0 CI_RET_MAP_DPR_1 CI_RET_MAP_PLX_0 CI_RET_MAP_PLX_1 CI_RET_mem_def CI_RET_mem_res_count CI_RET_plx_length CI_RET_UNMAP

Internal error identifying the CP with the Plug and Play Bios. Remedy check CP/computer contact | replace CP | replace computer.



DP_ERROR_RES Class

DP_ERROR_RES Class Error Codes

Meaning

DP_RET_CP_MEMORY Internal memory error

DP_RET_CP_MEMORY_1 Internal memory error(1)







DP_RET_CP_NO_BUS_PAR There are no DP bus parameters contained in the database of the CP.

DP_RET_CP_NO_DP_PAR There are no DP parameters in the database of the CP.

DP_RET_CP_TOO_MANY_SLV There are too many slaves configured.

DP_RET_CP_TOO_MANY_USR No more DP instances can log on at the CP.

DP_RET_MEMORY Internal memory error

DP_RET_TOO_MANY_USR No more DP instances can log on at the CP.

DP_ERROR_RES Class Error codes for the slave

module function of the CP 5614

Meaning

DPS_RET_LESS_MEM The requested buffer sizes are too high.

DPS_RET_NO_DPR_PTR No access to the dual-port RAM.

DPS_RET_NO_SLAVE_MODULE Slave module does not exist.



4.5 Formats of the Slave Data

Order of the Slave Data

The order of the data corresponds to the configured input/output ports of the DP slaves.

For example, the input ports of an ET 200B 16DI station are stored as follows: port 0 in the first byte, port 1 in the 2nd byte etc.

Format of Data Words

The following order is necessary for storing values in the word format (2-byte numbers):

First, the high byte (lower order address) of the word is entered followed by the low byte (higher order address),in other words in Motorola format.

Note 1 This order does not correspond to the format of processors belonging to the 80x86/Pentium family!

Note 2 Take into account any additional information from the vendor of the slaves your DP user program should support.



4.6 Formats of the Slave Diagnostic Data

Explanation

In some cases, in the following data structures single bits in the bytes are significant. The bits are numbered as follows: the least significant bit has the number 0 and the most significant bit has the number 7.

Caution Take into account any additional information from the vendor of the slaves your DP user program should support.



4.6.1 Overview of the Entire Structure

Possible Length

The typical length of diagnostic data is between 6 and 32 bytes. The maximum possible length is 244 bytes.

Header and up to Four Following Fields

Diagnostic data have a fixed header and up to four further fields:

Header Always present,fixed length

Device-relateddiagnostics

Optional,variable length

ID-relateddiagnostics

Optional,variable length

Channel-relateddiagnostics

Optional,fixed length

Revision number Optional,fixed length

Identification of the Optional Parts

At the beginning of the optional parts there is a unique coding to distinguish one part from another.



4.6.2 Format of the Diagnostic Data Header

Overall Structure of the Header

Byte Meaning Byte 1 Stationstatus_1 Byte 2 Stationstatus_2 Byte 3 Stationstatus_3 Byte 4 Diag.Master_Add Byte 5 and 6 Ident_Number



Byte 1 (Stationstatus_1)

Each bit in byte 1, the "stationstatus_1“ byte has a special meaning.

Bit Name and Meaning 7 Diag. Master_Lock — The DP slave has already had parameters

assigned by a different master,in other words, the local master cannot currently access this slave.

6 Diag. Prm_Fault — This bit is set by the slave if the last parameter assignment frame was incorrect (for example wrong length, wrong ident number, invalid parameters).

5 Diag. Invalid_Slave_Response — This bit is set as soon as an implausible response is received from an addressed DP slave.

4 Diag. Not_Supported — his bit is set as soon as a function is requested that is not supported by the slave (for example operation in the SYNC mode although the slave does not support this).

3 Diag. Ext_Diag — This bit is set by the DP slave. If the bit is set, there must be a diagnostic entry in the slave-specific diagnostic area (Ext_Diag_Data). If the bit is not set, there may be a status message in the slave-specific diagnostic area (Ext_Diag_Data). The meaning of the status message must be negotiated with each specific user program.

2 Diag. Cfg_Fault — This bit is set when the configuration data last sent by the master do not match those determined by the DP slave,in other words, when there is a configuration error.

1 Diag. Station_Not_Ready — This bit is set when the DP slave is not yet ready for the productive phase.

0 Diag. Station_Non_Existent — The DP master sets this bit, if the DP slave is not obtainable on the bus. If this bit is set, the diagnostic bits contain the status of the last diagnostic message or the initial value. The DP slave always sets this bit to zero.




Each bit in byte 2, the "station_status_2“ byte has a special meaning.

Bit Meaning 7 Diag. Deactivated — This bit is set as soon as the DP slave is

indicated as inactive in the local parameter record and was taken out of cyclic processing.

6 reserved 5 Diag. Sync_Mode — This bit is set by the DP slave as soon as it

receives the Sync control command. 4 Diag. Freeze_Mode — his bit is set by the DP slave as soon as it

receives the Freeze control command. 3 Diag. WD_On (Watchdog on) — This bit is set by the DP slave. If it

is set to 1, the watchdog monitoring is activated on the DP slave. 2 The DP slave always sets this bit to 1. 1 Diag. Stat_Diag (Static Diagnostics) — If the DP slave sets this

bit, the DP master must fetch diagnostic information until the bit is cleared. The DP slave, for example, sets this bit when it is not capable of providing valid user data.

0 Diag. Prm_Req — If the DP slave sets this bit, it must be reassigned parameters and be reconfigured. This bit remains set until parameters have been assigned (if bit 1 and bit 0 are set, bit 0 has the higher priority).


Bit Meaning 7 Diag. Ext_Diag_Overflow - If this bit is set, there is more diagnostic

data than can be indicated. The DP slave sets this bit, for example, when there is more channel diagnostic data than the DP slave can enter in its send buffer. The DP master also sets this bit when the DP slave sends more diagnostic data than the DP master can accommodate in its diagnostic buffer.

6 to 0 reserved

Byte 4 (Diag. Master_Add)

The address of the DP master that assigned parameters to the DP slave is entered here. If the DP slave has not been assigned parameters by a DP master, the DP slave sets the address 255 in this byte.



Bytes 5 and 6 (Ident_Number)

The vendor ID for a DP slave type is assigned in bytes 5 and 6, the "Ident_Number“ byte. This identifier can be used on the one hand for test purposes and on the other for precise identification of the slave. The value is in Motorola format,in other words the higher order part is in byte 5.



4.6.3 Format of the Device-Related Diagnostic Data (Standard DP Slave)

Meaning

With standard DP slaves (without the DPC1 extensions), this field contains general diagnostic information such as overtemperature, undervoltage or overvoltage. The coding is specified by the slave vendor. For further evaluation, the Ident_Number of the slave is required.

Structure

Byte Meaning Byte 1 Header byte Bytes

2 to 63 Diagnostic_User_Data

Byte 1 (Header Byte)

The two most significant bits in the first byte have the value 00. This identifies the entire field as "device-related diagnostics".

The remaining six bits specify the length of the data field including the first byte.



4.6.4 Format of the Device-Related Diagnostic Data (Slaves with DP-V1 Extensions)

Meaning

With these slaves, the device-related diagnostic data contains alarm data or status messages. The status messages also include the variant "module status".

Entire Structure with Two Variants

The device-related diagnostic data exists in two variants: alarms and status messages. Some components therefore have different codings.

The two variants can be distinguished by byte 2, bit 7.

Byte "Alarms" Variant "Status Messages" Variant Byte 1 Header byte Byte 2 Alarm_Type Status_Type Byte 3 Slot number Byte 4 Alarm specifier Status specifier Byte 5

to 63 Diagnostic_User_Data

Byte 1 (Header Byte)

The two most significant bits in the first byte have the value 00. This identifies the entire field as "device-related diagnostics".




Byte 2 (Variant Alarm_Type)

Bit Meaning 7 Value Meaning 0 Alarm 6 to 0 Alarm_Type

0 = reserved 1 = Diagnostic alarm 2 = Process alarm 3 = Pull alarm 4 = Plug alarm 5 = Status alarm 6 = Update alarm 7-31 = reserved 32-126 = Vendor-specific 127 = reserved

Byte 2 (Variant Status_Type)

Bit Meaning 7 Value Meaning 1 Status message 6 to 0 Status_Type

0 = reserved 1 = Status message 2 = Module status 3-31 = reserved 32-126 = Vendor-specific 127 = reserved

Byte 3 (Slot Number Variant)

Bit Meaning 7 to 0 Slot number



Byte 4 (Alarm Specifier Variant)

Bit Meaning 7 to 3 Seq_Nr Unique identifier of an alarm message 2 Add_Ack If this bit is set, the DP-V1 master indicates that this

alarm requires a user confirmation (for example in the form of a write service) in addition to the DPC1 alarm acknowledge.

1 to 0 Alarm specifier 0 = no further information 1 = Alarm enters state, slot problem

The slot generates an alarm due to an error/fault.

2 = Alarm leaves state, slot OK The slot generates an alarm and indicates that the slot no longer has an error/fault.

3 = Alarm leaves state, slot still has problemThe slot generates an alarm and indicates that the slot still has an error/fault.

Byte 4 (Status Specifier Variant)

Bit Meaning 7 to 2 reserved 1 to 0 Status specifier

0 = no further information 1 = status enters state 2 = status leaves state 3 = reserved



Byte 5-63

User-Specific Information These bytes contain data with additional user-specific information. The format is described in the slave documentation.

With the "status messages" variant and the "Module_Status" setting (see byte 2), two bits are assigned to each module/slot. The module status is byte-oriented, unused bits are set to 0.

MSB LSB 7 6 5 4 3 2 1 0 Byte 5: Module_

Status 4 Module_ Status 3

Module_ Status 2

Module_ Status 1

... ... ... ... ... Byte m: Module_

Status n Module_ Status n-1

... ...

The status bits are coded as follows:

Bit Meaning 00 Data valid 01 Data invalid: the data of the corresponding module are invalid due to

an error/fault (for example short-circuit) 10 Data invalid/wrong module: the data of the corresponding module are

invalid because the module is wrong 11 Data invalid/ no module: the data of the corresponding module are

invalid because no module is inserted



Example of Device-Related Diagnostic Data with Status Message

The following diagram shows status diagnostic data based on the scheme outlined above.

MSB LSB 7 6 5 4 3 2 1 0 Device-related

diagnostics: 0 0 0 0 0 1 1 1

Status type: status message 1 0 0 0 0 0 0 1 Slot number 2 0 0 0 0 0 0 1 0 Specifier: no further

information 0 0 0 0 0 0 0 0

User diagnostic data: 5 average temperature

0 0 0 0 0 1 0 1

User diagnostic data: temperature value (unsigned 16)

x x x x x x x x

x x x x x x x x

Example of Device-Related Diagnostic Data with Alarm Message

The following diagram shows alarm diagnostic data based on the scheme outlined above.

Device-related diagnostics:

0 0 0 0 1 0 0 1

Alarm type: process alarm 0 0 0 0 0 0 1 0 Slot number 3 (valve B) 0 0 0 0 0 0 1 1 Specifier: alarm enters state 0 0 0 0 0 0 0 1 User diagnostic data: 0x50

(upper pressure limit exceeded)

0 1 0 1 0 0 0 0

User diagnostic data (time of day, 4 bytes)

x x x x x x x x

x x x x x x x x x x x x x x x x x x x x x x x x



4.6.5 Format of ID-Related Diagnostics

Meaning

Module-specific diagnostics is possible for modular slaves with an ID byte per module. The DP master sends ID bytes to the slave in a configuration frame during the startup phase. In the ID-related diagnostic data each module is assigned a bit in the data field. If a bit is set, this means that there is diagnostic information on the corresponding module.

Identification of the ID-Related Diagnose Data and Length in the First Byte

The two most significant bits in the first byte have the value 01.


Content of the Data Field

The remaining bytes of the data field contain a bit array. The least significant bit of the 2nd byte has index 0 and this increases so that, for example, the most significant bit of the 3rd byte has index 15.

The bits indicate whether or not diagnostic data were signaled for the ID index.

Meaning of the Bits in the Diagnostic Byte

Each bit in the "diagnostic bytes“ has a special meaning.

Note Note the example at the end of Section 4.6.6.



4.6.6 Format of Channel-Related Diagnostics

Meaning

For the individual channels of a slave, the data organization of the channel and messages such as "undervoltage" or "short-circuit" is provided here.

Note Refer to the example later in the section.

Sequence of Entries each with Three Bytes

Channel-related diagnostic data consists of a sequence of entries all with the same format and three bytes long (header byte, channel number, type of diagnostic information).

Header Byte (ID Number) with Identification

The two most significant bits in the first byte of each entry have the value 10.

The remaining six bits in the first byte indicate the ID number. In ID-related diagnostics, the appropriate bit is set for the ID number.



Channel Number

Bit Meaning 7 and 6 Input/output

Value Meaning 00 reserved 01 Input 10 Output 11 Input/output 5 to 0 Channel number 0 to 63

Note If ID bytes contain both input and output, the direction of the diagnostic channel is indicated in bit 7 and bit 6 of the channel number.



Type of Diagnostics

Bit Meaning 7 to 5 Channel type

Channel type Meaning 000 reserved 001 bit 010 2 bits 011 4 bits 100 byte 101 word 110 2 words 111 reserved 4 to 0 Error type

Error type Meaning 0 reserved 1 Short circuit 2 Undervoltage 3 Overvoltage 4 Overload 5 Overtemperature 6 Wire break 7 Upper limit value exceeded 8 Below lower limit value 9 Error 10 - 15 reserved 16 - 31 Specified by the vendor



4.6.7 Format of the Revision Number

Meaning

The revision number of the slave is entered. The entry consists of a single byte.

Structure

Byte Meaning Byte 1 Revision number

Byte 1

The two most significant bits in the first byte have the value 11. This identifies the entire field as "Revision Number".

The remaining 6 bits contain the revision number of the slave.



Example: Structure of Diagnostic Information According the Above Scheme

The following figure represents diagnostic information arranged according to the scheme listed above.

MSB LSB 7 6 5 4 3 2 1 0

Header 6 bytes long

Device-related diagnostics: (header byte)

0 0 0 0 0 1 0 0

Device-specific diagnostic field

The meaning of the bits depends on the specific vendor, here 3 bytes long

ID-related diagnostics: (Header byte)

0 1 0 0 0 1 0 1

ID number 0 with diag info (diagnostic byte)

0 7.

0 6.

0 5.

0 4.

0 3.

0 2.

0 1.

1 0.


0 15.

0 14.

0 13.

1 12.

0 11.

0 10.

0 9.

0 8.


0 23.

0 22.

0 21.

0 20.

0 19.

1 18.

0 17.

0 16.

(diagnostic byte) 0 31.

0 30.

0 29.

0 28.

0 27.

0 26.

0 25.

0 24.

Channel-related diagnostics:

ID number 0 (header byte)

1 0 0 0 0 0 0 0

Channel 2 (channel number)

0 0 0 0 0 0 1 0

Overload, channel organized in bits (type of diagnostics)

0 0 1 0 0 1 0 0

ID number 12 (header byte)

1 0 0 0 1 1 0 0

Channel 6 (channel number)

0 0 0 0 0 1 1 0

Upper limit value exceeded, channel organized in words(type of diagnostics)

1 0 1 0 0 1 1 1



4.7 Format of the Slave Parameter Data

Definition

This section describes the format of the slave parameter data as obtained by the DP_read_slv_par call described in Section 4.1.11. There are three variants possible that are selected by the value of the "type" parameter in the DP_read_slv_par call:

Variant Value of the "type" Parameter General slave parameters DP_SLV_TYP

Parameter assignment data DP_SLV_PRM Configuration data DP_SLV_CFG

The structure of the three variants is described below in greater detail.



4.7.1 Structure of the General Slave Parameters

Overview

The components are bytes. They are byte-aligned,in other words, they are located one immediately following the other. The parameters shown on a gray background are relevant only for DP slaves with DP-V1 additional functions (not all currently supported). Where necessary the parameters are described in more detail later in the section.

Name Meaning (see below) Sl_Flag Activates fail-safe mechanisms etc. Slave_Typ Specified by the vendor Max_Diag_Data_Len Max. length of the diagnostic data Max_Alarm_Len Max. length of alarm data Max_Channel_Data_Len Max. length of DPC1 frame Diag_Upd_Delay Diagnostic counter Alarm_Mode Max. number of simultaneous alarms Add_Sl_Flag Data for AUTOCLEAR etc. Bytes 9 to 14 reserved

Byte Structure

In some cases, in the following data structures single bits in the bytes are significant. The bits are numbered as follows: the least significant bit has the number 0 and the most significant bit has the number 7.



Sl_Flag

This parameter contains slave-related flags.

Each bit in the "SI_Flag“ byte has a special meaning.

Bit Meaning 7 Active

0 means: DP slave is not activated 1 means: DP slave is activated

6 New_Prm 0 means: DP slave receives user data 1 means: DP slave receives new parameter assignment data

5 Fail_Safe 0 means: DP slave receives bytes with content 0 in the CLEAR mode 1 means: DP slave receives empty frames in the CLEAR mode

4 reserved 3 DPV1_Supported

0 means: DP slave functionality complying with EN 50170 1 means: DP slave functionality complying with DP-V1

2 DPV1 data types 0 means: DP slave configuration data complying with EN 50170 1 means: DP slave configuration data complying with DP-V1

1 Extra Alarm SAP 0 means: DP master acknowledges alarms via SAP 51 1 means: DP master acknowledges alarms via SAP 50

0 reserved

Slave-Type

This parameter contains a vendor-specific type identifier for the slave unit.

Value Meaning 0 Standard DP slave 1 to 15 reserved 16 to 255 Specified by the vendor



Alarm_Mode

This parameter specifies the maximum number of possible active alarms.

Value Meaning 0 1 alarm of each alarm type 1 2 alarms in total 2 4 alarms in total 3 8 alarms in total 4 12 alarms in total 5 16 alarms in total 6 24 alarms in total 7 32 alarms in total

Add_Sl_Flag

Bit Name and Meaning 7-2 reserved 1 Ignore_AClr

0 means: execute AUTOCLEAR 1 means: ignore AUTOCLEAR

0 NA_To_Abort 0 means: the slave is not initialized if it does not respond. 1 means: the slave is reinitialized if it does not respond.



4.7.2 Structure of the Parameter Assignment Data

Overview

The parameter assignment data consist of bus-specific data and DP slave-specific data.

Byte Number Meaning Byte 1 Station_status Byte 2 WD_Fact_1 Byte 3 WD_Fact_2 Byte 4 Min. Station Delay Responder Byte 5-6 Ident_Number

Byte 7 Group_Ident Byte 8 DPV1_Status_1 – Vendor-specific for slaves

without DP-V1 functionality Byte 9 DPV1_Status_2 – Vendor-specific for slaves

without DP-V1 functionality Byte 10 DPV1_Status_3 – Vendor-specific for slaves

without DP-V1 functionality

Byte 11-n Vendor-specific data

Use

r pa

ram

eter

da

ta

Hea

der d

ata



Byte 1 (Station_status)

Byte 1 "Station_status" has the following structure:

Each bit in the "station_status“ byte has a special meaning.

Bit Meaning 7 and 6 Lock_Req and Unlock_Req

Bit 7 Bit 6 Meaning 0 0 The min TSDR is overwritten when parameters

are assigned. All other parameters remain unchanged.

0 1 The DP slave is released for other masters. 1 0 The DP slave is disabled for other masters, all

parameters are adopted (exception: min TSDR = 0).

1 1 The DP slave is released for other masters. 5 Sync_Req

This bit indicates to the slave that it must operate in the Sync mode as soon as the command is transferred with the dpn_global_crtl() function.

4 Freeze_Req This bit indicates to a DP slave that it must operate in the freeze mode as soon as the command is transferred with the dpn_global_ctrl() function.

3 Watchdog If this bit is set to zero, the watchdog monitoring is deactivated. If the bit is set, the watchdog monitoring is activated on the DP slave.

2 to 0 reserved

Bytes 2 and 3 (WD_Fact_1 and WD_Fact_2)

These two bytes contain factors for setting the watchdog time (TWD).

The watchdog ensures that if this time expires after a DP master has failed, the outputs are set to a safe state.

TWD [ms] = 10 * WD_Fact_1 * WD_Fact_2



Byte 4 (Min. Station Delay Responder)

This is the time that the DP slave must wait before it is allowed to send its response frames to the DP master, unit: bit times.

Bytes 5 and 6 (Ident_Number)

This number is assigned by the vendor. The DP slave only accepts parameter assignment frames when the Ident_Number transferred with the parameter assignment data matches its own Ident_Number. The value is transferred in Motorola format,in other words, the higher order half is in byte 5.

Byte 7 (Group_Ident)

With this parameter, a group can be formed for the DP_global_ctrl() function. Each bit represents a group. The Group_Ident is accepted only when the Lock_Req bit is set (see byte 1).

Byte 8 (DPV1_Status_1)

Bit Meaning 7 DPV1_Enable

This bit is set to activate the DP-V1 functionality of a DP-V1 slave. If the bit is not set, the slave operates in the compatibility mode whenever possible.

6 Fail Safe This bit is set to show that the slave operates in the fail-safe mode.

5-3 reserved 2 WD_Base_1ms

If this bit is set, the watchdog time is calculated according to the following formula: TWD [ms] = WD_Fact_1 * WD_Fact 2 If the bit is not set, the watchdog time is calculated as follows: TWD [ms] = 10 * WD_Fact_1 * WD_Fact 2

1 to 0 reserved



Byte 9 (DPV1_Status_2)

Bit Meaning 7 Enable_Pull_Plug_Alarm

This bit is set to allow an alarm of the type "Pull_Plug_Alarm" to be signaled.

6 Enable_Process_Alarm This bit is set to allow an alarm of the type "Process_Alarm" to be signaled.

5 Enable_Diagnostic_Alarm This bit is set to allow an alarm of the type "Diagnostic_Alarm" to be signaled.

4 Enable_Manufacturer_Specific_Alarm This bit is set to allow all vendor-specific alarms to be signaled.

3 Enable_Status_Alarm This bit is set to allow an alarm of the type "Status_Alarm" to be signaled.

2 Enable_Update_Alarm This bit is set to allow an alarm of the type "Update_Alarm" to be signaled.

1 reserved 0 Check_Cfg_Mode

This bit can be used to influence the reaction to the reception of configuration data. If the bit is set to 0, the check is as described in EN 50170. If this bit is set, the check is made according to a specific user definition.



Byte 10

DPV1_Status_3

Bit Meaning 7-3 reserved 2-0 Alarm Mode

Bit 4 Meaning

0 1 alarm of each type

1 2 alarms in total

2 4 alarms in total

3 8 alarms in total

4 12 alarms in total




Bytes 11 to n

Vendor-specific data These bytes can be used for parameters specific to the DP slave (for example diagnostic filter, controller parameters). The meaning and the range of values are specified by the specific vendor.



4.7.3 Structure of the Configuration Data

Overview of the Structure

The configuration data contain the range of the input and output data areas and information on data consistency.

They consist of a sequence of data fields, each data field having one of two alternative formats:

Configuration data

Data field 1

Data field 2

...

Data field n

Variant 1ID byte

Variant 2Special ID byte

1st length byte (optional)

2nd length byte (optional)

Vendor-specific data(optional)

The two data block variants can be distinguished by bits 4 and 5 of the first byte.

Length of the Configuration Data

The length of the configuration data is ideally 1 to 32. If necessary, however, up to 244 bytes are possible.



Structure of an ID Byte

Each bit has a special meaning.

Bit Meaning 0 to 3 Number of data units - 1

3 means, for example, 4 data units of the length specified in bit 6 4 and 5 Input/output

Bit 5 Bit 4 Meaning

0 0 does not occur (seebelow)

0 1 Input

1 0 Output

1 1 input/output

6 Length of the data units 0 means: the data unit is in bytes 1 means: the data unit is 2 bytes

7 Consistency 0 means: byte or word consistency 1 means: consistency over the entire length of the module



Structure of a Special ID Byte

Special identifier formats allow the configuration to be extended by increasing the flexibility. Each bit in the ID byte has a special meaning.

Bit Meaning 0 to 3 Length of the vendor-specific data

These bits contain the length of the vendor-specific data. 4 and 5 These bits always have the value 00. 6 and 7 Input/output

Bit 7 Bit 6 Meaning 0 0 No optional bytes follow 0 1 1 length byte for inputs follows 1 0 1 length byte for outputs follows 1 1 This is followed by

● 1 length byte for outputs

● 1 length byte for inputs

Length Bytes

Each bit in the length bytes has a special meaning.

Bit Meaning 0 to 5 Number of data units

0 (decimal) means: 1 data unit 63 (decimal) means: 64 data units (for the length of the data units see bit 6)

6 Length 0 means: a data unit is one byte long 1 means: a data unit is two bytes long

7 Consistency 0 means: consistency over byte or word 1 means: consistency over the entire length of the module



Example of a Special ID Format

The following table shows an example of a special ID format.

Octet Bits in the byte Meaning

1 1 1 0 0 0 0 1 1 Input/output, 3 bytes of vendor-specific data

2 1 1 0 0 1 1 1 1 Consistency, output, 16 words 3 1 1 0 0 0 1 1 1 Consistency, input, 8 words 4 to 6 Vendor-specific data



4.7.4 Meaning of GSD Files

With PROFIBUS DP, the data exchange between a DP master and the connected slaves can be implemented in several different ways. PROFIBUS slaves can be adapted to the particular automation task in terms of their response and character-istics.

To be able to generate the necessary project engineering information (database of the DP master), the project engineering tools (for example SIMATIC NCM / Step 7) require the technical specifications of the connected DP slaves in the form of a GSD file (Generic Station Description). The GSD file is an ASCII file with a series of standardized keywords that uniquely describe certain attributes of a certified DP slave device type. This ensures that different DP slaves from different vendors can communicate with every DP master that complies with the standard.

You can obtain more detailed information on the structure of GSD files and the certification of DP slaves from one of the certification centers (refer to the next section).

GSD File for the Slave Submodule of the CP 5614

A GSD file describing the characteristics for the specific application must also be available for the slave submodule of the CP 5614. The most important characteristics described include the following:

• Operation as standard (DP-V0 slave) or operation as DP slave with additional enhanced functionality such as read/write data record, alarm handling (DP-V1 slave)

• Implementation as modular DP slave (number of submodules and the I/O data can be modified during configuration) or implementation as non-modular DP slave (compact slave). With a compact slave, the number of submodules and the IO data are fixed.

• Unique Ident number to specify the particular device type.

The following information relates to the sample GSD files (siem80b4.gsd for DP-V0 and siv180b4.gsd for DP-V1) for the DP slave submodule of the CP 5614 of the Simatic NET CD. These GSD files are stored in the Drive:\Program Files\Siemens\SIMATIC.NET\DP\DEMO_GSD directory during installation.

The PNO Ident numbers in these GSD files are demonstration licenses belonging to Siemens and may only be used for test purposes.

They can then be imported with the Simatic NCM PC Manager or STEP 7. With these project engineering tools, the DP slave submodule of the CP 5614 is avail-able as a DP-V0 or DP-V1 slave in the DP slave catalog in "Other field devices -> General“.



Based on these GSD files, you can create your own GSD files with slight modifica-tions (for example using a GSD editor). Ideally, only certain parameters should be changed.

These GSD files (and the corresponding slave application) must be certified by a certification center. Among other things during certification, a unique PNO Ident number will be assigned that is then unique for this newly established slave.

You can obtain more detailed information on certification from the following ad-dress: Certification Center ComDeC Würzburger Strasse 121 90766 Fürth Germany Phone: ++49 911 750 2074 Email: [email protected]

Assignment between GSD File and Transfer Parameters when DPS_open is Called

Using the DPS_open function (see Section 4.2.2), a DP slave application registers with the CP 5614 and sets important DP slave parameters.

Some of these slave parameters must match the actual project engineering information (database) on the DP master to allow the slave submodule of the CP 5614 to be included in the PROFIBUS data transfer.

The following table shows which parameters must match and from which source the data can be taken (keywords in the GSD file or project engineering data). The call parameters are described in detail in Section 4.2.2.

Call Parameters in DPS_open

Source of the Information

Slave_mode: DPS_SM_V1_ENABLE bit (activate DP-V1 services)

GSD file: Keyword DPV1_Slave: DPV1_Slave=1 -> DPS_SM_V1_ENABLE bit must be set; DPV1_Slave=0 or keyword does not exist -> Bit DPS_SM_V1_ENABLE must not be set.

Station_addr (station ad-dress of the slave):

Project engineering The value for the station_addr parameter must match the station address assigned during project engineering for the slave submodule of the CP 5614.



Pno_ident_nr (Ident num-ber of the slave type)

GSD file: Keyword Ident_Number. The value for the pno_ident_nr parameter must match the value of this keyword. Example: Ident_Number=0x80b4 -> enter 0x80b4 in pno_ident_nr.

Init_data, DPS_SIMPLE_S structure This substructure of the DPS_INIT_DATA_S union is relevant when the DPS_SM_SIMPLE bit is set in the slave_mode parame-ter. It contains the default values for the user parame-ter assignment data (user_prm_data_len, user_prm_data) and the configuration data (cfg_data_len, cfg_data).

Project engineering The values specified during project engineering must be entered. GSD file: If this information is not available from project en-gineering tool, it can be obtained as follows from the GSD file: Keyword User_Prm_Data specifies the user pa-rameter assignment data. Example: User_Prm_Data = 0x00, 0x00,0x00 Enter the value 3 in user_prm_data_len and 0x00,0x00,0x00 in the user_prm_data array (see also Note 1). Keyword Modular_Station and Keyword Module specify the modular structure and the number of I/O bytes of the DP slave (see also Note 2) For examples of compact and modular slaves, see below.

Init_data, DPS_DYNAMIC_S struc-ture This substructure of the DPS_INIT_DATA_S union is relevant when the DPS_SM_DYNAMIC bit is set in the slave_mode pa-rameter. It contains the set values for the default ("pro-visional“) configuraton data (def_cfg_data_len, def_cfg_data).

Analogous to DPS_SIMPLE_S

Note 1) If the project engineering tool allows further user parameter assignment data (not listed in the GSD file) to be entered, this data must also be taken into account in user_prm_data_len, user_prm_data.



Note 2) If the project engineering tool provides further setting options, the overall structure of the configuration data must be taken into account (detailed description in Section 4.7.3). Examples of configuration data: See below in the table "Examples of Submodule Configurations".

Note Bold characters indicate parameters that should ideally be changed.



Example 1: Compact station with fixed submodules and DP-V1 functionality

The Module keyword specifies the number and type of these submodules.

;====================================================== ; GSD Example derived from CP5614 DP-V1-Slave ; Not Modular DP-V1-Slave ; GSD-File for CP5614 Sample AAAA SIEMENS AG ; MLFB : 6GK1 561-4AA00 ; Auto_Baud_supp, 12MBaud ; Dated : 10.09.2002 ; File : SIV1AAAA.GSD ;====================================================== #Profibus_DP ;General parameters GSD_Revision = 3 Vendor_Name = "My Company" Model_Name = "My CP5614 Sample V1" ;Own name ;must be entered Revision = "V1.1" Ident_Number = 0xAAAA ;Assigned by ;Certification ;center Protocol_Ident = 0 Station_Type = 0 Hardware_Release = "HW_R" Software_Release = "SW_R" 9.6_supp = 1 19.2_supp = 1 45.45_supp = 1 93.75_supp = 1 187.5_supp = 1 500_supp = 1 1.5M_supp = 1 3M_supp = 1 6M_supp = 1 12M_supp = 1 MaxTsdr_9.6 = 60 MaxTsdr_9.6 = 60 MaxTsdr_19.2 = 60 MaxTsdr_45.45 = 250




Continued

MaxTsdr_93.75 = 60 MaxTsdr_187.5 = 60 MaxTsdr_500 = 100 MaxTsdr_1.5M = 150 MaxTsdr_3M = 250 MaxTsdr_6M = 450 MaxTsdr_12M = 800 Repeater_Ctrl_Sig = 2 Implementation_Type = "DPC31" Bitmap_Device = "SI9001PN" Bitmap_Diag = "SI9001PN" Bitmap_SF = "SI9001PN" ; Slave-Specification: OrderNumber="6GK1 561-4AA00" Freeze_Mode_supp = 1 Sync_Mode_supp = 1 Auto_Baud_supp = 1 User_Prm_Data_Len = 3 User_Prm_Data = 0x00,0x00,0x00 Min_Slave_Intervall = 1 Modular_Station = 0 Module="CP5614 Slave-Modul" 0xAF,0x9F ;These values were obtained0 ;with a GSD editor EndModule Fail_Safe = 1 Max_Diag_Data_Len = 244 Slave_Family = 0 ;Extensions DPV1_Slave = 1 C1_Read_Write_supp = 1 C1_Max_Data_Len = 240




Continued

C1_Response_Timeout = 500 Diagnostic_Alarm_supp = 1 Process_Alarm_supp = 1 Pull_Plug_Alarm_supp = 1 Status_Alarm_supp = 1 Update_Alarm_supp = 1 Manufacturer_Specific_Alarm_supp = 1 Alarm_Sequence_Mode_Count = 0 Alarm_Type_Mode_supp = 1 Diagnostic_Alarm_required = 1 Process_Alarm_required = 1 Pull_Plug_Alarm_required = 1 Status_Alarm_required = 1 Update_Alarm_required = 1 Manufacturer_Specific_Alarm_required = 1

A slave configured in this way is addressed by the software as follows:

DPR_DWORD user_handle=0; DPR_WORD StationAddr=33; // PROFIBUS address of DP slave DPS_INIT_DATA_T init_data; DP_ERROR_T error; init_data.simple user_prm_data_len = 0; init_data.simple user_prm_data = NULL; init_data.simple cfg_data_len = 2; init_data.simple.cfg_data[0] = 0xaf; init_data.simple.cfg_data[1] = 0x9f;




Continued

if ( DPS_open ( "CP5614A2(PROFIBUS)”, // in : cp_name &user_handle, // out : user_handle DPS_SM_SIMPLE| DPS_SM_V1_ENABLE,

// in : slave_mode StationAddr, // in : station_addr 0, // in, not used : addr_change 0xAAAA, // in : pno_ident_nr

0, // in, not used : user_wd &init_data // in : init_data NULL, // in, not used : max_data_len DPS_BD_AUTO_DETECT, // in : baud_rate &error // out : error ) == DP_OK) { // OK. Further actions } else { // Errorhandling }

Example 2: Modular DP Slave

The actual number and arrangement of the submodules is specified based on the project engineering. The GSD file contains the description of the submodules that can be selected dur-ing project engineering. The following sample shows 10 submodules of a GSD file that are available during project engineering.

;========================================================== ; GSD-File derived from CP5614 Sample 80b4 SIEMENS AG ; MLFB : 6GK1 561-4AA00 ; Auto_Baud_supp, 12MBaud ; ; Dated : 10.05.2000 mm ; File : SIEMBBBB.GSD ;===========================================================




Continued

#Profibus_DP ; Unit-Definition-List: GSD_Revision=1 Vendor_Name="My Company" Model_Name="CP5614 Sample BBBB" ; Name must be changed

Revision="V1.0" Ident_Number=0xBBBB ;Assigned by Certification ;center Protocol_Ident=0 Station_Type=0 Hardware_Release="Axxx" Software_Release="Zxxx" 9.6_supp = 1 19.2_supp = 1 45.45_supp = 1 93.75_supp = 1 187.5_supp = 1 500_supp = 1 1.5M_supp = 1 3M_supp = 1 6M_supp = 1 12M_supp = 1 MaxTsdr_9.6 = 60 MaxTsdr_19.2 = 60 MaxTsdr_45.45 = 250 MaxTsdr_93.75 = 60 MaxTsdr_187.5 = 60 MaxTsdr_500 = 100 MaxTsdr_1.5M = 150 MaxTsdr_3M = 250 MaxTsdr_6M = 450 MaxTsdr_12M = 800 Repeater_Ctrl_Sig = 2 Implementation_Type="DPC31" Bitmap_Device="CP5614_N" Bitmap_SF="CP5614_S" ; ; Slave-Specification: OrderNumber="6GK1 561-4AA00" ;




Continued

Freeze_Mode_supp=1 Sync_Mode_supp = 1 Auto_Baud_supp = 1 Fail_Save = 1 Set_Slave_Add_supp = 0 Min_Slave_Intervall=1 Max_Diag_Data_Len=16 Slave_Family=0 User_Prm_Data_Len=3 User_Prm_Data = 0x00,0x00,0x00 ; Modular_Station = 1 Max_Module=32 Max_Input_Len=244 Max_Output_Len=244 Max_Data_Len=488 ; ; Module-Definitions: ; Module = "1 Byte Input" 0x10 EndModule Module = "1 Byte Output" 0x20 EndModule Module = "2 Byte Input" 0x11 EndModule Module = "2 Byte Output" 0x21 EndModule Module = "4 Byte Input" 0x13 EndModule Module = "4 Byte Output" 0x23 EndModule Module = "8 Byte Input" 0x17 EndModule Module = "8 Byte Output" 0x27 EndModule Module = "16 Byte Input" 0x1f EndModule Module = "16 Byte Output" 0x2f EndModule



In the project engineering, three submodules are assigned to the DP slave module of the CP 5614: a) 2 bytes input b) 1 byte output c) 16 bytes output

A slave configured in this way is addressed by the software as follows:

DPR_DWORD user_handle=0; DPR_WORD StationAddr=12; // PROFIBUS address of the DP slave DPS_INIT_DATA_T init_data; DP_ERROR_T error; init_data.simple user_prm_data_len = 0; init_data.simple user_prm_data = NULL; init_data.simple cfg_data_len = 3; init_data.simple.cfg_data[0] = 0x11; init_data.simple.cfg_data[1] = 0x20; init_data.simple.cfg_data[2] = 0x2F;

if ( DPS_open ( "CP5614A2(PROFIBUS)”, // in : cp_name &user_handle, // out : user_handle DPS_SM_SIMPLE, // in : slave_mode StationAddr, // in : station_addr 0, // in, not used : addr_change 0xBBBB, // in : pno_ident_nr

0, // in, not used : user_wd &init_data // in : init_data NULL, // in, not used : max_data_len DPS_BD_AUTO_DETECT, // in : baud_rate &error // out : error ) == DP_OK)

{ // OK. Further actions } else { // Errorhandling }



Table "Examples of Submodule Configurations"

Length (Input) Cfg_Data 1 byte input 0x10

2 bytes input 0x11

3 bytes input 0x12

… …

16 bytes input 0x1f

17 bytes input 0x40, 0x00

18 bytes input 0x40, 0x01

… …

64 bytes input 0x40, 0x3f

Length (Output) Cfg_Data 1 byte output 0x20

2 bytes output 0x21

3 bytes output 0x22

… …

16 bytes output 0x2f

17 bytes output 0x80, 0x00

18 bytes output 0x80, 0x01

… …

64 bytes output 0x80, 0x3f

Length (Input) Cfg_Data 1 word input 0x50

2 words input 0x51

3 words input 0x52

… …

16 words input 0x5f

17 words input 0x40, 0x40

18 words input 0x40, 0x41

… …

64 words input 0x40, 0x7f



Length (Output) Cfg_Data 1 word output 0x60

2 words output 0x61

3 words output 0x62

… …

16 words output 0x6f

17 words output 0x80, 0x40

18 words output 0x80, 0x41

… …

64 words output 0x80, 0x7f


Description of the Sample Programs 5



5.1 Starting the Simple Sample Program

Purpose of the "ExamEasy" Sample Program

Apart from familiarizing DP programmers with the program, the simple sample program can also be used to test communication with a DP slave.

To use this function, you must have a DP slave with at least one input and output byte. In the supplied ExamEasy sample STEP 7 project, the slave is configured as an ET 200B at node address 3; the data transmission rate is 1.5 Mbps.

Even if you have more than one CP 5613 or CP 5614, the program always uses the access point "CP_L2_1:".



Procedure

Follow the steps outlined below to start the "ExamEasy" sample program:

Step Description 1 Set the STEP 7 project ExamEasy for the sample program. 2 If the slave you want to address is not an ET 200B with node address 3

or you do not operate at 1.5 Mbps, adapt the STEP 7 Project ExamEasy to your configuration.

3 Start the "ExamEasy" program (taskbar Start Simatic SIMATIC NET CP5613_CP5614 Examples Easy).

4 The current input and output byte are displayed in a DOS box. 5 If you now type in and enter a different value for the output byte, the

new output value is adopted and the current input and output byte displayed. If you make a blank entry, the output byte is retained and the current input and output byte is displayed.

6 Type "q" and press the enter key to quit the program.

Note 1

The source files for the sample program are in the "CP5613_CP5614\Examples\Easy" folder of your installation folder.

Note 2

The sample program occupies the DP-RAM pointer exclusively. The interface does not allow parallel operation of a second DP application if the pointer is not alternately released by the user programs.

Results

If an error occurs, the program displays a message.



5.2 Starting the Complete Sample Program

Purpose of the "ExamComp" Sample Program

Apart from familiarizing DP programmers with the program, the comprehensive sample program can also be used to test communication with up to three DP slaves.

Even if you have more than one CP 5613 or CP 5614, the program always uses the access point "CP_L2_1:".

It assumes a configuration with the following three slaves, one or two of which can be omitted:

Slave address

Configuration Configured as

3 1 Input byte, 1 output byte ET 200B 8DI/DO 4 1 Input byte, 1 output byte ET 200B 8DI/DO 6 Any standard slave

The current configuration of this slave is read out with the DP_get_actual_cfg function.

ET 200M IM153

The data transmission rate is 1.5 Mbps.



Procedure

Follow the steps outlined below to start the "ExamComp" sample program:

Step Description 1 Set the STEP 7 project ExamComp that matches the sample program

as the STEP 7 project to be used. 2 If the configuration does not match the slaves you want to address or

the actual data transmission rate, adapt the ExamComp STEP 7 project to your configuration.

3 Start the "ExamComp" sample program (taskbar Start Simatic SIMATIC NET CP5613_CP5614 Examples Complete).

4 The program provides various modes for selection. Select a mode or a combination of these modes (for example, "12" for simultaneous operation of modes 1 and 2).

5 The program now communicates using the selected modes with the corresponding slaves. Press the enter key to display the current status.


Note 1

The source files for the sample program are in the "CP5613_CP5614\Examples\Complete" folder of your installation folder.

Note 2


Results

The current data is displayed for each of the three slaves or a message if an error occurs.



5.3 Starting the "Fast Logic" Sample Program

Purpose of the "ExamFast" Sample Program

The "ExamFast" sample program explains the "Fast Logic" functionality of the DP master. You will get to know the functions DP_fast_logic_on, DP_fast_logic_off and how to handle Fast-Logic semaphores.

If several CP 5613 or CP 5614 modules exist, you can select the CP to be used when you start the program. ID 2 is always used as the Fast Logic ID.

It assumes a configuration with the following two slaves:

Slave Configuration Configured as 1 1 Input byte, 1 output byte ET 200 B 8DI/8DO, address 3 2 1 Input byte, 1 output byte ET 200 B 8DI/8DO, address 4




Procedure

Follow the steps outlined below to start the "ExamFast" sample program:

Step Description 1 Set the STEP 7 project ExamFast that matches the sample program as

the STEP 7 sample project to be used. 2 If the configuration does not match the slaves you want to address or

the actual data transmission rate, adapt the ExamFast STEP 7 project. 3 Start the "ExamFast" sample program (taskbar Start Simatic

SIMATIC NET CP5613_CP5614 Examples FastLogic).

4 The program prompts the user to provoke the Fast Logic event. To trigger the Fast Logic event, bit 1 in input byte 0 of the slave with address 3 must be set to "1".

5 The program now communicates cyclically with the selected slaves. Press the enter key to display the current status.


Note 1

The source files for the sample program are in the "CP5613_CP5614\Examples\FastLogic" folder of your installation folder.

Note 2


Results

The current slave states and any Fast Logic events that occurred are displayed. If an error occurred, texts are displayed.



5.4 Starting the Transfer Sample Program for the CP 5614

Purpose of the "Transfer" Sample Program

Apart from familiarizing DP programmers, the Transfer sample program can be used to test the communication with more than one DP slave and a controlling master. If several CP 5613 or CP 5614 modules exist, you can select the CP to be used when you start the program.

Explanation of the Transfer Functionality

The CP 5614 is suitable for hierarchically structured networks. The master section of the CP 5614 operates with "subordinate" actuators and sensors on its own bus segment. The slave module of the CP 5614 is attached to a controlling station via a separate bus segment.

One function that is often required is the passing on of actuator and sensor data to the control system. The software that provides this functionality is known as the Transfer software.

Actuator Sensor

PROFIBUS DP (II)

PROFIBUS DP (I)

RS

485CP 5614

RS

485

Slave

Master

Control system

Transfersoftware

PC



Transfer Program

With a transfer configuration program, you can specify which data from the actuators or sensors are passed on to the control system (see Section 5.5).

The sample supplied (STEP 7 project and transfer configuration file) was written for a slave ET 200B and a CP 5614.

Slave Configuration Configured as 1 1 Input byte, 1 output byte ET 200 B 8DI/8DO, address 3 2 2 input bytes, 2 output bytes Slave module CP 5614, address

10


The transfer program works with the "transfer.tra" file and the STEP 7 project "Examples" (database "pcst_transfer.xdb"). A data transfer from an ET 200B input bit to an output bit is configured in the "transfer.tra" file. A data transfer from the slave module of the CP 5614 bits 0 to 6 to an ET 200B starting at bit 1 is also configured.

Note If your DP environment is different from the one required for this example, create a suitable STEP 7 project with SIMATIC NCM PC or STEP 7 V5.1 SP2. The slave properties of the CP 5614 are set in the "Sample.GSD" file. If you want to define a different number of input/output ports for the CP 5614, please edit this file and create a new GSD file for the CP 5614.



Procedure

Follow the steps outlined below to start the "Transfer" sample program:

Step Description 1 Please set the STEP 7 project "Examples" that matches the sample

program (database "pcst_transfer.xdb"). 2 Start the "Transfer" sample program (taskbar Start

Simatic SIMATIC NET CP5613_CP5614 Examples Transfer5614).

3 The program runs in a DOS box and modifies the input data of the slave module of the CP 5614. On the ET 200B, you can see how the CP 5614 slave module increments the values.


Note 1

The source files for the sample program are in the "CP5613_CP5614\Examples\TRANSFER5614" folder of your installation folder.

Note 2


Results

On the ET 200B, you can modify the first input bit (value 0 or 1). This input bit is transferred to the first output bit (LED) by the transfer program.

A counter is implemented in the CP 5614 slave module. 7 bits of the counter reading are transferred to the LEDs, bits 1-7 of the ET 200B by the transfer program.

The transfer program transfers all the configured data cyclically every 10 ms.



5.5 Configuring the Transfer for the CP 5614 Transfer Sample Program

Purpose of the "Transfer Configuration" Tool

Using the tool, you can configure which input, output or diagnostic data is transferred between the attached slaves and the higher-level master in both directions.

All access addresses begin with 0, in other words, the lowest order bit or byte of a slave or the master module is bit or byte 0.

Procedure

Follow the steps outlined below to start the "Transfer Configuration" tool:

Step Description 1 Start the “Transfer Configuration" tool (taskbar Start Simatic

SIMATIC NET CP5613_CP5614 Transfer5614-Configuration). 2 Select the file for storing the transfer list or create a new file. 3 Enter your data in the transfer configuration window. A short form of the

data is displayed as an overview in the transfer list window.

Generally, an output (source on the left-hand side) is linked to an input (destination on the right-hand side).

4 Save the transfer list when it is complete.



Results

The figure above illustrates the configuration for the sample program: Bit 0 of the slave ET 200B with address 3 is copied to its output. Bits 0-6 of the slave module (address 127) are copied to bits 1-7 of the ET 200 B.

The LEDs of the ET 200 B flash in time with the counter addressing of the slave module.


FAQ (Frequently Asked Questions) 6

This chapter contains answers to typical questions ("Frequently Asked Questions") on the programming interface of the CP 5613 and CP 5614 arranged in categories.

For information on creating your DP user program, refer to the sections on structuring user programs and the check list for programmers.

Please refer to the FAQs in the readme file of the SIMATIC NET CD.



6.1 FAQs about the Range of Functions of the Product

Which CP is released as of which software version?

Please note the version table in the readme file of the "SIMATIC NET, PC Soft-ware" CD.

Which software versions exist and how do they differ from each other??

Please refer to the version table in the readme file of the SIMATIC NET CD.

Which operating systems are supported?


Which compilers and programming languages are supported?


For linking to Borland C++ and Delphi, please check with the AIXO company (Internet: http://www.aixo.com). By designing the "dp_base.dll" with standard calling conventions, linking to other development environments is in principle possible.

What are the differences between the CP 5613 and CP 5614?

The CP 5613 can be used either as a DP master or as a DP slave. The configura-tion of the CP 5613 as DP slave differs from the configuration of the CP 5614. The mode CP 5613 as DP slave is set in the properties dialog of STEP 7/NCM PC for the CP 5613. Configuration is as described in the manual "Commissioning PC Stations", section "Configuring the PC Station as DP Slave".

The CP 5614 has an additional DP port with which the PC can be operated as a DP slave on a second PROFIBUS network. There is also a transfer function for the automatic transfer of slave data to the controlling master. The module is configured by integrating the appropriate GSD file in the STEP 7/NCM PC configuration tool and inserting it in the master system; refer to the manual "Configuring PC Stations“, section "Creating a DP Master System".



Are there different GSD files for the CP 5613 as DP slave and CP 5614 as DP slave?

Yes, refer to Section 4.7.4, "Meaning of GSD Files ".

The names of the GSD files for the CPs are as follows:

CP name GSD file name CP 5613 "slv80b4.gsd" and "slv180b4.gsd"

The GSD files of the CP 5613 are only required when the CP 5613 as a DP slave is controlled by a DP master that cannot be configured in STEP 7/NCM PC.

CP 5614 "siem80b4.gsd" and "siv180b4.gsd" These files are also required when configuring with STEP 7/NCM PC.

As of which version can I use the CP 5613 as a DP slave?

As of version CP 5613 A2.

Does the CP 5614 have a greater range of functions as a DP slave than the CP 5613?

Yes, it also supports SYNC and FREEZE functionality.

Do the CP 5613 and CP 5614 also support the DP programming interface of the CP 5412(A2), the CP 5511, and CP 5611?

A further product "DP-5613" is intended for this purpose.

Are multiple CPUs, DP user programs and CPs supported?

Multiple CPUs in one PC: yes.

Are the CP 5613 and CP 5614 OPC-compliant?

Yes.



6.2 FAQs about Structuring the DP User Program

Can DP and DPC1 be operated at the same time?

Yes. The DP master must, however, already by in the OPERATE mode before DPC1 functions can be used.

How many DPC1 jobs can be sent at the same time?

Per slave address, up to two DPC1 jobs can be sent at any one time, one for reading or writing and one for alarm acknowledge.

How can I structure my DP user program?

There are basically three wait mechanisms that you can combine together:

• You can poll with your DP user program, inother words, it queries the process image cyclically.

• You can use hardware events with semaphores as the wait mechanism.

• You can call the DP_get_event function with a timeout value to wait for software events.

You can also break down your DP user program into several threads (see also the "ExamComp" sample program.).

What are the advantages of a DP user program that simply polls?

The program structure is relatively simple (assuming that your program does not use any other interfaces that would require event handling such as DPC1). Polling is particularly suitable when you expect a lot of data traffic due to a fast data transmission rate and a lot of slaves with fast changing data.



What are the disadvantages of simply polling in the DP user program?

If your DP user program does not restrict itself, the entire available CPU performance of the of the PC will be used to query the process image unnecessarily often. If the program restricts itself too much, on the other hand, the data will no longer be up to date. We recommend that you restrict polling using a time control suitable for your system.

What are the advantages of hardware events?

Your DP user program can react to changes quickly. Since it waits, it does not take up unnecessary CPU time on the PC.

What are the disadvantages of hardware events?

If your DP user program monitors a large number of active slaves using hardware events, the overheads for fetching events is high because semaphores must constantly be activated and run through. This increases PC-CPU load. If you therefore have a lot of slaves or very active slaves, we recommend that you use hardware events for only a few slaves and poll the others periodically.

What are the advantages of programming with multiple threads?

With multiple threads, you achieve a clearer structure in your DP user program. This is particularly useful when you want to run various activities at the same time, for example, periodic polling combined with hardware events on the one hand and asynchronous DPC1 jobs on the other. These unrelated tasks with their different dynamic characteristics can be implemented in two threads.

What are the disadvantages of programming with multiple threads?

The threads of a DP user program must not conflict, for example when accessing global variables; overwriting data and deadlocks must be avoided. It is particularly important to avoid multiple threads accessing the process image of the CP 5613 or CP 5614 at the same time otherwise they will overwrite each other's control register for consistent reading and writing of slave data. This could mean that the slave data read by a thread are no longer consistent although consistency is expected.



How do I access the process image with more than one thread?

This is not recommended. The control registers for writing and reading of consistent slave data can be overwritten which can lead to a reading thread no longer having consistent slave data although this is required. To avoid this, some form of interlock would be necessary so that only one thread can access the process image at any one time. You could do this using semaphores, mutex etc. in Windows.

How can I access the process image with multiple programs?

This works fine as long all the programs involved release the pointer to the process image again with the DP_release_pointer call. In real-time operation, we would advise against this, since both calls take up time and you would need to implement extra mechanisms to coordinate the programs.



6.3 FAQ Check List for Programmers

What are the most important aspects of the program structure?

Make sure that you keep to the rules below when structuring your program:

• Begin your DP user program with a DP_start_cp, DP_open and DP_get_pointer and always complete these with DP_release_pointer, DP_close and DP_reset_cp.

• Note that after a DP_release_pointer or DP_close call, access to the dual-port RAM is no longer allowed (pointer invalid).

• Evaluate all errors and check all the diagnostic data.

• Check that all the conditions necessary for validating the data are met (for example, when reading slave data, the master must be in the OPERATE or CLEAR mode and the slave in the READY state). READY means that the slave has had parameters assigned and been configured by the DP master and is taking part in the DP cycle. The diagnostic data that the slave sends to the master must, however, also be evaluated.

• With DPC1 slaves with alarm capability, read the diagnostic data only using the DP_fetch_alarm function. Acknowledge these alarms with DP_alarm_ack.

• With slaves without alarm capability, diagnostic data can also be read out using DP_fetch_alarm (alternative: consistent reading of the diagnostic data in the DPR). The two methods (DP_fetch_alarm and consistent reading of the diagnostic data in the DPR) must not be combined otherwise the same data will be displayed several times.

• If asynchronous calls to a slave are terminated with a communication error (see DP_get_result) or if the DP_fetch_alarm call signals data errors, the relevant slave must be reinitialized by calling DP_slv_state (for more detailed information, refer to the individual descriptions of the functions).

• Events can be reported in any order; so make sure that your algorithms are suitably flexible.

• Do not send more than one asynchronous DPC1 job to a slave at the same time (DP_ds_read/DP_ds_write, DP_alarm_ack).

• If the result of a DP_enable_event call is fetched, this must be repeated so that new events can be reported.



Should I retain the pointer while my program is running?

As long as your DP user program is in possession of the pointer to the process image (DP_get_pointer call), no other DP user program can access it. In this case, retain the pointer until the end of the program. If, however, you access the process image only sporadically, for example with a diagnostic program or when you have no real-time requirements, you should release the pointer again after each access.

What are the most important aspects of accessing data areas?

The process image is separate from the DP user program and the slaves Refer also to the information in Section 2.9.

Use the check list below for your data areas:

• Select data buffer lengths to match the longest possible data.

• Link job fields with valid data buffers in the startup phase of your program.

• If you use multiple threads, each thread should have its own job fields and data buffers.

• Interlock the threads if they can access the dual-port RAM at the same time, to avoid access conflicts.

What are the most important aspects of using hardware and software events?

• Until your DP user program has run through a semaphore for hardware events, it will not be activated again. After running through a semaphore, you should therefore check whether or not more than one event has occurred.

• After a hardware event arrives, the triggering control condition is reset so that your DP user program must then activate it.

• Your DP user program must log off with DP_delete_sema_object and not with Windows API functions.

How can I wait for more than one event in a thread at the same time?

Initialize a semaphore for each event type (DP_create_sema_object), trigger your jobs and then wait at the semaphores by calling the Win32 API function "WaitForMultipleObjects" or “sgWaitForMultipleObjects".



Where can I find a list of all the error messages?

In the header files "5613_ret.h" and "5614_ret.h". To decode the error messages, use the DP_get_err_txt function.

What should a DP application programmer take into account?

• Use unique order_ids for parallel jobs.

• Remember that a hardware event entering the state deletes its activation condition. You must make sure it is reactivated.

• Do not use hardware events at the same time as periodic polling on the same slave.



6.4 FAQs about Debugging and Starting Up Your Program

What are the typical errors when a program is first run?

• Bus malfunctions caused by bad contacts/bad cabling/forgetting the terminator are often the cause of initial problems.

• Incorrectly configured slave types

• Using the wrong database

• Bad bus parameters

• Wrong station addresses set on the slaves

Are there tools for troubleshooting?

Use the diagnostic tool "Configuration Console" (you can start the tool from the Start menu of Windows). This tool is ideal for troubleshooting. With this tool, you can activate the DP trace. With "DP Trace", you can create a log of the calls of selected DP functions.



6.5 FAQs Miscellaneous Programming Questions

Can groups of slaves be used for hardware events?

You can do this yourself with software tools, for example, as follows: At the start of each cycle, activate the hardware events of all slaves in your group and as soon as an event occurs, deactivate then all again until the end of the cycle. This option requires the constant bus cycle time mode on the module.

Which access points of the application are created during installation?

The following access points are created:

• CP_L2_1:

• CP_L2_2:

To allow the name "CP5613_5614_1" suggested for the CP 5613 version 1.x to continue to be used, the following access point is also created:

• CP5613_5614_1

Which interface parameter sets are created during installation?

The following interface parameter assignments are created for the first CP:

• CP5613_5614(MPI)

• CP5613_5614(PROFIBUS)

The following interface parameter sets are created for the second to fourth CP:

• CP5613_5614(MPI)<Board n>

• CP5613_5614(PROFIBUS)<Board n>

The n, is replaced by the relevant CP number.

What differences are there in the DP user program for a CP 5614 and a CP 5613?

With a CP 5613, the "DPS_open" call returns the message that no slave exists; see Section 4.2.2.



What do I need to remember if I use multiple DP master user programs that access the same CP 5613 or CP 5614?

With multiple applications, the DP user programs must be coordinated. This involves, for example, the following important points:

• As long as a DP user program is in possession of a pointer to the process image (DP_get_pointer call), no other DP user program can access it. A DP user program must therefor release the pointer after each access or cycle (DP_release_pointer call).

• Only one application should change the DP master mode (starting up and closing down the DP master with the DP_set_mode call) to avoid conflicts.

• Before changing the DP master from CLEAR to OPERATE, make sure that the output data of the DP slaves in the dual-port RAM have been initialized with suitable values. As soon as the DP master is in the OPERATE mode, these data will be sent to the (operational) DP slaves.

• Only one application should be able to write the output data of any particular slave. This avoids data being overwritten by another application before they are sent to the slave.

• With the exception of the semaphore DP_OBJECT_TYPE_ASYNC, semaphores of the same type can only be used by one application since they are created only once per CP 5613/CP 5614.

• Events and filters must not be used by more than one application for the same slaves (access conflicts).

• If a DP user program activates the AUTOCLEAR property (DP_slv_state call) or starts the watchdog (DP_watchdog call), the DP master changes automatically from OPERATE to CLEAR if one of these events occurs. The other applications should therefore constantly check the master status.

How can I use the CP 5613 or CP 5614 with a real-time kernel in Windows without having to port all the drivers etc.?

Implement the CP startup and log off in Windows. In the meantime, operate the CP in the real-time kernel only by accessing the process image. The alarm used and alsodata is entered in the structure "info_watch.pci" in the process image each time the Windows driver is started (see header file "dp_5613.h"). A Windows DP user program can read this from here and pass it on to a real-time kernel.




Glossary 7

AUTOCLEAR Configuration property of a DP slave - the master changes to the

AUTOCLEAR mode automatically if the configured slave drops out.

Bit time Time required by a bit for transmission on the bus, this is the reciprocal of the data transmission rate.

Bus parameter Bus parameters control the data transmission on the bus - Each PROFIBUS node must use bus parameters that match the bus parameters of other nodes.

c_ref Reference to identify connections to slaves in DPC1 calls.

Constant bus cycle time mode

The constant bus cycle time mode is a mode that can be selected for special applications in which the transfer of user data between the DP master and the DP slaves takes place at constant (equidistant) intervals.

CP Communications Processor — - communications module/network card for installation in computers or programmable controllers.

CPU Central Processing Unit — here processor of the PC

CPU load Load on the CPU of the PC - here: resulting from DP communication

Data transmission rate

Transmission rate on the bus (unit: bps). A bus parameter for PROFIBUS. The data transmission rate used depends on various conditions such as distance.

Data_Ex The slave is ready for productive operation

Glossary


DB Database — The local database describes the communications network from the view of the local system.

Deadlock When more than one parallel process (here: threads) become blocked (A waits for B and B waits for A).

Distributed I/Os An input/output module used in a distributed configuration. The connection between the programmable controller and the distributed I/Os is established via the PROFIBUS bus system. For the programmable controller, the distributed I/Os are no different from local process inputs/outputs.

DP Distributed peripheral I/Os, communication protocol for PROFIBUS complying with EN 50 170 Volume 2.

DP Base Name of the DP programming interface of the CP 5613/CP 5614, in contrast to the DP Lib interface of the CP 5412 (A2), CP 5611 and CP 5511.

DP master A node with master class 1 functionality in PROFIBUS DP - The DP master handles the exchange of data with the DP slaves assigned to it.

DP master class 1 see DP master

DP master class 2 Optional diagnostic master – The diagnostic master is used to monitor the DP master class 1 and the DP slaves.

DP Slave A node with slave functions in PROFIBUS DP.

DP subnet PROFIBUS subnet in which only distributed peripheral I/Os are operated.

DP subsystem A DP master and all DP slaves with which the master exchanges data.

DPC1 DP extended by acyclic read and write jobs and alarms between cyclic DP master and slave.

Glossary


DPC2 DP extended by connection control and read and write jobs from a non-cyclic master.

DP-V1 DP extensions — This includes DPC1 and DPC2

Driver Software that allows data exchange between application programs and the CP client.

Dual-port RAM Dual Port Random Access Memory — allows simultaneous access to one memory area (RAM) by two computer units (CP and CPU).

Event Here: an event that the CP 5613/CP 5614 can signal to the DP user program. There are hardware events and software events.

Fast Logic Property of the CP 5613/CP 5614: an input value of a slave can be monitored. When it changes to a specified value, output data of another slave is set.

FDL Fieldbus Data Link — Layer 2 for PROFIBUS

Frame Message from one PROFIBUS node to another.

Frame header A frame header consists of an identifier for the frame and the source and destination address.

Frame trailer A frame trailer consists of a checksum and the end identifier of the frame.

FREEZE mode The FREEZE mode is a DP mode in which the process data is acquired at the same time from all (or a group) of DP slaves. The time at which the data is required is indicated in the FREEZE command (a synchronization control frame).

Gap update factor A free address area between two active nodes is checked cyclically by the node with the lower PROFIBUS address to find out whether or not another station is requesting to enter the logical ring. The cycle time for this check is as follows:

gap update factor x target rotation time [ms]

Glossary


Group identifier DP slaves can be assigned to one or more groups using a group identifier. The DP slaves can then be addressed by the group identifier when transferring control frames.

GSD file A GSD file (Generic Station Description) is an ASCII file with a series of standardized keywords that uniqely describe certain attributes of a certified DP slave device type. This ensures that different DP slaves from different vendors can communicate with every DP master that complies with the standard. GSD files (and the corresponding slave application) must be certified by a certification center.

Hardware event Event whose arrival is monitored by the hardware of the CP (at the start of the cycle, end of the cycle, when data changes, when diagnostic data arrive, and when a fast logic condition arrives).

Highest PROFIBUS address

A bus parameter for PROFIBUS. This specifies the highest PROFIBUS address of an active node on the PROFIBUS. For passive nodes, PROFIBUS addresses higher than the HSA are permitted (possible values: HSA 1 to 126).

HSA Highest Station Address — one of the bus parameters. Specifies the highest node address used in the network.

I/O module DP slaves can have a modular structure. A DP slave has at least one DP I/O module.

I/O type The DP I/O type identifies a DP I/O module. The following types exist:

• Input module

• Output module

• Input/output module

Indication Message from a remote node.

Input data Here: the data read cyclically by the DP master from the slaves.

Intel format Numbers are stored in the Intel format when lower order bytes are stored first (in other words, at lower addresses).

Glossary


ISO International Standard Organization — International organization based in Geneva responsible for formulating general standards particularly in the area of data transmission.

Isochronous mode see constant bus cycle time mode.

LAN Local Area Network — local network for direct connection of computers.

LSB Least Significant Bit of a byte.

Master An active node on PROFIBUS that can send frames on its own initiative when it is in possession of the token (see also DP master).

Maximum station delay

A bus parameter for PROFIBUS - The maximum station delay (max. TSDR) specifies the longest interval required by a node in the subnet between receiving the last bit of an unacknowledged frame and sending the first bit of the next frame. After sending an unacknowledged frame, a sender must wait for the max. TSDR to elapse before sending a further frame.

min TSDR see "Minimum station delay"

Minimum station delay

A PROFIBUS parameter — The minimum station delay (min. TSDR) specifies the minimum time that the receiver of a frame must wait before sending the acknowledgment or sending a new frame. The min. TSDR takes into account the longest interval required by a station in the subnet for receiving an acknowledgment after sending a frame.

Motorola format Numbers are stored in the Motorola format when higher order bytes are stored first (in other words, at lower addresses).

MSAC_C1 "Master Slave Acyclic Class 1" — Name for DPC1 in the DP-V1 standard description.

MSAC_C2 "Master Slave Acyclic Class 2" — Name for DPC2 in the DP-V1 standard description.

MSB Most Significant Bit of a byte.

Glossary


MSCY_C1 Master Slave Cyclic Class 1 — Name for the normal DP master operation in the DP-V1 standard description.

Network A network consists of one or more interconnected subnets with any number of nodes. Several networks can exist one beside the other. For each subnet, there is a common node table.

Output data Here: the data sent cyclically to the slaves by the DP master.

PC Personal Computer

PG Programming device (industrial PC) belonging to the SIMATIC product family from Siemens AG used for programming, configuring and in maintenance and service.

PNO PROFIBUS Users Organization

Process image Here: used for a dual-port RAM of the CP 5613/CP 5614 that can be accessed directly by DP user programs and wherethe current data of the slaves are located.

PROFIBUS A fieldbus complying with EN 50 170 Vol. 2 (DIN 19245).

PROFIBUS address The PROFIBUS address is a unique identifier of a node connected to a PROFIBUS network. To address a node, the PROFIBUS address is transferred in the frame.

PROFIBUS DP PROFIBUS-DP EN 50 170 Vol. 2 (DIN 19245 T1 + T3) is a guideline from the PROFIBUS users organization for data exchange with distributed peripheral devices.

Protocol Rules governing the transmission of data — The rules specify not only the formats of the messages but also the data flow during data transmission.

READY time A PROFIBUS bus parameter — The READY time is the time within which an active node must be ready to receive an acknowledgment or response after sending a call.

Glossary


Reorganization token ring

All the masters on PROFIBUS form a logical token ring. Within this token ring, the token is passed on from station to station. If the transmission of the token is incorrect or if a master is removed from the ring, this leads to an error when the token is passed on (the token is not accepted by this station) and the station is excluded from the ring. The number of exclusions is counted in the internal Token_error_counter. If this counter reaches an upper limit value, the logical token ring is then reorganized.

S7 PLC Abbreviation for a programmable logic controller belonging to the SIMATIC product family from Siemens AG.

SAP Service Access Point — access point to PROFIBUS within a station

Semaphore Wait point mechanism for synchronizing several programs, for example in Windows NT

Services Services provided by a communication protocol.

Setup time A PROFIBUS bus parameter — The setup time specifies the minimum time between receiving an acknowledgment and sending a new call.

SIMATIC NCM PC Configuration tool for defining communications nodes and the bus parameters.

SIMATIC NET Siemens Network and Communication — Product range for networks and network components from Siemens.

Slave Passive node on PROFIBUS (See also DP slave).

Slot Time A PROFIBUS parameter — The slot time (TSL) is the monitoring time between a sender sending a frame and receiving the acknowledgment of the recipient.

Software event Here: An event that can be signaled by a Windows semaphore.

Glossary


SYNC mode The SYNC mode is a DP mode in which several or all DP slaves transfer data to their process outputs at a certain time. The time at which the data is transferred is indicated in the SYNC command (a control command for synchronization).

System The entire electrical equipment belonging to a plant/system includingprogrammable controllers, devices for operator monitoring and control, bus systems, field devices, drives, supply lines.

Target rotation time A PROFIBUS bus parameter — The token is the right to send for a node on PROFIBUS. A node compares the actual token rotation time it has measured with the target rotation time and depending on the result can then send high or low priority frames.

Thread A subprocess running parallel.

User watchdog Watchdog for monitoring the DP user program

Watchdog A mechanism for monitoring operability of nodes.

Watchdog time A monitoring time that can be set on a DP slave to detect failure of the controlling DP master.

Index


Index 8

A Active........................................................18 Add_Sl_Flag...........................................314 Alarm acknowledge ................................146 Alarm mode ............................................319 Alarm specifier........................................302 Alarm_Mode ...........................................314 Alarm_Type ............................................301 Alarms ......................................................67 Asynchronous.........................................109

get result .............................................159 AUTOCLEAR................................34, 39, 42

configuring ............................................42

B Bus parameters

query current.......................................243 Bus statistics...........................................246

C C pointer ...................................................48 c_ref........................................................162 Check_Cfg_Mode...................................318 CLEAR......................................................33 Compiler,supported ................................350 Configuration ............................................42

DP STEP 7 project ........................341, 343 STEP7 project .................................339

Consistent reading .............................65, 69 Consistent writing .....................................70 constant bus cycle time mode..................51 Constant bus cycle time mode .........61, 362 Control frame............................................40 CP 5613....................................................47 CP 5614....................................................90 CP5412(A2)............................................351 CP5614.....................................................90

D Database ..................................................42 Diag. Station_Not_Ready.......................296 Diag.Cfg_Fault........................................296

Diag.Deactivated.................................... 297 Diag.Ext_Diag ........................................ 296 Diag.Ext_Diag_Overflow........................ 297 Diag.Freeze_Mode ................................ 297 Diag.Invalid_Slave_Response............... 296 Diag.Master_Add ................................... 297 Diag.Master_Lock.................................. 296 Diag.Not_Supported .............................. 296 Diag.Prm_Fault ...................................... 296 Diag.Prm_Req ....................................... 297 Diag.Stat_Diag....................................... 297 Diag.Station_Non_Existent.................... 296 Diag.Sync_Mode.................................... 297 Diag.WD_On.......................................... 297 Diagnostic counter ................................... 75 Diagnostic data ........................................ 31

reading ............................................... 235 Diagnostics .............................................. 32 Distributed I/O .......................................... 18 DLL .......................................................... 12 DP ...................................................... 17, 18 DP Base................................................... 11 DP Base interface.................................... 47 DP master class 1.................................... 19 DP master class 2.................................... 19 DP master user program ......................... 78 DP slave................................................... 90 DP slave diagnostic data ......................... 67 DP slave input data............................ 65, 74 DP slave output data................................ 70 DP slave user program ............................ 92 dp_5613.h .............................................. 109 DP_alarm_ack ....................................... 146 DP_close................................................ 121 DP_cycle_time....................................... 182 DP_delay_irq ......................................... 178 DP_delete_sema_object........................ 165 DP_disable_event.................................. 158 DP_ds_read ........................................... 135 DP_ds_write........................................... 138 DP_enable_event .................................. 152 DP_enable_event .................................... 76

Index


DP_ERROR_CI......................................271 DP_ERROR_EVENT .............................271 DP_ERROR_EVENT_NET ....................271 DP_ERROR_REQ_PAR ........................271 DP_ERROR_RES ..................................271 DP_ERROR_T .......................................270 DP_ERROR_USR_ABORT ...................271 DP_fast_logic_off ...................................170 DP_fast_logic_on ...................................166 DP_fetch_alarm......................................141 DP_fetch_alarm........................................67 DP_get_actual_cfg .................................149 DP_get_cref............................................162 DP_get_err_txt .......................................123 DP_get_pointer.......................................118 DP_global_ctrl ........................................132 DP_init_sema_object .............................163 DP_OK ...................................................271 DP_OK_ASYNC.....................................271 DP_read_slv_par....................................130 DP_release_pointer................................120 DP_reset_cp...........................................115 DP_set_mode.........................................124 DP_slv_state ..........................................127 DP_start_cp............................................113 DP_watchdog .........................................172 DP_write_trc ...........................................175 DPC1........................................................44 DPC1 and DPC2 ......................................44 DPC1 functions.........................................86 DPC2........................................................45 dps_5614.h.............................................109 DPS_calc_io_data_len ...........................231 DPS_close..............................................194 DPS_get_baud_rate...............................198 DPS_get_gc_command .........................200 DPS_get_ind ..........................................208 DPS_open ..............................................187 DPS_set_diag.........................................205 DPS_set_resp ........................................223 DPS_start ...............................................196 DPS_stop ...............................................197 DP-V1 .......................................................44 DPV1_Enable .........................................317 DPV1_Status_1......................................317 DPV1_Status_3......................................319 DPV1_Supported ...................................313 Dual-port RAM..........................................49

E Empty frame .............................................23 Enable_Diagnostic_Alarm......................318 Enable_Manufacturer_Specific_Alarm...318 Enable_Process_Alarm..........................318 Enable_Pull_Plug_Alarm........................318

Enable_Status_Alarm ............................ 318 Enable_Update_Alarm........................... 318 Error information .................................... 123 Error messages

overview ............................................. 357 error_class ............................................. 271 error_code.............................................. 272 error_code_1.......................................... 272 error_code_2.......................................... 272 error_decode.......................................... 272

F Fail_Safe................................................ 313 Fail-safe ................................................. 317 Fast Logic .................................. 51, 58, 170 Fast Logic .............................................. 248 FastLogic ............................................... 166 Fieldbus ................................................... 16 Filter mechanisms.................................... 54 Firmware version ................................... 241 FREEZE................................................... 41 Freeze_Req ........................................... 316 Function calls ........................................... 48

G Global controls ......................................... 40 GlobalControl ......................................... 200 GlobalControlCommand ........................ 132 Group_Ident ........................................... 317 GSD data ................................................. 43

H Handle.................................................... 116 Hardware event

activating ............................................ 252 advantages and disadvantages ......... 353

Hardware events.......................... 52, 53, 55 Hardware version................................... 241 Header files........................................ 12, 50

I Ident_Number ................................ 298, 317 Identification no...................................... 241 Import libraries ................................... 12, 50 Initialization .............................................. 32 Input data ........................................... 23, 31

reading ............................................... 233

L LED ................................................ 114, 115 Lock_Req............................................... 316

M Master ...................................................... 18

modes................................................... 33 querying information........................... 241

Min.StationDelayResponder .................. 317 Min_Slave_Interval .................................. 43

Index


Multi-thread operation ..............................71

N New_Prm................................................313

O OFFLINE ..................................................33 OPERATE ................................................34 Operating data..........................................62 Operating system, supported .................350 Output data.........................................23, 31

writing..................................................237

P Passive .....................................................18 Piggyback module ....................................27 Pointer ....................................................118 Pointer access..........................................48 Polling.......................................................23

advantages and disadvantages..........352 Polling cycle........................................23, 82 Process image..........................................49

access by multiple programs ..............354 access by multiple threads .................354 pointer to .............................................118

Process image..........................................31 PROFIBUS ...............................................16 Programming interface .............................50 Programming languages, supported ......350

R Read data record......................................86

S Sample program...................... 12, 338, 340 Sample program.....................................342 SAP ........................................................313 Semaphore.......................................83, 265

delete ..................................................165 initialize ...............................................163

Sl_Flag ...................................................313 Slave.........................................................18

checking for changed data..................238 data format..........................................292 format of the diagnostic data ..............293 query state (CP5614)..........................203 querying configured data ....................245 querying the state ...............................240

reading configuration data.................. 149 reading database parameters ............ 130 receiving data ..................................... 256 sending data (CP5614) ...................... 255 sending diagnostic data (CP5614) ..... 257 set diagnostic data (CP5614)............. 205 state.................................................... 127 Type ................................................... 313

Slot number............................................ 301 Software events ........................... 52, 54, 56 Statistical data........................................ 246 Status_Type........................................... 301 STOP ....................................................... 33 SYNC ....................................................... 41 Sync_Req .............................................. 316 Synchronous .......................................... 109

T Threads

advantages and disadvantages ......... 353 Timeout monitoring ............................ 51, 60 Transfer.................................................... 28

configuring.......................................... 347 sample program ................................. 344

U UNFREEZE.............................................. 41 Unlock_Req ........................................... 316 UNSYNC.................................................. 41 User watchdog ....................................... 250 User watchdog ....................................... 173 UserWatchdog ....................................... 172

V Vendor-specific data .............................. 319 Version, overview................................... 350

W Watchdog................................... 39, 42, 172 Watchdog............................................... 316 Watchdog function ................................... 60 Watchdog time ....................................... 316 WD_Base_1ms...................................... 317 WD_Fact_1 ............................................ 316 WD_Fact_2 ............................................ 316 Windows semaphore ............................... 52 Write data record ..................................... 86

Documents

DP Base Programming Interface for CP 5613/CP 5614 · Preface DP Base Programming Interface for CP 5613/CP 5614 C79000-G8976-C139-09 5 Preface Purpose of the Manual This manual supports