Cross3 locks up copying .src file to KUKA KRC2

    Copying one or more .src files from the C:/ drive of our Kuka to the R1/Program folder results in the system freezing with the message "Inserting files." Opening task manager shows that the Cross3 application progressively takes up more and more memory when the copy operation is performed. This carries on until Cross3 takes a lot of the RAM (200+Mb) and CPU (97%) of the KRC2. The system remains in this state indefinitely until a restart is performed.


    The issue also occurs if a program (.src and .dat files) are cut out of the controller R1/Program folder into the C;/ drive and then copied back again.

    Not sure if it is of importance, but a cold start of the KRC2 is the only major thing that was done differently since files could be successfully copied. Further, we got the following internal faults when the system was last shut down (before this the file copying worked fine).

    2804 Internal Error (file: ads_in.c, line: 638, value: 'HFFFF'

    5 C3FIL ADS timeout in CLocalProxy::ItemCopy


    The symptoms of this issue sound similar to this: HMI freeze for .src file copying on KUKA KRC2

    Any ideas on what the cause could be, and potential solutions are greatly appreciated.

    System information and in response to the questions in the above post:

    Robot: Kuka KR150-2 2000

    Controller: KR C2 ed2005
    Software: V5.6.8, GUI 2.0.6.7 B50, Kernel system version: KS 5.6.50 RTAcc, Windows: 5.1.2600 XPe

    HMI freezing: yes - Cross3 is locking up in task manager, consuming a lot of system resources.

    Virus scanner installed: No, but KukaVarproxy is running
    Multiple files: Same issue with one or more files
    Overwriting files: Same issue overwriting or copying new files
    File size: as small as 50 lines and issue is still there
    Global variables in files: issue is there with and without globals in the file
    Files copied to same directory level: yes

  • Nation March 18, 2025 at 3:22 PM

    Approved the thread.
    • Best Answer

    If I had to guess, I'd say your KSS may have suffered some file corruption. Making a full HDD image backup immediately, before it gets any worse, is going to be vital.

    The brute-force solution (after making that image, and an Archive All) would be to re-install KSS from the D: partition. If that doesn't resolve the issue, I would suspect actual HDD sector corruption or failing RAM.

    One thing to remember is that the /R1 directory shown in the KUKA File Explorer is the RAM drive that the robot operates from. This drive is loaded during boot, and copied to the HDD during powerdown (and periodically). If something is causing the Copy/Paste function to overlook the EOF marker on the file being copied into the RAM drive, filling the RAM is something I would expect to see.

    One possible temporary workaround might be to boot the robot to just Windows, without KSS. Usually you can do this by connecting a keyboard and holding down Shift during boot. This should cause Windows to boot normally, but without starting any of the applications in the Startup folder (which is how the KSS is typically started on boot). It should be possible to copy a KRL module into /R1 on the HDD using Windows Explorer. When KSS is started, it should read all the files from that directory tree into the RAM drive and perform the syntax/linking cycle.

    In our case the solution was to remove as many files as possible and again to cold boot the robot (not just into windows). I have a suspicion that this forced the syntax and linking cycle you were talking about and correct any issues that were caused by previous copy operations.


    Reading through your answer, it occurred to me that this issue could have been introduced by a file we tried to copy (with which the copying issue started) that had a $ sign instead of an ampersand in the file header. Perhaps this contributed to an incorrect file copy.

    Code
    &ACCESS RVO
&REL 1763
$PARAM EDITMASK = *


    Thanks for your detailed answer. We are grateful this did not corrupt the file system.

    Quote from AllanV

    In our case the solution was to remove as many files as possible and again to cold boot the robot (not just into windows). I have a suspicion that this forced the syntax and linking cycle you were talking about and correct any issues that were caused by previous copy operations.

    It's possible you were starting to overload the RAM. KRCs load/compile/link every module during boot, regardless of whether they're used. And KRCs can start acting rather odd as the size of the RAM drive begins approaching the KSS limit. And the KSS limit is a fixed value, completely separate from the physical RAM.

    Quote from AllanV

    Thanks for your detailed answer. We are grateful this did not corrupt the file system.

    That's good news. But making a full HDD image backup is still Very Strongly Recommended. On HDDs this old, they can start suffering corruption without warning.

  • AllanV March 21, 2025 at 8:35 AM

    Selected a post as the best answer.

Advertising from our partners