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

EKI - PTP commands executing too slow

  • Ravnicas
  • January 10, 2022 at 10:46 AM
  • Thread is Unresolved
  • Ravnicas
    Trophies
    3
    Posts
    9
    • January 10, 2022 at 10:46 AM
    • #1

    Hello folks again,

    after setting and getting to know EKI a little bit, i'm having some follow up questions and problems.

    Code
    Robots:
    
    KR C               V8.3.38
    EthernetKRL        2.2.9
    R1Mada             8.3.371

    Problem description:

    The code found below, should start an EKI server, which listens on port 54601.

    After successfull connection the server should execute PTP motions with an advance run of 5 as the data packets come in (as soon as possible).

    The tests with this code were executed while beeing in T1 mode.

    What works:

    Connecting to the server from a PC application. Also sending data packets to the robot and receiving its status with a frequency of 50 hz.

    What doesnt work:

    The robot does receive and also execute its joint space trajectory, and i can see the the EKI buffer variable filling up, but with a severe delay.

    The PC program evaluates the UDP messages with the same frequency as it is sending new packets to the robot. Since the robots message contains the current EKI buffer lenght, im cheking for overflow. The problem is, this variable updates only after several seconds. This results in over 100 packets beeing sent to the robot, before getting an update.

    Even if i ignore the problem above. The execution of PTP motions and the frequency of in which i can see the buffer beeing emptied is closer to 2-5hz. Therefore the behavior is as follows, assuming a trajectory of >100 data points.

    1. PC Program streams >100 joint space poses to the robot and waits for their execution, since only after 2 to 3 seconds the EKI buffer variable is beeing set and the program can stop streaming.

    2. PC waits until the EKI buffer has less than 5 elements.

    3. In this time the robot does "something", while i can see on the PC program that the buffer is beeing emptied slowly.

    4. After a while the robot moves a part of the streamed trajectory.

    5. The cycle repeats.

    I've checked the timer and i would assume it is working correctly since im getting data to the PC, although i dont know how to measure the frequency of timers.

    I've also checked the "package monitor", which doesnt indicate any problems: the execution time of EKI is substantially less than 1ms.

    So the question is: What's happening here? And to some lesser degree, why is EKI behaving as slow as it does?

    Below is the full code, comments removed not to exceed the character limit.

    Code
    &ACCESS RVO
    def  kuka_eki_hw_interface()
    
    
       ; Declarations
       DECL E6AXIS joint_pos_tgt
       DECL INT elements_read
    
       ; INI
       BAS(#initmov, 0)  ; Basic initializasion of axes
    
       ;   Utilized system resources:
       ;     Flags:
       ;       $FLAG[1]:        Indicates active client connection
       ;       $TIMER_flag[1]:  Used to trigger periodic send of robot state
       ;     Interrupts:
       ;       15: Calls EKI_hw_iface_reset() on falling edge of $FLAG[1]
       ;       16: Calls EKI_hw_iface_send() on rising edge of $TIMER_flag[6]
       eki_hw_iface_init()
    
       ; BCO (Block COincidence) run to current position
       ; (requied for below loop continue before first incoming command)
       joint_pos_tgt = $AXIS_ACT
       PTP joint_pos_tgt
    
       ; Loop forever
       $ADVANCE = 5
       loop
          elements_read = EKI_hw_iface_get(joint_pos_tgt)  ; Get new command from buffer if present
          PTP joint_pos_tgt C_PTP                          ; PTP to most recent commanded position
       endloop
    
       ; Note: EKI channels delete on reset or deselect of this program
       ;       See <ENVIRONMENT>Program</ENVIRONMENT> EKI config element
    end
    
    
    
    def eki_hw_iface_init()
       DECL EKI_status EKI_ret
    
       ; Setup interrupts
       ; Interrupt 15 - Connection cleanup on client disconnect
       global interrupt decl 15 when $FLAG[1]==false do eki_hw_iface_reset()
       interrupt on 15
       ; Interrupt 16 - Timer interrupt for periodic state transmission
       global interrupt decl 16 when $TIMER_FLAG[6]==true do eki_hw_iface_send()
       interrupt on 16
       wait sec 0.012          ; Wait for next interpolation cycle
       $TIMER[6] = -200        ; Time in [ms] before first interrupt call
       $TIMER_STOP[6] = false  ; Start timer 1
    
       ; Create and open EKI interface
       EKI_ret = EKI_Init("EkiHwInterface")
       EKI_ret = EKI_Open("EkiHwInterface")
    end
    
    
    
    def eki_hw_iface_send()
       DECL EKI_STATUS eki_ret
    
       if $FLAG[1] then  ; If connection alive
          ; Load state values into xml structure
          ; position
          eki_ret = EKI_SetReal("EkiHwInterface", "RobotState/Pos/@A1", $AXIS_ACT_MEAS.A1)
          eki_ret = EKI_SetReal("EkiHwInterface", "RobotState/Pos/@A2", $AXIS_ACT_MEAS.A2)
          eki_ret = EKI_SetReal("EkiHwInterface", "RobotState/Pos/@A3", $AXIS_ACT_MEAS.A3)
          eki_ret = EKI_SetReal("EkiHwInterface", "RobotState/Pos/@A4", $AXIS_ACT_MEAS.A4)
          eki_ret = EKI_SetReal("EkiHwInterface", "RobotState/Pos/@A5", $AXIS_ACT_MEAS.A5)
          eki_ret = EKI_SetReal("EkiHwInterface", "RobotState/Pos/@A6", $AXIS_ACT_MEAS.A6)
          eki_ret = EKI_SetReal("EkiHwInterface", "RobotState/Pos/@E1", $AXIS_ACT_MEAS.E1)
          ; interface state
          eki_ret = EKI_checkbuffer("EkiHwInterface", "RobotCommand/Pos/@A1")
          eki_ret = EKI_SetInt("EkiHwInterface", "RobotState/RobotCommand/@Size", eki_ret.buff)
    
          ; Send xml structure
          if $FLAG[1] then  ; Make sure connection hasn't died while updating xml structure
             eki_ret = EKI_Send("EkiHwInterface", "RobotState")
          endif
       endif
    
       ; Set timer for next interrupt [ms]
       $TIMER[6] = -10  ; ~10 ms for above send + 10 ms interrupt timer -> ~50 Hz state transmission
    end
    
    
    
    deffct int eki_hw_iface_available()
       DECL EKI_STATUS eki_ret
    
       if not $FLAG[1] then
          return 0
       endif
    
       eki_ret = EKI_CheckBuffer("EkiHwInterface", "RobotCommand/Pos/@A1")
       return eki_ret.buff
    endfct
    
    
    
    ; EKI_hw_iface_get
    ; Tries to read most recent elemnt from buffer. q left unchanged if empty.
    ; Returns number of elements read.
    deffct int eki_hw_iface_get(joint_pos_cmd :out)
       DECL EKI_STATUS eki_ret
       DECL E6AXIS joint_pos_cmd
    
       if not $FLAG[1] then
          return 0
       endif
    
       eki_ret = EKI_CheckBuffer("EkiHwInterface", "RobotCommand/Pos/@A1")
       if eki_ret.buff <= 0 then
         return 0
       endif
       
       eki_ret = EKI_GetReal("EkiHwInterface", "RobotCommand/Pos/@A1", joint_pos_cmd.a1)
       eki_ret = EKI_GetReal("EkiHwInterface", "RobotCommand/Pos/@A2", joint_pos_cmd.a2)
       eki_ret = EKI_GetReal("EkiHwInterface", "RobotCommand/Pos/@A3", joint_pos_cmd.a3)
       eki_ret = EKI_GetReal("EkiHwInterface", "RobotCommand/Pos/@A4", joint_pos_cmd.a4)
       eki_ret = EKI_GetReal("EkiHwInterface", "RobotCommand/Pos/@A5", joint_pos_cmd.a5)
       eki_ret = EKI_GetReal("EkiHwInterface", "RobotCommand/Pos/@A6", joint_pos_cmd.a6)
       eki_ret = EKI_GetReal("EkiHwInterface", "RobotCommand/Pos/@E1", joint_pos_cmd.e1)
       return 1
    endfct
    
    
    
    def EKI_hw_iface_reset()
       DECL EKI_STATUS eki_ret
    
       eki_ret = EKI_Clear("EkiHwInterface")
       eki_ret = EKI_Init("EkiHwInterface")
       eki_ret = EKI_Open("EkiHwInterface")
    end
    Display More
    Code
    &ACCESS RVO
    defdat kuka_eki_hw_interface
       ext bas(bas_command  :in,real  :in )
    enddat
    Code
    <ETHERNETKRL>
       <CONFIGURATION>
          <EXTERNAL>
             <TYPE>Client</TYPE>                  <!-- Users connect as clients -->
          </EXTERNAL>
          <INTERNAL>
             <ENVIRONMENT>Program</ENVIRONMENT>   <!-- Server run via robot interpreter -->
             <BUFFERING Limit="512" />            <!-- Allow buffering of up to 512 messages (system max) -->
             <ALIVE Set_Flag="1" />               <!-- Use $flag[1] to indicate alive/good connection status -->
             <IP>10.100.10.17</IP> <!-- IP address for EKI interface on robot controller (KRC) -->
             <PORT>54601</PORT>                   <!-- Port of EKI interface on robot controller (in [54600, 54615]) -->
             <PROTOCOL>UDP</PROTOCOL>             <!-- Use UDP protocol -->
          </INTERNAL>
       </CONFIGURATION>
    
       <!-- Configured XML structure for data reception (external client to robot)
            <RobotCommand>
               <Pos A1="..." A2="..." A3="..." A4="..." A5="..." A6="..." E1="...">
               </Pos>
            </RobotCommand>
       -->
       <RECEIVE>
          <XML>
             <!-- Joint position command -->
             <ELEMENT Tag="RobotCommand/Pos/@A1" Type="REAL" />
             <ELEMENT Tag="RobotCommand/Pos/@A2" Type="REAL" />
             <ELEMENT Tag="RobotCommand/Pos/@A3" Type="REAL" />
             <ELEMENT Tag="RobotCommand/Pos/@A4" Type="REAL" />
             <ELEMENT Tag="RobotCommand/Pos/@A5" Type="REAL" />
             <ELEMENT Tag="RobotCommand/Pos/@A6" Type="REAL" />
             <ELEMENT Tag="RobotCommand/Pos/@E1" Type="REAL" />
          </XML>
       </RECEIVE>
    
       <!-- Configured XML structure for data transmission (robot to external client)
            <RobotState>
               <Pos A1="..." A2="..." A3="..." A4="..." A5="..." A6="..." E1="...">
               </Pos>
               <Vel A1="..." A2="..." A3="..." A4="..." A5="..." A6="..." E1="...">
               </Vel>
               <Eff A1="..." A2="..." A3="..." A4="..." A5="..." A6="..." E1="...">
               </Eff>
            </RobotState>
       -->
       <SEND>
          <XML>
             <!-- Joint state positions -->
             <ELEMENT Tag="RobotState/Pos/@A1"/>
             <ELEMENT Tag="RobotState/Pos/@A2"/>
             <ELEMENT Tag="RobotState/Pos/@A3"/>
             <ELEMENT Tag="RobotState/Pos/@A4"/>
             <ELEMENT Tag="RobotState/Pos/@A5"/>
             <ELEMENT Tag="RobotState/Pos/@A6"/>
             <ELEMENT Tag="RobotState/Pos/@E1"/>
             <!-- Interface state -->
             <ELEMENT Tag="RobotState/RobotCommand/@Size"/>  <!-- Number of elements currently in command buffer -->
          </XML>
       </SEND>
    </ETHERNETKRL>
    Display More

    Edited 4 times, last by Ravnicas (January 10, 2022 at 10:59 AM).

  • Ravnicas January 10, 2022 at 9:09 PM

    Changed the title of the thread from “EKI working through buffer too slow” to “EKI - PTP commands executing too slow”.
  • Ben014
    Reactions Received
    5
    Trophies
    3
    Posts
    32
    • January 11, 2022 at 4:34 PM
    • #2

    just my thought!

    If you want to have a fast motion response, RSI would be a better option compared to EKI, especially you execute the motion first then get the coordinate from the external devices.

    Not so sure about your application but you can try to send the entire position set first(store them in an array) then execute the motion planning later in a FOR loop. It might help you in this situation.

    Br

  • panic mode
    Reactions Received
    1,280
    Trophies
    11
    Posts
    13,088
    • January 11, 2022 at 8:35 PM
    • #3

    EKI is slow - that is the way it is.

    if you need real time performance use RSI.

    btw you are using same interpreter to stream data and run motions. not sure what your data set is - how dense (close to each other) data points are and what is the rate that those points should be processed at. maybe this can work well if data set is not dense.

    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

  • Online
    SkyeFire
    Reactions Received
    1,052
    Trophies
    12
    Posts
    9,431
    • January 11, 2022 at 11:47 PM
    • #4

    I've never tried using EKI this way, but I have worked on a KUKAbot that used EKI in the SPS to maintain constant background communications with a vision system, exchanging a 128-byte datagram every 250ms without any issues or delays that I ever noticed.

    So what you're trying to do can work, but only if you make each motion large enough that the robot's motion time is greater than the entire communications update period (plus some generous buffer, b/c TCP/IP is prone to packet delays). As others have said, if you want realtime control, you need RSI.

    Just off the cuff, to accomplish what I think you're trying to accomplish, I would consider moving the communications and buffer loading to the SPS, and reduce the main program to something like:

    Code
    DECL INT nArrayIndex
    
    nArrayIndex=1
    
    LOOP
      PTP PositionArray[nArrayIndex] C_PTP ; approximate motion
      nArrayIndex = nArrayIndex+1
      IF nArrayIndex > nArrayIndexMax THEN ; limit check
        nArrayIndexMax = 1 ; rollover
      ENDIF
    ENDLOOP
    Display More

    The SPS would need to fill the array up to a nArrayIndexMax (sized to whatever you DECL the E6POS or E6AXIS array to be), and then start over at 1.

    I would let the SPS handle the communications timing, without interrupts. Assuming a reliable 250ms update rate, and a TCP speed of 2m/s, each move in the buffer would need to be at least 8mm apart for the comm loop to keep ahead of the motion. Of course, you would probably want something more like 20mm.-

  • Ravnicas
    Trophies
    3
    Posts
    9
    • January 12, 2022 at 1:26 PM
    • #5
    Quote from huythai

    just my thought!

    If you want to have a fast motion response, RSI would be a better option compared to EKI, especially you execute the motion first then get the coordinate from the external devices.

    Not so sure about your application but you can try to send the entire position set first(store them in an array) then execute the motion planning later in a FOR loop. It might help you in this situation.

    Br

    I dont need hard real time, and also would prefer not to use RSI if possible.

    Im trying to use ROS in conjunction with EKI, to have a software based controller which lets me follow a trajectory. If i send the entire position set i wont be able to change execution speed, e.g. slowing the robot down if it needs to be.

    Quote from panic mode

    EKI is slow - that is the way it is.

    if you need real time performance use RSI.

    btw you are using same interpreter to stream data and run motions. not sure what your data set is - how dense (close to each other) data points are and what is the rate that those points should be processed at. maybe this can work well if data set is not dense.

    Im not sure i get this right. EKI is slow, maybe, i dont know that, but which part is actually slow?
    It doesnt seem to have any problems transfering the data i want at 50Hz. Thats OK with me.

    I assumed the ADVANCE directive in conjunction with PTP command would allow a blend of each new point, until the trajectory is finished?

    How much is "dense"? At the moment each data point should be approximately sampled at 10Hz, so about 100ms between joint configurations.

    Quote from SkyeFire

    So what you're trying to do can work, but only if you make each motion large enough that the robot's motion time is greater than the entire communications update period (plus some generous buffer, b/c TCP/IP is prone to packet delays). As others have said, if you want realtime control, you need RSI.

    That is more or less the problem i dont quite understand.
    I am already filling up EKIs buffer, so there are enough data points for the robot to execute.

    I also can see the current joint values and the state of EKIs buffer. And i cant see the robot doing any smooth motions. It moves very slowly at the beginning, then executes a part of the streamed trajectory at a reasonable speed, then repeats the slow part.
    And also all of this while i see the buffer beeing emptied very slowly, about 2 to 3 packets per second.

    Even if EKI is slower than RSI and i lose real time control, which part of this limits the performance?

    To be precise, i would like to have precise slow and arbitraraly controllable motions. Slow means in my case about 5 to 10 percent of the maximal possible velocity of my robots (kr120).

  • panic mode
    Reactions Received
    1,280
    Trophies
    11
    Posts
    13,088
    • January 12, 2022 at 3:04 PM
    • #6

    there are still things that are unclear.

    what is the data density - in space and in time domain? without this nobody else can reproduce what you are seeing.

    how does the number of buffered data points changes during execution?

    what metrics are you using to monitor connection and processing? i see no performance counters.

    there is no position arrays, received data stream buffering is handled entirely in EKI read buffer. what happens to buffer when connection is lost? does this happen and how often?

    all streaming is taking place in robot interpreter using interrupts that are firing at high rates . if there are one or two interrupts every 10ms and interpolation cycle is 12ms, what guarantees are there that there is enough resources to do anything else - besides EKI data transfer?

    if the data points are dense (~1mm apart, not 100+ mm apart) and the advance run pointer is at 5, then maximum path length that can be calculated is some 5mm. at such distances robot is going to move very slowly regardless how high acceleration and velocity are set - even if there is no added burden of some 200 interrupts per second. you can try to run test without EKI. just store all data locally in an array and and compare results.

    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

  • Online
    SkyeFire
    Reactions Received
    1,052
    Trophies
    12
    Posts
    9,431
    • January 12, 2022 at 3:33 PM
    • #7

    I'll be blunt -- the level of control you appear to be trying to achieve is better suited to RSI.

    EKI isn't slow, normally, for a single data transaction. But it's not reliably realtime, where RSI is. EKI is vulnerable to delays, dropped packets, and just being a low-priority task on either the server or client ends. EKI simply isn't built to stream reliable realtime control data -- to use a very loose analogy, if EKI is TCP/IP, RSI is UDP.

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

  • KUKA
  • EKI
  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