Control my Kuka robots totally with PC client with Qt and C++

    Hello, I am a newcomer to KUKA Robots recently. I have been familiar with KRL and EKI communication of Kuka. However, I want to do more with this powerful robot. Here are some questions that I want to ask:

    1. Is it possible to write a background program that will be executed right after the power of the KUKA Robot is turned on? If so, where can I put my source file in Kuka Controller?
    2. Is it possible to transfer the files I write on the PC to the Kuka robot through FTP directly? (Like using filezilla)
    3. is It possible to use my PC client to control the whole Kuka Robot, including selecting the program I want to activate instead of using the buttons on the Controller PAD?

    Thank you very much

  • Go to Best Answer

  • MOM June 5, 2023 at 9:51 AM

    Approved the thread.
    Quote from yen_like_capoo

    Is it possible to write a background program that will be executed right after the power of the KUKA Robot is turned on? If so, where can I put my source file in Kuka Controller?

    Yes. There is more than one way to do this, depending on your KSS version, but the most basic is to edit the "stock" background program SPS.SUB. Every KRC comes with this program, and it starts and runs in the background on boot.

    SPS.SUB has an "INIT" section that only runs once, on boot (or is the SPS is manually restarted), and a "PLC" section that runs in a continuous loop. Each of these sections has a labelled "USER" section where you can add your own code.

    SPS uses typical KRL language, but with certain special rules. SPS cannot issue motion commands (except for specially-configured external axes), and cannot issue commands that might affect motion (changing $BASE, $TOOL, etc), with the sole exception of adjusting the Override speed ($OV_PRO or $OV_APPL).

    SPS also must never stop. So using WAIT commands in the SPS is forbidden. KRL will actually allow you to do this, but it will cause the SPS to behave erractically.

    Quote from yen_like_capoo

    Is it possible to transfer the files I write on the PC to the Kuka robot through FTP directly? (Like using filezilla)

    FTP? No. The KRC operates out of a RAM disk, which is loaded from the hard drive during boot. There is no outside network access to the RAM drive.

    You can create a directory on the hard drive (D: recommended) and make that partition network read/writeable (obviously, making the C: drive network-writeable is a VERY BAD IDEA) as an SMB share. Then you can push files to that directory. But the only way to load program files into the RAM drive, for execution, is to do it manually on the SmartPad (using Copy/Paste), or to buy the KUKA DirLoader option that allows programs to be swapped in/out of the RAM drive while operating.

    Quote from yen_like_capoo

    is It possible to use my PC client to control the whole Kuka Robot, including selecting the program I want to activate instead of using the buttons on the Controller PAD?

    Not really. Remote access to the SmartPad is generally limited to non-Safety actions. So no switching modes between T1/T2/AUT/EXT, no drives-on, etc. You can Cancel/Reset/Select programs this way, but you will not be able to start them through this interface.

    Most applications that "remote control" the robot from a PC use EKI or OpenShowVar, and have a program in the robot constantly looping and branching based on variables set by one of those interfaces.

    I've heard (haven't tried it myself) that it's possible to select and start a "foreground" program from the SPS (only if Safeties are satisfied and drives are already on), but that brings up a host of potential safety issues. Along with the fact that you still can't switch between operation modes remotely.

    • Best Answer

    yes, if the drives are on, submit can use CWRITE with "RUN /R1/ProgramName" to start ProgramName.src and that can be dangerous. i wonder why CWRITE does not support "SELECT /R1/ProgramName"

    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

    Quote from SkyeFire

    Yes. There is more than one way to do this, depending on your KSS version, but the most basic is to edit the "stock" background program SPS.SUB. Every KRC comes with this program, and it starts and runs in the background on boot.

    SPS.SUB has an "INIT" section that only runs once, on boot (or is the SPS is manually restarted), and a "PLC" section that runs in a continuous loop. Each of these sections has a labelled "USER" section where you can add your own code.

    SPS uses typical KRL language, but with certain special rules. SPS cannot issue motion commands (except for specially-configured external axes), and cannot issue commands that might affect motion (changing $BASE, $TOOL, etc), with the sole exception of adjusting the Override speed ($OV_PRO or $OV_APPL).

    SPS also must never stop. So using WAIT commands in the SPS is forbidden. KRL will actually allow you to do this, but it will cause the SPS to behave erractically.

    Thanks, then I also want to ask another question. Can I create my own .sub* file in the same folder of sps.sub? Or do I just need to add my own background program in sps.sub?

    In addition, if I want to let the background program send the current joint of Kuka when PC client send command into Kuka, I should also create an xml file in Kuka, right? This is the only function I want, instead of any robotic motion program.

    Quote

    Not really. Remote access to the SmartPad is generally limited to non-Safety actions. So no switching modes between T1/T2/AUT/EXT, no drives-on, etc. You can Cancel/Reset/Select programs this way, but you will not be able to start them through this interface.

    Most applications that "remote control" the robot from a PC use EKI or OpenShowVar, and have a program in the robot constantly looping and branching based on variables set by one of those interfaces.

    I've heard (haven't tried it myself) that it's possible to select and start a "foreground" program from the SPS (only if Safeties are satisfied and drives are already on), but that brings up a host of potential safety issues. Along with the fact that you still can't switch between operation modes remotely.

    I have surveyed on the internet and found some suggestions. One of them is that I can set up Cell/Main sequence in Kuka and use EKI to receive INT to do the corresponding command, but I don't understand it very much. Do you ever hear this before?

    Quote from panic mode

    yes, if the drives are on, submit can use CWRITE with "RUN /R1/ProgramName" to start ProgramName.src and that can be dangerous. i wonder why CWRITE does not support "SELECT /R1/ProgramName"

    Thank you very much. Do you mean I can write a switch code in sps.sub to distinct file that my PC client want to select?

    By the way, why it is dangerous to use CWRITE for Kuka robot? Will this function select multiple files simutaneously?

    exactly

    and worse, plenty of people suck at what they do. the problem is they put others at risk too. how many have their robot started with X11 bypassed and then decided to keep it and run like that because 'it works'? add to that those that want to deliver program module to robot remotely and as well select it and start it also remotely - what could go wrong?

    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

    Quote from yen_like_capoo

    Thanks, then I also want to ask another question. Can I create my own .sub* file in the same folder of sps.sub? Or do I just need to add my own background program in sps.sub?

    It's not about the folder. Basically, there's a system variable that controls what .SUB file is started on boot. By default, that's SPS.SUB. You don't want to change that default unless you have a very good idea what you're doing.

    Standard practice is to create your own modules (either .SRC or .SUB), and call those subroutines from the appropriate lines inside SPS.SUB. As long as your modules are located somewhere under /R1/Program, the call will work.

    Same rules apply about WAIT commands and motion commands, though.

    Quote from yen_like_capoo

    In addition, if I want to let the background program send the current joint of Kuka when PC client send command into Kuka, I should also create an xml file in Kuka, right? This is the only function I want, instead of any robotic motion program.

    Should be doable. XML files define channels. You can use up to 3(?) channels in parallel with EKI, IIRC.

    The trick is, to get the robot to respond to a command from the PC, you'd probably need to open the EKI channel from the INIT section of SPS, then keep it open. Probably have the PC send updates to the robot every X milliseconds with a "null" command, and have the SPS routine written to send back $POS_ACT_MES or $AXIS_ACT_MEAS if/when the PC sends the correct command. So the channel would be passing traffic both ways constantly, and the "trigger" would be when a particular variable hit a particular value.

    Quote from yen_like_capoo

    I have surveyed on the internet and found some suggestions. One of them is that I can set up Cell/Main sequence in Kuka and use EKI to receive INT to do the corresponding command, but I don't understand it very much. Do you ever hear this before?

    Never seen it before, but it could be done. Create a "main" program that loops while waiting for an Integer variable to have a specific value, then calls a sub-program based on what that Interger's value is. This would look a lot like CELL.SRC, but the value of PGNO would be controlled by your EKI channel instead of by P00.SRC.

    Quote from SkyeFire

    Same rules apply about WAIT commands and motion commands, though.

    Should be doable. XML files define channels. You can use up to 3(?) channels in parallel with EKI, IIRC.

    The trick is, to get the robot to respond to a command from the PC, you'd probably need to open the EKI channel from the INIT section of SPS, then keep it open. Probably have the PC send updates to the robot every X milliseconds with a "null" command, and have the SPS routine written to send back $POS_ACT_MES or $AXIS_ACT_MEAS if/when the PC sends the correct command. So the channel would be passing traffic both ways constantly, and the "trigger" would be when a particular variable hit a particular value.

    OK, thank you very much. I understand what I should do to achieve the xml connection. However, I have aother question:

    It is necessary to set up IP address and Port number when writing an xml file, right? If I set up my kuka robot as a server and PC as client, should I create two sockets in PC to connect different xml files that support two different programs? Or I can set up two xml files under same port number and different IP address (Same Subnet)?

    Thank you

    Quote from SkyeFire

    You can create a directory on the hard drive (D: recommended) and make that partition network read/writeable (obviously, making the C: drive network-writeable is a VERY BAD IDEA) as an SMB share. Then you can push files to that directory. But the only way to load program files into the RAM drive, for execution, is to do it manually on the SmartPad (using Copy/Paste), or to buy the KUKA DirLoader option that allows programs to be swapped in/out of the RAM drive while operating.

    Hello, I just currently encountered a problem when I want to transfer my own .sub* file into kuka controller. I had set up the IP address and subnet mask, also inserted the ethernet cable to Kuka Controller and my PC. For example, the IP address and subnet mask of the kuka is 192.168.XX.11 and 255.255.0.0. And the setting on my PC is 192.168.XX.12 and 255.255.0.0. However, it seemed that only when I select a program that initializes a Xml file that my PC can successfully connect with Kuka Controller.

    I think it is a little weird. If I cannot connect with Kuka, how can I start Windows Shared to adding my personal files to directory of Kuka?

    In addition, should the IP address in every Xml file be the subnet of KUKA Controller? Which combination of IP should my Socket connect, the one in Kuka Controller or the one set up in Xml file?

    Quote from yen_like_capoo

    192.168.XX.11 and 255.255.0.0.

    What is "XX"?

    Also, you can't use that combination. The 192.168.1.* (EDIT: 192.168.1.* for KRC2s, 192.168.0.* for KRC4s) subnet in the robot is a reserved internal network IP range, and using 255.255.0.0 is creating a network collision.

    Quote from yen_like_capoo

    In addition, should the IP address in every Xml file be the subnet of KUKA Controller? Which combination of IP should my Socket connect, the one in Kuka Controller or the one set up in Xml file?

    The XML files are for EKI, they have nothing to do with file sharing.

    File sharing is done the same as for any standard Windows computer. You'll need to minimize the KUKA HMI on the SmartPad to get access to the underlying Windows layer, then pick your directories to share and set the permissions.

    Then you simply point your PC's File Explorer to the robot's IP address, as you would for any typical PC-to-PC file sharing.

    Quote from SkyeFire

    What is "XX"?

    Also, you can't use that combination. The 192.168.1.* subnet in the robot is a reserved internal network IP range, and using 255.255.0.0 is creating a network collision.

    I set up my KUKA robot's Ip address as 192.168.50.11, and my PC as 192.168.50.12

    You say that subnet mask should not be 255.255.0.0, then can I use 255.255.255.0?

    If I set up my Kuka robot's ip as above, what Ip address should I write in every Xml files in the Kuka Controller? Can I still write the same?

    <Kuka_background>

    <CONFIGURATION>

    <EXTERNAL>

    <TYPE>Client</TYPE>

    <IP>192.168.50.12</IP>

    </EXTERNAL>

    <INTERNAL>

    <ENVIRONMENT>Submit</ENVIRONMENT> <!-- Server run via robot interpreter -->

    <BUFFERING Limit="512" /> <!-- Allow buffering of up to 512 messages (system max) -->

    <ALIVE Set_Flag="11" /> <!-- Use $flag[11] to indicate alive/good connection status -->

    <IP>192.168.50.11</IP>

    <PORT>54611</PORT> <!-- Port of EKI interface on robot controller (in [54600, 54615]) -->

    <PROTOCOL>TCP</PROTOCOL> <!-- Use UDP protocol -->

    </INTERNAL>

    </CONFIGURATION>

    <RECEIVE>

    <XML>

    <!-- Get Joint position command -->

    <ELEMENT Tag="RobotCmd/@Joint" Type="BOOL" />

    </XML>

    </RECEIVE>

    <SEND>

    <XML>

    <!-- Joint state positions -->

    <ELEMENT Tag="RobotState/Pos/@joint1"/>

    <ELEMENT Tag="RobotState/Pos/@joint2"/>

    <ELEMENT Tag="RobotState/Pos/@joint3"/>

    <ELEMENT Tag="RobotState/Pos/@joint4"/>

    <ELEMENT Tag="RobotState/Pos/@joint5"/>

    <ELEMENT Tag="RobotState/Pos/@joint6"/>

    <!-- Joint state velocities -->

    <ELEMENT Tag="RobotState/Vel/@A1"/>

    <ELEMENT Tag="RobotState/Vel/@A2"/>

    <ELEMENT Tag="RobotState/Vel/@A3"/>

    <ELEMENT Tag="RobotState/Vel/@A4"/>

    <ELEMENT Tag="RobotState/Vel/@A5"/>

    <ELEMENT Tag="RobotState/Vel/@A6"/>

    <!-- Joint state efforts (torques) -->

    <ELEMENT Tag="RobotState/Eff/@A1"/>

    <ELEMENT Tag="RobotState/Eff/@A2"/>

    <ELEMENT Tag="RobotState/Eff/@A3"/>

    <ELEMENT Tag="RobotState/Eff/@A4"/>

    <ELEMENT Tag="RobotState/Eff/@A5"/>

    <ELEMENT Tag="RobotState/Eff/@A6"/>

    <!-- Interface state -->

    <ELEMENT Tag="RobotState/RobotCmd/@Size"/> <!-- Number of elements currently in command buffer -->

    </XML>

    </SEND>

    </Kuka_background>

    Here is my Xml file that I want to initialize in the sps.sub for Kuka.

    Quote

    The XML files are for EKI, they have nothing to do with file sharing.

    File sharing is done the same as for any standard Windows computer. You'll need to minimize the KUKA HMI on the SmartPad to get access to the underlying Windows layer, then pick your directories to share and set the permissions.

    Then you simply point your PC's File Explorer to the robot's IP address, as you would for any typical PC-to-PC file sharing.

    If xml files is nothing to do with file sharing, then what is the function of IP address and port number existing in every Xml file? Is it just the mark that make server to know which task is required?

    Quote from yen_like_capoo

    I set up my KUKA robot's Ip address as 192.168.50.11, and my PC as 192.168.50.12

    You say that subnet mask should not be 255.255.0.0, then can I use 255.255.255.0?

    Do you understand how subnet masks work?

    In the KRC4, 192.168.0.* (I was incorrect in my previous post, the KRC2 used 192.168.1.*), as well as 172.17.*.* amd 172.16.*.*, are reserved for internal use.

    A subnet mask acts like a filter on IP range. A mask of 255.255.255.0 means that connections can only be made between IPs whose first three quads are a perfect match. "255" means "perfect match requried", while "0" means "anything goes".

    So if you used 192.168.50.* with a subnet mask of 255.255.0.0 can cause a computer to treat 192.168.50.* and 192.168.0.* as the same network. Using 255.255.255.0 should keep them separate.

    If you need to use a mask of 255.255.0.0, then you need to make the 2nd quad something other than 168.

    Changing the subnet mask should not require changing your EKI channel config files.

    Quote from yen_like_capoo

    If xml files is nothing to do with file sharing, then what is the function of IP address and port number existing in every Xml file? Is it just the mark that make server to know which task is required?

    Because EKI uses TCP/IP (or UDP). That relies on specific IP addresses. EKI generates a TCP/IP connection based on the information in the channel file. If EKI is acting as a client, then it needs to know the IP of whatever computer is acting as a server. In your case, EKI is acting as a server, and needs to define which IP address it is going to open a port on. In the event that the KRC had multiple exposed NICs with different IPs, this information is important.

    But EKI runs in VxWorks/KSS, and has nothing to do with file sharing, which happens entirely in Windows. The KLI port is a "shared resource" that can be accessed by both VxWorks/KSS and Windows, although KSS has primary authority.

Advertising from our partners