Posts by desertgiant

The memory issue and the kuka smartpad freezing is a known issue and I have been facing it every now and then.

You can validate if this related to the same issue I am talking about, by doing a cold restart of the system. The system starts behaving normal until one point where the hmi freezes out and handling smartpad would be impossible.

Regarding the movement of files to D folder, what kuka claimed, everything under the R1 folder would be loaded to the ram and would stay in the virtual memory. The more garbage files exists, the slower the pc is going to behave.

One more situation where I have seen this happening is writing too many temporary messages. Kuka advised to store messages to variables and write and erase from the variable before loading the next one. loop messages remains in virtual memory blocking spaces and when infinite loop messages are written, the system starts behaving strange. I assume same applies to submit.

Talk to kuka, they usually have a ready made solution in the form of software updates / patches for this as this is not a new problem and it exists since kss 8.3 and i am seeing it also sometimes at kss 8.7.

KUKA KRC5, KR240 - 2

Has anyone successfully used KUKA joint torque values to identify the placement of a workpiece against a hard stop?

I need to align a workpiece precisely to a machine. The part is first identified and picked using a camera and must then be positioned accurately on the worktable. The robot in use is a KUKA KR240, and the total weight of the workpiece along with the gripper is around 130 kg.

I’m exploring two options:

1. Force Sensor: Are there any suitable force sensors that can be mounted on the robot's end-effector to detect force feedback when the robot moves against the stopper?
2. KUKA Torque Variables: Is it possible to utilize KUKA’s internal torque values to detect contact and ensure correct placement? If so, what variables or methods would be best for this application?

Any insights or experiences would be greatly appreciated!

Geometric operator is quite confusing and complex is you donot understand the underlying math behind it.

The first command shifts the base in the direction of your end Y and the new base will be moved by Y = 100 mm in the Y-direction where your Base[1] is pointing its Y.

In the second one you are shifting your global frame.Y to a new position which is old.Y + 100 mm

Write both values to a variable and see the difference to yourself.

FRAME var1 = BASE_DATA[1]::{X 0, Y 100, Z 0, A 0, B 0, C 0}

FRAME Var2 = BASE_DATA[1]

Var2.Y = var2.Y + variable

KUKA developed a tech package called AppTech

One module of this tech package is - Return to Home function.

It gives following possibilties:

1. return back in same way the robot moved to station/complete the loop and move to home

2. fail safe loop that moves the robot to nearest home.

In any case the robot decides which way is the correct one based on the status variable activated.

it also performs the gripper action programmed by user in such situation.

All this happens through one touch at the reset switch.

What I understand is

• You have a global dat file which includes the global positions
• You have your local program where you teach the positions
• you have a sub file which reads and assigns the local var to global var.
• Your global values are not populated.

From a sub file you cannot copy a local variable.

Try the following

#Your teach program might looks like something below
&ACCESS RV1
DEF  WritePosfromBG ( )
......
SPTP inline Pos1

SPTP inline Pos2
END

#Add your update program here
GLOBAL DEF update_bg_pos()
gpos[1] = XPos1
gpos[2] = XPos2

END

Call this update_bg_pos() from sub file.

However, be aware that this function manipulates a position variable in the background logic. Improper synchronization can lead to unexpected behavior or potential issues.

Proceed only if you fully understand the risks and have taken the necessary precautions to ensure proper synchronization.

You cannot use the arrays in an inline motion command of kuka.

One way of handling such problems when you have to store data points to array and call back during motion is to create a commissioning program where the individual data points will be stored to global position array and call back the position based on index in your motion program

;;------------------------
;; Commissioning program
;;------------------------

SPTP P1 (Use Inline form to create positions with tool and base data. Store position)
....
Create number of positions needed. 

Finally at the end store this positions to your global array

gPos[1] = Xp1
gPos[2] = Xp2	;; This is important otherwise the changes will not be updated to the global pos 


;;------------------
;; Motion program 
;;------------------
;; get the value of index to be moved 
xMove2Pos = gPos[index]
SPTP xMove2Pos (Use inline form to create pos with tool and base. Here the used tool and base must match the tool and base used during commissioning)

Thats how Palettization robot works.

A1, A2, A3 and A6 are active and A5 is grayed out.

The Axis A5 moves in synchronization with Axis A2, A3 movements s.t. the flange is parallel to the ground/base plane.

The only time A5 gets active is when axis loses its synchronization and we need to bring the axis back to synchronization in T1 by moving the Axis A5 s.t. the axis back in synchronization.

This is identified by seeing the axis A5 getting grayed out.

I have a KUKA KRC5 Controller with EL6695 connection to PLC at Application level and Safety via Hardware Safety Interface XG11.1, 11. 3.

Currently the function to open/close door is handled from the robot sub program.

I am currently using the 2nd Brakes A2-A5 (XG11.3 Pins 3-9, 6-12)as a requirement to enable the opening of the safety door at the hardware plan.

When the robot is in T1 mode, the relay is TRUE and I can open/close the door with the std. door opening/closing output signal. At EXT mode when I set the signal to open the door, the Brakes A2-A5 signal relay is FALSE when the Operator safety is set to False.

I tried turning down the DRIVE_ON and DRIVE_OFF signal but this does not change the state of 2nd Brakes A2 - A5

At What Application state the robot sets the brakes A2-A5 enabled in the Ext Mode ?

If this is not the correct signal which signal at the safety level can be used to denote the robot is in safe stop to enable the safety door opening function ?

Thanks

I think that is because of the ring buffer cycle configured.

They do it often to avoid filling disk with error reports.

Normally such ring buffers numbers can be changed based on user needs.

KUKA should be the best place to get further info.

Quote from SkyeFire

I'm not sure it's possible to set robot inputs from inside a Python script. To be honest, I haven't tried.

My first thought is to try wiring robot outputs to robot inputs, then control the robot outputs from the Python script. A bit hacky, but I don't see any reason it wouldn't work.

Reading and Writing KUKA IO from Python script is possible, atleast with Office PC / Office Lite.

But this requires additional interfaces like Y200 or VRC.

The signals set by the robot can be read from the variables defined in simulation and vice versa can be done to send signals to KUKA.

I have not exactly done what you need, but something similar.

Robot writes the position for the gripper in the $OUT signals.

This was defined as a variable in the SimPro Interface. and my python script was reading the input of the variables and was setting the required position of the gripper. And vice versa was done to read the status of the gripper from robot.

I donot have Simpro license to exactly explain what and where it was done.

When I was doing it I was referring to the training material from Visual components to do it.

May be check their site and see if it helps.

Updating this thread as I landed here after facing similar issue.

One possible solution could be to clean up the main project folder in the controller and leave the robot with no program selected and then connect via work visual.

Because some times the unused files in the main folder could have link variables with the Technology packet which prevents Workvisual from loading files.

After cleaning up the main project folder, I was able to connect via Diagnosis option of Wov.

This is really strange from KUKA.

SI document released in 2022 doesnot have info about $VEL_APPL whereas one from 2023 has.

Attaching images for reference

Changing the programmed velocity is possible before the start of the LIN movement.

To do this the velocity values in the respective LDAT params should be written before through a separate function and then the LIN/SLIN movement should be called.

This requires advanced KRL programming skills and setting wrong values can make robot perform unpredictable movements.

An alternative could be to play around the override values ($OV_PRO).

By setting a reduced override on specific condition can reduce the velocity of the movement.

You need to save the home position to an axis co ordinate system and copy the value to the XHOME variable under config.dat

The Home signal to be used should be changed under steu/machine.dat

After a few hustle the digital twin to the real robot with vision was established using the KUKA Office PC.

the simulated version of the camera here does not support calibration as done through KUKA VIsionTech HMI, hence the real calibration file from the KRC controller must be used.

When the image written to the Office PC is similar in dimension and pixel to the actual picture from camera the digital version can imitate the real robot movement.

The quality of the robot accuracy and repeatability in the digital world depends on how similar the image in digital world is to the real image captured from camera.

Was in contact with KUKA. They informed simulation of camera with reading image from folder is possible as they did it before for testing purposes. But this feature is strictly limited to Office PC.

I am currently in the design phase to commission a KUKA robot for a USA based client.

This is a Safe Robot.

Apart from the standard norms and regulations of EU, are there any special guidelines or commissioning/ software norms to be followed up for USA ?

Thanks in Advance

Thanks for the reply.

That is one possible and the best solution. The simulation software can communicate the actual position of the part to the robot and robot bypasses the vision callings in the simulation mode and use the frame to internally calculate its trajectory.

However the customer is pressing to use the same kuka software and wants to have the same behaviour in simulation like in real world.

The simulation software can stream the images to a specific port.

KUKA Office PC should be capturing this stream and make the KUKA KRL library think the stream is from a real camera and process further.

I am interested to know how such a solution can be solved with kuka and if there will be additional interfaces like the Y200 will be needed.

Do I need any additional interface like the Y200 ?

Because I have to somehow tell the KUKA Office PC that what it gets on KONI Port is not from a camera (Basler or Baumer) but from a simulated port.

Also when I look at the drop down box in the tools configuration page under VisioTech -> Task Configuration, it always looks for the missing camera.