Skip to content

Modbus udp server... xconnected is always true even when client is down?

doublec4doublec4
edited December 2021 in PLCnext Technology & PLCnext Controls
Hello, I have two 1152 controllers set up to communicate through MODBUS (downloaded the library on phoenix website). I have UDP activated on both client and server. I am using FC23 block to do a read/write in one shot.

On the client side I am using the fc23.xerror to successfully determine when the server drops off the network. I have the timeout enabled and I believe this is what is triggering the error. It works well.

However, on the server side... it doesn't matter if I initialize the server FB with no client present, or if there is a client present upon initialization, and then it goes offline, the server does not trigger the .xerror bool or the .xconnected bool. The error is always false, the connected is always true. So I am not sure how to detect a lost connection to the client on the server side? Even the error diagnostic codes show that everything is fine. Any ideas?

EDIT: Forgot to mention that I have the auto acknowledge turned off on the server... so it's not even that its the auto ack that is clearing them before I can read the errors.

Thank you

Comments

  • A EllisA Ellis
    Hi.

    The reason is because you are using UDP (which cannot tell if a client is connected, unlike TCP) so the xConnected output actually has a different meaning. See below for output taken from the manual:

    TCP:
    TRUE: The Server is connected to a client.
    UDP:
    TRUE: The Socket of the MB_TCP_Client is open

    So in your case so long as the server is running correctly, the xConnected will always show TRUE.

    I hope this helps.
  • doublec4doublec4
    Hello, yes I did read that in the manual as well, but I guess I misinterpreted that.

    In terms of the xError... why is this not getting triggered if the client is not reading / writing from it within the specified timeout?
  • A EllisA Ellis
    I can tell you how xError should work and hopefully this will help you debug your code. xError only should trigger if there is a timeout between writes. So:

    1. If only reads are occurring, the timeout (and hence the error) will never trigger.
    2. You need to write to a register and then not write again for the timeout period to trigger a timeout error.

    Can you please confirm if the FB works as intended if you write once and then do not write again. Also please double check that you have a timeout time defined on the FB and that this value is not 0 as this disables the timeout monitoring.

    If you have checked both elements and the block is still not timing out, please let us know.
  • doublec4doublec4
    edited December 2021
    That is correct, the FB is still not timing out for me despite reading and writing.

    My client is using FC23 for the read/write to the server. The FC23 block on the client works well and the error bit flips to true.

    On the server this does not seem to work for me. Yes I had defined my timeout at 6 seconds on both client and server. The update time that I run the FC23 on the client side is 2 seconds. I went with roughly 3x the update time for my timeout.

    In the meantime, I have implemented a 'heartbeat' bit through MODBUS so that my server can detect when it is not receiving updates from the client.

    Thank you

    EDIT: Just to clarify , I'm using the MODBUS TCP 9 library, I see now that MODBUS TCP 10 library has been released... not sure if this is still a problem on revision 10
  • Eduard PLCnext TeamEduard PLCnext Team
    edited December 2021
    Hello doublec4,

    the Modbus TCP Client establishes a connection and sends request frames to the Modbus TCP Server. The Modbus TCP-Server processes this request and send the answer to the request back to the Modbus TCP Client.

    You can monitor the connection status on the Modbus TCP Client site via defined timeout setting (monitor the TCP-Server response time).

    The Modbus TCP Server stack is forced to wait for the Modbus TCP connections and "xConnected"-Output should be permanent on "true".

    I assume the following description is not correct:
    UDP:
    TRUE: The Socket of the MB_TCP_Client is open.

    It should be:
    UDP:
    TRUE: The Socket of the MB_TCP_Server is open.

    I'll provide this issue to FB-Development Team to edit the documentation.


    I hope it helps and wish you success with your application.

    BR
    Eduard
Sign In or Register to comment.