Messages

Hello,

The KR3 is indeed a bit old, but you can find a 3D model of it on the regular KUKA downloads page (Downloads, CAD, Archive). Here's a direct link that should hopefully work: http://www.kuka-robotics.com/res/sps/8ba89f50-3ccd-4361-9b9a-60bdd0662ac6_kr3_STEP.zip

We do integrate new robots for our members for free, so if you decide to become a member it's no problem integrating it into PRC as a native component!
Best,

Johannes

Hello,

Definitely make the aluminum plate shorter if you only use it for the Kress spindle, there's no advantage in having a longer aluminum plate and I would rather scratch the robot with a plastic part then a sharp aluminum edge ;)
That being said, we never had any serious problems with the plate, so it somehow worked.
What do you mean by "so low"? If you refer to the distance between the flange and the tooltip you've got two factors that act against each other: The closer the distance is, the more it is likely that the robot's A5 collides with the ground when you do five-axis milling - the further away it is, the less stable the setup becomes. So you just have to find some compromise between those two.

I quickly threw together a definition where you can dynamically adjust the length of the plate and test it in PRC - that should make it easier to decide!
Note: Only works with the most recent member version of PRC!

Best,
Johannes

Hello Bob,

I just sent you an eMail, but maybe this is helpful for others as well - instead of using a helix you can also slice it into circles (in the case of a tube) and then flip the direction of every second circle so that the robot automatically unwinds itself.
The attached example uses the new PRC for the robot components, but most pathplanning is native Grasshopper anyway!

Best,
Johannes

Hello Alex,

Well, proper multi-robot support is hopefully incoming - I'm working with the RMIT guys and FabUnion on finding a nice solution.
I just checked again and robot|tool collisions seem to be working (see attached image). For a multirobot setup you would currently have to take the GEO output of the core component and then look for intersections/collisions, e.g. using the Collision One/Many component or the Mesh Intersection.

Hope that helps,
Johannes

Hello Bob,

It's important to mention that KUKA|prc is a "universal" tool and not a specialized milling solution. If your plan is to do mostly milling it definitely makes sense to e.g. get RobotMaster and MasterCAM (though they are quite expensive in the five-digits).
That being said it's totally possible to do additive fabrication, milling, wirecutting, etc. and quite many users utilize it exactly for that, look e.g. at the videos of Artis Engineering (not all are done with PRC, though) https://vimeo.com/user12374666

I've attached an example how the cylinder could for example work, the other surface wouldn't be any different. As mentioned in the other eMail, please send me an eMail for the temporary license (johannes@robotsinarchitecture.org).

Best,
Johannes

Hello Bob,

There you go, please find attached a quick definition. Also take a look at the files in the tutorial sections. Regarding the project, some things are important to keep in mind:

- If you're moving in a spiral, you will "wind" the robot up - every axis has got a certain axis limit, and if you keep turning in the same direction it will run into that limit. For some robots, you can set the axis 4 and 6 to infinite rotation, which would be helpful for your project (the Agilus for example can NOT rotate A4 infinitely as A4 contains the pressured air tubing).
- Even if the robot can move everywhere, the cable of your tool may wind itself around the robot.
- The "winding up" is not simulated in the "free" KUKA|prc, I would recommend taking a look at the member version, for which I can issue you a temporary license. Just send me an eMail.

All the best,
Johannes

Hello Alex,

Well, the usual way is to split the path into several segments as you mentioned - any particular reason why you want to avoid that?
It should be possible to adjust the speed while a program is running, e.g. via an analogue input if that is what you're after! If I remember correctly, $OV_PRO is the variable that controls the override speed (in percent, like you set it at the control panel)!

All the best,
Johannes

Hello Bob,

I've quickly put together an example how that could work, see attached files.
It doesn't yet include any robot-specific code as I don't know which version of PRC you are using. If you're using the old PRC version, right-click the LIN-movement component to switch it to using planes as the input geometry.

Hope that helps!
Best,

Johannes

Hello Joanne,

There are a number of reasons why that could happen - but first of all, are you using the member version or the regular version of PRC? We did quite a few improvements to the robot simulation in the new PRC so that it's much more accurate now.

Ideally also send me the file where the problem occurs!

Best,
Johannes

Hello,

That sounds interesting! So you basically want to create your own PRC for a hacked Mitsubishi robot?
Seeing as you've got full control over the controller and IK, you probably have to define some format how the control data for the robot should look like, and then represent it in Grasshopper. In PRC we basically "queue up" the LIN, PTP, SPL, etc. commands and the core component then generates a control data file that can be read by the robot.

For developing GH-components, you can either use .NET (VB.net or C#, can compile into DLLs/GHAs) or Python.

Best,
Johannes

Hello Bob,

Hmm... Let's make sure that I got that correctly: By "complex surface" you mean polysurface, i.e. multiple joined and possibly trimmed surfaces?
We've done quite a few milling projects with "native" Grasshopper, and while it is totally possible to create your own surfacing and roughening (usually more difficult) code, it's quite tedious and slow, as regular milling software also takes a few seconds to minutes to calculate toolpaths.
From my experience - if you don't mind the slight loss in resolution it's easier to deal with one mesh, rather than many (trimmed) surfaces. At the end you end up with polylines anyway, so using meshes instead of NURBS isn't that bad.

So if you e.g. want to mill hundreds of similar objects it makes sense to code it yourself in GH, otherwise (e.g. for single objects that you want to mill) I would recommend to use CAM software to generate the toolpaths and then turn it into robot code through PRC. Natively we support SprutCAM (which is also free for universities and students) but it should work with most CAM code.

It's a feature of the member version, but I can issue you a temporary license!

All the best,
Johannes @ Robots in Architecture

Hello Mavrick,

I wouldn't call Delcam and KUKA|prc "competitive software" - with Delcam you can do milling etc., while you can use KUKA|prc to do nearly anything - take a look what e.g. Artis Engineering is doing in Berlin: https://vimeo.com/user12374666
So for milling it definitely makes sense to use specialized software like Delcam, MasterCAM/RobotMaster, etc.!
You can of course still do milling with KUKA|prc quite nicely, either by programming your toolpath-strategies yourself or by importing G-Code, e.g. from SprutCAM. We recently added a functionality to output positions in a format that can be read by KUKA CAM.Rob for very large filesizes.

So to sum it all up:
Delcam = specialized milling software
KUKA|prc = general parametric robot control software (but can also do milling)

All the best,
Johannes @ Robots in Architecture

Hello Matthias,

Let's deal with that directly via eMail, if that's alright for you.
I have some ideas, e.g. an option for the Custom KRL component that puts the code outside the regular KRL...

Best,
Johannes

Hello Matthias,

Hmm... At the moment I cannot think of a really easy way to do that. First thing that comes into mind is that you expose the filename and save option (by right-clicking the Core component and selecting the option) and then adding the subprograms "manually", i.e. by reading the .src file (via Read File component), adding the relevant lines, and then resaving it.

But do the interrupt subprograms really have to be parametric? I'm mostly curious about the application...!

Best,
Johannes @ Robots in Architecture

Hello,

This forum is related to KUKA|prc, which is a different product from KUKA SimPro. Here is the link to the KUKA.SIM Helpdesk: http://www.kuka-robotics.com/en/products/software/kuka_sim/kuka_sim_detail/PS_FAQ_KUKASim_Kontakt_Detail.htm

Best,
Johannes @ Robots in Architecture