Messages

Hi there!

We have noticed a weird thing with our KR10.
We calibrated a tool and a base, then used a base movement offset 10m in the z axis to check the base geometry.
However, even if we only used x and y movements, the z value also changed when checking the display/actual position in the cartesian coordinate system, even at points, where we executed the base calibration. Any thoughts?

Gergely

Hello Johannes,

I hope my mail went through the other day...

I've been trying to excecute the kuka.cnc code for days. It initiates, and even completes the starting move added in grasshopper, but stops at the line, where the original fusion toolpath starts, with an error message from kuka.cnc, that the maximum angular velocity is exceeded.

I tried to modify the feedrate to extremely low values, but didn't help.
Befor we used MasterCam+Octopuz for simulation (at the moment our licence is out of date, and I would like to shift to kuka|prc). I tested some old nc code, and it worked.

I wonder, if the coordinet system is altered in kuka.cnc, so the otherwise normal move is interpolated in a way, that the axies need to do some extreme moves? Or could the version of kuka.cnc be a problem (it's 2.1)?

Tomorrow I will try to add some intermediate moves between the HOME and nc code strating positions, but I would really appretiate any advice to deal with kuka.cnc....

Bests,

Gergő

Dear Johannes,

Using circular movements was not on purpose: I just used the default settings of the fusion post-processor for KUKA|prc.
...and I found a solution for the moment: I set the minimum and maximum circular radius values to 0 in the post-processor.
The CIR-free XML code resulted in a valid NC generation in grasshopper. I will test the milling tomorrow.

At the same time, working on the implementation of CIR movements in KUKA.CNC sounds interesting since I'm working on architectural heritage projects milling/3D printing complex geometries based on laser scans. I sent you the files via eMail, please let me know if I can provide other data.

And thank you again for your help in locating the problem!

Cheers,
Gergő

Dear Johannes,

Thank you for your mail.
I updated KUKA|prc, but it didn't solve the problem.

I tried to play around with the toolpath by splitting it up, and it turned out, that the NC code can be generated up until line 1799, after which it stops operating. Up until line 1799, there are only LIN movements,  but Line 1800 would be a CIR command: could this be a cause?

Bests,

Gergő

Dear Johannes,

Thank you for your prompt reply.
I checked all kinds of options about the file generation (KRL/SUNRISE/CAMrob), which all generate files,
but KUKA.cnc option results in no file in the designated folder. I also checked the default location (desktop),
but there was neither any code generated there.

Could it be, that a certain component or setting is blocking the generation?

Gergő

Hello. I'm Gergő from the Kyoto Institute of Technology.

I'm using KUKA|prc 2022-01-21 and would like to generate a KUKA.cnc code for my KR22-R1610 robotic arm with a KR-C4 controller on KSS8.3.36.

I need to mill a complex geometry, so I have generated a toolpath in Fusion360.
Since the KRL code for even the first roughing was around 20 MB, I met the limits of the physical memory of the controller, so I would like to use the KUKA.cnc already integrated into our system.

However, when choosing the KUKA.cnc (beta)code option, no file is generated, even though the computer's processor has a high load for several seconds.

I left the settings at default, as you can see in the screen capture.

Am I missing something?