Kinda Lost between all of those options

You also have the option where the CAM post processor can generate native KRL. Robotmaster (Literally Mastercam for robots) is one of those.

What software is best for you depends on your needs (and budget).

Would be valuable to know (for cost/benefit) if these parts will be constantly changing- the program creation will be an ongoing process or if these programs will be created once and used for years.

Kuka.CNC is one of the most expensive options. If i recall it was more than $10kI USD. One of the advantages is the it could run huge NC programs. You can check READ FIRST for more info and getting documentation from Kuka Xpert portal.

If you just need a proof of concept then I would say write the KRL code by hand. Not very innovative, but short of running free trials of the programs, cheapest solution. Keep in mind the full project might not get a green light even after successful prototype if the plant management decides they can't afford the space/insurance/blood sacrifice/investment/disruption.

Quote from Robot2

a lot of the options available are very expensive considering the relativly simple task that we are trying to achieve.

I hate to say it, but there's nothing simple about it. Even for a CAM path that appears simple to the human eye, there's a lot of computation involved, and a lot of software engineering required to make sure it works with sufficient reliability across all use cases.

Also, the cost of creating this software doesn't really "scale down" -- the cost of creating a good CAM software for "simple" tasks really is any less than creating it for "complex" tasks, except when you make complexity jumps like going from 3-axis to 4+ axes. And a robot has 6 degrees of freedom that have to all be taken into account, so you're almost automatically in the expensive end of the pool.

Quote from Robot2

For example from what I understood robotDK is not capable of creating toolpaths and I dont know if it is worth it to get another software + RoboDK for what we are trying to achieve.

I know that RoboDK can generate 3D printing paths for robots -- I would assume CNC paths are possible. But I would recommend talking to someone at RoboDK. I do know there's a module in RoboDK named KUKA_CNC, although that might only be a postprocessor for KUKA.CNC.

OctoPuz is supposed to have similar abilities. And I know there's a KUKA Post-processor for Fusion 360, though I've never used it. Still, for a low-cost proof of concept, it might not be a bad place to start.

What kind of cutting job is this? Would it be doable with a simple 3-axis CNC path, or would it require something more equivalent to a 4- or 5-axis CNC? For a simple 3-axis path, it's possible to create a simplistic post processor to convert GCode commands into KRL commands. I built one several years ago just to show that it was possible (attached). I wouldn't use it for production, but for dead-simple GCode (simple G1 commands, no Arc/Circle commands, etc), it worked.

Quote from Robot2

all I can say is that with my low experience in the field and no experience with CAM software I am lost.

is diametrically opposite of :

Quote from Robot2

the proof of concept that I am supposed to make is nearly automated part cutting

......

In one month I think I can have pretty good results.

i would say good luck...

you can contact manufacturers for trial versions of software. some may have it. some may have trials that last a month though i would not be surprised if that is limited to shorter interval (week or maybe two) if at all. you may have much better success talking to CAD/CAM companies directly and requesting demo.

Another thing to consider is that with a cnc machines it is relatively simple to go from a calculated toolpath to a accurate cut product. With robots this is a lot more difficult. Robot base and tool must be calibrate perfectly to get an reasonably accurate cut.

Robots are a lot less stiff and you will notice that.

I have looked in to getting CAM software for our robots a few times and each time i come to the same conclusion: To expensive! (for us)

I have gone for a different approach. Most of the product i have to cut need relatively simple work. a circle hole here, a slotted hole there. stuff like that. So i made some default functions to do just that. so in code you get simple commands like: cut_circle(60,6) which means cut a circle 60mm in diameter 6mm deep.

I do get more complicated work now and then, but i can calculate those tool paths by hand. it is bit tedious but certainly not impossible. As long as i don't have to do that each week i am not buying cam software.

Quote from Robot2

But I still need to generate the toolpath for it to be working and I have no clue on how to generate a 3 axis toolpath .

Ah. Well, that's not too hard. Doing it well is what gets professionals the big bucks, but for a proof-of-concept where you can muddle through with trial-and-error, it's doable.

I found MeshCAM to be a great entry-level tool for generating a toolpath, but the free trial only lasts 15 days. Wouldn't hurt to play with it in that time frame, though. Very educational without drowning you in options.

Fusion360 is probably the free option with the most gradual learning curve, and there's lots of tutorials online. The free version is limited to 3-axis toolpath output, but the Pro version is probably the cheapest path to 5-axis I've ever seen, barring perhaps FreeCAD.

FreeCAD is open-source and supports plugin modules that will do CAM output. I've always found it hard to get into, though. Last I checked, FreeCAD had experimental support for 5-axis, but it still had a ways to go.

MeshCAM is a "standalone" path generator -- that is, you import a 3D shape (usually STL) into it, describe the stock you want to carve that shape out of, and hit the "generate" button. FreeCAD and F360 are both integrated packages -- you would need to import the 3D model of what you want to create into their Design workspace, maybe make tweaks to it, then shift to the Manufacturing workspace. At that point, it works a lot like MeshCAM, just with a lot more options.

To put it very simply, you give the CAM program the shape you want to end up with, and the shape (stock) you're starting with. You describe the materials, speeds, and tools you're using, select the postprocessor for the machine you want to run the path, then hit the button and stand back. The CAM engine will spit out a G-Code file written for the dialect of your specific machine.

That's where the serious complexities start, and it can feel like trying to drink from a fire hose. I would recommend just downloading one of these packages, CADding up a fairly simple shape, and work your way up the learning curve in small steps. If you have a robot you can play with, starting with some simple cheap materials (like wood) would be ideal. Make your mistakes early and cheaply, get a handle on getting the robot to go where you need it to without breaking the cutter or smashing into things, then work your way up to the actual production material.

Quote from Leon

Another thing to consider is that with a cnc machines it is relatively simple to go from a calculated toolpath to a accurate cut product. With robots this is a lot more difficult. Robot base and tool must be calibrate perfectly to get an reasonably accurate cut.

Robots are a lot less stiff and you will notice that.

This is a definite issue. On a CNC machine, you define a 0-reference point (location and orientation) in the workspace, then physically define the same point on the object you're making. Most often, a corner of the stock material is used, but you can also use a key feature on the part pallet or vise. For a robot, you'll need to do the same thing, but it can be a bit more complicated. Best option, IMO, is to define a Base in the robot using the 3-point method, and pick something you can both define in the CAD/CAM model, and physically touch-off to in the real world.

Also, no robot will ever be as accurate as a CNC, or as stiff. So don't expect tight tolerances. There are some tricks you can maybe use to make it a bit better, but we should save that until you need it.

Would linking the turntable to the kinematic system as a synchronous axis not be easier, simpler and have less points of failure?