EthernetKRL connection does not close when submit is deselected

  • I have EKI running in a user defined submit (multi-submit package installed) on a KRC4. I am not sure how to close the connection when deselecting the submit.

    This sometimes causes an error when the submit is selected. Error - Connection is already initialized. I am trying to find a way to check if the connection is initialized before calling EKI_Init(), but I have not found a valid way to check this. IF NOT RET_Init.Connected THEN EKI_Init() also causes an error.

    I will continue looking for a way to check if there is a connection before initializing (maybe with $FLAG[x]...?), but I also want to know how to close the connection when the submit is deselected. It doesn't make sense to leave it open when it is not in use.

    I found some useful information in this thread How to tell if a connection has already been opened in KUKA.EthernetKRL, but I haven't figured out how to implement the suggestions without getting more erros:

    IF RET.Msg_NO==0 THEN...

    IF NOT RET.Connected THEN...

    I checked the EthernetKRL30 documentation as recommended as well, but it only says to "Delete overprogrammed function" to solve the already initialized error. I only have EKI_Init in the program one time. The issue is that it is called more than once when the program is run again. Actually, the issue is that the program does not close when deselected. I would like to handle both issues, but I am a bit stuck.

  • Place your Ad here!
  • you may want to elaborate... what is the configuration? what is the code? is the EKI used as client or server? did you set ENVIRONMENT correctly?

    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

  • Configuration:


    I had to dumb down the code, but this is the basic skeleton of what is happening.

    This service is working. I receive data every time I sendAThing. My main issue seems to be stopping and starting the submit. I want to add error handling, but I am not sure how to achieve this.

  • Where is TCP_Streaming called from? Or do you have it assigned as one of the secondary SPSs?

    Try checking $FLAG[1] instead of EKI_Init.Connected.

    Also, EKI_Init is function call, not a variable. IF NOT EKI_Init.Connected THEN is not a valid instruction.

  • SkyFire and Panic Mode, sorry for the typo in the dummy code, I was adding back in the block of code that caused the error and mistyped in the posted code. It was correct in my original post about the error. The original code did use IF NOT RET_Init.Connected THEN.

    I found a solution to the first error.

    The error was: {%variable} value invalid. Cause: Calling RET_Init.Connected.

    To get rid of this error, I had to Declare and Initialize RET_Init in a .DAT file. I couldn't figure out how to do this before, but here is how I got it working, in case anyone else runs into this issue.


    DECL GLOBAL EKI_STATUS RET_Init = {Buff 0, Read 0, Msg_No 0, Connected FALSE, Counter 0}


    I still would like to know how to tell the EKI connection to close when this submit program is deselected. It seems problematic to leave the connection open while it is not in use. Can this be done with something like an interrupt, or would I have to use another submit to check if this submit is still running and close it from there? That doesn't seem like a real solution.

  • you mentioned that your code tries sending message, then it gets response.

    if your message fails to send you can use this info to close connection.

    but this is only sending...

    also you can have a timer. reset timer every time new message is received. if you stop receiving messages for some time, timer will expire and this can be used to to something.

    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

  • I receive the data in my external program. I am only sending from EKI.

    After testing my application some more, I am still getting the connection already initialized when calling EKI_Init().

    My application Initializes the connection only once at the top of the program. I then open, write, send and close the connection on each loop when there is something to send. When the program is reset, my RET_Init.Connected is FALSE, but the connection is still initialized. This doesn't seem possible. If it is possible, I don't see how I can check if the connection is initialized. I tried IF NOT $FLAG[1] THEN, but $FLAG[1] is only TRUE for a brief second when the program is running, so this still lets me initialize an already initialized connection. I am about to just put ON_ERROR_PROCEED on the EKI_Init() call, but I don't like this as a solution.

  • Code
      IF NOT $FLAG[1] THEN ;Flat[1] is set ALIVE by Config
        IF NOT RET_Init.Connected THEN

    Here are the If statements I am using. I am not sure what else I can check before trying to initialize the connection.

  • If $FLAG[1] isn't True, then the connection isn't open. Period. But that's different from not being initialized.

    You still haven't answered the question of how this program is being called from the SPS, or if it's set up in an SPS of its own. Or how the program gets "de-selected."

    After testing my application some more, I am still getting the connection already initialized when calling EKI_Init().

    And what is the actual code # of this message, and it's exact text? And is this error actually halting the program, or is it just throwing a nuisance informational warning?

    This is from deployed production code using EKI in an SPS, and you'll see it's not really any different than what you're doing:

       IF (InitRet.Msg_No == 0) THEN
          IsInit = TRUE
          IsInit = FALSE
       IsConn = FALSE

    I can't recall EKI_INIT ever throwing a halting state, only EKI_CHECK, and then only if the XML file was buggy. The above code is run every time the robot boots, or the SPS is re-selected, or the connection is lost and triggers an automatic re-connect.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners