Posts by Xerces

Thanks guys for the answers. Will look into these options

I will see if I find a way to solve this using the SPS. I have a tight cycle time on this cell so I cannot afford the robot to stop.

As I tried to explain earlier this problem occurs when the operator safety is broken when the robot has passed its signal check to see if the machine is ready. The machine then will loose its air pressure since it can be dangerous with pressure on, hence machine is not ready for robot anymore. Then when starting again robot will continue where it left and it still believes the machine is ready, which will result in a crash.

One thing I can do is checking the ready signal again right before going into the machine, but then I would get a little stop on my motion since I have to stop to check the signal. Which is something that is critical for my cycle time.

Quote from SkyeFire

Couple options here. You could add the signal settings you need to the User sections of IR_STOPM, which gets called by most fault-based program halts (assuming you're using the standard templates). It also has a "restore" section that executes when the program is resumed. It's used a lot in MIG and laser welding, to avoid burn-through but also enable resuming a weld without interruption.

Even if IR_STOPM isn't suitable for your purposes, studying it and how it's called via interrupt can be very instructive.

Second option would be to use the Level 0 interpreter (SPS or Sumbit).

Yeah I could do something in the submit. But I tought interrupts would work even tough the program is not running. I tought the robot checked for changes in the signal used in the interrupt also when the program is not running. And since the robot runs the interrupt program on the next fine point or wait sec then it has to know that the signal that triggers the interrupt has been set. Find this a bit strange tbh.

Hello guys,

Im haveing a issue with the use of interrupt, tried to search the forum but couldn't find the answer to this specific case.

KSS version: 8.5.6

Robot: KR 120 R3100-2

The problem happens when the program on the robot is stopped either because of operator safety is broken or the robot program is stopped on the KCP. If the trigger signal for the interrupt gets activated while the robot program is stopped, the interrupt will not be triggered before the next motion without approximation or something else stops advance runner.

So this kind of ruins my failsafe, cause I got a machine that the robot works on that isnt ready anymore if the operator safety is broken since it then will loose vacuum, and when starting the cell again we have to do some things on the PLC to make it ready for the robot again. But the robot keeps on going all the way till the advance runner stops and if that occurs the robot would crash with the machine. In my interrupt routine I only have brake signal to stop the robot and a WAIT FOR the machine to be ready again.

When the robot program is running the interrupt works as planned, as soon as we get the signal for the interrupt the robot does exactly as planned and the interrupt routine is called.

So the code on the robot is like this:

Wait for machine ready

Turning interrupt ON

Local home position for machine

Stopping program here, and signal that triggers interrupt occurs.

Approach position for machine

In position for machine (motion without CONT)

Interrupt will be triggered and robot goes into interrupt routine.

Exactly, we've tried that but then we get error on eio.cfg file.. Maybe its something they have gotten rid of in RW 6.01... Stupid if so

I've got version 6.01.6495.1010. And there I cannot see it, but how is the syntax in youre EIO.cfg file for the signals you choose too store?

Well, I cannot see that radio button anywhere, yes it is there in the older versions of robotstudio but not here as far as I can see:

Hello!

I was wondering if this function store signal value at powerdown is just gone at Robotstudio 6.01.X and RobotWare 6.01.X? Cannot find it anymore. If someone has some info about it that would be highly appreciated.

Thanks

Well as I see it you got all the answers in the forum threads youve inserted links too =)

Maintenance cannot only be counted in hours, for example a robot that has been used for 2000 hours over 3-4 years still need oil change and stuff. Cannot really remember how often they recommend to change the oil,if it is every 2nd year or every 5th... Also isnt the oil change on the wrist axis's (A4,A5,A6) 5000 or 10000 hours?

Or, he could just remove Status and Turn from the E6POS variable in the .dat file and the robot will sort out the rest itself

Yeah for now we've done a edit in the template for the FTCtrl Monitor and just added a ETHERNET object there so we get out the same data as the built in RSI monitor in Kuka.

We are exploring the options to monitor also when the FTCtrl is not in use, just too see how big forces we get during movements and stuff.

Thanks for that Skyefire! Ill look into it. We tried using the ATINETSENS block and monitor that one, but then we got a fault when we tried to use the FTCtrl at the same time saying that the FTCtrl couldnt run because the atinetsens allready was active.

Hello!

We are using Kuka FTCtrl on KRC4 and we want to get the monitoring values out to a external system.

I found the file FTCtrl_User_ConfigNameXYZ.rsi under c\KRC\TP\FTCtrl\Templates\UserRSI on the robot. This looks like this in RSI visual:

Problem is there is no documentation however and I find the RSI quite difficult to work with. So I was wondering if someone had used this earlier and had some tips on how to get this values out to for example an PLC via ethernet. Ive tried adding a ethernet block in RSI visual, putting all the files in the Sensor Interface folder and used the test server that Kuka has in its RSI folder.

The versions being used is:

Kuka RSI V3.1.4
Kuka FTCtrl V3.0.3

Quote from Metalikooky

Flag evaluations trigger an advance run stop. If the robot is in the middle of a move while this advance run stop occurs, you may see a momentary stop in motion.

Try writing a CONTINUE on the line previous to any IF... statement in this routine.

So it would look like this:

CONTINUE
if $flag[28] then
H1pour8()
endif
CONTINUE
if $flag[29] then
H1pour9()
endif

The CONTINUE forces a continuation of the advance run pointer, thus allowing your motion to continue.

Display More

To make sure youre programs is executed at the right times I wouldve have used a subroutine which I wouldve called with a trigger distance function (cause I guess you have points you can trigger on). Cause as SkyeFire mentions, continue can be a bit dangerous at times. Also as mentioned here a switch for all youre pour programs might be a bit cleaner..

So I would have maked the code something like this:

; If distance=1 it will jump into the subroutine when the first position after this line is reached.
TRIGGER WHEN DISTANCE=1 DELAY=0 DO Prog_Pour() PRIO=-1

DEF Prog_Pour

CONTINUE
if $flag[28] then
H1pour8()
endif
CONTINUE
if $flag[29] then
H1pour9()
endif

END

Hello guys!

We have a robot with a little unusual tool on it. This tool is connected with a toothbelt to A6 so the rotation doesnt happen in A6 but is offset a little bit out in the X-direction.

Does anyone know if its possible to change some parameters or something to get the robot to understand that the A6 has been "moved"?

Any help would be appriciated since we've tried to contact Kuka but havent gotten any secure answers or help with this.

I tought you where using the inline formulars for KUKA. Thats why I had the IF FALSE block. If youre gonna hardcode it then you can declare everything in the program like under, guess R1 is youre external value, to test it i wouldve declared it and assigned a value like under.. But as Skyefire says the normal thing is to defince the positions in the .dat file.

DEF k10()
DECL FRAME x1
DECL FRAME x1Calc
DECL INT R1

R1=10
x1Calc= { X900, Y 0, Z 1162, A 180, B 0, C 180}
x1 = x1Calc
x1.x = x1.x+R1
PTP x1

END

If youre gonna make an offset for a rotational angle you can write x1.a, x1.b, x1.c. All depends on which angle you want to offset.

Well I guess there is some ways doing that, but a simple way is to do it like this:

Lets say youre teached point is called Move and youre INT with x-value from the external device is called x.value then the syntax would be like this:

xMove.x=xMove.x+x.value ;The x before Move is just syntax from kukas side and is necessary to write directly into the position variable. This line adds x.value to youre current X in Move.
PTP Move

END

Hope you understand if not just ask And remember, with this kind of syntax it will add x.value everytime and therefore youre x will always increase. If you want it to always have the same start point before offset is done you need too use 2 position variables. For example like this:

xMove=xMoveCalc ;Copies so you always have the same starting point from youre offset.
xMove.x=xMove.x+x.value
PTP Move

IF FALSE THEN ;Since youre not gonna move to this position
PTP MoveCalc ;This is just the position you always offset from.
ENDIF

Youre logged in as expert I suppose? Have you tried logging in as safety maintenance instead whent transferring the project?

Also sometimes you need to transfer the project 2 times because of somekind of bug with activation.

Hi guys!

Just tought I would share news I got from Kuka now, there is a bug in theire Kuka ForceTorqueControll V3.0.2 that affects Workvisual. You wont find youre project if you choose browse and you will get a fault message saying: Error retrieving cell information from device at XXX.XXX.XXX.XXX.

So if you experience this problems you know whats wrong.... =)