self-developed UDP server can receive xml file from robot, but cannot send xml successfully

  • Dear all,


    My robot is kuka KR6-R900, with KRC4 compact and KSS 8.6.6. The version of RSI is 4.0.


    I am trying to connect an external PC to my robot to achieve real time motion control. Right now I am basically following the RSI_Ethernet example in the manual while I developed a UDP server in Python 3.9 to imitate the function of Testserver.exe.


    Testing with Testserver.exe is good, I am able to acquire signal and command movement. However, using my own UDP server, I am able to receive xml message from robot but send command to robot. So I guess the ethernet configuration and UDP connection are alright. What happens is RSI will stop in few seconds after the execution of "RSI_MOVECORR()", and pops out "stop by $CORRECTION function (reset or block selection required)" and "Signal flow (running): Object ETHERNET 1 returns error RSITimeout". Meanwhile my UDP server will terminate after receiving several xml message from robot.


    I guess the possible cause is either the robot address is set wrong in my UDP server, or the XML format is incorrect. I put effort on checking everything but haven't sort this problem out yet. Any advice from you is appreciated!


    My Ethernet configuration:


    robot side:

    IP: 192.168.1.2 (RSI, virtual 6)

    subnet: 255.255.255.0

    (I forget other settings but they are default)


    external PC side:

    IP 192.168.1.1

    submnet prefix length 24

    gateway 192.168.1.2

    DNS 8.8.8.8/ 8.8.4.4


    XML message from robot:

    Code
    <Rob Type="KUKA">
    <RIst X="445.0" Y="0.0" Z="790.0" A="180.0" B="0.0" C="180.0"/>
    <RSol X="445.0" Y="0.0" Z="790.0" A="180.0" B="0.0" C="180.0"/>
    <Delay D="0"/>
    <Tech C11="0.0" C12="0.0" C13="0.0" C14="0.0" C15="0.0" C16="0.0"  C17="0.0" C18="0.0" C19="0.0" C110="0.0"/>
    <DiL>0</DiL><Digout o1="0" o2="0" o3="0"/>
    <Source1>0.0</Source1>
    <IPOC>29106442</IPOC>
    </Rob>


    XML message sent to robot from external PC:

    Code
    <Sen Type="ImFree">
    <EStr>Message from RSI TestServer</EStr>
    <Tech T21="1.09" T22="2.08" T23="3.07" T24="4.06" T25="5.05" T26="6.04" T27="7.03" T28="8.02" T29="9.01" T210="10.00" />
    <RKorr X="0.000" Y="1.0000" Z="0.0000" A="0.0000" B="0.0000" C="0.0000" />
    <DiO>125</DiO>
    <IPOC>53189046</IPOC>
    </Sen>


    UDP server code (Python 3.9):

  • Hi Wong!


    I also did a similar project as you are doing but with C# language (So I can not consult you with PYTHON :D)



    I would recommend you first to use Hercules as an intermediate level to check for both connections from the robot and PC, not directly from the PC-python app to robot RSI because It would be difficult for debugging


    Next, just make sure the network transmission frames are in order of receiver and sender sockets (an example is in the picture)


    Hope it helps.


    BR,

    Quang Huy

  • For any RSI project, adding a Monitor object and capturing the data from inside RSI is crucial to debugging.


    I would recommend using WireShark or something similar to check exactly what is being sent to the robot. Tiny formatting errors can be fatal.


    Before attempting motion control, I would suggest trying an RSI program that just receives some data from your server and echoes it back. Isolate the motion issue from the communications issue.

  • Hi Quang,


    Thank you so much for your advice. I was really inspired that there is a software to check connection detail. Finally I make my own program working!


    Your project looks quiet fun, what's that for? Using joystick to control robot?


    bests,

    Arthur Wong

  • For any RSI project, adding a Monitor object and capturing the data from inside RSI is crucial to debugging.


    I would recommend using WireShark or something similar to check exactly what is being sent to the robot. Tiny formatting errors can be fatal.


    Before attempting motion control, I would suggest trying an RSI program that just receives some data from your server and echoes it back. Isolate the motion issue from the communications issue.

    Hi Skyfire,


    Thank you so much for your advice, they are really helpful. Using wireshark I am able to analyze what is the exact process of UDP communication. Finally I got me bugs fixed, now my server can be used to control robot! Appreicate it!


    bests,

    Arthur Wong

  • Hi Wong,


    Basically it is!


    Br,


    Quang Huy

  • For anyone who may face the same issue as mine, I would like to summarize my mistakes for your information:

    Regarding the error "Signal flow (running): Object ETHERNET 1 returns error RSITimeout" there are two causes, one is the Ethernet communication isn't set up correctly, the other is the IPOC tag.

    1. Port number: I used the same port number for server and message sent to client (robot) by the server, which is wrong. The port number of client can be defined, but in this case it is automatically allocated by robot itself, and it is not 59152. A naive mistake.

    2. IPOC: I guess this IPOC tag in xml file is used as timestamp. In the packets back and forward between example Testserver.exe and robot, they have the same IPOC number. (I guess) With some level of tolerance, a same IPOC number should be sent back to robot within 100 cycles, otherwise this RSI timeout error happens.

    3. xml.etree.ElementTree: the functions from this library needs some time to execute, be caution of timing.


    and the following is my UDP server code:

  • Thanks for your report Arthur.


    It is taken for granted the last received IPOC has to be echoed in each new message.


    Besides responding in time, consistency of timing response is also important for smooth control. For that reason I chose a fast Arduino to run my code, as it is not influenced by any parallel or background functions like in a PC...

  • geraldft has a good point here about timing consistency is an important one. I've been working on a system involving a PC running RSI servers and streaming corrections to Kuka robots for a little over a year now, and can say that putting the 12ms server loop on the PC can cause delay issues <Delay D = "#"> when some process pre-empts your server. It might not happen often, but after flying the robots by RSI-wire for consecutive days at a time, you find frequent cases where the link delays and causes issues.


    Moving the response loop to a microcontroller or other realtime system is a good solution to this problem, although if you have more higher-level code that can tolerate some delay, you can keep it in python on the PC.

Advertising from our partners