kuka.cnc code generation

[gergole]

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?

[Johannes @ Robots in Architecture]

Hello Gergo,

Please note that KUKA.CNC creates a file that ends with *.nc and not *.src
So I would first check if you get an SRC file written, and if that is the case, change the code generation to KUKA.CNC and see if a NC file is written.

That being said, KUKA.CNC is complicated to integrate and leaves a lot of options to the integrator - so test it carefully and slowly.

Best,
Johannes

[gergole]

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ő

[Johannes @ Robots in Architecture]

Dear Gergo,

I'll send you an updated version via eMail to try out, just to see if it's your version of KUKA|prc or something else!

Best,
Johannes

[gergole]

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ő

[Johannes @ Robots in Architecture]

Hello Gergo,

Now that is interesting, could you please send me the file via eMail? You mentioned Fusion - please also include the Fusion 360 XML file!

Thanks,
Johannes

[Johannes @ Robots in Architecture]

Hello,

There was a bug that caused the code generation to fail, however there is a second issue as well:
We don't support CIR movements with KUKA.CNC yet. There is no special reason for that, we just never needed it and as a "Beta" implementation did not go further than what we needed for that project.
If you can provide some support (testing) and examples for CIR movements and KUKA.CNC I'd be happy to work with you to implement them.

In the meantime I would recommend not to use CIR movements with KUKA.CNC.

Best,
Johannes

[gergole]

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ő

[Johannes @ Robots in Architecture]

Hello Gergo,

I didn't get any eMails from you, maybe the file size was too large?
And it definitely wouldn't hurt to have CIR movements for KUKA.CNC as well.

All the best tomorrow!
Johannes

[gergole]

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ő

[Johannes @ Robots in Architecture]

Hello Gergo,

The last eMail I got from you was from Monday, I haven't received anything since then, also not in the spam folder.
Unfortunately I have no way of testing KUKA.CNC code so it is hard for me to troubleshoot, especially as the error message with the maximum speed is rather strange.
If you have previous code that ran in KUKA.CNC, can you compare it to the one generated in KUKA|prc? That might help you pinpoint the error message.
Did you maybe enter the speed in mm/min instead of m/sec? KUKA|prc internally multiplies the speed by 60000 for CNC. Just a quick idea.

But as I wrote in the beginning, KUKA.CNC allows quite a bit of customization, so it's hard to come up with a generic solution and that's why integrators charge a lot of money for customized postprocessors and integration in general.

Best,
Johannes