axis variation for stacking welding layers

(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:

DECL INT _nIndex
DECL FRAME _fOffset

; Always reset Base 1 to original values before starting the build
: I'm assuming Base 2 is a permanent copy of Base 1 with no offsets applied
BASE_DATA[1] = BASE_DATA[2]
FOR _nIndex = 0 TO 100
  _fOffset = $NULLFRAME ; set to all 0s
  _fOffset.Z = _nIndex * LayerThickness ; generate offset for layer
  BASE_DATA[1] = BASE_DATA[2] : _fOffset ; apply offset
  PTP P1
  ARCON P2
  ARCOFF P3
  PTP P4
ENDFOR
PTP HOME

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.

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

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

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

Quote from domtoretto

-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?

Quote from domtoretto

-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 from domtoretto

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.

Quote from domtoretto

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.

Quote from domtoretto

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?

Quote from domtoretto

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).

Quote from domtoretto

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...

Quote from domtoretto

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).

Quote from domtoretto

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.

Quote from domtoretto

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).