Traversing a Point List and/or Auto-Generating and Using Point Variable Names

    I have found the two following posts that seem to touch on what I am trying to do:


    Thread
    How can I integrate the g code into krl?
    My thesis was about 3D printing with six axis industrial robot.

    (my robot: KR 6 R900, robot controller: KRC4)

    I use slicer software which generate g code from a 3D model and this g code should be used for 3d printing.

    I can't use it kuka cnc package, because my company doesn't buy it!!!

    How can I integrate the g code into krl, in some alternative way?
    ardobebe
    Thread
    Kuka program language
    Good evening all,

    Could some please help me understand kuka programming language:
    robot-forum.com/attachment/31076/

    Like start/end point of a weld but really as much as possible would be perfect.

    Thanks
    Marsden1985


    I am writing a C# program that is similar to what is being done above. It is not translating G-Code, but it is close enough to doing so that we can call it "translating G-Code."


    When I generate the point list of the path to be traversed and have it broken down into various weld groups (as few as two or more than a thousand, I need to be able to address certain groups and have the operator decide whether or not to weld one area or another.


    1. If I generate an array in the .DAT file, it is not a very big list before I get an error that the array is too large.

    2. If I generate a list in the .DAT file comprised of

    DECL E6POS P1={x 0, y 0, z 0,... }

    ...

    DECL E6POS P3550={x __, y __, z __...}


    then I have a problem with traversing through the list. I think. With this method, I do not know how to have a generalized reference to a named point that is not an array element. Preferably, the algorithm would be a nested FOR loop that the outside loop goes through the number of path groups while the inside loop runs between the automatically-generated from point P391 through point P632, for example.


    Obviously, it would be fairly trivial to create the .DAT file with the point names and then create a SWITCH statement in the .SRC file where each CASE is a long sequence of LIN P32 statements, but this is not very elegant and *MOST IMPORTANTLY*, if the operator needs to stop the process at some point along the way, I want to be able to perform a restart by simply knowing the name or number of the last completed LIN move. This is easy with an array, but I think that it is less simple with a long series of named points, unless there is a handy trick that I do not know about.


    I do know that the KRL does its own point name generation whenever you create a new motion step, but I don't know if I have any access to how to traverse through such a list.


    Is there such a method?

    i would do a basic sanity check when coming up with an architecture. a bit of math can go long way. for example:


    if your system does not have 6 external axes, it is a really wasteful idea to use E6POS. a single E6POS declaration means reserving space for fourteen 32-bit values: X,Y,Z,A,B,C,S,T,E1-E6. that is 56 bytes.


    in comparison E3POS does not have E4-E6 so it takes 44 bytes.


    and simple POS does not have any of E1-E6 so it takes 32 bytes.


    a FRAME also does not have S & T so when that works, it brings the size down to 24 byte per point.


    so on a large array (say 30k elements) that difference does add up...



    also you are not mentioning KSS but that is the key factor determining how large declared arrays can be. which is why any programming question should always include KSS version (read pinned topic READ FIRST).


    years ago i remember that (on a KSS 5.2 i think) array size limit was some 26000 BOOLs or about 600 FRAMEs or about 500 POS etc. the larger array element is, the fewer elements fit into limited memory.


    with newer KSS one can declare larger arrays. on more recent KSS versions (pretty much anything running on KRC4 or newer) those limits are often down to file size that KRL supports but i recall declaring on KSS8.3 several POS arrays each with 32k elements. (just for test)


    next part is that your code and mentioned messages are completely made up. you talk about arrays but you are not using them - you are declaring bunch of individual points. and therefore any resulting message (details still lacking) simply cannot be mentioning array. if there is a problem message - state it in its entirety and EXACTLY as shown on the robot (with message number and each and every character)... or post as screenshot.


    the idea of using switch/case is possible but... this is rather impractical. if you want to go that route, just declare an array and there is no need for switch/case. but even that will only reduce SRC file from many thousands of lines to just few lines.


    example DAT file


    Code
    DECL POS MyPoints[32000]
MyPoints[1]={X 150, Y 42, Z .....}
MyPoints[2]={X 150, Y 42, Z .....}
MyPoints[3]={X 150, Y 42, Z .....}
MyPoints[4]={X 150, Y 42, Z .....}
;etc

    then in the SRC file just use something like this


    but the biggest problem with all that is that is that you are trying to use data points declared as variables. more specifically - you are trying to declare them in a DAT file and that is a bad idea when you have a lot of points, specially when they will only be used once. how and where variables are declared controls the life and scope of the variable and this requires careful considerations when dealing with large volume of declarations.


    you see, the thing about variables declared in DAT file is that they are given memory as soon as program module is selected but... there is no way to take that memory back without reboot. so if you have 200 program modules, each with bunch of variables declared in DAT file and you keep selecting or calling those program modules, pretty soon you will be out of memory and you WILL have to reboot because your KRC will be out of memory.


    variables in DAT files are fine if one is working with moderate or small number of them. an example of this is set of programs with data points that are taught manually - all such sets are small sets (sparse).


    but when there are many thousands of data points as generated by some CAD to path software this is not a good idea. Cad2Path software can make all moves very short (fraction of a millimeter) and therefore any contour would be made of huge number of points.


    which is why all CAD to Path software do not do that... they simply generate only SRC files - if there is a DAT file involved, it is tiny and only to keep track of essentials (handful of parameters) but there is no set of massive DAT files with many thousands of points.

    Also those points are not declared as variables - they are used as literals (hard-coded values). This way once the SRC file is finished (and deselected), all memory that was used by it is returned to the system - no need to reboot even if you call all the programs over and over.


    an example SRC is


    Code
    BAS(#INITMOV,0)
BAS(#TOOL,1)
BAS(#BASE,12)
PTP xHOME

PTP {X 100, .... }
PTP { X...}
; etc.

PTP xHOME

    good luck...

    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

    panicmode - thanks for all of that info. I would have used the E3POS already if I had known that it existed. All of my systems have either one or two external axes, so I have to use something with that capability


    That said, I think that my plan will have to use two arrays sequentially and then re-assign values to one of them sometime while traversing through the other one. I'm sure that array assignment time would be a factor, so I will have to make a "stop, load next array, restart" sequence for handling these.


    Thanks again for the quick help.

    All told, for this first experimental project, it will be a total of ~65,000 segments split into ~1,400 groups. Each group has from ~5 up to ~3,000 points. I think that two arrays of 500 elements each should be able to swing it where the last array is reassigned to the next set of points, though I will check to see how big an array I can get away with.


    Unfortunately, there will be much larger pieces in the future.

    If you have KRC4 you can also use files to read data into KRL program, for example also point data(check CREAD,CWRITE manual).

    There is a folder C:\KRC\ROBOTER\UserFiles but i think it is limited to 10MB.

    But one can use also "krl_mount" function to access network drive and read data from there.


    For example one can make E3POS MyPoint[20] point array in KRL and read all points data from 10MB file by using only 20 points for example.

    Handling a big array that is splited in two or more arrays isn't that complicated.

    Create two arrays, let's say arr1[500] and arr2[500].

    Then create a procedure and a function to set/read the big array, here the function to read:

    Code
    Deffct e3pos readarr(index:in)
Decl Int index
If index<=500 then
 Return arr1[index] 
Else
 Return arr2[index-500] 
Endif
Endfct

    For setting, create a procedure with two parameters: index and value to set.

    If you have more small array parts than fit into one Dat file, you must declare them global, or you need to create global function/procedure in every corresponding src file, and call them to access the small arrays.


    Hope it's clear what I mean, otherwise ask.

    Easiest way is keeping all points in different src files

    Having one main programme with

    - initialization

    - calling subprogrammes (watch the size limits)


    This was already discussed in some threads - simply use search function

    Quote from EngineerTex

    All told, for this first experimental project, it will be a total of ~65,000 segments split into ~1,400 groups. Each group has from ~5 up to ~3,000 points.

    Be aware that the KRC4 has some very silly memory limits -- something like 4MB in the user-program space. This sounds like you could be at risk of hitting that limit. And sadly, the KRC does not warn you about this -- it simply becomes badly unstable and begins crashing randomly.


    To get around this, you will either need to "swap" point lists in and out via krl_fread/VarProxy/etc, as mentioned above, or buy the KUKA DirLoader option.

Advertising from our partners