Messages

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

Hello Nate,

I've quickly thrown together a few examples how that could work, see the attachments of this post.
It covers a few possibilities, e.g. following the isocurves of a surface or projecting contours onto a Brep. Just disable the preview of the examples that you are not interested in, when you open the file there will be several robots visible at the same time.

Hope that works, let me know if you get stuck anywhere! I can also issue you a brief trial license of the current member version.
Best,

Johannes @ Robots in Architecture

Hello Ben,

The WorkVisual side is easy to troubleshoot (at least if you've got regular Beckhoff modules) - you just go to Display/IO, go to the output tab, select the output and then (while pressing the confirmation button on the back of the smartPAD as if you were moving the robot) click "Value". This should now toggle the state of the output, and you should see a light on the Beckhoff module go on or off. If nothing changes, there is probably some issue with the IO Configuration in WorkVisual.
On the hardware-side you have to get the voltage of the Beckhoff digital output (usually 24V) down to either 5V or 3.3V, depending on the Arduino. There are countless ways to adjust the voltage, personally I like the small step-down modules that cost like 4USD and allow you to adjust the voltage by turning a small screw (variable resistor). Alternatively you could e.g. connect the output to a relay that can be switched by 24V DC.
Please mind that I'm most definitely not an electronics expert myself (which is why I use 4USD step-down adapter rather than 30 Cents of resistors) but it worked for us ;)

Of course be sure to measure the voltage before connecting the Arduino!

Best,
Johannes @ Robots in Architecture

Awesome, nicely done - and thank you for sharing!
The axis calculations in the new PRC are quite a bit more reliable (i.e. the entire process is simulated so that you can see when the robot is e.g. "winding" itself up via the A4 or A6). If you want to give it a try I can send you a temporary license, just send an eMail to johannes@robotsinarchitecture.org.

Best,
Johannes

Hello Ken,

The new PRC quite accurately tracks the axis values so you should be able to detect such issues much more quickly. You can adjust the initial posture of the robot by either adjusting the status value (three binary values, e.g. 010) either in the menu or by adding a PTP position with a status value at the beginning of the job. This often helps with reorientations as well.
The new PRC works alongside the old one, however you must not "mix" components, i.e. only use the new LINear movements for the new PRC. Also, there was a change in regards to the custom tool, where you now have to place your mesh as if it were on the robot's flange, i.e. the X axis facing "downwards".

I've also unlocked your account so that you can access the member section with the new KUKA|prc.

Best,
Johannes @ Robots in Architecu

Hello Lewis,

First of all sorry for the late reply, somehow I wasn't notified of a new post on the forum!
Nice job on the definition, I would recommend using the new beta version of PRC as it has got a few features especially in regards to simulation that make these tasks easier.
With an object such as your bowl, a big problem is the reachability if you do not have a turntable. You either have to split your job up (e.g. into three sectors with a different movement strategy) or position the workpiece in a clever way. In the attached example I did the latter.

In any case, if you want your simulation to get close to reality you have to set the right values for tool and base. See also here: http://forum.robotsinarchitecture.org/index.php/topic,115.0.html

And in regards to the programming I slightly changed your code - basically I divided the toolpath into a number of planes whose normals are oriented away from a point within the bowl. Then their X-axis is oriented towards the robot for better reachability. By adjusting the first point you basically set the toolaxis of the process, and with the second point the rotation around the tool axis.
With the new analysis view you can then quickly evaluate if the job works or not.
Just keep in mind that the Analysis-view only shows the set positions, i.e. there could also be unreachable points in between. To simulate them as well you can also set the "Interpolate LINear Movements" option.

As part of UTAS I've also unlocked the member section for you, if you don't have your license installed please get it from Robin Green.

Best,
Johannes @ Robots in Architecture

Hello Pete,

Great to hear about UTAS!
There are ways on the KUKA controller to deal with static tools, however we just did the transformation within Grasshopper. The core part of this operation is the Orient component in Grasshopper where you flip from one coordinate system into another.
I've attached part of an exercise that we did at ACADIA 2014. It contains some additional functionality within the cluster, but the transformation should be clear.
Hope that helps, if not just let me know and I'll see if I have a nicer example around somewhere!

Best,
Johannes @ Robots in Architecture

P.S.: I also just enabled your member access so that you can access the member section. The new PRC version there is quite much improved and you can install it alongside the "old" version that you are probably using. Just note that you will have to adapt any existing examples such as the attached ZIP files as the versions of the components are not compatible (e.g. replace any LIN move component from the old PRC with LIN move from the new PRC).

Awesome, thanks!

Perfect!
What turned out to be the problem, how did you fix it? Just in case anyone runs into the same issue!

Best,
Johannes