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 |
---|---|
0x0 | No IOxS octet follows |
0x1 | One more IOxS octet follows |
Bit 1 to 4:
Reserved
Bit 5 to 6:
Value (hex) | Bedeutung |
---|---|
0x0 | detects inside Subslot |
0x1 | detects inside Slot |
0x2 | detects inside IO-Device |
0x3 | detects 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++
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.