Sending Position From PC to Robot via RSI

    KRC v8.3.8165

    RSI v3.3.3


    I am trying to send data from an external motion controller in real-time via the RSI option. I have set-up the RSI as per the manual and tried using the Example server application. It is very inconsistent for me. I have got communication between the two, sometimes I am able to use the example application - and only move it a few mm before it errors:

    But most of the time I am receiving this error:

    KSS29002

    Signal flow(running): Object ETHERNET1 returns error RSITimeout.


    I'm not too sure why it is timing out, or the solution to fix this issue.


    My next question is, how do I send the motion controllers data from a C program I have written to the robot ( I get that I need to put it in some sort of XML file, but where does the RSI read that data?). I dont understand how the RSI Visual gets external data from the example application into the Ethernet1 object, and then I don't know how I could read that data sent from the PC on the robot to then make it move to that position. First time trying to use RSI, so my knowledge and understanding on it is very basic, minimal. Let me know if you need any more info.

    The corrections need to be small or they will quickly wind up or exceed the correction limit.


    RSI expects solid connection and messages every few milliseconds. If the external system acting as server cannot keep up, you will get timeout and everything stops....


    You can use wireshark to monitor connection. Each message gets timestamp...

    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

    JM212 it sounds like you have two problems:


    1. Your RSI connection is timing out

    Quote from JM212

    Signal flow(running): Object ETHERNET1 returns error RSITimeout.

    RSI, when running over an ethernet TCP connection and not in IPO_FAST mode, sends a query to your server every 12ms, and expects a reply within 8ms (if I recal). If the response from the server is received outside of that window, the packet is marked as "delayed", and the Delay counter in the next query packet is incremented by 1. When that delay counter reaches the configured maximum count of delayed packets, the link will break.


    Workstation PCs are NOT realtime systems, and while they can usually run quite fast, any given process is not protected from being sidelined by the OS task scheduler in favor of a higher priority process. An example of a high priority OS process is a video/audio player, as these tolerate very little delay.


    Fixes for this are multiple. You can make your RSI link code faster, or get a faster PC. You can increase the priority of the processes managing the link, or move that component of your system onto a Realtime system.


    2. Your Correction Limits are Too Low

    Once you manage to get your server to run fast enough to support an RSI link, your corrections are exceeding the correction limits. I know that when using RSI with KRC2s, the solution is a simple ST_SETPARAM() call targeting a ST_PATHCORR object. with KRC4, you're probably gonna have to RTFM to figure out how to increase the correction limits.


    Note that increasing the correction limits puts you at risk for horrendous, robot-destroying crashes if you f up. We've implemented our own full trajectory management and build volume monitoring processes for our RSI application, and it wasn't a small amount of work. You have been warned.

    Thanks Robonovak, and what is the format to send a packet via udp.

    "b'<Sen Type=\"ImFree\"><EStr>Message from RSI Control Server - PPG !</EStr><AxisCorr A1=\"" + x_str + "\" A2=\"" + z_str + "\" A3=\"" + y_str + "\" A4=\"" + "0" + "\" A5=\"" + "0" + "\" A6=\"" + "0\"" + "/><RKorr X=\"0.00001\" Y=\"0.0000\" Z=\"0.0000\" A=\"0.0000\" B=\"0.0000\" C=\"0.0000\" /><IPOC>" + test2.c_str() + "</IPOC></Sen>\n'";

    Or do I need to send it closer to this:

    <root><Axis1>0.0</Axis1><Axis2>0.2</Axis2><Axis3>0.0</Axis3><Axis4>0.0</Axis4><Axis5>0.0</Axis5><Axis6>0.0</Axis6><Direction>1</Direction></root>

    but filled in correctly


    Edit:

    This is what Im receiving and sending from PC side

    Edited once, last by JM212 ().

    Quote from JM212

    I know it doesnt show PosCorr, but what values should I be sending for that. It seems anything above 1 is too fast for the robot atleast in T1 Mode

    RSI operates on a 12ms clock cycle. POSCORR objects accept inputs in millimeters. This means that sending a POSCORR object a value of 1.0 is ordering the robot to move 1.0mm in 12ms, or 83mm/s.


    While this is a velocity the robot should be able to attain, RSI operates "below" many of the robot's normal path-smoothing features. So switching a POSCORR input from 0.0 to 1.0 is equivalent to ordering the robot to accelerate from 0mm/s to 83mm/s in 12ms, an acceleration of nearly 7 meters/S^2. In normal KRL motions, the robot would simply accelerate as best it can and attempt to reach the target velocity, but RSI bypasses these protections. If you give the POSCORR input values (or changes to those inputs) that command impossible velocities or accelerations, the motion planner will simply fault.


    Using RSI requires the person programming the RSI container to create their own PID algorithm to shape the POSCORR inputs such that the robot is not given motion commands that violate the motion envelope limits.

    JM212

    Quote from JM212

    "b'<Sen Type=\"ImFree\"><EStr>Message from RSI Control Server - PPG !</EStr><AxisCorr A1=\"" + x_str + "\" A2=\"" + z_str + "\" A3=\"" + y_str + "\" A4=\"" + "0" + "\" A5=\"" + "0" + "\" A6=\"" + "0\"" + "/><RKorr X=\"0.00001\" Y=\"0.0000\" Z=\"0.0000\" A=\"0.0000\" B=\"0.0000\" C=\"0.0000\" /><IPOC>" + test2.c_str() + "</IPOC></Sen>\n'";

    This is not correct, but is closer than the other packet you pitched.


    WIth regards to packet format, the format is mostly determined by which ***_CORR blocks you are using in your KRL program. If you have AXISCORR, then you will need the <AKorr ...> subtag. If you have POSECORR, then you will need the <RKorr ...> subtag.



    Note: the above is not STRICTLY true - depending on your program, you can structure the corrections within the XML in whichever way you want. This might be easier for you to get rolling, though.


    Note: You don't have to supply both cartesian correction and axis corrections. Indeed, I'm not sure what happens if you try to use both at the same time. Nothing good, I expect. The only time I've done this was when I was driving a 7-axis robot - we drove the robot position through POSECORR, and the external rail through AXISCORR.



    The IPOC must be an integer that matches the IPOC entry of the packet you just received. Otherwise the link gets unhappy. That might be what you're doing with the test2.c_str() entry, but I can't be sure.

Advertising from our partners