Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Panel | ||||
---|---|---|---|---|
| ||||
How to deal with I&M data? |
Panel | ||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||
OverviewIdentification & Maintenance (I&M) is an integral part of each PROFINET Device implementation. It provides standarized information about a device and its parts. The I&M Information is accessible through PROFINET Record Objects and is always bound to a submodule belonging to the item to be described. An item means here the PROFINET Device itself or a part of this device e.g. a plugable module for modular devices. Submodules can provide own I&M objects or share the I&M objects of other submodules. The I&M objects can be grouped into three kinds of information as described as follows. I&M0 is a read only information which describes the associated item. The following fields are defined:
The I&M1 to I&M4 objects provide a non-volatile storage for PROFINET engineering-related information. This information is typically generated by the engineering software and stored within the objects at engineering time. The information must be stored by the device in non-volatile memory. The objects must be stored physically within the associated item. This means in particular, if a plugable module is removed from one backplane and plugged into another backplane, it must deliver the same I&M1 to I&M4 information as stored before. Finally, the I&M5 record provides information about the PROFINET protocol implementation itself. It is quite similar to I&M0 but describes the PROFINET protocol implementation instead. Thus it is handled by the PROFINET protocol implementation itself. Addtionally to these submodule specific I&M objects each Profinet device must support the global I&M Filter Data object, the so called "I&M0FilterData". This is an read-only object which is used to determine which submodules are associated with dedicated I&M objects. Structure and access paths of I&M objectsThe following figure shows the structural organization of I&M Records within a device and the access paths:
According I&M a submodule can be characterized as follows:
When reading the I&M objects of a submodule the following order is used to deliver the requested data:
In contrast to this, writing I&M1 to I&M4 objects is only possible on the submodules associated with the I&M objects itself. Finally, the I&M0 Filter Data object contains the information which submodules are associated with their own I&M data, which submodules represent their superodinate module and which submodule represents the whole device. This object is global and a read-only object and it is not associated with any submodule. Usage of I&M with Hilscher PROFINET ProtocolThe PROFINET Device protocol implementation of Hilscher supports two modes of operation with I&M. For simple applications the PROFINET protocol implementation provides I&M0 to I&M5 objects within the DAP submodule. In this case the I&M is fully handled by the PROFINET protocol implementation without any interaction with the Application. If a more complex I&M structure is required, the PROFINET protocol implementation can forward I&M accesses to the Application. In this case all I&M objects must be handled by the application. The desired mode of operation is configured using the Set Configuration Service. If the PROFINET protocol implementation is configured to handle the I&M internally, the following parameters will be used within the I&M0 object:
If the application requested to handle the I&M objects, all I&M accesses will be forwarded to the Application using the I&M Read and I&M Write service. For details on the data structures of the I&M services refer to the protocol api. The application must store the data of I&M write services permanently, so that the I&M1 to I&M4 objects and the I&M0 revision counter can be recovered after a power cycle. The I&M0 Filter data structure must be filled by the application with a list of the submodules which are associated with dedicated I&M data. Exactly one of these submodules must be characterized as device representative. Characterization as a module representative is optional and only sensible if the module has more than one submodule. The protocol stack will then internally build up to three lists out of the information provided by the application. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|