Appendix A - Values of rb_response with Windows 95, Windows NT and MS-DOS. Appendix B - Error Messages of the SEND/RECEIVE Functions

(1)

Manual

1

Introduction to the SEND/RECEIVE Programming Interface

2

Communication with SIMATIC S5 Programmable Controllers

3

Communication with SIMATIC S7 Programmable Controllers

4

Communication with PCs/Workstations

5

SEND/RECEIVE Request Block

6

Description of the SEND/RECEIVE Job Types

7

How to Compile a Program

Appendix A - Values of rb_response with Windows 95, Windows NT and MS-DOS Appendix B - Error Messages of the SEND/RECEIVE Functions

(2)

Angaben in der Druckschrift werden jedoch regelmä-ßig überprüft. Notwendige Korrekturen sind in den nachfolgenden Auflagen enthalten. Für Verbesse-rungsvorschläge sind wir dankbar.

Technische Änderungen vorbehalten.

lung oder GM-Eintragung. C79000-G8976-C097

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

Technical data subject to change.

The reproduction, transmission or use of this docu-ment or its contents is not permitted without express written authority. Offenders will be liable for damages. All rights, including rights created by patent grant or registration of a utility or design, are reserved. C79000-G8976-C097

Nous avons vérifié la conformité du contenu du pré-sent manuel avec le matériel et le logiciel qui y sont décrits. Or, des divergences n'étant pas exclues, nous ne pouvons pas nous porter garants pour la conformité intégrale. Si l'usage du manuel devait révéler des erreurs, nous en tiendrons compte et apporterons les corrections nécessaires dès la pro-chaine édition. Veuillez nous faire part de vos sug-gestions.

Nous nous réservons le droit de modifier les caracté-ristiques techniques.

Toute communication ou reproduction de ce support d'informations, toute exploitation ou communication de son contenu sont interdites, sauf autorisation ex-presse. Tout manquement à cette règle est illicite et expose son auteur au versement de dommages et intérêts. Tous nos droits sont réservés, notamment pour le cas de la délivrance d'un brevet ou celui de l'enregistrement d'un modèle d'utilité.

C79000-G8976-C097

Siemens Aktiengesellschaft Elektronikwerk Karlsruhe

(3)

SEND/RECEIVE Programming Interface

(4)

We would further point out that, for reasons of clarity, this instruction manual cannot deal with every possible problem arising from the use of this device. Should you require further information or if any special problems arise which are not sufficiently dealt with in the instruction manual, please contact your local Siemens representative.

General

This device is electrically operated. In operation, certain parts of this device carry hazardous voltages. WARNING !

Non-observance of the safety instructions can result in severe personal injury or property damage. Only qualified personnel should work on or around this equipment after becoming thoroughly familiar with all warnings, safety notes and maintenance procedures contained herein.

The successful and safe operation of this equipment is dependent on proper handling, installation, operation, and maintenance.

Qualified Personnel

Qualified personnel as referred to in this instruction manual or in the warning notes is defined as persons who are familiar with the installation, assembly, startup, and operation of this product and who possess the relevant qualification for their work, e.g.:

− training in or authorization for connecting up, grounding or labeling circuits and devices or systems in accordance with current standards in safety technology;

− training in or authorization for the maintenance and use of suitable safety equipment in accordance with current standards in safety technology;

− First Aid qualification.

(5)

The SEND/RECEIVE Programming Interface

The SIMATIC S5/S7 system components communicate with each other via the SEND/RECEIVE communications protocol. The SEND/RECEIVE programming interface has been developed to provide programming device/PC user programs with access to SIMATIC S5/S7 system components. Its C programming interface allows you simple and flexible access to the data of S5/S7 system components.

(6)

6

1 Introduction to the SEND/RECEIVE Programming

Inter-face

This chapter deals with the following topics:

➢ the advantages of the SEND/RECEIVE programming interface,

➢ how the SEND/RECEIVE Programming Interface operates in the single and multi-device modes

➢ how the sample and SEND/RECEIVE functions work

➢ which support is available to programmers in addition to the manual, ➢ how user programs use the SEND/RECEIVE programming interface ➢ what is involved in job handling with SOFTNET Industrial Ethernet

Contents of Chapter 1

1.1 Advantages of the SEND/RECEIVE Programming Interface ...10

1.2 SEND/RECEIVE Programming Interface under Windows 95 and Windows NT in the Single Device Mode...11

1.2.1 SEND/RECEIVE SetSR( ) Function ...14

1.2.2 SEND/RECEIVE Call_Ina( ) Function ...15

1.2.3 SEND/RECEIVE ResetSR( ) Function ...16

1.2.4 Signaling ...17

1.3 SEND/RECEIVE Programming Interface under Windows 95 and Windows NT in the Multi-Device Mode ...18

1.3.1 SEND/RECEIVE SRMD_Set( ) Function...21

1.3.2 SEND/RECEIVE Function SRMD_Request( ) ...23

1.3.3 SEND/RECEIVE Function SRMD_Reset( ) ...24

1.3.4 Signaling ...25

1.4 The Trace under Windows 95 and Windows NT...26

1.4.1 The SEND/RECEIVE SR_Trace Function...27

1.4.2 Parameters of the Trace ...28

1.4.3 Parameter SR_Trace_Target ...30

1.4.4 Parameter SR_Trace_Depth...31

1.4.5 Parameter SR_Trace_Select ...32

1.5 SEND/RECEIVE Programming Interface under MS-DOS ...33

(10)

10

1.1 Advantages of the SEND/RECEIVE Programming

Inter-face

Access to SIMATIC S5

The SEND/RECEIVE programming interface allows you to set up communication between your PC and SIMATIC programmable control-lers, primarily with SIMATIC S5 PLCs.

Programmer Support

To familiarize programmers with the SEND/RECEIVE programming interface, support software is also shipped with the documentation:

• sample programs, and

• a job library

Sample Programs Sample programs are included. These are written in the "C" program-ming language.

They allow you to see how the interface operates. With suitable adap-tation, you can even use parts of the sample programs in your own programs.

Job Library The job library for function jobs of the SEND/RECEIVE interface can also be very helpful. It is written in "C" and is also shipped with the documentation.

For C programmers, this means:

• the job library can be integrated directly into your own software;

• the jobs contained in the library can be used directly as described in the sample programs.

Apart from the theoretical explanation in the manual, the handling of data structures (request block) is illustrated in a practical context by sample programs and function jobs.

Independent of the Transport Protocol

You can choose between the ISO Transport protocol and the TCP/IP protocol. The choice of transport protocol does not affect the

SEND/RECEIVE programming interface.

Multi-Device Mode With the SEND/RECEIVE programming interface, the "Multi-Device mode“ is possible.

This means that one or more user programs (applications) can address one or more network cards in the local PC at the same time. Each network card can also be addressed via one or more "access points of the application".

(11)

1.2 SEND/RECEIVE Programming Interface under

Win-dows 95 and WinWin-dows NT in the Single Device Mode

Software Components

The SEND/RECEIVE programming interface package includes SEND/RECEIVE functions and sample programs and sample functi-ons.

Integration of the Software

Components

The sample programs and the sample and SEND/RECEIVE functions handle the basic tasks of communication. They are part of the product and can be integrated into the user software if the task to be performed is appropriate.

The Single Device Mode

In the single device mode, the single device functions are used. The user can communicate using only one access point of the application per user program.

SEND/RECEIVE Functions

In the single device mode of the SEND/RECEIVE programming inter-face under Windows 95 and Windows NT, there are the following SEND/RECEIVE functions:

• SetSR( )

• Call_Ina( )

• ResetSR( )

These are parts of the SEND/RECEIVE function library (S7_SR.DLL).

Following Sections The remainder of this section shows first a graphical overview of the software components followed by a description of the operation of the components.

(12)

12 SEND/RECEIVE Programming Interface in the Single Device Mode

The schematic below illustrates the functions of the SEND/RECEIVE programming interface under Windows 95 and Windows NT in the

single device mode.

SEND/RECEIVE function SEND/RECEIVE function

INA_CONNECT INA_LISTEN INA_CLOSE

INA_RECEIV INA_SEND INA_OPEN

Request blocks Sample functions SEND/RECEIVE function

Further sample functions

Sample programs Sample programs

SetSR( ) e.g. SRSample

ISO protocol 8073 or

TCP/IP with RFC 1006 Transport protocol Message Call_Ina( ) Message Receive thread of SEND/RECEIVE Message e.g. SRSample ResetSR( )

(13)

Dynamic Sequence The following table describes the individual phases of a function se-quence used to call communications job.

Stage Procedure

1 Calling the SEND/RECEIVE function SetSR( ) transfers an "access point of the application" initializes signaling. 2 A sample program calls a sample function.

3 This sample function fills the request block with job data. 4 Afterwards, the sample function calls the SEND/RECEIVE

Call_Ina( ) function. In so doing, the request block is transferred to Call_Ina( ).

5 The SEND/RECEIVE Call_Ina( ) function transfers the request block to the communications software.

6 The transport protocol handles the job. Here, the Windows sample program can be continued, for example, to send further jobs.

7 When the job has been processed, this is reported to the SEND/RECEIVE message thread.

8 The SEND/RECEIVE receive thread signals completion of the job with a message to the sample program. The request block is returned.

9 The SEND/RECEIVE function ResetSR( ) closes the "access point of the application" used in this call.

(14)

14

1.2.1 SEND/RECEIVE SetSR( ) Function

Description With the SEND/RECEIVE SetSR( ) function, the user program initiali-zes the "access point of the application" and at the same time selects the corresponding network card.

How Signaling Works

The SEND/RECEIVE SetSR( ) function must be called before the first Call_Ina( ) function.

You can check the available "access points of the application" in the configuration menu.

To release the connection to the initialized "access point of the appli-cation" again, the ResetSR( ) function must be called.

Restriction The SEND/RECEIVE SetSR( ) function must not be called more than once per user program.

This means that a user program in the single device mode can use only one "access point of the application".

Syntax int SetSR (LPSTR SRAccessPoint, HWND SRwnd, UINT SRmsg)

Meaning of the Parameter

The parameters of the SEND/RECEIVE SetSR( ) function have the following meaning:

Parameter Type Description

SRAccessPoint LPSTR "Access point of the application" for the se-lected CP.

SRwnd HWND A handle to the window of the user program in which the messages of the SEND/RECEIVE programming interface are managed. SRmsg UINT ID of messages received by the user program

via the SEND/RECEIVE programming inter-face. SRmsg must be greater than WM_USER (Windows constant).

Return Value If the SEND/RECEIVE SetSR( ) function call was successful, 0 is returned, otherwise, the return value is -1.

If an error occurred, the precise cause of the error can be queried with the GetLastError( ) function. The error constants are described in “Appendix B - Error Messages of the SEND/RECEIVE Functions”.

(15)

1.2.2 SEND/RECEIVE Call_Ina( ) Function

Description All functions must call the SEND/RECEIVE Call_Ina( ) function after they have filled in the request block. The Call_Ina function passes the communications job on.

Before the Call_Ina( ) function is called, the request block must be filled with job-specific data. Then a pointer to the request block is transferred to the SEND/RECEIVE Call_Ina( ) function by the calling function.

Chapters 5 and 6 contain detailed information on the SEND/RECEIVE request block.

Syntax int Call_Ina(RB

_*

rb)

The parameter of the SEND/RECEIVE Call_Ina( ) function has the following meaning:

rb RB

_*

Pointer to the user-defined request block.

Return Value If the SEND/RECEIVE Call_Ina( ) function call was successful, 0 is returned, otherwise the return value is -1.

(16)

16

1.2.3 SEND/RECEIVE ResetSR( ) Function

Description The SEND/RECEIVE ResetSR( ) function closes the "access point of the application" that was initialized with the SetSR( ) function.

Syntax int ResetSR(void)

Return Value If the SEND/RECEIVE ResetSR( ) function call was successful, 0 is returned, otherwise -1.

(17)

1.2.4 Signaling

Purpose The signaling procedure helps to avoid the user program having to wait for job processing to be completed.

With the SEND/RECEIVE SetSR( ) function, the function parameters SRwnd and SRmsg are transferred to the SEND/RECEIVE program-ming interface. These parameters are used for signaling in a Windows environment.

Signaling in the User Program

The user program transmits a job by calling the Call_Ina( ) function. After the job has been processed, the relevant PostMessage( ) (Windows function) is transferred by the SEND/RECEIVE program-ming interface to the calling user program.

Implementation in the User Program

The SEND/RECEIVE function library "S7_SR.DLL“ is either loaded automatically when the user program starts or using the Windows function "LoadLibrary( )“. A receive thread is also generated.

If a SEND/RECEIVE job is processed by the user program, the follo-wing takes place in the receive thread:

• It receives a message

• It reads the result buffer

• It passes on a message indicating the end of the SEND/RECEIVE job to the user program using SRwnd as the window handle and SRmsg as the message ID.

How the

PostMessage( ) Function Works

The SEND/RECEIVE programming interface transfers the following parameters to the PostMessage( ) function:

PostMessage(SRwnd, SRmsg, rb_user, RB

_*

rb)

Using the rb_user and RB

_*

rb parameters, a message can be uniquely assigned to a previously transmitted job.

(18)

18

1.3 SEND/RECEIVE Programming Interface under

Win-dows 95 and WinWin-dows NT in the Multi-Device Mode

The SEND/RECEIVE programming interface package includes SEND/RECEIVE functions and sample programs and sample functi-ons.

Components

Sample programs and SEND/RECEIVE and sample functions perform basic communication tasks. They are part of the product and can be integrated into the user software if the task to be performed is appro-priate.

The Multi-Device Mode

In the multi-device mode, the multi-device functions are used. The user can communicate via more than one "access point of the applica-tion" per user program.

SEND/RECEIVE Functions

In the Multi-Device mode of the SEND/RECEIVE programming inter-face under Windows 95 and Windows NT, the following

SEND/RECEIVE functions are available:

• SRMD_Set( )

• SRMD_Request( )

• SRMD_Reset( )

These are parts of the SEND/RECEIVE function library (S7_SR.DLL).

(19)

SEND/RECEIVE Programming Interface in the Multi-Device Mode

The schematic below illustrates the functions of the SEND/RECEIVE programming interface under Windows 95 and Windows NT in the

multi-device mode.

SRMD_Set( )

SEND/RECEIVE function SEND/RECEIVE function

INA_RECEIV INA_SEND INA_OPEN

Request blocks Sample functions SEND/RECEIVE function

Further sample programs

Sample programs Sample programs Transport protocol Message SRMD_Request( ) Message Receive thread of SEND/RECEIVE Message e.g. SRSample e.g. SRSample ISO protocol 8073 or TCP/IP with RFC 1006 SRMD_Reset( )

(20)

20

1 With the SEND/RECEIVE SRMD_Set( ) function call, an "access point of the application" is transferred and signaling in-itialized.

2 A sample program calls a sample function.

3 This sample function fills the request block with job data. 4 The sample function then calls the SEND/RECEIVE

SRMD_Request( ) function. At the same time, the request block is transferred to SRMD_Request( ).

5 The SEND/RECEIVE function SRMD_Request( ) transfers the request block to the communications software.

6 The transport protocol handles the job. Here, the Windows sample program can be continued, for example, to send further jobs.

7 When the job has been processed, this is reported to the SEND/RECEIVE message thread.

8 The SEND/RECEIVE receive thread signals completion of the job with a message to the sample program. The request block is returned.

9 The SEND/RECEIVE function SRMD_Request( ) closes the "access point of the application" used.

(21)

1.3.1 SEND/RECEIVE SRMD_Set( ) Function

Description With the SEND/RECEIVE function SRMD_Set( ), the user program initializes the "access point of the application" and at the same time selects the corresponding network card.

The SEND/RECEIVE SRMD_Set( ) function must be called before the first SRMD_Request( ) call.

You can check the available "access points of the application" in the configuration menu.

To release the connection to the initialized "access point of the appli-cation" again, the SRMD_Reset( ) function must be called.

This means that a user program in the multi-device mode can use mo-re than one "access point of the application".

Restriction The maximum number of "access points of the application" on the computer is 32.

Syntax int SRMD_Set (LPSTR SRAccessPoint, HWND SRwnd, UINT SRmsg)

The parameters of the SEND/RECEIVE function SRMD_Set( ) have the following meaning:

SRAccessPoint LPSTR "Access point of the application" for the se-lected CP.

SRwnd HWND A handle to the window of the user program in which the messages of the SEND/RECEIVE programming interface are managed. SRmsg UINT ID of messages received by the user program

via the SEND/RECEIVE programming inter-face. SRmsg must be greater than WM_USER (Windows constant).

(22)

22

Return Value If the SEND/RECEIVE SRMD_Set( ) function call was successful, values >= 0 are returned, otherwise values < 0.

Return Value Meaning

>= 0 Handle to the transferred "access point of the application" < 0 If an error occurred, the precise cause of the error can be queried with the GetLastError( ) function. The error con-stants are described in "Appendix B - Error Messages of the SEND/RECEIVE Functions”.

(23)

1.3.2 SEND/RECEIVE Function SRMD_Request( )

Description After the request block has had data entered, all functions must call the SEND/RECEIVE SRMD_Request( ) function. The Call_Ina function passes the communications job on.

Before the SRMD_Request( ) function is called, the request block must be filled with job-specific data. The SEND/RECEIVE SRMD_Request( ) function is transferred a pointer to the request block by the calling function.

Syntax int SRMD_Request(int hSRAccessPoint, RB

_*

rb)

The parameter of the SEND/RECEIVE SRMD_Request( ) FUNCTION has the following meaning:

hSRAccessPoint INT Handle to the transferred "access point of the application"; return value of SRMD_Set( ) rb RB

_*

Return Value If the SEND/RECEIVE function SRMD_Request( ) was successful, 0 is returned, otherwise -1.

(24)

24

1.3.3 SEND/RECEIVE Function SRMD_Reset( )

Description The SEND/RECEIVE function SRMD_Reset( ) closes the "access point of the application" named in the transferred parameter.

Syntax int SRMD_Reset(hSRAccessPoint)

The parameter of the SEND/RECEIVE SRMD_Reset( ) FUNCTION has the following meaning:

hSRAccessPoint INT Handle to the "access point of the application"; return value of SRMD_Set( )

Return Value If the SEND/RECEIVE function SRMD_Reset( ) was successful, 0 is returned, otherwise -1.

(25)

1.3.4 Signaling

Purpose The signaling procedure helps to avoid the user program having to wait for job processing to be completed.

With the SEND/RECEIVE SRMD_Set( ) function, the function parame-ters SRwnd and SRmsg are transferred to the SEND/RECEIVE pro-gramming interface. These parameters are used for signaling in a Windows environment.

Signaling in the User Program

The user program transmits a job by calling the SRMD_Request( ) function. After the job has been processed, the relevant PostMessa-ge( ) (Windows function) is transferred by the SEND/RECEIVE pro-gramming interface to the calling user program.

Implementation in the User Program

The SEND/RECEIVE function library (S7_SR.DLL) is loaded automati-cally when the user program is started. A receive thread is also genera-ted.

If a SEND/RECEIVE job is processed by the user program, the follo-wing takes place in the receive thread:

• It receives a message

• It reads the result buffer

• It passes on a message indicating the end of the SEND/RECEIVE job to the user program using SRwnd as the window handle and SRmsg as the message ID.

How the

PostMessage( ) Function Works

The SEND/RECEIVE programming interface transfers the following parameters to the PostMessage( ) function:

PostMessage(SRwnd, SRmsg, rb_user, RB

_*

rb)

Using the rb_user and RB

_*

rb parameters, a message can be uniquely assigned to a previously transmitted job.

(26)

26

1.4 The Trace under Windows 95 and Windows NT

What is Meant by Trace?

Under Windows 95 and Windows NT, the trace is a simple and ne-vertheless effective aid to debugging the SR library.

During operation, the SR library writes important data to the trace file. The content of the trace file

• is used as a log of all actions executed by the SR library.

• allows the sequence of events to be checked both for the applicati-on and for the library itself.

• allows simple debugging and checking of the data and parameters on the SEND/RECEIVE programming interface.

Uses of the Trace When active, the trace writes data and events to the trace file. It can be adapted to a wide range of situations and applications:

• You can select any name for the trace file.

• The parameter SR_Trace_Target specifies whether or not a new trace file should be created or an old one used.

• The parameter SR_Trace_Depth can be set for all trace types:

− Trace active only for negative events

− Trace of all SEND/RECEIVE functions

− Trace dump of the transferred request blocks

• With the parameter SR_Trace_Select, you can select the events to be logged.

• You can also write to the trace file yourself. Such entries can be used to save important data for checking and to check the running of the program.

(27)

1.4.1 The SEND/RECEIVE SR_Trace Function

Description With this call, any entries can be made in the trace file. This makes it possible to save important data so that they can be checked, to check the running of the program and to synchronize it with the trace entries.

Requirements Under Windows NT, the parameters can only be modified if you have administrator rights.

Syntax int SR_Trace(char 5format[, argument]...)

The parameter of the trace function SR_Trace has the following mea-ning:

format[, argument]... CHAR 5 Formatted string with the user message to be entered in the trace file.

In one trace line, the current time, a process ID (PID) and thread ID (TID) are output before the actual trace informati-on.

The syntax corresponds to the C function printf( ).

Return Value If the SEND/RECEIVE function SR_Trace( ) was successful, 0 is re-turned, otherwise -1.

(28)

28

1.4.2 Parameters of the Trace

Adapting the Trace The trace can be adapted to a wide variety of applications by mo-difying the trace parameters. The trace parameters for adapting the trace to your requirements are described below.

The parameters can be set with a utility; Name: "Setting the PG/PC Interface”.

Parameters of the Trace

The running of the trace is controlled by parameters.

Names of the Trace Parameters

• SR_Trace_Filename • SR_Trace_MaxLines • SR_Trace_MaxFiles • SR_Trace_Target • SR_Trace_Depth • SR_Trace_Select

The meaning of the parameters is described in the following sections. The values of the constants described here are contained in the file SR_TRACE.H.

SR_Trace_ Filename

The name of the trace file and path are entered in this parameter. Default: “SRTRACE.TXT” in the current working directory.

SR_Trace_ MaxLines

The maximum number of lines in the trace file is specified in this pa-rameter. Once the maximum number of lines is reached, a new trace file is opened.

Default: 10 000

SR_Trace_ MaxFiles

The maximum number of trace files is specified in this parameter. If the maximum number of files is reached, recording starts again in the first trace file.

This means that the last (SR_Trace_MaxFiles - 1) files are always available.

(29)

Further Parameters The remaining parameters require more detailed description:

• SR_Trace_Target

• SR_Trace_Depth

• SR_Trace_Select

(30)

30

1.4.3 Parameter

SR_Trace_Target

Description The target for the trace is specified in this parameter. The following values can be set:

Parameter Values Description

TRACE_TARGET_NEW_FILE The trace entries are written to a file. The file is created. Any old entries in this file are deleted.

TRACE_TARGET_OLD_FILE The trace entries are written to a file. An existing file remains unchanged subsequent trace entries are appen-ded to the older entries.

(31)

1.4.4 Parameter

SR_Trace_Depth

Description The trace depth is set in this parameter. The following values can be set:

Parameter Values Description TRACE_DEPTH_OFF Trace deactivated.

TRACE_DEPTH_USER With this value, only the strings specified the user program with the SR_Trace( ) function are entered. TRACE_DEPTH_ERROR This setting means that trace entries

are made only after negative events or events.

TRACE_DEPTH_INFO With this value, all SEND/RECEIVE functions with their transfer parame-ters and return values are logged. TRACE_DEPTH_BUF_SR With this value, a trace dump of the

transferred request blocks is also entered.

(32)

32

1.4.5 Parameter

SR_Trace_Select

Description With the parameter SR_Trace_Select, the events to be logged can be selected.

By ORing the parameter values, you can combine various trace se-lections.

Example:

TRACE_SELECT_SEND | TRACE_SELECT_RECV

The following values can be set:

Parameter Values Description TRACE_SELECT_INIT The trace is activated when the

SetSR( ) or SRMD_Set( ) function is called.

TRACE_SELECT_SEND The trace logs all SEND jobs sent to the local transport system

(underlying interface).

TRACE_SELECT_RECV The trace logs all RECEIVE jobs received from the local transport sy-stem (underlying interface).

TRACE_SELECT_ALL The trace is activated for all the pa-rameter values described above.

(33)

1.5 SEND/RECEIVE Programming Interface under MS-DOS

The SEND/RECEIVE programming interface package includes a SEND/RECEIVE function and sample programs and functions.

Components

Sample programs and sample functions perform the basic communi-cations tasks. They are part of the product and can be integrated into the user software if the task to be performed is appropriate.

SEND/RECEIVE Function

Under MS-DOS there is a SEND/RECEIVE function:

• Call_Ina( )

This is part of the SEND/RECEIVE function library.

(34)

34

Illustration of the SEND/RECEIVE Programming Interface

The diagram below shows the principle of operation of the SEND/RECEIVE programming interface UNSIG16.

FETCH4 H1RECV

ISO protocol 8073 Sample functions

Sample programs Further sample programs

INA_OPEN

Call_Ina( )

Interrupt

Transport protocol

INA_RECEIV INA_SEND

SEND/RECEIVE function Request blocks

Sample functions

(35)

1 A sample program calls a sample function.

2 This sample function fills the request block with job data. 3 Afterwards, the sample function calls the SEND/RECEIVE

Call_Ina( ) function. In so doing, the request block is transferred to Call_Ina( ).

4 The SEND/RECEIVE Call_Ina( ) function passes the request block to the communications software by interrupt.

5 The transport protocol handles the job.

6 When the job has been processed and the interrupt terminated, the calling sample program is continued.

7 Depending on the job type, the results are now in a request block or the job is still being processed (in the event of asyn-chronous processing).

8 With asynchronous jobs, the sample program can establish when the asynchronous job is completed and data in the request block become effective by scanning a component in the request block (rb_response).

(36)

36

1.5.1 SEND/RECEIVE Call_Ina( ) Function

Description All functions must call the SEND/RECEIVE Call_Ina( ) function after they have filled in the request block. The Call_Ina function passes the communications job on.

A pointer is also transferred to the request block header and process interrupt 5B is initiated.

Before the Call_Ina( ) function is called, the request block must be filled with job-specific data. Then a pointer to the request block is transferred to the SEND/RECEIVE Call_Ina( ) function by the calling function.

Syntax UNSIG16 Call_Ina(RB

_*

rb)

The parameter of the SEND/RECEIVE Call_Ina( ) function has the following meaning:

rb RB

_*

Return Value If the SEND/RECEIVE Call_Ina( ) function call was successful, E_OK is returned, otherwise the return value is E_FATAL.

(37)

2 Communication with SIMATIC S5 Programmable

Control-lers

With the help of flowcharts, this chapter describes the sequence required in the user program in a PC to transmit jobs to the communications software. In the configuration described, a PC is connected to an S5 programmable controller.

Contents of Chapter 2

2.1 General Notes on the Description in this Chapter...38 2.2 General Sequence of Communication ...39 2.2.1 Phases of Data Communication...40 2.2.2 Jobs of Data Communication ...41 2.2.3 Flowcharts in General ...42 2.3 Phase 1: Logon...44 2.4 Phase 2: Connection Establishment - Description ...45 2.4.1 Connection Establishment - Implementation ...47 2.4.2 Problems during Connection Establishment, Example 1 ...49 2.4.3 Problems during Connection Establishment, Example 2 ...50 2.5 Phase 3: Data Exchange ...52 2.5.1 Data Exchange Variant 1, Normal Data Exchange ...53 2.5.2 Data Exchange Variant 2, Expedited Data Exchange...55 2.5.3 Data Exchange - Variant 3, Normal Data Exchange with Segmented

Transmission ...57 2.5.4 Data Exchange Variant 4, Data Exchange with the WRITE Job type...61 2.5.5 Data Exchange Variant 5, Data Exchange with the READ Job type ...66 2.5.6 Problems During Data Exchange, Example 1 ...71 2.5.7 Problems during Data Exchange, Example 2 ...72 2.6 Phase 4: Connection Termination and Logoff ...73 2.7 Aborted Communication ...75

(38)

38

2.1 General Notes on the Description in this Chapter

Presentation of Information

The description in this chapter is based on a simple network architectu-re for communication between a PC and a SIMATIC S5 programmable controller (S5 PLC).

Network Architecture

The following diagram describes the network architecture of a PC-S5 or S5-PC connection. It can be extended to include several connecti-ons to further communication partners.

Explanation of Terms

The table below explains the terms used in the diagram.

Term Description

PC The PC contains:

• the user program,

• the communications software

• a network interface card with an appropriate driver LAN

cable

The LAN cable is the physical connection between the different communication partners. For this network architecture, an In-dustrial Ethernet network with bus components is assumed. S5 PLC The S5 PLC needs a communications processor (CP) for

com-munication. The CP handles the communication tasks to relieve the programmable controller.

This chapter primarily describes the following CP parameters for configuring a communication connection:

• Job type: SEND or RECEIVE

• Priority: 2 with SOFTNET IE or CP 1413 PC SIMATIC S5 PLC with communications processor LAN cable

(39)

2.2 General Sequence of Communication

Introduction This chapter provides a general description of communication between a PC and an S5 PLC, and vice versa. The terms used in this descripti-on are explained below.

Phases The sequence of communication is divided up into chronological

pha-ses. Every phase is a self-contained unit and handles jobs.

Jobs Jobs are functions in the software package.

Flowcharts Flowcharts describe the chronological sequence within a phase or

phase variant. They show jobs and the resulting presentation of the messages transmitted via the LAN cable.

Structure of a Phase

The following diagram shows the way a phase is structured and descri-bed in this chapter.

Several jobs can be assigned to one phase.

Phase Job Example: connection establ. Phase Job Job Example:

➢ Normal data exchange ➢ Normal data exchange

with segmented transmission Phase Job Example: Connection termination

(40)

40

2.2.1 Phases of Data Communication

Description The phases of data communication represent a chronological structure. Each data communication is divided into four self-contained phases that occur only once during communication.

Phases of Data Communication

The table below shows the general sequence of communication for one connection.

Phase Name of the Phase

1 Logon

2 Connection establishment

3 Data exchange

4 Connection termination and logoff

Note The data exchange phase can take any length of time. Any amount of data can be transmitted. It ends with the start of the connection termination and logoff phase.

Several Connections

The phase sequence illustrated above applies to one connection. If several connections are established, the sequence shown is run through for every single connection.

(41)

2.2.2 Jobs of Data Communication

Description Jobs are functions implemented in the communications software. The user program uses them to handle the individual phases of communi-cation.

A total of ten jobs are available.

Job Types The following list shows which jobs are transmitted in the individual phases. Logon • OPEN_REQ Connection establishment • AWAIT_CONN_REQ_TRAN • SEND_CONN_REQ Data exchange • SEND_DATA • SEND_EOM_DATA • SEND_EXP_DATA* • RECEIVE_DATA • RECEIVE_EXP_DATA*

Connection termination and logoff

• AWAIT_CLOSE

(42)

42

2.2.3 Flowcharts in General

Description Flowcharts describe the chronological sequence of a phase. They show the job types and the representation of the messages transmitted.

The S5 PLC handles communication in the CPU by data handling blocks (HDB types), and by an appropriate parameter assignment in the related CP.

Flowchart Structure

The left side of the chart shows the initiating communication partner, the right side shows the receiving communication partner.

Both communication partners are physically connected via a "LAN cable". The chart shows the presentation of the messages under this heading.

The time axis runs from top to bottom. The chronological sequence shows the order in which jobs must be transmitted and which messa-ges are transmitted via the LAN cable.

Example:Sample Flowchart; PC-S5 Connection

The following diagram shows a general example of the schematic lay-out of a flowchart for a PC-S5 connection.

PC LAN cable S5 PLC

UP TS TS CP conf. S5-CPU progr.

Job TPDU Job return HDB types Parameters of transp. conn. • Job type: • Read/write: • Act/pass: • Priority:

(43)

Explanation of the Terms Used in the Chart

The table below explains the terms used in the diagram above.

Term Description

PC UP User program - The user program provides a request block with data and then initiates a job (Call_Ina( )) to the transport system (TS). Job A job is a function that the user program must process in conjunction

with the transport system at the time indicated. Every job is provided with a parameter set called the request block (job list).

Job return Every job is acknowledged after execution.

Success or failure of the job is signaled in the rb_response parameter of the request block.

TS Transport System - Each communication partner has a transport sy-stem (layer 4 of the ISO 7-layer model) as communication program. LAN cable TPDU Transport Protocol Data Unit - Representation of a message by the

transport system (layer 4) of the sender to the transport system (layer 4) of the receiver.

S5 PLC TS Transport System - Each communication partner has a transport sy-stem (layer 4 of the ISO 7-layer model) as communication program. CP conf. A communications processor must be configured before

communicati-on. The "Transport connection parameters" dialog contains the parame-ters relevant for communication between a PC and an S5 PLC.

S5-CPU progr.

Data handling blocks (HDB type), which establish the connection bet-ween the S5-CPU and the CP, have to be run in an S5 PLC. The HDB types necessary are listed in the charts.

(44)

44

2.3 Phase

1:

Logon

Introduction The effect of logon is that the resources necessary for communication, for example buffers, are provided.

Description Logon is performed from the PC side by the "OPEN_REQ" job. Once completed, the connection can be established.

At the S5 end, logon is follows the PC and CPU startup on condition that the CP has already been configured.

No messages are transmitted on the LAN cable during logon.

Flowchart The following diagram shows a general example of the schematic lay-out of a flowchart for a PC-S5 connection.

OPEN_REQ OPEN_REQ return

Example of a Call Failure during Logon

Logon with regard to a connection may be rejected for several reasons, e.g.:

• resources exhausted or

• request block entries incorrect

Representation of a Failed Call

A failed call during logon is represented by the rb_response ≠ ok_response parameter in the request block returned.

HDB types Parameters of transp. conn. • Job type: • Read/write: • Act/pass: • Priority:

(45)

2.4 Phase 2:

Connection Establishment - Description

Introduction After logging on, the connection must also be established before data exchange is possible.

Description When configuring a communication connection from a PC to an S5 PLC or vice versa, it must be defined which of the communication stations is to establish the connection. The user program is then written in accordance with this definition and the S5 PLC configured accor-dingly.

Among other things, one result of establishing a connection is that memory areas in the transport system are made ready for the expected data exchange.

Restriction The establishment of a connection between a PC and the CP of an S5 PLC or vice versa is mainly determined by the way in which the CP is configured in the S5 PLC.

Reason:

The communication of the CP in the S5 PLC can only be influenced by the variants in the corresponding configuration program. In contrast, the type and sequence of jobs can be freely selected in the PC user program.

Who Establishes the Connection?

The first “current job type” in the CP of the S5 PLC specified during configuration of the connection decides who establishes the connecti-on.

• If the first CP job type is a job of the SEND type, the CP will be the initiator of the connection establishment (active connection

establishment).

• If the first CP job type is a job of the RECEIVE type, the PC will initiate the connection establishment (passive connection establishment).

(46)

46

Example of Duplex Connection

Establishment

The following diagram shows the establishment of a duplex communi-cation connection between a PC and an S5 PLC. If a duplex

con-nection is to be established, two jobs per TSAP must be configured

for the CP of the S5 PLC .

The PC establishes the connection. For this purpose, it transmits a SEND_CONN_REQ job. This corresponds to the RECEIVE job type as the first job for the communication connection in the configuration of the CP. A SEND job must be configured as the second job. This allows the S5 PLC to send and receive on one TSAP.

S5 PLC CP configuration Communication con-nection Jobs Parameters of transp. conn. • Job type: RECEIVE • Read/write: N • Act/pass: P • Priority: 2 PC UP SEND_CONN_REQ Parameters of transp. conn. • Job type: SEND • Read/write: N • Act/pass: P • Priority: 2 1 2

(47)

2.4.1 Connection Establishment - Implementation

Description Following the general description of connection establishment in the last section, this section describes the establishment of a simplex con-nection.

Flowchart; PC as Initiator

The diagram below shows the sequence of connection establishment for a PC-S5 connection; the initiator of the connection establishment is the PC.

SEND_CONN_REQ CR-TPDU CC-TPDU AK-TPDU SEND_CONN_REQ return Flowchart; S5 as Initiator

The diagram below shows the sequence of connection establishment for an S5-PC connection; the initiator of connection establishment is the S5 PLC.

S5 PLC LAN cable PC

S5-CPU progr. CP conf. TS TS UP

AWAIT_CONN_REQ_TRAN CR-TPDU CC-TPDU AK-TPDU AWAIT_CONN_REQ_TRAN return HDB types • RECEIVE DIR and • at least one RECEIVE-ALL Parameters of transp. conn. • Job type: RECEIVE • Read/write: N • Act/pass: P • Priority: 2 HDB types • SEND DIR and • at least one SEND-ALL Parameters of transp. conn. • Job type: SEND • Read/write: N • Act/pass: P • Priority: 2

(48)

48

Abbreviations The following table explains the TPDU abbreviations used in the dia-grams above.

Abbreviatio n

Meaning

CR Connection Request

CC Connect Confirm - positive acknowledgment after establish connection request

(49)

2.4.2 Problems during Connection Establishment, Example 1

Description The communication partner does not exist or does not respond. (The situation in which an S5 PLC does not send an

AWAIT_CONN_REQ_TRAN cannot occur, since this is done when the S5 PLC is turned on.)

The diagram below shows the sequence of an attempted but failed connection establishment; initiator is the PC.

SEND_CONN_REQ CR-TPDU timed repetition CR-TPDU SEND_CONN_REQ return rb_response = loc_timeout

Abbreviations The table below explains the TPDU abbreviations used in the diagram above.

Abbreviation Meaning

(50)

50

2.4.3 Problems during Connection Establishment, Example 2

Description Although the Ethernet/IP address has been entered correctly in the request block by the user program and was specified correctly during CP configuration, TSAP addresses are wrong. The transport system of the S5 PLC therefore rejects connection establishment.

The diagram below shows the sequence of an attempted but failed connection establishment; initiator is the PC.

SEND_CONN_REQ CR-TPDU DR-TPDU SEND_CONN_REQ return rb_response = conn_reject HDB types Parameters of transp. conn. • Job type: RECEIVE • Read/write: N • Act/pass: P • Priority: 2

(51)

Flowchart; S5 PLC as Initiator

The diagram below shows an attempted but failed connection establishment; initiator is the S5 PLC.

AWAIT_CON_REQ_TRAN

CR-TPDU DR-TPDU

Abbreviatio n

Meaning

CR Connection Request

DR Disconnect Request - request to terminate connection and log off or negative acknowledgment of a connect request Parameters of transp. conn. • Job type: SEND • Read/write: N • Act/pass: P • Priority: 2 HDB types

(52)

52

2.5 Phase

3:

Data

Exchange

Introduction After a connection has been established between a PC and an S5 PLC, data exchange can start.

Description Apart from the three universal variants of data exchange, two other variants are described. They support data exchange specifically with an S5 PLC.

Variants for Data Exchange

The following five variants are available for data exchange:

• Variant 1:

Normal Data Exchange

• Variant 2:

Expedited Data Exchange*

• Variant 3:

Normal data exchange with segmented transmission (data distribu-ted over several send jobs).

• Variant 4:

Data Exchange with the WRITE Job type

• Variant 5:

Data Exchange with the READ Job type

* ISO transport only, not TCP/IP

(53)

2.5.1 Data Exchange Variant 1,

Normal Data Exchange

Description Normal Data Exchange is the standard job for transferring data.

Flowchart: PC-S5 Connection

The diagram below shows the sequence of a variant 1 data exchange (normal data exchange) on a PC-S5 connection.

SEND_EOM_DATA DT-TPDU AK-TPDU SEND_EOM_DATA return HDB types • RECEIVE DIR and • at least one RECEIVE-ALL Parameters of transp. conn. • Job type: RECEIVE • Read/write: N • Act/pass: P • Priority: 2

(54)

54

Flowchart; S5-PC Connection

The diagram below shows the sequence of a variant 1 data exchange (normal data exchange) on an S5-PC connection.

RECEIVE_DATA

DT-TPDU AK-TPDU

RECEIVE_DATA return

Abbreviatio n

Meaning

DT Data exchange

AK Acknowledge incoming data Parameters of transp. conn. • Job type: SEND • Read/write: N • Act/pass: P • Priority: 2 HDB types • SEND-DIR and • at least one SEND-ALL

(55)

2.5.2 Data Exchange Variant 2,

Expedited Data Exchange

Description Expedited Data Exchange is used to transfer small amounts of data quickly. This job is only supported by ISO Transport and not by TCP/IP.

Sample Flowchart; PC-S5 Connection

The diagram below shows the sequence of a variant 2 data exchange (expedited data exchange) on a PC-S5 connection.

SEND_EXP_DATA ED-TPDU EA-TPDU SEND_EXP_DATA return HDB types RECEIVE-DIR Parameters of transp. conn. • Job type: RECEIVE • Read/write: N • Act/pass: P • Priority: 0 or 1

(56)

56

Flowchart; S5-PC Connection

The diagram below shows the sequence of a variant 2 data exchange (expedited data exchange) on an S5-PC connection.

RECEIVE_EXP_DATA

ED-TPDU EA-TPDU

RECEIVE_EXP_DATA return

Abbreviatio n

Meaning

ED Expedited Date Exchange

EA Expedited Data Acknowledge for incoming data Parameters of transp. conn. • Job type: SEND • Read/write: N • Act/pass: P • Priority: 0 or 1 HDB types SEND-DIR

(57)

2.5.3 Data Exchange - Variant 3,

Normal Data Exchange with Segmented Transmission

Description The difference between "normal data exchange with segmented transmission" (variant 3) and "normal data exchange" (variant 1) is that the SEND_EOM_DATA job can be preceded by several SEND_DATA jobs; this variant is therefore known as segmented transmission. Data exchange with variant 3 (normal data exchange with segmented transmission), is used if the amount of data to be exchanged cannot be transmitted by the SEND_EOM_DATA job.

Complete Flowchart:

PC-S5 Connection

The diagram below shows the sequence of a variant 3 data exchange (normal data exchange with segmented transmission) on a PC-S5 con-nection.

Apart from the representation of the necessary jobs, the chart contains a "segmented transmission" sub-sequence which can be repeated any number of times.

The "segmented transmission" sub-sequence is described in detail on the following page.

"Segmented transmission" sub-sequence

SEND_EOM_DATA DT-TPDU AK-TPDU SEND_EOM_DATA return HDB types • RECEIVE-DIR and • at least one RECEIVE-ALL Parameters of transp. conn. • Job type: RECEIVE • Read/write: N • Act/pass: P • Priority: 2

(58)

58

"Segmented Transmission" Sub-sequence; PC-S5 Connection

The diagram below shows the sub-sequence of a variant 3 data exchange (normal data exchange with segmented transmission) on a PC-S5 connection.

SEND_DATA

DT-TPDU AK-TPDU

SEND_DATA return

Abbreviatio n

Meaning

DT Data exchange

AK Acknowledge incoming data

HDB types • RECEIVE-DIR and • at least one RECEIVE-ALL Parameters of transp. conn. • Job type: RECEIVE • Read/write: N • Act/pass: P • Priority: 2

(59)

Complete Flowchart:

S5-PC Connection

The diagram below shows the variant 3 data exchange (normal data exchange with segmented transmission) on an S5-PC connection. Apart from the presentation of the necessary jobs, the flowchart con-tains a "segmented transmission" sub-sequence which may be repea-ted any number of times.

The "segmented transmission" sub-sequence is described in detail on the following page.

RECEIVE_DATA

RECEIVE_DATA return RECEIVE_DATA

DT-TPDU AK-TPDU

RECEIVE_DATA return rb_response = ok_eom_resp

Note After a sub-sequence of "segmented transmission", a

"RECEIVE_DATA Return“ is always possible if the receiving transport system (TS) does not have enough buffer space.

In this case, a further RECEIVE_DATA job must be transmitted. Parameters of transp. conn. • Job type: SEND • Read/write: N • Act/pass: P • Priority: 2 HDB types • SEND-DIR and • at least one SEND-ALL

(60)

60

"Segmented Transmission" Sub-sequence; S5-PC Connection

The diagram below shows the sub-sequence in a variant 3 data exchange (normal data exchange with segmented transmission) on an S5-PC connection.

DT-TPDU AK-TPDU

Abbreviation Meaning

DT Data exchange

AK Acknowledge incoming data Parameters of transp. conn. • Job type: SEND • Read/write: N • Act/pass: P • Priority: 2 HDB types • SEND-DIR and • at least one SEND-ALL

(61)

2.5.4 Data Exchange Variant 4,

Data Exchange with the WRITE Job type

Description The data exchange variant 4 (data exchange with the WRITE job ty-pe) differs from data exchange variant 1 (normal data exchange) in that destination parameters in the data buffer "user data 2" are also transferred with SEND_EOM_DATA, so that the receiving S5-PLC communications processor writes directly to the CPU of the S5-PLC. Objects such as inputs and outputs, data blocks, flags and counters can therefore be written to directly.

Flowchart:

The following diagram illustrates the sequence of the data exchange variant 4 (data exchange with the WRITE job type) on a PC-S5 con-nection.

SEND_EOM_DATA with destination parameters

DT-TPDU AK-TPDU SEND_EOM_DATA return RECEIVE_DATA DT-TPDU AK-TPDU RECEIVE_DATA return Flowchart: S5-PC Connection

Objects such as inputs and outputs, data blocks, flags and counters exist only in the S5 PLC, not in the PC. An S5-PC data exchange with the WRITE job type is therefore of no practical use.

HDB types RECEIVE-ALL Parameters of transp. conn. • Job type: RECEIVE • Read/write: J • Act/pass: P • Priority: 2

(62)

62

Abbreviations The table below explains the TPDU abbreviations used in the diagram above.

Abbreviatio n

Meaning

DT Data exchange

(63)

Structure of the Destination Parameters for Sending

The following diagram shows the structure of the data buffer "user data 2“ used for data exchange with the WRITE job type

(SEND_EOM_DATA with destination parameters) in memory when

sending.

The structure of the destination parameters for the WRITE job type can be found in the shipped sample file "S5.H”.

Value to be Entered Description Byte ‘S’ System ID 1 (BYTE) 0 ‘5’ System ID 2 (BYTE) 1

16 Length of the header (BYTE)

2

1 ID of the opcode (BYTE)

3

3 Length of the opcode (BYTE) 4 3 Opcodes (BYTE) 5 3 ORG field (BYTE) 6

8 Length of the ORG field (BYTE)

7

ORG ID (BYTE)

Explanation, see below

8

DB number (BYTE)

Explanation, see below

9

Start address (WORD)

High byte, low byte

10 11

Length (WORD)

High byte, low byte

12 13

FFH Empty field

(BYTE)

14

2 Length of the empty field (BYTE)

(64)

64

Explanation ORG ID

The values to be entered for the ORG ID can be seen in the following table.

Value to be Entered ORG ID Meaning

1 DB Data block 2 FY Flag byte 3 IB Input byte 4 QB Output byte 5 PB Peripheral byte 6 CB Counter cell 7 TB Timer cell

8 RS RS word (system area)

9 AS Absolute start address

AH DX Extended data block (S5-135 U)

10H DE Data block in external memory (S5-150 U)

11H QB Source data from or destination data in peripheral modu-les in the extended peripheral I/O area (S5-150U)

Explanation DB number

The DB number is only entered when the DB will be written; otherwise 0.

(65)

Structure of the Destination Parameters when Receiving

The diagram below shows the structure of the data buffer "user data 2“ used for data exchange with the WRITE job type

(SEND_EOM_DATA-Return with destination parameters) in memory when receiving.

The structure of the destination parameters for the WRITE job type can be found in the shipped sample file "S5.H”.

Value to be Entered Description Byte ‘S’ System ID 1 (BYTE) 0 ‘5’ System ID 2 (BYTE) 1

16 Length of the header (BYTE)

2

1 ID of the opcode (BYTE)

3

3 Length of the opcode (BYTE) 4 4 Opcodes (BYTE) 5 0FH Acknowledgment field (BYTE) 6

3 Length of the acknow-ledgment field (BYTE) 7 Error number (BYTE) 8 FFH Empty field (BYTE) 9

7 Length of the empty field (BYTE) 10 free (BYTE) 11 free (DWORD) 12 13 14 15

(66)

66

2.5.5 Data Exchange Variant 5,

Data Exchange with the READ Job type

Description Data exchange variant 5 (data exchange with the READ job type) dif-fers from data exchange variant 1 (normal data exchange) in that source parameters in the data buffer "user data 2" are sent with the SEND_EOM_DATA send job so that the receiving S5-PLC communi-cations processor reads directly from the CPU of the S5-PLC and re-turns the data. Objects such as inputs and outputs, data blocks, flags and counters can therefore be read out directly.

Flowchart:

The following diagram shows the sequence of data exchange variant 5 (data exchange with the READ job type) on a PC-S5 connection.

SEND_EOM_DATA with source parameters

DT-TPDU AK-TPDU SEND_EOM_DATA return RECEIVE_DATA DT-TPDU AK-TPDU RECEIVE_DATA return Flowchart: S5-PC Connection

Objects such as data blocks, flags, counters and inputs/outputs exist only in the S5 PLC, not in the PC. An S5-PC connection would therefo-re be of no practical value. HDB types SEND-ALL Parameters of transp. conn. • Job type: FETCH • Read/write: J • Act/pass: P • Priority: 2