KUKA.EthernetKRL and OfficeLite

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.

need to setup beer account ...

@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

Thank you very much, it worked!!!

Hello,

Excuse me, where could I found the EthernetKRL_serve.exe?

That should be easy if you have the option. You can find it in the folder DOC/Example/Application of the option installation folder.

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

No.

If cant we send data in background its useless.

Quote from Dzonzi

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.

Quote from Dzonzi

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.

Nevermind. I used c3 bridge instead and it works perfect.