I am working on KRC2 KSS5.6.
It is already clear to me that arrays are limited in the number of elements, where it also makes a difference if the elements are bool, int or real.
I also saw that if the number of elements in an array is within the limit, if you have several of these arrays it can however also be a problem if too much of these 'near the limit' arrays.
I saw this phenomenon within a .dat-file, but can this be seen project wide : that all the arrays of all files are accumulated and that you still can get a problem with the 'overal' number of elements?
Array limits
-
Plc_User -
August 24, 2016 at 10:37 AM -
Thread is marked as Resolved.
-
-
Array size is limited to a certain number of bytes (exactly how many varies with KSS version). Different variable types (BOOL, INT, REAL, etc) take up different amounts of memory per variable. So an array of type BOOL can be much larger (in terms of how many elements the array is declared for), than an array of type INT. Because BOOLs take up 1 byte each, while INTs take up (IIRC) 4 bytes each.
This does not add up across modules -- you can have many arrays, with each array at the maximum size. However, if you do this too much, you might eventually encounter the total program memory space limit of the KRC. But this would require a very large number of max-sized arrays.
-
limits do exist. after all memory in controller is finite. older KSS versions had lower limits, i don't recall details but on KSS5.2 it was something like:
BOOL 26000
INT 7500
FRAME 1100 or so
etc.on newer KSS you can make array of any data type up to 32767 elements.
declaring variables in DAT file means that once the DAT file is linked, all variables will consume some RAM and - this allocation is permanent (even if you cancel program or select another one). in fact if you have 50 program modules and you select each of them at some point in time, all of their variables that are declared in individual DAT files will still be taking memory. -
KSS 8.3, KRC4
Hi all,
I was wondering if somebody could shed some more light on the array/memory limitations of the machines.
I have tried creating many 32766 sized FRAME arrays dynamically as a run-time variable. I am able to get up to about 9 of these, but if I include the 10th variable I get an error along the lines of "not enough memory for dynamic variable." This is a problem as I want to create about 100 of these variables. Assuming a frame is composed of 6 REAL values, that means each FRAME should take 24 bytes. So each frame being 24 bytes * 32766 frames in an array * 100 = ~78,000,000 bytes = 78 MB.
The memory available on my machine is 1400 MB with 40% usage I believe. So I am having difficulty understanding why this memory error is occuring.
Is there a hard limit on the number of variables that can be declared or anything like that?
Is there a system variable that allocates certain amounts of memory to dynamic variables that I could change?
Lastly, is there any distinction between declaring a variable globally, in a DAT file, or run-time in the SRC file? I understand some will stay in memory forever until a shutdown, and others only exist when the program is running. I am curious if there is a distinction regarding the number of variables that can be declared? The word "dynamically" in my error makes me think if I declare all these variables in DAT or globally it may work.
Sorry for all the questions, but thank you in advance if anybody can shed some light on my questions!
Regards!
-
Memory allocated to KUKA software (KSS) is not total RAM on motherboard.
So that information about 1400MB and 40% is misleading as it is not what KSS memory is.
I do not know of any ways of allocating more RAM memory to KSS. -
How can I go about seeing how much RAM my KUKA robot has available? And is an upgrade of the RAM an easy task?
-
I have done some more digging on the forums and it appears that I should be interested in the memory allocated to the VxWorks instead of the KUKA controller CPU.
Is there any way to upgrade this relatively easily?
Thanks!
-
https://www.robot-forum.com/robotforum/kuk…58isa6#msg76206
So you can increase Windows Memory but not vxworks Memory.
Fubini
-
https://www.robot-forum.com/robotforum/kuk…58isa6#msg76206So you can increase Windows Memory but not vxworks Memory.
Fubini
So this would not necessarily be able to increase the number of FRAME variables I want to declare. Would DirLoader be the appropriate add-on to purchase?
-
DirLoader is able to load files into running system and delete them.
So if you run out of memory because there is too many programs DirLoader is kind of solution.
DirlLoader process is time consuming (anywhere from 3-7 minutes , that depends on amount of programs)
DirLoader active means robot is not running (you cannot execute programs and run DirLoader simultaneously) -
DirLoader is able to load files into running system and delete them.
So if you run out of memory because there is too many programs DirLoader is kind of solution.
DirlLoader process is time consuming (anywhere from 3-7 minutes , that depends on amount of programs)
DirLoader active means robot is not running (you cannot execute programs and run DirLoader simultaneously)Thank you for your replay. I definitely need my program to be running while I read in these data points and turn them into variables. So it appears as if DirLoader is not the option for me.
What other potential KUKA solutions are there for running almost 1 million points? Surely there are several applications that use this many points. There must be a reasonable solution.
-
Text file and function to read points from it or external system feeding the robot with positions (Ethernet KRL)
-
Text file and function to read points from it or external system feeding the robot with positions (Ethernet KRL)This discussion includes some test code that worked pretty well for loading FRAME arrays in the robot from a large text file.
https://www.robot-forum.com/robotforum/kuk…88891/#msg88891