program example of a palletizing program KUKA KRC4

    Hello.

    im new to the kuka world and i have i mission to setup a robot to pick parts from a loaded plate. X-Led 5 pices Y-Led 3 picec.

    The sequens should look like somthing like this.

    robot picks part from place 1. puts in machine. picks part 2. and so on.

    Does anyone have a program exampel for this? i Read in the forum, skyfire hade posted som exampel of this. but i can´t find it.

    greatful for help

    //Daniel

    Hello
    This is well covered in KUKA training program. There is also a set of tutorials which KUKA has prepared for beginners and this is included in it. On the KUKA download center you can get this .zip file named KUKA.WorkVisual_V4.0_Videotutorials. The sample program include basic palletizing.

    Thanks for the replay!

    i downloaded the KUKA.WorkVisual_V4.0_Videotutorials but where were only .mp4 files. no program exampel.
    And in the movies i can se that they use a cub_palettizing program.

    Not my code but I found it somewhere a while back.

    Quote from Koppel

    someone has try to use this code??

    Saludos / Best Regards

    Madrijo3

    I try to use on different kind of kuka robots (60/30/90/250) and isnt working :frowning_face: , have a lot of syntaxis problems , i'm trying to make a palletizing program, but I still have some questions with this part, could someone explain exactly what it does in this line?


    Abl_Position[Ebene,Reihe,Spalte]= xMasterPos1

    """"""Xmasterpos1 Is a global variable? ”"""""

    """"""" Why put Abl_Position[Ebene,Reihe,Spalte].x=Abl_Position[Ebene,Reihe,Spalte].x+(Spalte-1)*x_Abl


    Specifically ].x=

    regards

    Saludos / Best Regards

    Madrijo3

    The main problem is, that the example is missing the .dat file.

    Xmasterpos1 is defined in the dat, and is a 'normal' created position in an Inline Form (one corner on the pallet).

    It makes no sense to try to use a not working code on different robots, if the code doesn't work on one robot it will not work on another one.

    The example is only an example, it will not really be usable in a real application without adjusting some parts.

    The biggest problem is that many people learn to write a program with teached positions, then they are called "real robot programmers".

    You should try to go a different way: learn to code some programs on a PC, in a language of your choice (pascal, c, basic,...), and learn things about data structures, programming structures, algorithms..., then learn the robot specific things on top. JM2C

    leave that program as is...

    create another program of type Module

    inside that program add one inline form motion, name point MasterPos1 and make sure it uses same tool and base as your palletizer demo code. this will be teachable point so it need to be an inline form.

    since (in this case) this is a separate program module, you need to make some changes, this point need to be global so that position variable xMasterPos1 can be reached from other programs.

    edit DAT file of the new created module:

    at the end of DEFDAT line add word PUBLIC

    at the declaration line of xMasterPos1 insert word PUBLIC between DECL and E6POS.

    close and save

    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

    Quote from madrjo3_kuka

    Why put Abl_Position[Ebene,Reihe,Spalte].x=Abl_Position[Ebene,Reihe,Spalte].x+(Spalte-1)*x_Abl

    Specifically ].x=

    This is the "shift" calculation for the X axis. Any E6POS variable is a structure containing the aggregate {X,Y,Z,A,B,C,S,T,E1,E2,E3,E4,E5,E6}. To access one element of a Structure aggregate, you use VariableName.ElementName. So:

    DECL E6POS P1

    P1.X = 111.22

    Gives P1 the value {X 111.22}, leaving the other elements undefined. Adding

    P1.Y = 222.33

    P1.A = -21.3

    results in P1 being {X 111.22, Y 222.33, A -21.3}. Each element of the aggregate can be accessed and manipulated in this manner.

    Since Abl_Position is a 3-dimensional array, the array index needs to be part of the VariableName.ElementName:

    DECL E6POS PosArray[2]

    PosArray[1].X = {111.222}

    PosArray[2].Y = {222.111}

    results in:

    PosArray[1]={X 111.222}, with all others undefined

    PosArray[2]={Y 222.111}, with all others undefined.

    So, Abl_Position[,,] is set to MasterPos1, then this calculation is carried to to shift this member of the Abl_Position array by the X-direction spacing of each box (x_Abl), multiplied by the X index counter (Spalte).

    The next two lines perform the same operations for the Y and Z axes, using the Y and Z counters.

    Panic ,skyefire , thanks for explain me ,🙏


    Decl e3pos pointer


    Pointer={x 200, y 400, z 600}

    Or

    Pointer.x=200

    Pointer.y=400

    Pointer.z=600


    Ptp_rel pointer


    now it is clear for me 😃,now I try on robot and understand how to work👨‍🔧


    But I have an other questions🤔

    How I can assign a value with a variable🤔


    Because I try putting something like this

    Decl real value1

    Decl real value 2

    Decl int value3

    Decl int value4

    Decl e3pos pointer


    Pointer={value1, value1,value1}📛

    Pointer={value3, value3, value3} 📛

    I try putting real, int variable :frowning_face:

    What is the correct sintaxys

    For assign a value to the variable and

    For assign the variable to the p3pos

    Specifically this

    Pointer={variable, variable , variable}


    Thanks

    Saludos / Best Regards

    Madrijo3

    Basically, you cannot have variables inside an aggregate, aside from the variables that are Declared as part of the aggregate. So

    P1={X 100} is legal, but

    P1={X My_X_Variable} is not. The simplest way to remember this is that you cannot put your own variables in between the {}.

    It's not hard to get around this, although it can be a bit annoying:

    P1.X = My_X_Variable

    P1.Y = My_Y_Variable

    ...and so on.

    Hello,

    can someone please explain me this part of program as I am a new to KUKA.

    ;FOLD PTP EndPos_1 Vel=100 % PDAT3 Tool[1] Base[0] ;%{PE}

    ;FOLD Parameters ;%{h}

    ;Params IlfProvider=kukaroboter.basistech.inlineforms.movement.old; Kuka.IsGlobalPoint=False; Kuka.PointName=EndPos_1; Kuka.BlendingEnabled=False; Kuka.MoveDataPtpName=PDAT3; Kuka.VelocityPtp=100; Kuka.CurrentCDSetIndex=0; Kuka.MovementParameterFieldEnabled=True; IlfCommand=PTP

    ;ENDFOLD

    $BWDSTART = FALSE

    PDAT_ACT = PPDAT3

    FDAT_ACT = FEndPos_1

    BAS(#PTP_PARAMS, 100.0)

    SET_CD_PARAMS (0)

    PTP XEndPos_1

    ;ENDFOLD

    Okay, KRL 101: Any line, or part of a line, that starts with ; is a comment. The compiler ignores it entirely. So:

    Code
    DEF MyProgram
;This entire line is a comment
DECL INT X ; only the part of this line after the ; is a comment

    However, the user interface is a different beast from the compiler. Certain special types of comments are still ignored by the compiler, but change how the user interface (the KUKA HMI) displays those lines.

    I would suggest downloading OrangeEdit to try this out. OE does the best job of simulating the way code appears on the pendant.

    FOLDs are what causes the display to change. Any code in between a FOLD and ENDFOLD will only appear on the pendant as a single line, unless/until you use the Open Fold option on the pendant (or hit the +/- button in the WorkVisual editor):

    Code
    ;FOLD This is My Fold
; The operator will only see "This is My Fold"
; Everything else inside this Fold is invisible unless the Fold is opened
; Opening a Fold requires logging in as Expert or higher
PTP P1 ; the robot will move
PTP P2 ; The robot will move again, but to the user, the cursor will be on the "This is my Fold" line
; another comment
;ENDFOLD  

; This comment will be visible to any user, b/c it's not inside a Fold

    You can create Folds however you like, as long as you follow the formatting rules. However, KUKA has a special class of Folds called Inline Forms (ILF), and these are used to create programs on the pendant.

    Your code is a fairly normal motion command, created on the pendant using the menu structure.

    ;FOLD PTP EndPos_1 Vel=100 % PDAT3 Tool[1] Base[0] ;%{PE}

    The red part makes it a Fold. The green part is the "title" of the Fold, displayed when the Fold is closed. The blue part, starting with the %, is the special coding that makes all the drop-down menus in the ILF work. So, when you hit the Change button on a motion Fold, that's what drives all those little menu boxes.

    While you can create your own "normal" Folds, you cannot create your own ILFs unless you buy the UserTech option package from KUKA. Ditto for modifying the stock ILFs.

    Your quoted code also has a Fold inside a Fold. Nested Folds are legal, and turn up fairly often. The {h} on the end of the Fold make it Hidden, not visible at all normally on the pendant.

    In between the ;FOLD and ;ENDFOLD, is normal "raw" KRL that executes in a completely normal fashion. Being inside a Fold does not change how the code runs, only how it is displayed on the pendant, and (in the case of ILFs) how it interacts with menus.

    Thank you for your reply. Actually, I got a KUKA robot pick-and-place program from my boss and have to find out how the robot executes the process. I have .dat and .src file so, from which file do I have to read the main program so, i can get the process of robot.

    Abhi

    Quote from Abhi123

    Thank you for your reply. Actually, I got a KUKA robot pick-and-place program from my boss and have to find out how the robot executes the process. I have .dat and .src file so, from which file do I have to read the main program so, i can get the process of robot.

    KRL 101: Modules

    In KRL, the basic program organization unit is the "module." A Module usually consists of an .SRC file for the executable code, and a .DAT file for non-volatile variables. The two files are implicitly connected by having the same name. Hence, the Module MyProgram would usually consist of two files:

    MyProgram.SRC

    MyProgram.DAT

    It is possible for a module to consist of only an .SRC or .DAT file -- certain common system modules like CELL and $CONFIG.DAT are examples. There is also the special case of the background task, which is a .SUB file (most often SPS.SUB). But most common KRL Modules consist of both files.

    An .SRC file can contain multiple routines or functions. The first routine must have the same name as the SRC file itself. A routine begins with a DEF, and ends with an END. A function begins with DEFFCT and ends with ENDFCT.

    Any variable DECL'd in the .DAT file of a module is automatically available to any routine in the .SRC file of the module.

    The first routine of a module is implicitly Global. So, in the Module MyProgram, the first routine would have to be named MyProgram, and would be callable from any other routine in the robot:

    DEF MyPRogram()

    ..

    ...

    END

    It is also possible to explicitly declare subroutines, and .DAT file variables, with the GLOBAL statement, which makes that particular routine or variable explicitly Global.

    There's also the system file $CONFIG.DAT, which is a module that consists only of a .DAT file, and any variable DECL'd in that file is implicitly Global.

    Most KUKA robots have the program CELL (a system Module that consists only of an .SRC file) as the top-level routine (what other programming languages might call the MAIN() or "entry point"). This program runs in an infinite loop, and calls specific customer-created modules on demand based on an integer value received from an external control system.

Advertising from our partners