1. Home
    1. Dashboard
    2. Search
  2. Forum
    1. Unresolved Threads
    2. Members
      1. Recent Activities
      2. Users Online
      3. Team Members
      4. Search Members
      5. Trophys
  3. Articles
  4. Blog
  5. Videos
  6. Jobs
  7. Shop
    1. Orders
  • Login or register
  • Search
This Thread
  • Everywhere
  • This Thread
  • This Forum
  • Articles
  • Pages
  • Forum
  • Blog Articles
  • Products
  • More Options
  1. Robotforum - Support and discussion community for industrial robots and cobots
  2. Forum
  3. Industrial Robot Support and Discussion Center
  4. KUKA Robot Forum
Your browser does not support videos RoboDK Software for simulation and programming
Visit our Mainsponsor
IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Sponsored Ads

Question about EthernetKRL

  • Daniil1994
  • March 25, 2022 at 8:22 PM
  • Thread is Unresolved
  • Daniil1994
    Reactions Received
    1
    Trophies
    2
    Posts
    14
    • March 25, 2022 at 8:22 PM
    • #1

    Hello,

    I'm working on a project where it's necessary to communicate between Main Control Unit (Just a PC) and KUKA KRC4. For that, Ethernet KRL 2.2 (for KRC4 8.3) package was chosen. Provided EthernetKRL documentation is quite brief, but enough to understand and ensure basic communication.

    My task involves quite intensive communication where MCU acts as server and robot as client. Lets say I have 10 different queries, some of them use binary stream, some XML data option. I use binary stream when robot asks server about some information\data availability (and server request: yes or no). If data\information is available robot reconnects with different configuration file and receives data as XML structure. The difficulty lies in the fact that some requests must occur in parallel, independent of each other, because the requests calls happen in different submits (yeah, multisubmit module). Right now, this system is implemented in the following way -> I have separate sub ("Networking_manager.sub" ;)) which cycles all possible request, checks if this particular type of request is active (they can be activated from different subs), and if it is -> creates connection with proper configuration file, sends request, receives answer from server -> deactivates request ->move to next request type. So, robot constantly bombards the server with requests. Some times it works, but sometimes I receive errors about lost connection. Even if every RET variable returns 0 as result. And so, based on all the information above:

    1. Is it possible to create multiple simultaneous connections from robot to server with EthernetKRL? This would solve the problem like a charm. Documentation states ("...The number of active connections is limited to 16."), but I didn't managed to test is successfully.

    2. In my mind, there is another implementation option. Just make large single request which will contain all smaller requests with their status (active\inactive) and all "answer" data. So robot and MCU can just ping pong this single large data butch, changing necessary parts of it to communicate. Is it good option from your opinion?

    3. How would you implement such communication with Ethernet KRL?

    Thanks in advance!

  • panic mode
    Reactions Received
    1,264
    Trophies
    11
    Posts
    13,031
    • March 26, 2022 at 9:47 PM
    • #2
    Quote from Daniil1994

    1. Is it possible to create multiple simultaneous connections from robot to server with EthernetKRL?

    If i recall correctly Ethernet KRL allows only one server (on the robot side). But in your case server is external, so robot is acting as client. That means (as long as your server support it) you can create several connection to it, either from same or from different robots.

    Quote from Daniil1994

    2. In my mind, there is another implementation option. Just make large single request which will contain all smaller requests with their status (active\inactive) and all "answer" data. So robot and MCU can just ping pong this single large data butch, changing necessary parts of it to communicate. Is it good option from your opinion?

    We do not know your requirements and EthernetKRL documentation does not mention any kind of benchmark info (even for orientation). But there is no such thing as free lunch. The larger the telegram, the longer transmission time and fewer telegrams in same time frame are possible.

    Quote from Daniil1994

    3. How would you implement such communication with Ethernet KRL?

    Well... You read the manual, decide what you need, try to make it work. If you run into issues, solve them one by one or reconsider what is important for you.

    I find EKI documentation and examples not very good. There is a lot left to be desired. Had to spend a lot of time to get things working the way i intended (reconnections, buffering, checking buffer etc.). And it can be slow, specially when using extended submit. Different interpreters have different CPU quotas and extended submits are rather limited.

    Since KUKA really neglected debugging of submit interpreters, i write all code in SRC modules and do all testing and debugging using robot interpreter. When it works to my liking, program can be linked with main or one of extended submits. This also allows evaluation or comparison of performance.

    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

  • Daniil1994
    Reactions Received
    1
    Trophies
    2
    Posts
    14
    • March 28, 2022 at 10:47 AM
    • #3
    Quote

    If i recall correctly Ethernet KRL allows only one server (on the robot side). But in your case server is external, so robot is acting as client. That means (as long as your server support it) you can create several connection to it, either from same or from different robots.

    I'm using src modules to test things first, so sub modules were mentioned to give explanation of planned end system. I have written simple src module which tries to create two simultaneous connections from robot to server. Server is 100% capable to work with multiple connection form single client. Here is src module code:

    Code
    DEF  multi_tcp_connection ( )
        INT i
        DECL EKI_STATUS RET1
        DECL EKI_STATUS RET2
        DECL CHAR inquiry1[64]
        DECL CHAR inquiry2[64]
    
        INTERRUPT DECL 89 WHEN $FLAG[1] == TRUE DO GET_FIRST_DATA()
        INTERRUPT DECL 90 WHEN $FLAG[2] == TRUE DO GET_SECOND_DATA()
        INTERRUPT ON 89
        INTERRUPT ON 90
    
        FOR i=1 TO 64 STEP 1
          inquiry1[i]=0
          inquiry2[i]=0
        ENDFOR
        
        RET1=EKI_Init("Call_to_server1")
        RET2=EKI_Init("Call_to_server2")
        RET1=EKI_Open("Call_to_server1")
        RET2=EKI_Open("Call_to_server2")
        WAIT SEC 0
        
        inquiry1[] = "1 connection test"
        inquiry2[] = "2 connection test"
        $FLAG[1] = FALSE
        $FLAG[2] = FALSE
        RET1=EKI_Send("Call_to_server1", inquiry1[])
        RET2=EKI_Send("Call_to_server2", inquiry2[])
        $FLAG[89] = FALSE
        $FLAG[90] = FALSE
        WAIT SEC 0
        
        WAIT FOR $FLAG[89] AND $FLAG[90]
        
        
        RET1=EKI_Close("Call_to_server")
        RET1=EKI_Clear("Call_to_server")
        RET2=EKI_Close("Call_to_server")
        RET2=EKI_Clear("Call_to_server")
    END
    
    DEF GET_FIRST_DATA()
        DECL EKI_STATUS RET
        DECL INT i
        FOR i=1 TO 64 STEP 1
           echo1[i]=0
        ENDFOR
        RET = EKI_GetString("Call_to_server1", "BufferIn1", echo1[])
        $FLAG[89] = TRUE
        $FLAG[1] = FALSE
    END
    
    DEF GET_SECOND_DATA()
        DECL EKI_STATUS RET
        DECL INT i
        FOR i=1 TO 64 STEP 1
           echo2[i]=0
        ENDFOR
        RET = EKI_GetString("Call_to_server2", "BufferIn2", echo2[])
        $FLAG[90] = TRUE
        $FLAG[2] = FALSE
    END
    Display More

    Here is "Call_to_server1.xml" internals:

    Code
    <ETHERNETKRL>
        <CONFIGURATION>
            <EXTERNAL>
                <IP>172.31.1.140</IP>
                <PORT>59152</PORT>
                <TYPE>Server</TYPE>
            </EXTERNAL>
        </CONFIGURATION>
        <RECEIVE>
            <RAW>
                <ELEMENT Tag="BufferIn1" Type="STREAM" Set_Flag="1" EOS="10"/>
            </RAW>
        </RECEIVE>
        <SEND>
            <RAW>
                <ELEMENT Tag="BufferOut1" Type="STREAM" EOS="10" />
            </RAW>
        </SEND>
    </ETHERNETKRL>
    Display More

    The difference between "Call_to_server1" and "Call_to_server2" are receive flag number (1 or 2) and different names for input and output buffers (with indices 1 or 2). External configuration contains right server connection parameters and they are the same for both configuration files.

    Considering basics of TCP\IP protocol, a connection or "socket" on server side is defined by combination of "Server IP, Server Port, Client IP, Client Port". So any other connection to the same server will have ether different Client IP or Client Port. The Client IP will be the same coz we are connection from the same robot. According to EthernetKRL documentation, we do not have access to port choice if KLI is acting as client, so, I suppose EthernetKRL package manages ports itself. So, in theory, my test program must work. But code gives EKI00023 error at line:

    Code
    RET2=EKI_Init("Call_to_server2")

    what means that - "The Ethernet connection has already been initialized with the function EKI_Init()." And documentation advices me to close active connection before creating new....

    Either, I'm doing something wrong, or it is not possible to make several simultaneous connections from single robot to the same server, even if documentation states it is possible.

    Edited once, last by Daniil1994 (March 28, 2022 at 11:41 AM).

  • Online
    SkyeFire
    Reactions Received
    1,038
    Trophies
    12
    Posts
    9,375
    • March 28, 2022 at 3:33 PM
    • #4
    Quote from Daniil1994

    Either, I'm doing something wrong, or it is not possible to make several simultaneous connections from single robot to the same server, even if documentation states it is possible.

    I'm pretty sure that parallel connections require separate ports for deconfliction.

    Also, in my experience (which is a few versions old now), opening and closing connections rapidly tends to cause errors. You might be better off creating some persistent connections and simply use some error trapping to delete and re-open the connection if/when there's a failure.

  • Daniil1994
    Reactions Received
    1
    Trophies
    2
    Posts
    14
    • March 28, 2022 at 4:12 PM
    • #5
    Quote from SkyeFire

    I'm pretty sure that parallel connections require separate ports for deconfliction.

    Also, in my experience (which is a few versions old now), opening and closing connections rapidly tends to cause errors. You might be better off creating some persistent connections and simply use some error trapping to delete and re-open the connection if/when there's a failure.

    I found a problem. Was not related to software part at all, a switch I used to create LAN network was guilty. So, now I can create up to 16 simultaneous connections as it stated in documentation.

    SkyeFire, how error trapping can be implemented? Through EKI_STATUS value control?

  • Online
    SkyeFire
    Reactions Received
    1,038
    Trophies
    12
    Posts
    9,375
    • March 28, 2022 at 6:36 PM
    • #6

    I'd have to dig out some archives, but IIRC, the SPS loop detected a connection failure by monitoring the $FLAG for the connection status (setup in the XML file), and a timeout on a heartbeat value being passed cyclically between the robot and the remote PC.

    In the event that the $FLAG went False, or a heartbeat timeout occurred, the SPS loop would stop running the EKI_SEND/GET routines, do a ClearBuffer and Delete on the connection, then re-open it.

  • haris.bukhari
    Trophies
    1
    Posts
    2
    • August 8, 2023 at 6:08 PM
    • #7

    Hi Danii
    I am going to work on a project involving simple communication between the KRC and a PC/Laptop. The configuration we are going to use is KRC as server and PC as client. Data exchange will be binary. Is there any update on your project and is there anything that I must look out for?

  • Online
    SkyeFire
    Reactions Received
    1,038
    Trophies
    12
    Posts
    9,375
    • August 8, 2023 at 11:23 PM
    • #8
    Quote from haris.bukhari

    KRC as server and PC as client

    That, by itself, is fairly straightforward, and documented fairly well in the EKI manual. The details are where it gets interesting. What protocol are you planning to use? With what update rate? Foreground or background?

    Quote from haris.bukhari

    Data exchange will be binary

    Any particular reason? ASCII is easier. Also, how much data? Of what kind?

  • Daniil1994
    Reactions Received
    1
    Trophies
    2
    Posts
    14
    • August 9, 2023 at 6:21 PM
    • #9
    Quote from haris.bukhari

    Hi Danii
    I am going to work on a project involving simple communication between the KRC and a PC/Laptop. The configuration we are going to use is KRC as server and PC as client. Data exchange will be binary. Is there any update on your project and is there anything that I must look out for?

    We are using xml data exchange option. Much much simpler, because xml allows to parse data with ease, for both, KRC and external PC. Of course it depends on amount and type of data you would like to send/receive. So SkyeFire asked right questions!

  • haris.bukhari
    Trophies
    1
    Posts
    2
    • August 10, 2023 at 12:15 PM
    • #10
    Quote from SkyeFire

    That, by itself, is fairly straightforward, and documented fairly well in the EKI manual. The details are where it gets interesting. What protocol are you planning to use? With what update rate? Foreground or background?

    Any particular reason? ASCII is easier. Also, how much data? Of what kind?

    Thank you for the response.
    For now the only reason to go for binary was that a previous colleague of mine was working with binary, The amount of data is not too much only the positions and velocities for now. We might add to the data that we are going to get but only at a later stage. For now the update rate has not been decided, but the speed of data acquisition isn't important at this stage. My own opinion was building around using XML instead, which seems to be the preferred choice here as well, so I will discuss this with my team. once we run some tests the data is going to be foreground.

    We are going to use python TCP socket to read the data into our PC as a first test and later on move to a companion PLC/HMI setup ultimately.

    For now we are examining the Manuals and post only if we run into some difficulties.

    Edited 2 times, last by haris.bukhari (August 10, 2023 at 12:37 PM).

Advertising from our partners

IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Advertise in Robotics
Advertise in Robotics

Job Postings

  • Anyware Robotics is hiring!

    yzhou377 February 23, 2025 at 4:54 AM
  • How to see your Job Posting (search or recruit) here in Robot-Forum.com

    Werner Hampel November 18, 2021 at 3:44 PM
Your browser does not support videos RoboDK Software for simulation and programming

Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Thread Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Tags

  • Ethernet KRL
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™
As a registered Member:
* You will see no Google advertising
* You can translate posts into your local language
* You can ask questions or help the community with your knowledge
* You can thank the authors for their help
* You can receive notifications of replies or new topics on request
* We do not sell your data - we promise

JOIN OUR GREAT ROBOTICS COMMUNITY.
Don’t have an account yet? Register yourself now and be a part of our community!
Register Yourself Lost Password
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on Google Play
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on the App Store
Download