Posts by VDm

    Seems to me that you can use the KONI for transferring files to the KRC4... what do you think?

    Yes, you can.

    I use KONI almost every working day to transfer files via SMB, as well as to connect to my network applications or remote desktop.

    Even WorkVisual finds the control system through KONI, although I haven't tried to work with it fully.

    I have already described how to achieve this.

    It's a weekend and I can't take a screenshot from a real system because it's at my work.

    But I will try to clarify it again. You can see several devices in the Device Manager under "Network Adapters".

    One of them is KONI with the "wrong" driver.

    All you need to do is to initiate the driver update process and specify the path to one of the folders on disk D where the "correct" driver lies.

    It will have the word "Intel" in its name because all network interfaces in the motherboard of the control system are built on Intel chips.

    After that, a normal network device will appear in Windows with the ability to specify an IP address, subnet mask, and gateway.

    But be careful, the control system's firewall is disabled by default.

    And I am not sure that you can turn it on because there is a lot of service network exchange going on in the system.

    All this makes the system vulnerable to external network attacks through KONI.

    I used a small hack: take the KONI network interface from VxWorks, and return it to Windows by removing the Realtime driver and then manually installing the native network interface driver (Intel).

    C3 Control Panel

    The C3 Control Panel is an application to remotely control KUKA robots via the C3 Bridge Interface Server or KUKAVARPROXY.


    • KRL Variable Control
    • Variable Watch List
    • Actual Position Display
    • Jog, the manual control of robot movement (EXPERIMENTAL)

    System Requirements

    • Windows XP SP3 or later
    • DirectX 9.0c
    • Xbox 360 Controller Driver for Windows (optional)


    Actual Position


    Watch List




    Download Links

    Repository (license information only):

    Binary (Windows XP or later):…v1.0/

    I assume that the amount of RAM is more important than the access speed. The fact is that on KRC4 VxWorks starts its work AFTER Windows 7 is booted (this happens with the UploadRTOS.exe application).

    VxWorks may not boot at all if, for example, there is no free processor core for it. I have had this happen because the process of recovering Windows 7 from the image has been done without any further reconfiguration. And Windows 7 was running on both cores available.

    A similar situation can theoretically happen with RAM because UploadRTOS must correctly allocate the address space for the second operating system.

    Could it be the result of a network problem? Do you connect your laptop directly to OfficePC? Or through a network switch, router or chain of switches?

    Unfortunately, I don't have the VRP, but I have studied the mechanism of remote control on the HMI side. There is a lot of attention to tracking the state of the connection.

    on the kukavarproxy is "debug" option where I can see all IN/OUT traffic. Is there (C3Bridge) some equivalent functionality?

    When start i see only messages for connection options on C3Bridge window.

    No, the C3 Bridge Interface does not have this feature. It was designed for very frequent requests. This would inevitably lead to a log overflow in a matter of seconds.

    Can You share C3 Control Panel .

    Unfortunately, no. I am working hard on this software and maybe in the future I will release a freeware version.

    Today I saw your project and I will test the possibilities using a python.

    I will be happy if I can assist in the development or testing of your project.

    Nice. You can try to replace KukavarProxy with C3 Bridge Interface. It's fully compatible.

    does your software meets the requirements of "SPOC"?

    Do you mean Single Point of Control? No, I don't think so. Like the KukavarProxy, my software allows for simultaneous connection of several network clients.

    Greetings everyone.

    I'd like you to meet the project that I've been working on for the last six months.

    It's called the C3 Bridge Interface.

    The C3 Bridge Interface Server is a lightweight network application that allows remote clients to execute requests to the KUKA Cross 3 subsystem and return responses. The application provides advanced functionality and high performance.

    Some distinctive features

    • Well-documented application protocol. It is fully compatible with KukavarProxy protocol, which means that existing client solutions (RoboDK, ROS) can be used.
    • Executes more functions of the KUKA Cross 3 subsystem (in the future I hope to implement all available functions).
    • Controls the execution of a KRL program (you can start/stop/reset your program).
    • High performance. The software is written in C++ and can be compiled using both modern development tools and development tools of the past years (like Visual C++ 6.0).
    • It does not require additional software libraries to be installed in the control system.
    • It starts minimized to tray and does not take up any space on the screen.
    • There are no limits on the number of simultaneous network connections and idle time.
    • The Discovery Protocol for easy identification of the control system in the network.


    To confirm the correctness of the created software product functioning, the C3 Control Panel application was developed.

    It allows displaying coordinates of the robot's current position and controlling the movement of individual axes.

    Work on both programs is carried out in parallel.

    Increasing the functionality of the C3 Bridge Interface Server requires the addition of verification functions to the control panel.

    Unfortunately, I am not ready to publish the C3 Control Panel at this stage because of its primitive and debug oriented nature.

    Protocol Specification

    You can download the application protocol specification from the repository here:…face%20Protocol%201.1.pdf

    Download Links

    The main repository:

    Binary (v1.0, Unicode, for Windows 7 or newer):…oad/v1.0/

    Binary (v1.0, ANSI, for Windows 95 or newer):…1.0/


    The software is licensed under the 3-clause BSD license.

    The full text of the license is available in the repository:…erver/blob/master/LICENSE

    Project Support

    I'm not sure if I can leave a donation link here.

    If you find this project useful, you can thank me with a donation.

    All necessary links can be found in the file and on the home page of the repository.

    I would also be happy to receive your wishes and comments of any kind.

    Best regards,

    Dmitry Lavygin

    PhD, Senior Researcher

    S.P. Kapitsa Research Institute of Technology, Ulyanovsk State University, Russian Federation

    What is the advantageof of this complicated, probably illegal method?

    You need an USB stick, an USB sata adaptor, a CDrom drive and the suitable CD.

    It is much easier to connect the adaptor direct to the kuka harddisk and laptop to use your prefered backup software.

    In my case I didn't have an image of HDD, but had original .wim files instead. That's the reason why I needed original Recovery system.

    Are you sure that publishing instructions on how to hack kuka software should be posted public. Do not get me wrong but as a former KUKA employee i am aware that a lot of Kuka people are watching this forum.


    Ethical and legal issues are left to the discretion of the person using the instructions.

    I don't distribute any source or modified software from KUKA or other companies.

    And obviously, I don't profit from it.

    I have supplemented the disclaimer with lines about this.

    If the KUKA representatives or moderators of this forum see a problem with the existence of these instructions, they can simply delete them.

    Screenshot 4

    Acknowledgements and wishes

    I would like to thank others for help in researching of the original KUKA.RecoveryUSB.

    I would also like to ask the moderators to edit this manual in order to improve the grammar (I'm not a native English speaker) and, if possible, combine several posts into one.

    Screenshot 3

    Step 4. Making RecoveryUSB

    1. Copy whole Recovery subfolder from a hard disk to your USB stick.
    2. Launch patched X:\Recovery\Recovery.exe (where X: is drive letter of your USB stick), KUKA.Recovery application window will be opened
    3. You can change the language to your preferred.
    4. Press Update USB stick button, locate file for the Update package field, press Update button.
    5. Wait when the creating process will complete, then close KUKA.Recovery application.
    6. Now you need to copy patched Recovery.exe file from your hard disk to USB stick again (it's important).
    7. Your self-made RecoveryUSB is ready.
    8. (Optional) Launch Recovery.exe from the USB stick again, select Expert settings and uncheck Support only KUKA controllers to make it possible to boot and run on any PC.

    Step 5. Making Super Grub2 Disk

    1. Download CD image of universal boot manager from SourceForge.

    2. Burn the image to CD/DVD using your preferred CD recording software.

    Step 6. Booting to Recovery System

    1. Connect a CD-ROM drive with Super Grub2 Disk inserted to your KUKA Robot Controller.

    2. Insert your self-made RecoveryUSB into your KUKA Robot Controller.

    3. Perform reboot or power-on of the control system.

    4. During POST stage of booting (KUKA Logo) press F12 to select boot device.

    5. Select your CD-ROM device from the list and press Enter, universal bootloader will be loaded (see the screenshot 4).

    6. Select Boot manually... ⇒ Disks and Partitions (Chainload) ⇒ (hdX, msdos1) "KRC_ARCHIVE" (where X is a number).

    7. Now your RecoveryUSB system will be loaded (you must see the loading progress bar), you can disconnect CD-ROM drive from your KUKA Robot Controller.

    8. Follow the manual for KUKA.RecoveryUSB.

    Step 3. Patching procedure

    1. This step involves the use of a hexadecimal editor, so if you haven't one you can download free hex editor called Hexplorer from SourceForge
    2. Open Recovery.exe file from Recovery subfolder (Step 1.5) in the hex editor.
    3. Use Edit ⇒ Find... (Ctrl+F) with hex chain of bytes: 4B0055004B0041005F00550053004200 (it means KUKA_USB encoded as UTF-16 little-endian wide string).
    4. The hex editor will jump to offset where 0x17DDB0 is a beginning of the located chain, and 0x17DDBF is an ending of the chain (see the screenshot 2).
    5. Now edit the chain by overwriting first three letters of KUKA_USB to just USB (or your specific substring from Step 2.6), subsequent letters must be zeroed (see the screenshot 3).
    6. So the hex chain 4B0055004B0041005F00550053004200 is now replaced by 55005300420000000000000000000000.
    7. Save the file (File ⇒ Save), now you're ready to make RecoveryUSB.

    Screenshot 2

    Running KUKA.RecoveryUSB from any USB Flash Drive


    Everything you do, acting according to this manual, you do at your own risk.

    I'm not responsible for any loss or damage arising from reading of this manual.

    All legal liability associated with making changes to the software rests with the person making the changes.

    I offer this manual only for those who have an original KUKA.RecoveryUSB stick that does not work or has failed.


    1. IBM PC-compatible computer with Microsoft Windows 7 or higher.
    2. USB CD-ROM drive or SATA CD-ROM drive with SATA-to-USB adapter.
    3. Couple of writable CD/DVDs.
    4. USB Flash Drive with 1 Gb of memory at least.
    5. KUKA Robot Controller 4 (I did my experiments on KRC4 compact).

    Step 1. Dealing with archives

    1. Download file from
    2. Open the downloaded file in any archiver application (I prefer free 7-Zip Archiver).
    3. Inside the archive you will see Recovery_V3.0.3_Build0015 subfolder which contains file, extract that file to a folder on your hard disk.
    4. file is an archive too, so open that file in your archiver application.
    5. Extract whole Recovery subfolder from the archive to a folder on your hard disk (and don't delete

    Step 2. Collecting information

    1. Physically remove any USB sticks from your system except one which planned to be self-made RecoveryUSB (If there is no plugged USB sticks in your system, just insert one).
    2. Open the Device Manager (In Windows 10: right click on Start Button ⇒ Device Manager, or right click on This PC ⇒ Properties ⇒ Device Manager).
    3. In the Device Manager's tree locate Disk drives branch, expand it, locate your USB stick device (you must distinguish that from any other drives on your machine).
    4. Make a double-click on your USB stick device, device properties window will be opened, select the Details tab and Friendly name property from drop-down list.
    5. Now read the value, in my case it's Generic Flash Disk USB Device (see the screenshot 1).
    6. If the Friendly name of your device contains substring USB then you can just continue read this manual step-by-step, but if not you'll need to choose any unique three letter substring from the value and use that on the step of patching procedure (or you can replace a USB stick to one which Friendly name value contains USB substring).

    Screenshot 1

    I think for booting from USB-flash the bios checks some informations of the controller chip in the USB device, like VID / PID and some more.You even can't change this with an acronis backup of the whole flash drive.

    So i am amazed about the fact that your controller booted from an attached CD-ROM.

    So far, I've learned this:

    • My KRC4 system doesn't boot from any USB non-optical disk drive (I tried USB stick and regular HDD with SATA-to-USB adapter)
    • System does boot from CD-ROM attached by SATA-to-USB adapter (in MBR mode)
    • System does boot from any USB stick which formatted as FAT32 partition contains 64-bit EFI loader (in UEFI x64 mode)
    • System does boot from secondary HDD or CD-ROM directly connected via SATA (in MBR mode)

    Also today I was able to create a bootable CD that boots successfully but Recovery.exe doesn't start due to an incorrect letter assignment of the CD file system (Windows PE expects Recovery.exe to be found in the C:\Recovery folder but in fact it is in the D:\Recovery).

    A temporary workaround: Use a flash drive clone and a CD at the same time. Windows PE will boot from the CD, and then launch C:\Recovery\Recovery.exe from the USB flash drive.

    Thank you, so I have to think hard about why KRC refuses to boot from the flash drive's MBR.

    The system does not even try to transfer control to the boot sector code.

    I wrote into the first sector of the flash drive 512 bytes of special code to confirm the booting stage.

    It runs and works on any PC, but not on KRC4.