Developer Portal Community

    We are moving! We are currently migrating our community to the new Bosch Connected Industry Online Portal. The community will be available latest in the new year again, until then it will be in read-only mode. Click here for more information.

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 
    SOLVED

    OpconTcpServerIpV4 do not update connect state after it send/received hex data from client

    OpconTcpServerIpV4 do not update connect state after it send/received hex data from client

    ZhangJack
    New Poster

    Hello,

      I have a TcpIp server application to comunicate with AGV client, it use Hex data to send/receive data.

      I have found a question that if I send/receive data using hex data(not ascii data),when client interrupt the connection from server, the server connect states do not update ,it still display connected ,and client cannot connect after that.

      I use a TcpIpDebugTool to test ,the question is the same situation.But if I use ascii data to send/recieve ,it will not happen.

    ZhangJack_0-1667270058281.png

     

    1 REPLY 1

    Thorsten_Brach
    New Contributor

    How does the client close the socket?

    Is the socket closed correctly or does the client application simply exit without closing the socket first ?

    I have already observed the behaviour described, but the cause was always, that the client did not close the socket correctly.

    Explanation:
    This is not a problem of the PLC function block - this is a problem of the operating system,
    which binds the socket and does not automatically release it again,
    if the connection was not terminated correctly.

    If the client can tolerate that something is sent from the server to the client without being asked,
    then this can be used to determine whether the socket is still alive.
    If the client is no longer connected, then the sending leads to an error,
    whereupon the server socket can be closed and reopened again.

    But that would only be a workaround - it would be nicer / better,  if the client closes the connection correctly.

    Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist