Details
Description
We currently have a design flaw in the API with regards to the Connection Indciation in case of pre-consumption timeouts (PCT).
In a PCT-scenario a received ForwardOpen Request is answered by the device with status SUCCESS in the ForwardOpen Response. The device starts producing process data frames on the network and at the same time loads its Inactivity Timer with the pre-consumption timeout value (which typically is 10sec, if RPI x Timeout-Multiplier <= 10secs).
If there is no process data frame received within the pre-consumption time, a timeout occurrs and all connection related resources are cleaned up.
In a PCT-scenario with the current stack implementation, no Connection Indication (cmd 0x1A2E) at all will be generated towards the host application, since the connection is never accounted as ESTABLISHED internally. The transition to ESTABLISHED would instead take place with the first received I/O frame from the originator, which is none for the PCT-scenario.
This contradicts the specification which assumes a connection to be ESTABLISHED after the ForwardOpen Request has been successfully processed.
This acquires special importance when read in conjunction with, e.g., the requirements of the Discrete Output Point Object, which requires transition into a FailSafe-State after any timeout. Since this object is implemented exclusively on the host application level, it's requirement cannot be met.
We have to rework the design/implementation so that the Connection Indication is generated after the ForwardOpen Request has been successfully processed, and the host application subsequently also can take notice of a PCT-scenario by means of a second indication.
This is a behavioral change in the packet API and the impact for the application has to be considered carefully.
Therefore, for the LFW release branch V3.7.0.x, the behavior will be optional and has to be explicitly enabled by means of a new configuration parameter EIP_OBJECT_PRM_ENABLE_NEW_CONNECTION_IND_BEHAVIOR for packet EIP_OBJECT_SET_PARAMETER_REQ. The new behavior will be the default behavior for all Stack version V3.8.0.x and following.
Attachments
Issue Links
- relates to
-
PSEISV3-794 Update to EtherNet/IP Core V3.7.0.11
- Closed
-
PSEISV5-347 Update to EtherNet/IP Core V3.7.0.11
- Closed