Announcement

Collapse
No announcement yet.

overworking a DL06 H0-ECOM100 with modbus tcp

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


  • overworking a DL06 H0-ECOM100 with modbus tcp

    We are looking hard at and playing around with a DL06 H0-ECOM100

    Our goal is to be able to communicate with it via MODBUS TCP.

    I've found with my testing here that I'm able to swamp the PLC with modbus requests, and even after I remove the load, the PLC is in a state where all the MODBUS TCP response packets are exceptions. It's as if the PLC never recovers, save powerclearing.

    The responses themselves are curious.
    I send a function 01h (ReadCoils)

    Normally I receive a func. 01h when all is well.
    However I'm receiving a function 81h after I've managed to get the PLC in this state.
    Also the length is 3 instead of the correct 6.

    Also when the PLC gets in this state we can only connect to the PLC from DirectSoft via DirectNET Protocol link, ECOM and K Sequence are unable to connect.

    So basically I'm blasting out MODBUS TCP requests, at such a rate that I am able to get the PLC to choke, and then it never recovers. Granted I probably shouldn't be cramming so many requests, but shouldn't this issue be recoverable for the PLC?


  • #2
    to further clarify the responses I'm getting are

    FunctionCode = 80h +
    ExceptionCode = 04h

    04h seems to be defined as:

    SLAVE DEVICE FAILURE
    An unrecoverable error occurred while the server (or slave) was attempting to perform the requested action.
    [MODBUS Application Protocol Specification V1.1b]

    Comment



    • #3


      if anyone wants to play around with my testprogram.

      http://globalsoftware-inc.com/harncw/ModBusTest.exe

      Comment



      • #4
        upgraded
        from h0ecom100_4_0_224
        to h0ecom100_4_0_227

        at least I'm not seeing a red error light anymore

        the modbus tcp still returns a function >128 with exception code 04

        Comment



        • #5
          Look at FAQ #38
          http://www.hosteng.com/FAQFiles/ECOM.htm#FAQ0038
          and look at the link to the document that maps Modbus Address to the DirectLogic element address.

          The problem may be that your FC 16 is asking for a Modbus Address out of range in your DirectLogic PLC.
          There are 10 kinds of people in this world, those who know binary, and those who do not.

          Comment



          • #6
            Originally posted by franji1 View Post
            Look at FAQ #38
            http://www.hosteng.com/FAQFiles/ECOM.htm#FAQ0038
            and look at the link to the document that maps Modbus Address to the DirectLogic element address.
            Saw that thx, got it printed out on my desk here.

            Originally posted by franji1 View Post
            The problem may be that your FC 16 is asking for a Modbus Address out of range in your DirectLogic PLC.
            All I'm sending are 2 identical requests over and over again.

            Code:
            0000   00 01 00 00 00 87 01 10 02 00 00 40 80 00 00 00
            0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0070   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0080   00 00 00 00 00 00 00 00 00 00 00 00 00
            
            0000   00 02 00 00 00 87 01 10 02 40 00 40 80 00 00 00
            0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0070   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
            0080   00 00 00 00 00 00 00 00 00 00 00 00 00
            And it works! for awhile... it's the quirkyness of "awhile" and the fact that after it dont work it wont until I hit the power... and I've come near to shocking myself several times today pulling the cord from the powerstrip

            At a rate of 200 mbtcp requests per second (Function 16's for 64 words a total length of 135 bytes) , it fails after a few minutes.
            I tested roughly 10 minutes one time and 2 minutes another.

            hmmm I think I maybe sending malformed packets which are bombing the ECOM... need to go more on this manana

            Comment



            • #7
              Have you tried slowing it down?
              "...Specialization is for insects." - Heinlein

              Comment



              • #8
                Originally posted by stimpsonjcat View Post
                Have you tried slowing it down?
                We went into this issue further host engineering's site as well.
                http://forum.hosteng.com/index.php/topic,545.0.html

                IIRC Hosteng expressed a concern that they may have an issue with multiple modbustcp frames in a single tcp packet. It may also be that my network card is sending malformed packets. Either way the H0-ECOM100 is getting borked.

                To answer your original question.

                Yes slowing it down is an option. I'm crashing it by flooding with large requests. Just don't flood it seems to work.
                But then that opens the question of "how much to slow it down by?"
                Also raises the issue of why is it intermittent?

                Comment



                • #9
                  We are currently testing firmware which we believe fixes this issue.

                  The main issue here was multiple requests in a single packet where the last request was split across two packets. The ECOM100 supports multiple requests per packet as long as all the requests are complete. The new firmware will return an error code for the request that was split and ignore any bytes that don't form a valid request. In the process of fixing this, we added code to validate all incoming requests to make sure the request was valid and the data was all there.

                  This firmware will probably be fully tested and released next week (1st week of August 2010).
                  Greg Kiser
                  Hos Engineering, Inc.
                  support@hosteng.com
                  http://forum.hosteng.com
                  This isn't all true.

                  Comment



                  • #10
                    Originally posted by GKiser View Post
                    We are currently testing firmware which we believe fixes this issue.

                    The main issue here was multiple requests in a single packet where the last request was split across two packets. The ECOM100 supports multiple requests per packet as long as all the requests are complete. The new firmware will return an error code for the request that was split and ignore any bytes that don't form a valid request. In the process of fixing this, we added code to validate all incoming requests to make sure the request was valid and the data was all there.

                    This firmware will probably be fully tested and released next week (1st week of August 2010).
                    Thanks for the update!

                    Comment



                    • #11
                      That's fine if HOST engineering wants to allow multiple Modbus messages (called ADU's in Modbus TCP speak) within one TCP frame. It's their product. But...

                      That is a clear cut violation of the Modbus TCP specification. Only 1 Modbus ADU per TCP frame.

                      If this is your application, you may want to re-consider that methodology. I think you'll have problems with most Modbus TCP servers.

                      If you are not doing this on purpose, look at the TCP No delay setting (sometimes referred to as the 'Nagle algorithm'). Setting this incorrectly is usually what causes this issue.

                      Comment



                      • #12
                        Originally posted by jackson View Post
                        That's fine if HOST engineering wants to allow multiple Modbus messages (called ADU's in Modbus TCP speak) within one TCP frame. It's their product. But...

                        That is a clear cut violation of the Modbus TCP specification. Only 1 Modbus ADU per TCP frame.
                        agreed, it is a violation of the spec, although IMHO violating the spec should not cause the ECOMM to get stuck in this erroneous state, pending a power clear.
                        6) A TCP frame must transport only one MODBUS ADU. It is advised against sending multiple MODBUS requests or responses on the same TCP PDU
                        as per MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDE V1.0b

                        Originally posted by jackson View Post
                        If this is your application, you may want to re-consider that methodology. I think you'll have problems with most Modbus TCP servers.

                        If you are not doing this on purpose, look at the TCP No delay setting (sometimes referred to as the 'Nagle algorithm'). Setting this incorrectly is usually what causes this issue.
                        I'll look into fiddling with that flag, thanks for the direction.

                        Comment



                        • #13
                          Originally posted by harncw View Post
                          agreed, it is a violation of the spec, although violating the spec should not cause the ECOMM to get stuck in this erroneous state
                          The issue is that the CLIENT is violating the specification, and the ECOM100 as the SERVER gets HUNG because of this violation. The proposed fix for the ECOM100 SERVER is to
                          1. Not get hung
                          2. reject the badly-formed request(s) by the CLIENT (if it can)
                          There are 10 kinds of people in this world, those who know binary, and those who do not.

                          Comment



                          • #14
                            well since we are all getting in the koolaid here... and since this is such an interesting conundrum

                            Can I argue that the Modbus TCP's specification of "only 1 ADU per frame" is a flawed assumption destined to fail?

                            http://www.drdobbs.com/184416578
                            TCP is based on a stream of bytes — the only thing it guarantees is that the data will be delivered in sequence and error free or you will be notified of an error. Any program that is written with the expectation that TCP will keep application layer messages separate will fail; it's just a question of when.
                            http://www.clarion-software.com/inde...oup=9&id=17778
                            In your case it's not NetTalk that's putting the packets together, but most likely the Winsock layer. There are some OS properties you can tweak to try and manage this, but frankly you shouldn't try. In the real world traffic goes through hubs, switches, routers and all manner of other equipment. And at each place packets can be chopped up, or put together.
                            This is why TCP/IP protocols typically have some way of knowing where a packet starts, and where it ends.
                            I looked into fiddling with my Nagle, but it seems like waving a dead chicken to me.

                            Comment



                            • #15
                              To close out this topic...

                              Host Engineering released an update, that addressed the issue.

                              Good job guys!

                              http://forum.hosteng.com/index.php/topic,545.0.html

                              Comment

                              Working...
                              X