KUKA.EthernetKRL and OfficeLite

  • Hello, is it possible to use KUKA.EthernetKRL in OfficeLite? I have installed KUKA.EthernetKRL v2.2 in OfficeLite v8.3.28 and cant connect to external system from OfficeLite v8.3.28, always giving EKI00014 "Ethernet connection to external system failed", but i can ping the external system just fine inside the virtual machine where OL is installed, so connection is there...:/

  • AD
  • i did... and yes it works.


    if using EKI to communicate with program running inside OL, just use address 192.168.0.1.


    for communication with external application normally one need to use router. this is a small piece of software that can be obtained from KUKA.


    Note that EKI runs on VxWorks. This is also where KLI port is.

    But in OL there is no KLI so the only option users have is to get access to EKI through RTOS port 192.168.0.1.

    Without router there is nothing to connect that port with the Windows interface that you use to ping outside world.

  • Thank you very very much for detailed post on how to set it up and you took time to write all the info... i will get on to it immediately... just for the info i also wrote to kuka simulation office where i got the OL and they said it can't be used...


    I´m sorry – that´s not possible Ethernet is communicating via KLI (KUKA Line Interface) – this interface isn´t available in OfficeLite.


    But going through all the post in the forum about EKI in OL i got a hinch that it can be done... so thank you again for detailed info on how to set it up and i'm sure this post will come handy not just to me and also for others using EKI in OL


    just because that now i don't have to have robot beside me to test some vision camera with KRL...:thumbup::thumbup::thumbup::love::love::love:

  • @panic_mode showed perfectly how to solve the communication from EthernetKRL acting as a client. The thing I need to do is to make EthernetKRL inside of OfficeLite as a server. Clould you please show how to realize that direction.


    Many thanks in advance

  • I think I solved it with the help of your screenshot myself. Adding a route for the used port and the ip 192.168.0.2 seems to work

  • Hello,


    I followed the described steps, but something went wrong, because when I run the application, the IP that appears is IPV6 and it is not what the program is expecting for.


    The configuration is in the right path, with the right IP address, and I have no idea of what is going on.

    Attached is a printscreen of the cofigurations, if someone has any idea of what I'm doing wrong, please let me know!!


  • when running Application you need to pick correct interface.

    default value is 0 for "Network card interface index" but you need to manually try values 0,1,2,3,4.... until you see message that it is listening on correct IP address


    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

  • If cant we send data in background its useless.

    sending data in the background is not a problem but that sentence got me thinking...

    would you also say that those who did not learn, cannot read and interpret manual are also useless?


    and please try to avoid creating chains of deleted posts. you may not see deleted posts but some people here see everything and trails of destruction are not much different than spam. that is not useful for those who try to keep this place clean and - useful


    as mentioned before forum is not a substitute for formal education, so consider reading documentation or take training. when posting in forum, try to make the points clear and well defined. try to understand terms before using them.


    for example real-time and background are not the same.


    "real time" is relative and it simply means "sufficiently fast and consistent response time". and you did not define what is your "real time". for certain processes this could be value measured in picoseconds. for others it could be in minutes, hours or ... maybe weeks.


    in case of industrial automation, "real time" is usually expected to be in the range of few milliseconds at most. therefore in case of KRC, term "real time" is normally reserved for things like RSI or FSD, because EthernetKRL may not be able to meet such times reliably.


    "background" process is something that happens in parallel with something else. it does not say how fast response need to be.


    on KRC one can use SPS to do things in the background. this could be opening connection and sending or receiving data (or both). this would allow sending and receiving data in the background - regardless what robot is presently doing, regardless if robot is faulted or if robot program is even selected... but SPS is NOT a priority task and it is NOT synchronous to robot program so execution times are NOT guaranteed to be consistent or reliable in any way. hence anything running in SPS is normally not seen as "real time"... but to be honest, that would really depend on your definition of "real time".


    about EthernetKRL...


    there seem to be misunderstanding of key concepts.


    every TCP connection requires client and a server. that is part of TCP fundamentals and there is simply no way around it. and every TCP connection requires client to connect to server. (it must be client that initiates connection). once the connection is open, data exchange can take place.


    consider another example:

    when you type "robot-forum.com" in your browser and press enter or click on load page, your browser is a client and it is connecting to this site (which is hosted on some server). the point is that YOU (client) requests data from this forum (server). if you do not do that, this site will NEVER somehow magically and voluntarily open your browser and load the page you are reading right now. and if the forum is down for example (server is down), there is NOTHING you can do with your browser (client) to get the forum page to load. server always must be ready and running BEFORE client tries to connect to it.


    so when you start demo EKI server and see "Waiting for connection", it means that server is ready to do its work. it is just waiting for some client to connect to it. so your robot controller or OL should have program code (created by you) that will open connection to this server. without that code on the robot, there is NO connection...



    about buffers....


    buffer is just a temporary storage. it is used to temporarily hold data before it is used.

    there are two buffers - one to send and one to receive messages.


    send buffer can only hold data for one message but message can be complex and have many elements. you can write bunch of elements one at a time until the buffer contains all required message data. (this is done using EKI_SetBool, EKI_SetInt, EKI_SetString etc.)

    then you can issue send command (that would be EKI_Send) and entire message is sent out. this "send" action also clears the send buffer so you can start loading parts of the next message.


    receiving buffer can hold multiple received messages. reason is that messages may be delivered quicker than they can be processed - for example if server sends a burst of several messages, they all will end up in the receiving buffer. note that receiving buffer is a queue (FIFO or LIFO) so when your program reads one of messages, that message is removed from the buffer. depending on configuration you can read either the oldest or newest message in the buffer but - you cannot read messages out of order (for example try to first read one that is in the middle of the buffer queue).

    really, you can keep receiving messages endlessly (billions of messages) even if the size of receiving buffer is 512... or just 1. the important thing here is to empty buffer in order to make room for next message. and this "emptying" of receiving buffer is normally done by reading from the buffer (using EKI_GetBool, EKI_GetInt, EKI_GetString etc.)


    suppose your receive message that contains INT, STRING, BOOL and you read INT,BOOL but not STRING... and it does not really matter which element was not read, we are simply considering case where some part of received message is not read entirely. this means that message is not going to be removed from buffer UNTIL it is read completely. but if the other node keeps on sending more messages, count of messages stored in the buffer will keep on increasing.... once you reach the configured message limit, error will be generated.


    suppose we expect message containing INT, STRING, BOOL but the other side sends incomplete message (such as INT, STRING and without BOOL). if you try to use EKI_GetBool to read non-existent element of the message, there will also be a fault....


    to manage things like this one need to dive deeper into EKI manual and learn about flow control, checking buffer (this is receiving buffer) etc.


    if you are only sending data, there is nothing to worry about receiving buffer.

    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

  • is it possible to send data in real-time using sps and ethernet KRL?

    Qualified "yes". Depends on your definition of "real time."


    The key weakness of EKX for "realtime" communications is that it's not hard realtime. It usually uses TCP/IP, which is vulnerable to packet lags and losses. Unlike RSI, which is hard-realtime on a fixed 12ms or 4ms cycle, and will throw a fatal error if more than a few packets are delayed.


    For example, I've recently worked on a system that used EKX in the SPS to cyclically communicate with a PC-based application using UDP, exchanging 128 bytes every 250ms. Now, this application did not have any RSI-style hard-realtime requirements, so the worst case issue if a few consecutive data exchanges got lost would be that the robot's foreground task would have to wait several hundred ms for an update.


    OTOH, if you want to try to use EKX as a substitute for RSI, it probably won't work. It definitely won't work as well as RSI. So the answer to your question depends on what, exactly, you're trying to do.

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