memory upgrade on KRC2

    Hello.

    I want to upgrade my KRC2 memory from 256 Mb to 1 Gb, replacing with two sticks of 512 mb instead of 128 mb as it is. My memories of 128 were manufactured by DATARAM Denmark as is writen on them. Should I replace with same manufacturer sticks or can I use any brand of SD RAM from computers?
    Can you also let me know what modification I should do in memconfig.ini?
    Thank you very much.

    The requirements for a realtime OS like VxWorks are much tighter than for a Windows PC. So RAM that will work reliably in a KRC is generally more expensive. Sometimes off-the-shelf RAM from Crucial, et al, will work, but sometimes not. KUKA spare-part RAM is guaranteed.

    If you can find an alternative source for top-quality RAM with guaranteed signal timing, you could try that, but it's still something of a risk.

    I replaced my memory with two new sticks of 512 Mb , in trying to upgrade RAM from 256Mb to 1 GB.
    Controller PC can see in BIOS 1 GB total memory.
    Without any change in memconfig.ini I tried to reload a finishing program with 150 src files by 75 Kb each.
    Loading from 150 up to 72 then same message phisicall memory is not enough.
    I saved initially memconfig.ini settings then I edited some new limits increasing values found there 4 times, as my memory upgrade 4 times more.
    I tried to reload those 150 src files, same thing, at 72 phisicall memory not enough.
    I got in Help/Info/System and there Phisical Memory is still 256 Mb and 60 % load.

    A Kuka guy told me that is not necessary any changing in memconfig.ini but didn't work.
    Controller doesn't know that memory is 1 Gb still see 256.
    What should I change?
    Thank you

    Should I force a cold start up for booting in sense to be considered my changing in memconfig.ini?

    I increased MINIMUM PHYSICAL PAGES FROM 10 TO 40
    I CHANGED RESERVED PAGES FOR SRC FROM 64 TO 256
    PAGES FOR DAT FROM 64 TO 256

    Should I change any other item in memconfig.ini?

    size of descriptor table refer to what? should remain 256 pages or need to be increased?
    what about expansion size when area move is necessary?
    reserved pages for link of module and for error list ?

    Edited once, last by signum (April 4, 2015 at 9:17 PM).

    You have some problems with vxworks Memory, not with Windows.

    You have to change in the registry (regedit.exe):
    HKEY_LOCAL_MACHINE\SOFTWARE\KUKA Roboter GmbH\Cross3\Manager\Boot\VxWin
    - Physical pages
    - VxWinRam

    Attention: Too high values can Crash the System.

    KSS-Version ?
    Windows Version ?
    Actual Values ?

    SJX,

    what are the maximum values ?

    I already increased them and did work.

    PHYISICAL PAGES WERE 3000 AND I INCREASED TO 6250
    VXWINRAM WAS 1300000 IN HEXADEZIMAL AND I INCREASED TO 2000000 (OR 32 X 1024 X 1024 DEZIMAL) BUT I WANT TO KNOW MAXIMUM.

    KSS IS 5.2.19
    WINDOWS XP
    RAM I UPGRADED FROM 256 TO 1 GB NOW

    Sorry, don't know it.
    But i think, KUKA too (ask Hotline .....)

    It depends on a lot of things........
    - KSS-Version
    - KSS Options
    - XP-Version (it has more than one xp-Version)
    - Hardware
    ...

    Works the System without crashes, it's fine.
    With your values should be ok.

    ...... Image HDD always good idea ........

    Signum,

    If you are going through all this trouble just because you want to satisfy your intellectual curiosity as to how far you can push the Physical Pages limits, then you don't need to read further...

    But if you really trying all these tricks in order to be able one day to run large size programs (for example a milling program with hundreds of thousands of points or multiple of those) I can tell you right now that you have entered a process so painful that in the end the experience of going through it it will measure the density of hair in your chest... I went through the same exact mental-trip trying to upgrade memory cards then wasted days and days trying to find the right amount of Physical Pages just to crash the system, cold starts, hot starts, and quite honestly, I never became able to run REALLY large size files. I ended up feeling that I made a huge mistake investing in an older KR210 KRC2 and that for my application it was quite useless.. My advice... don't do it...

    There is a better way.... :fine:

    It's called CAMRob KRC

    You will need:

    KSS 5.4.14 or later. If you have a DSE card installed in your KRC2 you can upgrade from v 5.2.19, make sure you also have the right Windows version for it.

    The Package consists of:

    Art.# 91B300-012 KUKA.CAMRob KRC V2.2 which you can get from KUKA Belgium. This version is newer than the V2.3 that they sell in the US. Buy it from them. KUKA USA will tell you that older KRC 2 controllers cannot support it, I am the living proof that this is a pile of poop.. It works perfectly fine.

    Art.# 91B300-010 KUKA.Applications KRC V1.2 You need this because CAMRob works on top of this. The awesome part of this particular version of Applications is that via Job Creator you can take a number of .src files and turn them into a Job and batch-run them, a functionality very similar to that of DirLoader but for a fraction of the money and the headache.(See page 16 in the attached manual)

    You will also need KUKA.UserTech V2.4.1 Build 2

    I am attaching the manuals so you can read all the info that I just mentioned for your self.

    Bottom line. With an investment of 2,400 Euro you can run programs of hundreds of thousands of lines or hundreds of subprograms of that size in one shot, I do it every day of my life.

    In short, if you are not familiar with CAMRob KRC, this is what happens: You generate an src file that is not more than 20-30 lines and all it does is calling all the CAMRob functions. You also put separately in a .CSV file all the points(XYZABC E1 etc values). This file can be massively big(million points or more). You do not need a .dat file. The .src file as usual goes in R1\Program. The .CSV file goes into D:\Applications In the .src file you can set up your spindle feed and speed, start, stop it, set up ATC all with CAMRob commands. You also call the PROCESS command (or multiple PROCESS commands)which what it does is it reads-in chunks of points from the .CSV file one buffer after the other. Then buffers that their points have been processed get flushed out of memory and get populated again with new chunks of points for later execution. That way CAMRob basically drip-feeds points into memory and this is a process that can go on for ever.

    A few key points. There is a myth that you need also the 12K CAMRob PC package to make this work. That's incorrect. Although the PC part generates the entire Job folder automatically (includes among others the .src and the .bin file) plus it looks like it is an excellent simulator, you can completely enjoy all the functionalities of CAMRob KRC without the PC part (see attached manual page 49) It is a bit of extra work to create manually the .CSV file but Excel is your best friend on that... You will also need to be very careful with how you configure CAMRob KRC because it will simply not work, or work unpredictably.

    I encourage you if you decide so, to buy it from KUKA Belgium. They are extremely knowledgible and on contrary to the fellas from KUKA USA, are extremely polite. To give you an idea, I worked with the man who runs the R&D department and in order to walk me through the program, he called me from his house on his cel, on his own time in the middle of the night there, because we couldn't establish a good internet connection during his office hours. And I wasn't even trying to buy a robot...

    I hope you found this useful.

    Thank you for your replay.It is not very simple.
    CamRob is more than an uploading software is a CAM generator and postprocessor for Kuka.
    I have my own CAM solutions . I cannot understand how CamRob manage larger size files in a small RAM memory of 256 mb for ex.
    But my question is do you know how works DirLoader, can you explain me ? Cause some people say here that uploading large size is possible with DirLoader.
    Other say no, memory is same even you use DirLoader is just a transfer program.
    If would work DirLoader I would prefer it cause I already have src files written in subroutines and called by a main program.
    DirLoader is not more expensive than Camrob.

    So far I increased Physical Pages up to 12400 in dezimal and I can upload 30 mb maximum. But it can be too low.

    No CAMRob KRC is not a CAM generator.
    Apparently you didn't read the manuals that I attached.

    CAMRob comes in two flavors. CAMRob PC and CAMRob KRC.

    CAMRob PC is built on top of KUKA.Applications PC and in conjunction with KUKA.Sim pro or tech can read in CAM files generated from your own CAM package, run a simulation, check for collisions singularities etc and generate src Files. It also generates a .job file and a .bin file that contains all the XYZABC values of all the targets in the program. This is the PC side of the package that if you have your own simulator you don't need it.

    CAMRob KRC is the part that gets installed in your controller. This is the part I was talking about. One of the main functionalities that offers is that of drip-feeding chunks of targets in memory so you can ultimately run in one shot a program as big theoretically as you D:\ drive can handle.

    I will let you read the manual and see why this is your best option but briefly I will give you a small example of my workflow to better understand the idea.

    I create a 3D model in my CAD app
    I generate toolpath in my CAM package.
    I generate the .src file in my simulator. In specific I use KUKA PRC, a plugin for Rhino. It generates a single src file that contains all the LIN commands, sometimes hundreds of thousands or more.
    I copy all the LIN commands and paste them in a .txt file.
    Then I delete them from the src. Now my src file is not more than 20 lines.
    I read the .txt file in Excel.
    I format it in the following pattern:
    Line nr;X;Y;Z;A;B;C (you can actually add user-specific parameters per line but it's optional)
    Export it as a semicolon separated .csv file
    Then I copy the src file in R1\Program and the .csv file in D: (note that in D: the only file-size restrictions you have is the available room in that partition.)
    I add the CamRob in-line commands in the src file. You can actually use regular KRL commands for IO etc but you need to add at least the Proccess CAMRob command that basically starts the drip-feeding process.
    If you formatted correctly the CSV file you are done.

Advertising from our partners