KUKA: Effect of Ethernet IP tag link communication on CIP communication

    Hi,

    So i understand the that CIP and normal Ethernet IP communication happens using the same X66 port.

    My question is wouldn't having higher traffic on the same port because of normal tag link communication affect the CIP communication? Or KUKA prioritizes the CIP over tag link and when CIP is present it drops the tag link communication?

    Sorry if the question is too naive

    Regards :smiling_face:

  • Go to Best Answer

    do the math... or check it with Wireshark

    the amount of traffic due to EIP is low. and CIP safety packets are also small and far apart - RPI is some 25ms or so. for Ethernet port those 25ms is an eternity... it can send and receive many messages every millisecond so utilization due to EIP is low.

    in fact so low that same KLI port is used for many things including EKI, RSI, FastSendDriver, windows services (WorkVisual, folder sharing), etc.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    • Best Answer

    It takes a lot of traffic to bog down a ethernet connection, and EIP/CIP (or Profi or EtherCat or ModBus) are deliberately designed around small, tight packets.

    That isn't to say it can't happen -- I recall a certain Major Automaker facility who thought putting everything on the same network (EIP/CIP, e-mail, video conferencing, file servers, etc) on the same network was a great way to save money and avoid having to maintain two separate networks. It... didn't end well.

    In another case, I had a network of about a dozen robots, PLCs, and smart network switches that were using EIP, CIP, and also doing heavy use of EKI, not to mention some RDP into the robots, backups, file transfers, etc. And it worked fine, except that the automated network switches we had bought would completely re-negotiate the network topology every time a node dropped out (say, a robot being rebooted). And that re-negotiation was complicated enough to cause a network timeout on CIP packets at some random device in another, unrelated, part of the production line. But that was a special case, caused by using network switches that were not well-suited to our application.

    You should never see any issues unless you have:

    1. network hardware issues (causing packets losses, say)
    2. Some device(s) on the network that are just spamming really heavy traffic (basically, an unintentional DDoS attack)
    3. Your network gets huge

    #2 and #3 can usually be managed by intelligent network design, and using managed switches that can prioritize time-critical traffic (CIP, EIP) over traffic that can afford to wait an extra hundred ms (SMB, FTP, most TCP/IP, etc).

Advertising from our partners