How to tell if a connection has already been opened in KUKA.EthernetKRL

RoboticsMan · April 6, 2021 at 4:34 PM

Hi

I have the following problem:

I am using a robot with KRC4 and KUKA.EthernetKRL 2.2.

We have made an API on the robot for our vision system. The first time our Init() command is called, we establish a command to the PC that runs the vision software. However, the Init() command may have to be called again, with different parameters. If we try to establish a connection, and one has already been established, then we get an error. I don't want that. If we try to close the connection before opening a new one, then we also get an error, if no connection has been established yet (i.e. first time the command is called). I also don't want that.

This problem could be avoided if there was some way to ask the KUKA software whether a connection has already been established. This does not seem to be the case. Or am I missing something?

We are also using our software with KRC2 robots. In the older versions of KUKA.EthernetKRL it is possible to call the command for closing a connection, and it gives no error message even if no connection is open. This is the behavior I want!

I know I could just restructure our API and add a specific command for opening a connection once in the beginning, but I would rather not do that.

So: Is it in some way possible to ask the KUKA.EthernetKRL software whether a connection is already open? If so, then can just skip opening it again.

I have tried to suppress the error messages from the EthernetKRL software by adding this to the xml file that configures the communication:

</INTERNAL>

But this does not seem to work.

Thanks in advance for any tips!

/RoboticsMan

**panic mode** · April 6, 2021 at 7:56 PM

are you evaluating EKI_STATUS and ALIVE flag?

**panic mode** · April 6, 2021 at 7:58 PM

i let EKI log everything but not display messages (because i prefer my own):

RoboticsMan · April 7, 2021 at 11:48 AM

Quote from panic mode

are you evaluating EKI_STATUS and ALIVE flag?

To evaluate the EKI_STATUS value, I guess that I would have to call a command that returns the value? The problem is that I get the error message when I call the commands, so I never get to evaluate the return value. I thought these messages could be suppressed via the setting in the XML file, but this does not seem to work.

I also thought about using the ALIVE flag, since it turns out we have used it before. In the end I ended up monitoring the $PRO_STATE1 variable in the SPS instead, to see if the program has been reset since the last time a connection was established. In that way I only try to open a connection if there was a program reset since the last connection. The good thing about that solution is that it works just as fine on KRC2. But thanks for the reply anyways!

/RoboticsMan

**panic mode** · April 7, 2021 at 2:50 PM

why i recommend reading pinned topic READ FIRST and posting some details. such as how to reproduce problem.

"we get an error..." is not specific...

i would say post your code sample, configuration, state exactly what the message as is etc.

RoboticsMan · April 7, 2021 at 3:51 PM

Quote from panic mode

why i recommend reading pinned topic READ FIRST and posting some details. such as how to reproduce problem.
"we get an error..." is not specific...
i would say post your code sample, configuration, state exactly what the message as is etc.

Yes, you are right. There was not enough info. Even though I already found a workaround for the problem, I made some code to reproduce the problem, so that I could get the exact error message.

Test case 1: Messages are not suppressed. I try to open a connection twice

Code

DECL EKI_STATUS RET_VAL

RET_VAL = EKI_INIT("TEST_COM")
RET_VAL = EKI_OPEN("TEST_COM")
RET_VAL = EKI_INIT("TEST_COM")
RET_VAL = EKI_OPEN("TEST_COM")

Then I will get the error "EKI00023: Initialization already performed"

Test case 2: Messages are not suppressed. I try to close a connection without opening it first.

Code

DECL EKI_STATUS RET_VAL

RET_VAL = EKI_CLOSE("TEST_COM")
RET_VAL = EKI_CLEAR("TEST_COM")

This results in error "EKI00009: Connection not available"

Test case 3: Messages are suppressed with <MESSAGES Logging="enabled" Display="disabled"/>. I try to open a connection twice, same code as in case 1. This time there is no error message.

Test case 4: Messages are suppressed with <MESSAGES Logging="enabled" Display="disabled"/>. I try to close a connection, even though it wasn't opened first. Same code as in case 2. Same error message as in case 2.

So suppressing the error message only seems to work when opening a channel, not when closing it.

KSS version is 8.3.27, EthernetKRL version is 2.2.7

I am no longer looking for a solution, but maybe this info can be useful to someone else.

/RoboticsMan

**SkyeFire** · April 7, 2021 at 4:01 PM

The "Alive" flag that Panic refers to is part of your EKI channel XML file -- you can assign an $OUT or $FLAG to reflect that status of the channel. This is in the EKI manuals.

Code

<ETHERNETKRL>
    <CONFIGURATION>
        <EXTERNAL>
            <IP>172.20.1.61</IP>
            <PORT>59152</PORT>
        </EXTERNAL>
        <INTERNAL>
            <ENVIRONMENT>Program</ENVIRONMENT>
            <BUFFERING Mode="FIFO" Limit="16"/>
            <TIMEOUT Connect="5000"/>
            <ALIVE Set_Flag="1"/>
            <PROTOCOL>TCP</PROTOCOL>
            <MESSAGES Logging="error" Display="disabled"/>
        </INTERNAL>
    </CONFIGURATION>
    <RECEIVE>
        <XML>
            <ELEMENT Tag="Server/@Recipient" Type="STRING"/>
            <ELEMENT Tag="Server/@Sender" Type="STRING"/>
            <ELEMENT Tag="Server/Command/@Handle" Type="INT"/>
            <ELEMENT Tag="Server/Command/@Name" Type="STRING"/>
            <ELEMENT Tag="Server/Command/Status/@Message" Type="STRING"/>
            <ELEMENT Tag="Server/Command/Status/@Code" Type="INT"/>            
            <ELEMENT Tag="Server" Set_Flag="22"/>
      </XML>
    </RECEIVE>
    <SEND>
        <XML>
            <ELEMENT Tag="Host/@Recipient"/>
            <ELEMENT Tag="Host/@Sender"/>
            <ELEMENT Tag="Host/Command/@Handle"/>
            <ELEMENT Tag="Host/Command/@Name"/>
            <ELEMENT Tag="Host/Command/Parameters/Param1/@Name"/>
            <ELEMENT Tag="Host/Command/Parameters/Param1/@Value"/>
            <ELEMENT Tag="Host/Command/Parameters/Param1/@Type"/>            
        </XML>
    </SEND>
</ETHERNETKRL>

Display More

RoboticsMan · April 7, 2021 at 4:15 PM

Quote from SkyeFire

The "Alive" flag that Panic refers to is part of your EKI channel XML file -- you can assign an $OUT or $FLAG to reflect that status of the channel. This is in the EKI manuals.

Yes, I also considered that, but in the end I decided for another solution. But now that we talk about it: Is the alive flag always up to date, even before a connection is established in first case?

/RoboticsMan

**panic mode** · April 7, 2021 at 4:42 PM

you write code that initializes EKI, opens channel etc. all of them are writing to a variable you named RET_VAL but ... you never evaluate it. i see nothing in your code that checks what is in the RET_VAL. you are just following examples from EKI manual... which are very crude... they do not use things like

IF RET.Msg_NO==0 THEN...

IF NOT RET.Connected THEN...

also manual keeps reusing same RET variable. that is not good because very next command is going to overwrite the RET value. hence later you cannot know if specific instruction such as INIT() was ok or not. you can reuse same RET but should evaluate it and handle any problem immediately... after every instruction. also nothing stops you to keep track of status using own variables.

and finally you are using EKI2.2

and while you are not into reading manuals, that manual is incomplete, it lacks info messages for example.

as always with KUKA... when things are not doing what you want... check other manuals (newer or older) and you may find what you are after.

try manual for EKI 3.0 ...

RoboticsMan · April 7, 2021 at 6:46 PM

Quote from panic mode

you write code that initializes EKI, opens channel etc. all of them are writing to a variable you named RET_VAL but ... you never evaluate it. i see nothing in your code that checks what is in the RET_VAL. you are just following examples from EKI manual... which are very crude... they do not use things like
IF RET.Msg_NO==0 THEN...
IF NOT RET.Connected THEN...
also manual keeps reusing same RET variable. that is not good because very next command is going to overwrite the RET value.

Yes, I know that I don't evaluate the result, but that is irrelevant for this example, since the error message that I could not suppress is shown from within EKI_CLOSE().

As I wrote earlier: "The problem is that I get the error message when I call the commands, so I never get to evaluate the return value. "

I could evaluate the result all I want, but that doesn't change that the user would still have to acknowledge the message on the KCP first, and that is what I wanted to avoid

Quote from panic mode

and finally you are using EKI2.2
and while you are not into reading manuals, that manual is incomplete, it lacks info messages for example.
as always with KUKA... when things are not doing what you want... check other manuals (newer or older) and you may find what you are after.
try manual for EKI 3.0 ...

I think it would be a natural assumption that the manual for EKI2.2 would be valid for EKI2.2, and the manual for EKI3.0 would be valid for EKI3.0 and that the 3.0 manual might even be misleading for EKI2.2 . But alright, I learned something new today then. I will keep it in mind.

/RoboticsMan

**panic mode** · April 7, 2021 at 6:53 PM

Quote

"The problem is that I get the error message when I call the commands, so I never get to evaluate the return value. "

of course.... should keep track of things and evaluate previous one. then decide how to proceed...do not call the command that will create the fault

**panic mode** · April 7, 2021 at 6:58 PM

just FYI, i am using EKI right now and it is working without issue for quite some time on a headless unit (no smartPad connected). and i chose to make it auto reconnect etc. no matter what. you can unplug cable, reboot robot or restart external application or reboot PC on which it runs, it does not matter.... this thing reconnects automatically without user intervention as soon as "stars align" (both nodes are booted and network connection is present).

but that's me...

RoboticsMan · April 7, 2021 at 7:23 PM

Quote from panic mode

just FYI, i am using EKI right now and it is working without issue for quite some time on a headless unit (no smartPad connected). and i chose to make it auto reconnect etc. no matter what. you can unplug cable, reboot robot or restart external application or reboot PC on which it runs, it does not matter.... this thing reconnects automatically user intervention as soon as "stars align" (both nodes are booted and network connection is present).
but that's me...

Well that is nice.

But anyways: The message from EKI_CLOSE() is not suppressed, even though I use

<MESSAGES Logging="enabled" Display="disabled"/> .

The user will still have to acknowledge it. So is it by design only some messages that are disabled, or is it a bug?

/RoboticsMan

**SkyeFire** · April 7, 2021 at 8:30 PM Best Answer

Quote from RoboticsMan

Yes, I also considered that, but in the end I decided for another solution. But now that we talk about it: Is the alive flag always up to date, even before a connection is established in first case?

I relied on it when I was using EKI heavily, and never had any issues. I suppose there could be a problem if some other program were to manipulate the Flag or Output in conflict with the EKI driver.

How to tell if a connection has already been opened in KUKA.EthernetKRL

Advertising from our partners

Anyware Robotics is hiring!

How to see your Job Posting (search or recruit) here in Robot-Forum.com