axis variation for stacking welding layers

  • Hello,


    I'm new to robotics, I'm doing research on additive welding with a welding robot. consists of stacking several weld beads. then I will test the specimens and see their mechanical properties. Faculty of Mechanical Engineering.


    the robot is a kuka KR 8 R1620 arc HW with ESAB power supply


    I managed to make the robot weld in line and open the file in workvisual, I put a loop (I don't know if it's right where I put the loop), but I don't know how to vary the Z axis to generate the stacking of the layers without having to generate thousands of points . after searching a lot I found out that it is necessary to declare variables, but I don't know how to do it, I don't know which variable to declare and I don't know how to vary just the z axis



    the idea of putting a loop is so that later I can change the parameters and check the differences between them.


    thanks in advance, any help is welcome.

  • (Post actual code into Code boxes, not screenshots)


    Well, it's possible to offset in the Tool Z axis, or the Base Z axis. I'm going to assume you want to build your weld in the Base Z direction. Since your program is using Base 1, you can do like so:


  • one way to accomplish what you are after is to manipulate base. for example you would need to have a variable to track progress and based on that offset base.


    btw.

    your loop need to have an exit condition and after that robot need to go home.

    Code
    IF whatever THEN
      EXIT
    ENDIF

    so your code (lines 32-76) should be between the two PTP HOME instructions.

    that is where user code always need to be since each program starts at home, does something then returns home.


    you could add in the DAT file declarations such as

    Code
    DECL INT LoopCount = 0
    DECL REAL LoopStep = 2.217 ;mm

    also copy value of your base1 to some other base such as base2 so that value does not get lost. copying value in SRC from base 1 to base 2 is also possible but... this only need to be done ONCE and better never. otherwise every time you start program, previous (recalculated) value of base1 would be transferred to base2 and you do NOT want that...


    then in your SRC file, inside LOOP add something like


    Code
    base_data[1]=base_data[2] ; copy all six frame elements
    base_data[1].Z=base_data[2].Z+LoopStep*LoopCount ; then recalculate Z
    LoopCount=LoopCount+1 ; count each pass

    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

  • Good afternoon,


    thank you very much for your answer, it was of immense help to me, because without it I would not even be able to start my research.


    I ran the Skyefire script, as it's urgent, I don't have time to change. however there was a line missing to say what the value of the "LayerThickness" variable is. so I put on line 3 written "LayerThickness = 2"


    the script works fine, but there were some problems.

    -I don't know why, but the smartpad jog and smartpad movement controls were inverted after I loaded the workvisual project

    -To search, SPTP was recorded, 4 points were needed in our case, but when executing and simulating the movement, "axis 4" seems to lose its position settings and self-adjust to compensate for the movement. Axes, so far, have a speed limit, and even conform to what they move, and he, with a drastic speed limit. (I put the robot to weld and due to the speed the welding torch pierced the plate)

    -still on axis 4- when moving the robot through the jog, it just moves axis 4, turning to one side or the other. others in the same place. we are having to register the SPTP controls for each axis. (We use axis mode to move the robot).


    Does anyone know how to solve these problems, if there is a solution? or is it like that?


    I have attached here an image of the device installation, and an image of an installation of the batteries that was carried out.


    last question is about the things written in the script

    what does it mean (what do they do)

    DECL INT _nIndex

    DECL FRAME _fOffset

    BASE_DATA[1] = BASE_DATA[2]

    $NULLFRAME

    BASE_DATA[1] = BASE_DATA[2] : _fOffset


    I know it might be some stupid questions but I didn't fully understand the script and I need to explain it in my article



    and how do I know which variables exist and which ones to use? Is there somewhere to comment on them? because I searched a lot and found nothing.

    I have access to trainings 1 2 and 3 that came along with the robot, but I didn't find anything about those writings there.


    when I have time I will test the panic mode script.


    thanks again for the help!


  • -I don't know why but the smartpad jog and the smartpad move buttons were inverted after I loaded the workvisual project

    Define "inverted". This can mean many different things. Also, which jog mode are you using? World? Base? Which Base is active?

    -For our research, the SPTP we need was registered, in our case it was 4 points, but when executing and simulating the movement, the "axis 4" seems to lose its position settings and auto-adjust to compensate for the movement. however axis 4 has a rotation limit and as the robot moves through the positions it twists to the limit and loses speed drastically. (I put the robot to weld and due to the drop in speed the welding torch pierced the plate)

    -still on axis 4- when I move the robot through the jog, it just moves axis 4, twisting to one side or the other. the others remain in the same place. we are having to register the SPTP by the buttons of each axis. (We use the axis mode to move the robot).

    Typical symptom of wrist singularity. How close is A5 coming to 0 during these motions?

  • Quote

    Define "inverted". This can mean many different things. Also, which jog mode are you using? World? Base? Which Base is active?

    in jog, when I push left it goes right, if I push up it goes down, and if I turn clockwise it turns counterclockwise

    on the buttons when I press, for example, " + "to move the A2 axis, it moves backwards (I think the image I put will help to see)


    I'm using axis mode


    which base is active I don't know. I do not know what is



  • Quote

    Typical symptom of wrist singularity. How close is A5 coming to 0 during these motions?

    the stitches are short between them, but they are according to the image of him welding that I sent along, I think they are not close to 0 it starts aligned according to the image but goes 150mm and starts to completely twist the axis 4

  • in jog, when I push left it goes right, if I push up it goes down, and if I turn clockwise it turns counterclockwise

    That's... meaningless. How the robot moves depends entirely on what jog mode you're in, and what Base/Tool you have active.

    on the buttons when I press, for example, " + "to move the A2 axis, it moves backwards (I think the image I put will help to see)


    I'm using axis mode

    No, you're not. In your own photo, you have Base mode active. Which means you're jogging in Cartesian coordinates, in a Base frame we know nothing about. Activating different Bases can easily change the robot's reference frame and make it move differently.

    which base is active I don't know. I do not know what is

    ....what? If you don't understand even that much, then this entire thread until now has been meaningless. Have you even read the basic programming manual?

    the stitches are short between them, but they are according to the image of him welding that I sent along, I think they are not close to 0 it starts aligned according to the image but goes 150mm and starts to completely twist the axis 4

    A5 is axis 5 of the robot. If A5 comes close to 0deg (in other words, straight) during a LIN or CIRC move, it can easily cause A4 and A6 to counter-rotate until one hits a limit (usually A4 on this robot model, as it has tighter limits).

  • in jog, when I push left it goes right, if I push up it goes down, and if I turn clockwise it turns counterclockwise

    sound like you are using space mouse to move the robot but you are using to move robot joints. this has to be the most awkward way possible to move robot...


    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

  • ok, sorry for my lack of knowledge, but this is not my area and it was really necessary to use the robot in the research, the stacked cords will be used in tests for mechanical and microstructure analysis.


    but I really don't know what ":" on line 10 is for

    I don't know what "BASE_DATA[1]" and BASE_DATA[2]" means


    because the _fOffset variable is equal to $NULLFRAME and what would that $NULLFRAME be. on line 8


    the focus of the research is really the stacked cords and their analysis, but I want to explain how the script works

  • but I really don't know what ":" on line 10 is for

    It's the "Geometric Operator". You can look that up in the manuals. Short version: It performs a 6DOF matrix multiplication of two 6DOF variables (FRAME, POS, or E6POS in KRL). These are Structure variables that contain (among other things) values to define positions in space in 6 Degrees Of Freedom: X, Y, Z, A, B, C (where A is Rz, B is Ry', C is rX", in Euler rotation notation).

    I don't know what "BASE_DATA[1]" and BASE_DATA[2]" means

    Again, you really need to read the manuals. Short version: $BASE is the "active" Base, or "reference frame", that the robot is operating in. Each entry in the BASE_DATA array is a user Base that can be edited by the programmer to fit their own needs. Each Base is a transform relative to $WORLD, which is (normally) located in the center of the bottom of the robot's base, with Z+ pointing straight up and X+ pointing in the direction the arm points when A1 is at zero degrees.


    When using a program with Inline Form (ILF) points, the ILF includes a menu option to select which Base (BASE_DATA) is to be activated, and the ILF takes care of $BASE=BASE_DATA[whatever]. If you're not using ILFs, then you'll need to program that yourself.


    In the example I wrote, BASE_DATA[2] was the original un-shifted Base, to be set up once and never shifted. BASE_DATA[1] was the "scratchpad" Base, used as a copy of Base 1 with an additional mathematical offset added. That program was written assuming your P1, P2, etc points were ILF-programmed using Base 1.

    because the _fOffset variable is equal to $NULLFRAME and what would that $NULLFRAME be. on line 8

    The very next line sets the Z value of _fOffset. The $NULLFRAME set is to reset the entirety of _fOffset to ensure every unused element of _fOffset (.X, .Y, .A, .B, .C) are set to 0 and not left undefined. The Geometric Operator faults if any element of the argument variables is undefined.


    So when using only one element of _fOffset, the simplest approach is to set _fOffset to $NULLFRAME, then set the one element (.Z in this case) that we're actually using).

Advertising from our partners