PD 667 Profibus – System notes

Index:

PD 667 integration in the P-NET system
Mapping of Profibus DP data into the P-NET system
Mapping of Profibus DP data into VIGO
Profibus DP basics

PD 667 integration in the P-NET system

The PD 667 driver controls the data exchange between the DP_Slaves I/O area and the Profibus slaves.

The data in the DP_Slaves I/O area are accessible by any P-NET device via the Light-Link port. The devices in the P-NET system can read or write any data in the DP-Slaves I/O area and by so doing read inputs from all Profibus devices and also send outputs to them.

Mapping of Profibus DP data into the P-NET system

The DP_Slaves I/O data is an array of bytes. In this array, some of the bytes may together form another data type; e.g. a word, a real, a Bit8, a Bit16 etc.

The Profibus slave documentation should contain a description of the data types and the layout of the data input and output arrays.

With the Profibus slave documentation, it is possible to create a "P-NET overlay" for the array, allowing individual data in the array to be accessed by P-NET as normal P-NET variables through this overlay.

Principle of data mapping:

Application DPI's on the P-NET can access the in the PD 667 in different ways:

Individual data (e.g. word, real) are mapped by a pointer to the specific position in the byte array. Example.

A record structure is mapped by a pointer to the specific area of the array it is representing. This allows access to the individual data in the array or to the record as a whole. Example.

A variant record is declared in the application DPI. The application DPI reads the number of bytes into a equivalent array in the application DPI and by a variant record individual data can be access in this copy of the PD 667 array.

Individual data mapping:

Each data is declared in the application DPI as a pointer to the slave_IO array by the use of NodeList and PointerToNode.

Example:

Var
	Temperature : Pointer to Real

Begin
NodeList[1].Code := 32; (* Capabilities of PD 667 *)
NodeList[1].NodeAddr[0] := char(2); (* path size: 2 *)
NodeList[1].NodeAddr[1] := char(2); (* Port = 2 *)
NodeList[1].NodeAddr[2] := char(1); (* P-NET address = 1 *)
Temperature -> PointerToNode(1,400,625);
IF Temperature > 34.3 Then ..... (* Access the data *)
End;

NodeList element 1 is used. "400" is the Softwire number for the DP_slaves array. "625" is the offset address in the DP_slaves array for first byte in this data.

Record data mapping:

A record is declared in the application DPI as a pointer to the Slave_IO arrray by use of NodeList and PointerToNode. Each data in the record or the record as a whole can be accessed.

Example:

Type
	SlaveRecordType = Record
			Speed : Word;
			Temperature : Real;
			Status : Byte;
			Direction : Byte;
			Frequency : LongInteger;
		End;
Var
	SlaveRec : Pointer to SlaveRecordType;

Begin
NodeList[1].Code := 32; (* Capabilities of PD 667 *)
NodeList[1].NodeAddr[0] := char(2); (* path size: 2 *)
NodeList[1].NodeAddr[1] := char(2); (* Port = 2 *)
NodeList[1].NodeAddr[2] := char(1); (* P-NET address = 1 *)
SlaveRec -> PointerToNode(1,400,623);
IF SlaveRec.Temperature > 34.3 Then ..... (* Access one data *)
End;

NodeList element 1 is used. "400" is the Softwire number for the DP_slaves array. 623 is the offset address in the DP_slaves array for first byte in this record.

To minimize traffic on the P-NET it may be more efficient to read or write the entire record in one instruction and store the copy in the application DPI. Access to the individual data is then done into the copy, instead of a P-NET communication for access to each data.

Example:

Type
	SlaveRecordType = Record
			Speed : Word;
			Temperature : Real;
			Status : Byte;
			Direction : Byte;
			Frequency : LongInteger;
		End;
Var
	SlaveRec : Pointer to SlaveRecordType;
	SlaveRecCopy : SlaveRecordType;

Begin
NodeList[1].Code := 32; (* Capabilities of PD 667 *)
NodeList[1].NodeAddr[0] := char(2); (* path size: 2 *)
NodeList[1].NodeAddr[1] := char(2); (* Port = 2 *)
NodeList[1].NodeAddr[2] := char(1); (* P-NET address = 1 *)
SlaveRec -> PointerToNode(1,400,623);
SlaveRecCopy := SlaveRec; (* Read the full record *)
(* Access one data in the local copy *) IF SlaveRecCopy.Temperature > 34.3 Then .....
End;

NodeList element 1 is used. "400" is the Softwire number for the DP_slaves array. 623 is the offset address in the DP_slaves array for first byte in this record.

Note:

Each data in a record always starts with an even offset address, except bytes that can be placed at both even and odd offset addresses. This may create "gaps" in the overlay record structure that makes it different from the array structure it should represent.

It is thus not possible to declare a record like: "Byte, Real, Byte, Word", as the Real will be placed at offset 2 and the Word at offset 8. The overlay will then no longer match the structure of the original data.

The first byte in an array is at offset 0, the second byte at offset 1, etc.

Access to data at odd addresses is done be declaring and communicate each variable individually. In the application DPI each variable is declared with a softwire number and an offset into to DP 667.

Alternative method:

In the application DPI, declare a variable as a variant with a parallel array of the same size, and then transfer each byte one by one into the array. The parallel variable (the Real) can then be accessed as usual.

Bit8 types must be converted into Process-Pascal type as:

Var
	Bitrow : Bit8;

Bitrow := Convert(DP_Slaves.Input[x]);

Bit16 (and Bit32) types must be converted into Process-Pascal type as:

Var
	Bitrow : Bit16;

(* The 2 bytes are declared as a word: *)
Bitrow := Convert(DP_Slaves.InputBit1Word);

When converting a value that is not declared with a type, it is necessary to inform the Process-Pascal complier about the type of the variable (type cast).

This is used e.g. to initialize a variable:

OutPut_16 := Convert(word (0));

Mapping of Profibus DP data into VIGO

In the same way as mapping Profibus DP data into a P-NET system, it is possible to define a data overlay in VIGO.

A VIGO overlay allows structured access into the raw Profibus I/O byte arrays.

The VIGO overlay enables structured data access for VIGO and Visual VIGO.

In VIGO, each data is defined by its SoftWire number, Offset address and Data type.

The offset address can be an even or odd address. Thus by the VIGO mapping (as opposed to Process-Pascal mapping), it is possible to access a data placed at an odd address.

In the PD 667 Sub MIB, VIGO overlays for ProfiDrive PPO1 to PPO8 are defined. The user can create new device I/O types by use of MIB Edit.

All I/O types must be defined with I/O data offset calculated as slave[1].

Slaves, for whom a mapping is required, must be listed in the VIGO_IO_MAPS record with the corresponding type definition. When including the I/O mapping type into the VIGO_IO_MAPS, an offset value for each I/O type moves the mapping defined as slave 1 to the memory position of the actual slave's I/O arrays.

All I/O mapping types in VIGO have "IO_" as the first 3 letters in the type name.

Mapping I/O data does not change the standard layout of the DP_Slaves record. All I/O mapping is made in parallel with the standard structure, allowing access of data both ways.

Example:

Step 1. Define a layout type for the specific data I/O:

In the PPO5 type, it defines all the I/O data for the VLT.

Each data offset is declared according to its offset regarded as slave 1.

For each data the appropriate type is selected.

The StatusWord (byte 9 in the Input array) is at offset 418 relative to the slave record start.

Step 2. Create a slave and link it to the type. Set offset to the specific slave:

VIGO_slaves_record contains a list of all slave devices for which an I/O data mapping is required.

The slave record of this particular slave starts at offset 1206.

The resulting address of the VLT2800_2's Statusword is:

Offset: 1206+418= 1624.

Step 3. Create an instance of the slave record type:

The VIGO_IO_maps is created as a softwire object with the VIGO_slaves_record as its type.

VIGO_IO_map is mapped to the DP_Slaves array at

SW No.: 400.

Step 4. Access the data thought the mapping:

The data is now ready to be accessed in MIB View:

· Select VIGO_IO_MAPS

· Select VLT2800_2

· Select StatusWord

· Select Bit_2

· Value of the bit is 'false'.

Note:

Using a Bit16 or Bit32 type will result in the low and high bytes being swapped when displayed in VIGO.

Profibus DP basics:

Profibus DP is a master / slave field bus. Only the master is allowed to initiate a communication.

The master cyclically polls all slaves. For each poll the output and input data are transferred.

When initiating a connection, the master and the slave have to agree on the communication setup. When this is done and accepted, the slave enters Data Exchange mode.

Data exchange:

In data exchange mode, the master transfers an array of bytes from the master to the slave (Output) and reads an array of bytes from the slave (Input).

Input and Output arrays can be from 0 to 244 bytes. Input and Output arrays don't need to be of the same size.

The size of Input and Output array for each slave is fixed by the configuration. Thus the master always exchanges the same size of data with that slave.

Profibus does not specify any structure of the data in the array - it merely transfers the data.

It is a part of the slave specification to describe the layout of the input and output data.

The slave may offer the master different data layouts (with different sizes) to choose between, depending on how it wants to control the slave, or depending on the configuration of the slave. Again, once the master is setup to use a specific configuration (I/O definition), it is fixed to this until the user changes the configuration setup in the master.

Examples:

If the slave is a modular I/O rack, the number and order of the data depends on the number of I/O modules in the rack.

If the slave is a frequency converter (Drive) it may use the Profibus standard for drives called "ProfiDrive". ProfiDrive specifies some fixed data layouts called PPO's.

The user selects a PPO depending on how many data the user wants to be able to exchange with the drive, and depending on how advanced a control for the drive is required.

To implement a general data access protocol in Profibus DP, slaves often use a few I/O bytes for a read / write service that can address data outside of the cyclic data area.

The syntax of this is slave specific.

This function is often named as: mail box system / command system / PCA handling / Request-response handling etc.

Diagnosis:

When in Data exchange, the slave response may include a signal to the master that the slave contains some diagnostic data that it wants the master to read. In the next scan the master will request the diagnostic data. The layout of the diagnostic data can be user defined or follow the Profibus specification. The master is allowed to request the diagnostic information from the slave at any time, even when no "read diagnosis request" is active in the slave.

Parameters:

When initiating a connection, the master may send an array of user specified parameter bytes to the slave.

Parameters are constants stored in the master, and are always transferred to the slave before entering data exchange. Parameters can be used as setup definitions for the slave. By storing them in the master, the slave does not need memory to permanently store setup data. Further, the user does not need to have configuration tools for each slave type; they are all setup by configuring the master.

Parameters may be linked to the data I/O definitions to describe the format of I/O etc. of each data.

Examples:

The master wants to read 4 bytes of input. By means of a specific parameter byte it is specified wether the value in the 4 bytes should be sent to the master as a Real or a LongInteger or a LongInteger x 10 or a LongInteger x 100 etc.

A specific parameter is used to set up a filter in the slave. Depending on the value of the parameter, the slave configures its input filter.

If the slave is a modular I/O system, parameters are used to inform the slave of the order of modules, what mode the different I/O channels should operate in, scaling, alarm limits etc.

Profibus does not specify any layout of the parameter data. The data is merely transferred to the slave. In the slave documentation, it must be specified how to create the parameters.