Program doesn't work in T1/T2 mode (and also in automatic)

Does it execute programs in AUTomatic mode?

When trying to execute program in T1/T2, do you keep deadswitch and play button pressed?

Can you show us the program code?

Maybe the program speed is set to 0?

Does the robot execute non movement code (calculation, initialisation, etc.)?

Post the actual program.

Details:

1. What error messages (if any) occur when you try to run the program?
2. Does the program execute to the end, hang on a particular line, what?
3. Do any axes move when you run the program?

can you please try to aim your camera at the teach pendant? it would be helpful to see entire screen and without all the reflections.

this is English forum so if you expect help here, change your HMI language to English before taking the screenshot or your posts will be moved to Other languages.

controller CANNOT run program when robot is at the soft limit, according to Google translate you have more than one axis at the limit. of course it will not run,.. you need to jog those axes away from limits. also do some maintenance on your system.

As Panic says, message 205 indicates that an axis (two axes, in your case) are on the soft limits. This prohibits program execution. Also, any point programmed with a location hitting an axis limit will not execute.

On the KCP, the color of the "R" icon in the bottom status bar indicates the program status. Yellow indicates that the program has been Reset or freshly Selected, and has not begun execution. Green indicates that the program is executing. Red indicates the program has halted for some reason. Black indicates the final line of the program has been reached and there are no more lines to execute.

In T1, when you press Step Forward, the "R" should change from Yellow to Green. If the program hits an error, or if you release the Step Forward or deadman, it will change to red.

From the screenshot it seems that the robot did go through Bas(#initmov,0). If it's trying to move past axis limits, that could be because tool or base it's using has been changed?

Try and programmatically move it cannon position; should be something like :

ptp {a1 0, a2 -90, a3 90, a4 0, a5 0, a6 0}

Slowly though, don't want to tear out any cables

much better....

your screenshot shows that robot is in T1 mode, override is 100%, programmed speeds are only 10% but that is ok, drives are on and - your program is RUNNING.

this means all issues related to safety, permissions etc are cleared.

what you may have is a very low acceleration value. so robot is moving but... really it is just creeping very very slowly. in a month it will reach speed you may observe. probably someone was messing with BAS.SRC or $CONFIG.DAT or MADA.

so i would open those inline forms or use Single Variable Monitor to check acceleration.

Francesco Pantoli , can you please upload the complete robot backup?

Ok. I will take a look at it.

Francesco Pantoli, at this first look, I didn't found anything strange on Your backup (and next time, a simple archive would suffice).

But at Your sps.sub, You have this code

IF ANTICOLLITION==FALSE THEN
$OV_PRO=0
ENDIF

I've saw on Your pictures that speed was 100%, but I would take a look at this ANTICOLLITION signal, $IN[5], according to Your $config.dat

yes, this is arc welder so collision sensor is either not wired or it is tripped.

you can use single variable monitor to check any suspect variable

$IN[5] or ANTICOLLITION

$OV_PRO

$ACC_AXIS[]

$ACC_EXTAX[]

$VEL_AXIS[]

$VEL_EXTAXIS[]

etc.

you cannot change input value from controller side. you need to either influence external signal (wire it correctly and reset collided clutch). on controller side you can only bypass it or remove it. this input is a safety for your arc welding torch and you should not bypass it except for debugging.

simple way to passivate it is to comment out $OV_PRO=0 in your SPS. but beware, if your tool collides with something, robot will no longer stop.

One specific weakness of controlling $OV_PRO from the SPS is that, if the SPS is trying to set the SPS to 0% while someone is trying to change the SPS from the pendant +/- softkeys, the KCP display can become "disconnected" from the real value of $OV_PRO. One way to check if this has happened is to open the Variable Monitor and type in $OV_PRO. This will access the real value of $OV_PRO. If this value disagrees with the number displayed in the KCP's upper-right corner, you've encountered this issue.

Another cross-check is to open the Position Monitor while attempting to run the program. If the robot is simply moving or accelerating very slowly, you should still be able to see consistent motion in the Position Monitor. If there is no motion in the PM while the program is running, this strongly suggests that $OV_PRO has been set to 0%, as other posters have suggested.