Announcement

Collapse
No announcement yet.

Ethernet IP developer problem with Forward Close

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


  • Ethernet IP developer problem with Forward Close

    I am developing a EIP control for our product. I have been using a P1-540 PLC connected to an HMS IEP adapter module. All is going quite well apart from an error that occurs when I issue a Forward Close command for the O->T connection.
    Using wireshark I can see the PLC sending this CIP connect manager packet

    4e 02 20 06 24 01 03 fa 01 00 94 02 eb d3 05 d0

    03 00 20 04 2c 96 2c 64

    which causes the HMS module to respond with General Status == 0x01 and Additional Status == 0x0315 should, for the Connection Manager object, mean "Invalid segment in connection path"

    Now is I use a stand alone PC based program to issue what should be the same close forward command the sent packet looks like this...

    4e 02 20 06 24 01 0a f0 10 6d aa 00 78 56 34 12

    04 00 20 04 24 01 2c 96 2c 64

    and this results in a close "success".

    So it looks like the PLC is sending a Forward Close packet that is mis-formed, or a well-formed alternative which the HMS module does not understand.
    Is this a P1-150 bug that I need to raise an issue for?

    Best Regards
    Q


  • #2
    Can you give us the specific HMS device PN?
    Do you have an EDS file for it?
    Are you configuring this to communicate via Implicit (I/O) messaging or are you using Explicit messaging instructions?
    Thanks!
    - J. Payne
    "Controls make the world go round"

    Comment



    • #3
      Hi
      The module is the ABCC-M40-EIP Article AB6604-C
      I have the EDS file which is generic, I have attached it, I had to change the EDS extension to txt so your upload works.
      Implicit Class 1 connection to assemblies 150 and 100.
      The Forward Open and the cyclic chit chat works like a dream. It is just the Forward Close that the module does not like.
      Thanks Q
      Attached Files

      Comment



      • #4
        Thanks for the additional data. We were able to gather a lot by the packets you provided. We have identified a potential problem that is causing this nuisance error. Based on the eds file you provided, it would appear that config data is not required for your device, so initially we would recommend un-checking the Enable Configuration Data box in the CONGIF DATA tab of the device setup to see if that takes care of this.

        We are continue to look at this to determine what additional is required.
        - J. Payne
        "Controls make the world go round"

        Comment



        • #5
          Thanks
          Unfortunately if I disable the Configuration data it will not connect. With the guide of HMS support I had to enable this but give it an empty message. In other words set Message size to 0. This did sound wrong, but it will not connect without it.
          I have attached 4 'shark dumps (zipped), two with successful connection/open but failed close ( configuration enabled ) two with failed connection ( configuration disabled ).
          Q
          Attached Files

          Comment



          • #6
            Ok, thank you. We're having a hard time finding another device "that cares". We can see the same packet sequence and even the relative nature of the problem, but we have not been able to successfully duplicate what you see. If you don't mind me asking, what is on the other end of the Anybus converter?
            - J. Payne
            "Controls make the world go round"

            Comment



            • #7
              Not at all. It is a motor soft starter developed by our company. The host firmware is written by me and I am responsible for configuring the Anybus module and then servicing the data requests from it. I have been assured by HMS there is no configuration changes I can make that will alter its behavior in terms of solving the problem. It does seem to be hard coded to "care", and I guess I could ask them to get it to stop "caring" but I am sure they will not be happy to do that. Is it possible for you to fix the problem at your end please.
              Last edited by markQ; 01-29-2018, 06:19 AM.

              Comment



              • #8
                We have full intentions of making the change to fix this, we just want to be able to test against a device that exhibits this same behavior before we release a patch.
                - J. Payne
                "Controls make the world go round"

                Comment



                • #9
                  Ah yes, I see your problem and understand why you are asking the questions now. I can not supply you my system but I am very willing to help you in any other way, ie, testing a patch or two.

                  Comment



                  • #10
                    Any news on this fix?
                    Q

                    Comment



                    • #11
                      Originally posted by markQ View Post
                      Any news on this fix?
                      Q
                      I'll send you a message with details.
                      - J. Payne
                      "Controls make the world go round"

                      Comment



                      • #12
                        I am having the same issue with the Cutler Hammer SPX 9000 VFD with the OPTCQ communications card. I can communicate with the drive with most everything except the Productivity PLC's.

                        Mike

                        Comment

                        Working...
                        X