Announcement

Collapse
No announcement yet.

Modbus TCP vs Ethernet IP implicit overhead

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


  • Modbus TCP vs Ethernet IP implicit overhead

    Just curious about how efficient these communication standards are. Is there a reason to chose one over the other when they are both viable options.

    I have been going with Ethernet IP implicit when given the option but am wondering if i should start using more Modbus (i have a device in the field that speaks both and the reliability on Ethernet IP implicit isn't where i would like it to be)


  • #2
    I dont know for sure, but I would imagine both have the same overhead more or less. Both standards run on normal Ethernet cables and switches, which means they must conform to the Ethernet packet standard so the switch can process the data properly. That means you have all the same overhead as a normal Ethernet packet and the data payload of the packet must conform to the same size in all the standards. Now, the size of the data can vary, as packets can range from 64-bytes to 1512-bytes in total size. Jumbo packets are another thing but are rarely used so we dont need to worry about that. Either way, the data can be sent in a variable size within the packet size range, but each packet will still have the same overhead for routing information regardless of the data size inside the packet. Switches can handle packets just fine and sending 100,000 64-byte packets wont really have any difference from sending 100,000 packets of 1512-byte size in performance.

    As for protocol specific data for these industrial protocols, I would bet there are a few extra bytes of "headers" sent as part of the data payload within the packet. This would let the proper Ethernet headers allow the packet to traverse, and the industrial specific info would be regarded as part of the data section. Only the industrial devices would probably know what to do with these sections of the data payload and would probably be configured to know for example the first 32 bytes are additional routing information to tell it which PLC should acknowledge the data and what memory address it goes to. But again, since there is basically no difference between a very small packet and a full size packet as far as performance, changing protocols to adjust between a few additional bytes of routing info within the data payload section wont matter.

    Here is an example of how an Ethernet packet is constructed:
    Click image for larger version  Name:	EthernetPacket.png Views:	1 Size:	26.0 KB ID:	119084


    I would imagine that both industrial protocols have their data for which memory address and what data for that address within the layer 5, which is the data layer. The PLC destination would probably be within the IP layer since these both use IPs for connections.
    edit: I just read that Modbus TCP adds 7 bytes to each packet within the data layer. These control bytes say what the transaction is, the protocol, the length of the data, and the unit for the data. I wouldnt find how many control bytes are added by EtherNet/IP, only that all information is within the data layer.



    If you have reliability problems that is usually due to dropped packets from bad connections, interference in the cables, or bad hardware. Or, a router or other high end switch blocking some of the packets because it is configured improperly and thinks the packets are either bad or malicious. For example, EtherNet/IP uses broadcast UDP type packets. These go out to "every device" on the network, and if your industrial device is set to send a packet every 1 millisecond then a router could perceive this traffic as some form of compromised computer doing a denial of service attack and block its traffic on your network. You know it is a PLC type device sending industrial information, but the router just sees a ton of packets spamming from 1 IP out to the whole network and it trips a rule that is set up to not allow that type and that much traffic. Not saying that IS happening, but it is a possibility. To fix this sort of thing, managed switches are used with IGMP Snooping, which lets the switches on the network snoop into the packet and will only let the broadcast packets through to devices it is intended for. This cuts down on network traffic quite a bit and will help the router not perceive the industrial devices as threats on the network. Rockwell's recommended hardware when using EtherNet/IP is a managed switch with IGMP Snooping.

    In my own situation, I recently had a BRX with an encoder attached to it. I needed to send that encoder value to a DL06 and so I used the extremely handy and awesome instructions built into the BRX to directly send to the DL06 memory address I needed. This worked, but had an issue. I was sending the encoder info every 3 milliseconds, and once in a while the traffic would stop going through all of a sudden. It would cause problems because the DL06 program was running and it would skip sections of the process when the data froze because it never saw that it was at the right encoder count. I figured that I must have something stopping the traffic because it is sending it out so fast and often, so I tried a simple swap from an unmanaged switch to a managed switch and turned IGMP Snoop on, and the problem was solved! No changed in either PLC were done and no other network changes. Simply going from one switch to the other with the necessary feature fixed my traffic blockage right up and the DL06 has never had an issue getting the encoder count every 3ms again. All that to say, you may very well need a managed switch if you use certain kinds of PLC traffic. It can easily cause a communication issue.
    Last edited by MikeN; 11-14-2018, 07:02 PM.

    Comment



    • #3
      Other considerations are reliability and the type of data flow. EIP I/O messaging is repetitive UDP packets, and I'm not sure there is any ack or handshake. This is perfectly fine for I/O data, where the latest data is always the best, but may not be as suitable for a handshake or synchronization between devices. A protocol like Modbus can make that easier.

      Comment



      • #4
        the device i am using Ethernet IP driver just quits running and i have to do a soft reboot to get it to start back up. When i had it set up for Modbus tcp i didn't have these issues. i was just under the impression that Ethernet IP was a more efficient standard and should try to use it if possible.

        Comment



        • #5
          Originally posted by z28z34man View Post
          the device i am using Ethernet IP driver just quits running and i have to do a soft reboot to get it to start back up. When i had it set up for Modbus tcp i didn't have these issues. i was just under the impression that Ethernet IP was a more efficient standard and should try to use it if possible.
          Well if the driver stops and you have to reboot hardware then definitely switch off of it. Never use hardware that has issues running the task it was designed for.

          Comment



          • #6
            Originally posted by MikeN View Post

            Well if the driver stops and you have to reboot hardware then definitely switch off of it. Never use hardware that has issues running the task it was designed for.
            You mean like a P3-550 that fails to work properly? (P3-550 SW 1.9.2.0 FW 1.1.14.39)

            Yesterday the process would function, but not update physical outputs.
            All sequence operations completed normally.
            The output instructions indicated TRUE states. The tasks in question are ALWAYS RUN!
            The physical outputs did not update after a STOP/RUN cycle, but did after a power cycle.

            I have seen this on another P3 as well.
            Last edited by kewakl; 11-15-2018, 06:56 AM.

            Comment



            • #7
              Originally posted by kewakl View Post

              You mean like a P3-550 that fails to work properly? (P3-550 SW 1.9.2.0 FW 1.1.14.39)

              Yesterday the process would function, but not update physical outputs.
              All sequence operations completed normally.
              The output instructions indicated TRUE states. The tasks in question are ALWAYS RUN!
              The physical outputs did not update after a STOP/RUN cycle, but did after a power cycle.

              I have seen this on another P3 as well.
              Ya if the PLC is unreliable in controlling the machine and causing downtime that's lost money. Depending on how much the machine makes per minute you could even eat up the cost of a new PLC in lost product output in even just one day.
              In your case there are other things to try first though. You seem to be having a lot of issues with your P3000(s), but your firmware is 4+ years old. You could always try updating everything and seeing if the behavior gets better.

              Comment



              • #8
                Originally posted by MikeN View Post

                Ya if the PLC is unreliable in controlling the machine and causing downtime that's lost money. Depending on how much the machine makes per minute you could even eat up the cost of a new PLC in lost product output in even just one day.
                In your case there are other things to try first though. You seem to be having a lot of issues with your P3000(s), but your firmware is 4+ years old. You could always try updating everything and seeing if the behavior gets better.
                I don't think that I am up for the easter egg hunt just yet. AND, it is NOT the only CPU that has had these issues! SO I am not sure that it is hardware.

                [EDIT] We do have discussed a timeline for testing new fw/sw. Have to ensure that we dont get bitten by any hidden "features"
                if you know what i mean

                Last edited by kewakl; 11-15-2018, 07:02 PM.

                Comment

                Working...
                X