Skip to end of banner
Go to start of banner

Profinet-V3 - IOCS / IOPS [EN]

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

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 subscriber 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 aid of 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)Bedeutung
0x0No IOxS octet follows
0x1One more IOxS octet follows



Bit 1 to 4:

Reserved


Bit 5 to 6:

Value (hex)Bedeutung
0x0detects inside Subslot
0x1detects inside Slot
0x2detects inside IO-Device
0x3detects inside IO-Controller



Bit 7:

Value (hex)Bedeutung
0x0

Bad:

The data field contains invalid data

0x1

Good:

The data field contains valid data

Applicative 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
	abRecvData[4] = 0x80;
	abRecvData[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
		...
	}
	
	// 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 set "GOOD" (0x80) flag and are transmitted. Reading the process data from the process image requires knowledge of the position of the user data.


  • No labels