KUKAVARPROXY for KRC4

thank you for sharing that. and there goes my weekend...

KukaVarProxy for KRC4
Release date:15 November 2022
Authors:
    Massimiliano Fago(massimiliano.fago@gmail.com)
    Davide Rosa(programmare@live.com)

Protocol is BIG-ENDIAN
Messages Header format: [2 bytes MESSAGE ID][2 bytes MESSAGE BODY LEN]

FUNCTIONS:
0:GetVar
1:SetVar
4:Discover robots
5:Set target robot ip

GetVar format:
REQUEST MESSAGE BODY: [1 byte FUNCTION][VARIABLE NAME LENGTH][VARIABLE NAME]
REPLY MESSAGE BODY: [1 byte FUNCTION][VARIABLE VALUE LENGTH][VARIABLE VALUE][RESULT LENGTH][RESULT]

SetVar format:
REQUEST MESSAGE BODY: [1 byte FUNCTION][VARIABLE NAME LENGTH][VARIABLE NAME][VARIABLE VALUE LENGTH][VARIABLE VALUE]
REPLY MESSAGE BODY: [1 byte FUNCTION][VARIABLE VALUE LENGTH][VARIABLE VALUE][RESULT LENGTH][RESULT]

Discover robots format:
REQUEST MESSAGE BODY: [1 byte FUNCTION]
REPLY MESSAGE BODY: [1 byte FUNCTION][IP ADDRESSES COUNT][4 bytes IP ADDRESS * IP ADDRESSES COUNT][RESULT LENGTH][RESULT]

Set target robot ip format:
REQUEST MESSAGE BODY: [1 byte FUNCTION][4 bytes IP]
REPLY MESSAGE BODY: [1 byte FUNCTION][RESULT LENGTH][RESULT]


RESULT values:
0 - error
1 - success

Usage:
1. Discover available robot IPs
2. Set the target robot IP
3. Read and write

NOTE: For write operation it is required the robot operational mode to be AUT or EXT
EXAMPLE: GetVar request
[2 bytes MESSAGE ID][2 bytes MESSAGE BODY LEN][1 byte FUNCTION][VARIABLE NAME LENGTH][VARIABLE NAME]

Quote from dddomodossola

This allows you to communicate with more than one robot on the network, and it doesn't require the server to be installed on the robot anymore.

Great job!

Quote from dddomodossola

NOTE: I developed it some months ago. If I remember correctly, in order to read/write variables, a program (KRL program) must be selected on the controller. Not a specific program, a program of your choice. It is a limitation of kuka API.

Not necessarily, at least when using the Cross 3 Interface. Not sure about Contracts from WorkVisualInterface.

All right, i implemented own client in visual studio and it talks...

there were only few minor crashes in the early stage.

did not see any mention of port but it need to be 7000.

the lengths are USINT (2 byte)

message format is simple and convenient. have not run any performance tests yet, will leave that for later.

i don't use Python so i wrote my version just by looking at the description of the message structure but did end up running python example to verify that message structure matches because i was running into issues after discovery and setting ip.

for some reason running Pyton sample in IDE did work but only rarely, but running it from command line worked most of the time. neither way would work when more than one KRC (OL instance) was running:

so if someone is trying to make their own client, example byte sequence is a bullet proof way to confirm your messages are structured correctly.

tx 00 01 00 01 04                              ; msg 0001 len 0001 cmd 04 (Discover robots)
rx 00 01 00 0a 04 00 01 c0 a8 02 25 00 01 01   ; msg 0001 len 000a ret 04 count 0001 IPaddress 192.168.2.37
                                            
tx 00 02 00 05 c0 a8 02 25                     ; msg 0002 len 0005 cmd 05 set IP address 192.168.2.37
rx 00 02 00 05 05 00 01 01                     ; msg 0002 len 0004 ret 05 set IP address successful
                                            
tx 00 03 00 0a 00 00 07 24 4f 56 5f 50 52 4f   ; msg 0003 len 000a cmd 00 GetVar, len 0007 for $OV_PRO
rx full frame:
0000   02 00 00 00 45 00 00 59 1d 5f 40 00 80 06 00 00   ....E..Y._@.....
0010   7f 00 00 01 7f 00 00 01 1b 58 ca ea c0 e8 66 b9   .........X....f.
0020   02 c2 8a 53 50 18 27 f9 aa 5a 00 00 00 03 00 2d   ...SP.'..Z.....-
0030   00 00 27 7b 24 4f 56 5f 50 52 4f 2c 20 31 30 30   ..'{$OV_PRO, 100
0040   20 61 74 20 32 30 32 33 2d 30 32 2d 30 38 20 33    at 2023-02-08 3
0050   3a 34 30 3a 30 36 20 41 4d 7d 00 01 01            :40:06 AM}...

or as seen in Wireshark:

Not sure why the timestamp is included since all nodes are on the same subnet, likely in the same building. I mean, sure i can strip it and replace with local timestamp but just mentioning it. is there a way to adjust it to show local time? It thinks I am in Portugal

it would be nice if the discovery would work but at least i was able to simply skip it...

i picked IP addresses from local list and that was fine, rest worked, i can switch to a different controller. so far only tested with two OLs, but hope to try soon discovering two or more real KRCs.

as stated it does not write variables unless in AUT or EXT as mentioned. not sure why would protocol have such limitation but that is the way things are at the moment.

hello there,

had coworker also try it on the real robots and the exact same thing happened there too. yes it is reproducible. it goes like this:

scenario 1:

powerup one KRC (real robot or OL), start KVP, start either Python client or my client - everything works (discovery, set ip, read var, write var). collect sample of commands to KVP and responses for reference.

scenario 2:

powerup two KRCs (robots or OL) that are on the same network. start KVP - it runs, everything looks normal. using Python script, connection is made, then when discover command is issued, there is no response, KVP gets stuck for a moment (this part is random... gets stuck for 0-5 sec).

then it shows exception and crashes. catching exception is hard because it happens so fast but here it is one of the best takes. it looks odd - i see cursor at the left side and handle size of the scrollbar looks like there may be more in the output that i did not catch. but that was not the case. this is really it.

immediately after that, Python client is stuck too since server is gone

using WireShark i confirm that discovery command was received and acknowledged but no response message is returned

scenario 3:

powerup two KRCs (robots or OL) that are on the same network. start KVP - it runs, everything looks normal. using my client i connect to KVP, start discovery, server crashes pretty much instantly. using WireShark i confirm that discovery command was received and acknowledged but no response message is returned (same like in scenario 2)

scenario 4:

powerup two KRCs (robots or OL) that are on the same network. start KVP - it runs, everything looks normal. using my client i connect to KVP, then i skip discovery , set correct IP to one of the two KRCs, read some variable no problem. while still connected, i send command to set correct IP of the other KRC, it is ok, i can read/write variables. send command to set IP back to first KRC, read write variables , no problem. also using WireShark i confirmed that messages sent and received from KVP are correct. sent and received data is encoded and decoded correctly.

after reboot have not seen any difference between running Python client in either CLI or IDE. behavior is exactly the same and repeatable. as far as i can see client is fine. but server gets shut down due to unhandled exception.

as mentioned above i really wanted to see if there is anything else in the output of crashed server window.

at first i tried to use batch file to start server and redirect output to a text file but that did not help. the only thing in text file is what server shows normally. exception that is shown afterwards is not there.

KUKAVARPROXY_KRC4_server.exe > KVP.txt

next i tried simply using batch file and stopping it by PAUSE so that windows would not close:

KUKAVARPROXY_KRC4_server.exe
PAUSE

and that did work. so here is the entire text of the exception:

if there is anything else you would like me to try or, just let me know, i would be happy to assist. and really thank you for making and releasing this product.

awesome... that was quick. and it seem to work perfectly. many thanks

Quote

#### KVP C4 test with Discovery started ####

Connection accepted

Discover KRCs, Found = 2, 192.168.2.37 192.168.2.36, Ok

Select KRC IP = 192.168.2.36, Ok

Read $OV_PRO = 100, Ok

Read $AXIS_ACT = {$AXIS_ACT, {E6AXIS: A1 -47.9058304, A2 -75.0000076, A3 97, A4 2.56357703E-06, A5 47.0000763, A6 104.999702, E1 163, E2 0, E3 0, E4 0, E5 0, E6 0} at 2023-02-10 1:53:42 PM}, Ok

Connection closed, Ok

#### KVP C4 test with Discovery ended ####

Display More

if i may add, it would be really handy to have a command to identify server and version.

also tested on system with three real robots, and discovery worked beautifully.

connections to robots running KSS8.5, 8.6, 8.7 are confirmed.

tested on my busy PC while running bunch of other apps using structure that resembles following

init connection with KVP_C4
set robot ip  
start stopwatch
FOR n=1 to 1000
   read $AXIS_ACT 
   textbox.append( result and status)
NEXT
stop stopwatch
display stopwatch result

the "read" in above pseudo code included composing message each time and decoding each response and stripping out timestamp.

it takes about 11000ms or 11ms per message

i suspected that UI probably takes a lot of time adding more and more text to a textbox, so i also tried commenting out the textbox.append. in this case result was about 6400ms or 6.4ms roundtrip per message.

the extracted value is 147 byte long:

$AXIS_ACT, {E6AXIS: A1 -97.3276443, A2 -43.2973099, A3 109.029694, A4 -8.19240665, A5 -4.03252316, A6 -55.1122, E1 0, E2 0, E3 0, E4 0, E5 0, E6 0}

according to task manager memory load was negligible, CPU load by KRCserver was averaging about 1% (0.9-1.1%)

command to set robot ip is processed only locally by the server (nothing to transfer to/from robot) so it should be faster than reading variable.

for that i moved that command inside loop just before read, so it too is executed 1000 times.

this was done in 7000ms or 7ms per pair of commands (setIP + read var). so setIP round trip was averaging 7ms-6.4ms = 0.6ms

next, i replaced reading of $AXIS_ACT to $OV_PRO to see effect of much shorter response. $OV_PRO was set to 50 so payload is only two characters. loop still had both commands to set robot IP and read variable, no output to textbox.

to my surprise this took on average a bit longer 7100ms (it was 5000-7500ms in multiple runs)

then i tried to misspell variable. this should take even longer, so removed dollar sign and tried reading nonexistent OV_PRO, loop took 18500ms pretty consistently.

i really like what you have created which is why i jumped at the opportunity to try it out.

and very kind of you to make that offer, much appreciated.

about version check suggestions, i can see two options:

it could be another command similar to set robot ip.

another option is just use special variable that is handled by existing GetVar command. in this case one should just make sure that name is not confused with anything that KRL may want to use. adding prefix with some special character can help (@,#,%,&,! ,? etc.)

for example

GetVar("@VER")

or

GetVar("?VER")

could return something unambiguous, perhaps containing just the file name and version ("KUKAVARPROXY_KRC4_server.exe V1.0.0.0").

using verbose reply would eliminate any doubt about what is on the other side.

dddomodossola what do you think about using unified protocol?
https://c3.ulsu.tech/protocol/latest/
This is my version of the C3 Bridge Interface protocol, based on your first KUKAVARPROXY protocol.

It has GET PROXY INFORMATION message: https://c3.ulsu.tech/protocol/latest/#commandproxyinfo

Also you can request special variables from C3 Bridge Interface Server like:
GetVar("@PROXY_TYPE") == "C3 BRIDGE INTERFACE" (in your case it could be KVP KRC4)

GetVar("@PROXY_VERSION") == "1.0.0"

You can also explore the C# library with the implementation of C3 Protocol: https://github.com/ulsu-tech/c3sharp

In my opinion, it would be great to have a common protocol for our products, it would make it easier to create new client applications.

The only problem, in C3 Bridge messages #4 and #5 are used for READ VARIABLE (UTF-16) and WRITE VARIABLE (UTF-16) messages. But messages #8 and #9 are completely free. There is also some difference in the responses returned. It turns out that you use two bytes to describe the RESULT LENGTH, and to me it looked like a numerical error code. And the last byte looked like an error flag (TRUE/FALSE).

If you like the idea of unification, I am ready to help you implement the protocol.

that would be awesome

did someone already try to write $INSIM_TBL[] and read $OUT[] best would the whole range at once

you cannot write entire $INSIM_TBL[] because some things are system inputs (drives, on, drives off, move enable...). you can see those marked "SYS" in the IO monitor. writing other works. reading entire $OUT[] in one shot is no problem.