Announcement

Collapse
No announcement yet.

Modbus TCP/IP support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Modbus TCP/IP support

    Hello Beerygaz,

    I think currectly you only support Modbus RTU over serial and Modbus RTU over TCP/IP.

    Do you have plans to support Modbus TCP.

    ---
    John

    #2
    I'm not sure I follow. The plugin supports TCP encapsulation of the Modbus RTU or ASCII protocol (ok, so ASCII ha snot been implemented because I've seen no demand) which is how the protocol is described. Can you give me more details on what you're looking for, a datasheet/device etc?
    Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

    Comment


      #3
      Hi Beerygaz,

      See the information below. This will explain the difference between Modbus RTU over TCP and Modbus TCP. The difference seems to be minor.

      See also this link for the complete info.

      Modbus RTU over TCP
      Simply put, this is a Modbus RTU message transmitted with a TCP/IP wrapper and sent over a network instead of serial lines. The Server does not have a SlaveID since it uses an IP Address instead.
      Modbus TCP
      A Modbus Messaging Implementation Guide provided by Schneider Automation outlines a modified protocol specifically for use over TCP/IP. The official Modbus specification can be found at www.modbus.org/specs.php . The main differences between Modbus RTU and Modbus TCP are outlined here.
      ADU & PDU
      Aside from the main differences between serial and network connections stated above, there are a few differences in the message content.
      Starting with the Modbus RTU message and removing the SlaveID from the beginning and the CRC from the end results in the PDU, Protocol Data Unit.
      Here is an example of a Modbus RTU request for the content of analog output holding registers # 40108 to 40110 from the slave device with address 17.
      11 03 006B 0003 7687
      11: The SlaveID Address (17 = 11 hex)
      03: The Function Code (read Analog Output Holding Registers)
      006B: The Data Address of the first register requested. (40108-40001 = 107 =6B hex)
      0003: The total number of registers requested. (read 3 registers 40108 to 40110)
      7687: The CRC (cyclic redundancy check) for error checking.
      Removing the SlaveID and CRC gives the PDU:
      03 006B 0003
      MBAP Header
      A new 7-byte header called the MBAP header (Modbus Application Header) is added to the start of the message. This header has the following data:
      Transaction Identifier: 2 bytes set by the Client to uniquely identify each request. These bytes are echoed by the Server since its responses may not be received in the same order as the requests.
      Protocol Identifier: 2 bytes set by the Client, always = 00 00
      Length: 2 bytes identifying the number of bytes in the message to follow.
      Unit Identifier: 1 byte set by the Client and echoed by the Server for identification of a remote slave connected on a serial line or on other buses.

      Summary
      The equivalent request to this Modbus RTU example
      11 03 006B 0003 7687
      in Modbus TCP is:
      0001 0000 0006 11 03 006B 0003
      0001: Transaction Identifier
      0000: Protocol Identifier
      0006: Message Length (6 bytes to follow)
      11: The Unit Identifier (17 = 11 hex)
      03: The Function Code (read Analog Output Holding Registers)
      006B: The Data Address of the first register requested. (40108-40001 = 107 =6B hex)
      0003: The total number of registers requested. (read 3 registers 40108 to 40110)


      ---
      John

      Comment


        #4
        Hi Beerygaz,

        This evening I performed a Factory Acceptance Test (FAT) on my to be delivered Modbus device. A t is a custom build project we were able to make some changes to the protocol settings (changed to Modbus RTU over TCP/IP) and the communication is successful.

        Nevertheless I think Modbus TCP/IP is the protocol that will be used more often in the future (based on a search on the internet).

        A look at Modbus Poll showed that the following protocol variants are supported
        • Modbus RTU
        • Modbus ASCII
        • Modbus TCP/IP
        • Modbus RTU Over TCP/IP
        • Modbus ASCII Over TCP/IP
        • Modbus UDP/IP
        • Modbus RTU Over UDP/IP
        • Modbus ASCII Over UDP/IP


        Looking closer to all protocols I think there is no need for the protocols indicated in red. But it will be helpfull if all other protocols are supported to make the PI future proof.

        ---
        John

        Comment


          #5
          John I've looked into this and I can implement the additional protocols but it will take a change of underlying architecture and quite some investment of time. Given there are only 3 modbus clients out there using the plugin it's hard to justify the investment I'm afraid.


          Sent from my iPhone using Tapatalk
          Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

          Comment


            #6
            Originally posted by beerygaz View Post
            John I've looked into this and I can implement the additional protocols but it will take a change of underlying architecture and quite some investment of time. Given there are only 3 modbus clients out there using the plugin it's hard to justify the investment I'm afraid.


            Sent from my iPhone using Tapatalk


            Hi beerygaz,

            As mentioned there is currently no need for me.

            3 modbus clients is not much. I use your plugin at the moment for four devices. It is a very popular protocol in building management systems and industrial automation.

            ---
            John


            Sent from my iPhone using Tapatalk

            Comment


              #7
              John I appreciate your enthusiasm and support. As soon as I have the time available I will extend support for pure TCP and some other enhancements I have in mind for improved performance. I'm not discontinuing support at all it just needs to be a function of demand.

              Gaz


              Sent from my iPhone using Tapatalk
              Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

              Comment


                #8
                Originally posted by beerygaz View Post
                John I appreciate your enthusiasm and support. As soon as I have the time available I will extend support for pure TCP and some other enhancements I have in mind for improved performance. I'm not discontinuing support at all it just needs to be a function of demand.

                Gaz


                Sent from my iPhone using Tapatalk
                Hi Beerygaz,

                I agree that adding functionality based on demand is the best way to do.

                Currently I have no demand for the pure TCP support.

                Are you also still looking to the CAPI handler issue. It is more user friendly if I can change a value by an event. Currently I created several scripts as workaround.

                Which enhancements do you have in mind. Currently the PI fit my needs.

                ---
                John

                Comment

                Working...
                X