Background

With the update of the Profinet Stack from version 2 to version 3, there was a significant change in the handling of the so-called IO Consumer States (IOCS) and IO Provider States (IOPS). So far, the status flags have been checked and handled within the protocol stack, with the new standard this task has been outsourced from the protocol stack for performance reasons. This step was required with the requirement of a minimum bus cycle of 250 microseconds. Responsibility for the status flags was assigned to the application. Now the status flags are mapped into the process image so that the application can access the status values.

Implementation

Basic Terms - Consumer / Provider

In this application note, so-called provider or consumer are mentioned. In principle, the provider is the device who sends the payload, regardless of his role (controller or device). The consumer is thus the one who receives the data.

Provider & Consumer Status-Flags

Each configured module / submodule is assigned a provider and a consumer flag. It is exchanged between the participants via the process image together with the process data. A provider status is always sent in the same send direction as the process data, so it is located in the output image of the DPM and is hung behind the process data of the module. The consumer status is thus sent in the opposite direction to the user data, can therefore be found in the input image of the DPM and is placed above the process data of the next process data block.

The following figure shows the process data images for the input and output data of a sample configuration, respectively. With the module names or the slot indices <Slot_1 ... Slot_n> contained therein, the affiliation of the respective status flags can be determined. The address contained in the list shows with which offset the respective value can be reached on the process image.

The first four status bytes belong to the Device Access Point (DAP) and are integrated into the process image for each bus user. They have the data length of "0". Setting the flags to "GOOD" is mandatory for a successful communication setup.

Interpretation

The content of the data corresponds to a specific encoding.

Note that in case of a certification, the correct treatment of the status values may be necessary.

Bit 0:

Value (hex)	meaning
0x0	No IOxS octet follows
0x1	One more IOxS octet follows

Bit 1 to 4:

Reserved

Bit 5 to 6:

Value (hex)	meaning
0x0	detects inside Subslot
0x1	detects inside Slot
0x2	detects inside IO-Device
0x3	detects inside IO-Controller

Bit 7:

Value (hex)

meaning

0x0

Bad:

The data field contains invalid data

0x1

Good:

The data field contains valid data

Application environment

Selective handling

The respective modules, consisting of the process data block and the status flags, can be considered as one unit. Each unit can be traded selectively. The setting of the status flags thus has a specific effect on the respective module. The release of the process data of a module also requires the setting of certain status flags. This is also to be considered at the initial start of the bus communication:

The header flags on the first four bytes of the process image are mandatory and must be set for the global release of the process image.

The provider status for the corresponding data module, identifiable by the slot number, releases the respective process data.

Example for C/C++

Source-Code

// Array in size of process-image
uint8_t		abRecvData[27] = {0};
uint8_t 	abSendData[22] = {0};
	...
	...
	...
// Set flags of header-states
abSendData[0] = 0x80;
abSendData[1] = 0x80;
abSendData[2] = 0x80;
abSendData[3] = 0x80;

// Do I/O data exchange until a key is hit
while(!kbhit())
{	
	if(CIFX_NO_ERROR != xChannelIORead(hChannel, 0, 0, sizeof(abRecvData), abRecvData, IO_WAIT_TIMEOUT)){
		// ERROR reading IO Data area!
		...
	}
	
	// Consumer-states for incomming data-slots - set to GOOD-Flag when all data could be received completely in
    // in the consumer states in the outgoing image
    abSendData[4] = 0x80;
    abSendData[8] = 0x80;
	
	// check if provider flags from node are GOOD-Flag...
	if(abRecvData[8] != 0x80 || abRecvData[26] != 0x80){
		// Provider status are BAD ... data from node are not persistent
		...
	}

	// check if consumer reports a successful recaiption of the process data
	if(abRecvData[9] != 0x80 || abRecvData[27] != 0x80){
		// Cosumer status are BAD ... data could not receive correct from node
		...
	}
	
	// Handle I/O data-arrays
	... = abRecvData[/* {x: 4 .. 7 } */];
	... = abRecvData[/* {x: 10 .. 25 } */];
	abSendData[/* {x: 5, 6 } */] = ...
	abSendData[/* {x: 9 .. 20 } */] = ...

	// Provider-states for all outging data-slots - set to GOOD-Flag
	abSendData[7] = 0x80;
	abSendData[21] = 0x80;
	
	if(CIFX_NO_ERROR != xChannelIOWrite(hChannel, 0, 0, sizeof(abSendData), abSendData, IO_WAIT_TIMEOUT)){
		// ERROR writing IO data area!
		...
	}
	...
}

IO Monitor

The following figure shows the entire structure of the process image in the IO monitor. All modules are released by the "GOOD" (0x80) flag and are transmitted. Reading the process data from the process image requires knowledge of the position of the user data.

Browser not supported