Messages

[EDIT: As this is post is viewed very frequently, here is some useful troubleshooting advice:]

EDIT: As this is post is viewed very frequently, here is some useful troubleshooting advice:

For an accurate simulation, the physical and digital robot have to be synchronized, i.e. tool and base have to use the same number and XYZABC value. Please refer to the sticky post on top of the forum: http://forum.robotsinarchitecture.org/index.php/topic,115.0.html
It is possible to set custom axis limits, which differ from the standard robot setup. If you change them back to default, make sure that there are no mechanical stops installed.
The simulation is only accurate until the first point that is out of reach. Do not depend on any information that comes AFTER an unreachable position, .e.g. when you manually skip an unreachable position via the smartPAD/KCP.
KUKA|prc only calculates the programmed positions, but there can be out-of-reach positions in between as well. You can enable LIN Interpolation in the settings to spot errors in between LIN movements.
Members are encouraged to use the most recent version of KUKA|prc - we usually update the software at least once a month.
Post in the forum or get in touch with johannes@robotsinarchitecture.org if the problem persists.

Thanks!




Hello,

First of all, this may of course be a bug, but I cannot diagnose this without the file (and preferably the robot).
Basically, it's important to consider that there is no "official" KUKA kinematics solver available for third-party software. The most accurate simulation you are going to get is via the combination of KUKA SimPro and OfficeLite, which is a virtualized robot controller, i.e. you put the KUKA|prc-generated KRL file there and can execute it virtually. So the KUKA|prc solver is made to best approximate the way KUKA robots behave.
Regarding the A4 problems you can try to set the first position as a PTP movement with a specific Status value - e.g. 010, an explanation is in the KUKA Expert Programming Manual, should be on the included CD, see also the graphic below that shows the different ways how a robot can reach a defined position.



The fact that B is always 90 probably means that you've got only vertical positions (B is the rotation around the local Y-axis).

Best,
Johannes

[NOTE: This example uses an older version of KUKA|prc!]

NOTE: This example uses an older version of KUKA|prc!




Title: Robotically Extruding Material along a NURBS CURVE
Level: Beginner
Description: Robot follows a NURBS curve tangentially as to extrude material.
Requirements: Rhinoceros 5, Grasshopper 0.9.0072, KUKA|prc

Refer to projects such as www.mataerial.com/#mataerial-in-action by Mataerial - but note that such processes are more complex than just the motion planning as shown in the Grasshopper example above. The ";KRL EXTRUDE START" command is just a placeholder, if e.g. the extruder is attached to the robot's digital output #33, you could use "$OUT[33]=TRUE" instead.

The example has been updated to use the most recent version of the KUKA|prc trial version!

Hello,

You are correct about the base and tool - you first have to calibrate the tool and base on the robot and then use the same number that was set at the robot inside KUKA|prc. The XYZABC values in KUKA|prc are only used for the simulation.
There is a particular reason for that - let's assume that a milling tool breaks and you have to put in a new one. If the values were hard-coded, you would have to go back into KUKA|prc and change them there again. As only the ID is referenced, you just have to save the new tool with the same tool-number.

By default we're using X as the tool axis in the tool definition - as in the KUKA manuals. If you go into the settings of the Custom Tool component, there is an illustration. However, you can use the Z-axis as well, there is an option in the KUKA|prc settings for it (though I'm not 100% sure if it's already available in the trial version).
If you're using planes as the input for movements, the planes' positive Z-axis will be the tool axis.

...so to sum things up: You assumed correctly!

Best,
Johannes

Sure, there you go:

KUKA|prc Core generates the KRL code (double-click it to go into settings and set an output directory, though), If you enable Collision checking (in the settings, Simulation tab) you can plug a mesh object into the COLLISION input input and KUKA|prc will check for collisions. The default tool is just the initial tool that will be used, e.g. one of the included spindles. Every tool you measure in at the robot will get a number - it's important that you give the tool you're using the same ID as how you saved it at the robot.
KINEMATIC is the output for the virtual robot component - KUKA|prc simulates only the end-effector, if you attach the Virtual Robot component you can also simulate the full kinematic movements of the robot.
Don't worry about the ENDEFFECTOR and ORIENTATION outputs, they are just geometry, if you need it e.g. for rendering or visualization.

The ENABLE toggle will go away in the next version, it's actually highly redundant with Grasshopper functionality as was a bad idea to start with... Anyway...
Also take a look at the existing examples in the Tutorials section, this should make the data flows clearer as well.

Hope this helps you along!
Best,
Johannes

P.S.: I've taken the liberty of renaming the topic to "Getting started with KUKA|prc" to make it easier for people looking for similar information.

Hello,

Good initial reading are the KUKA manuals, which you should have received with your robot (if not, I can send you a few) - this will make it easier to understand some aspects.
Basically, KUKA|prc works with the principle that you just queue up commands, mostly movements. There are several types of movement, e.g. linear, PTP, spline, circular (see manual for details) which require different inputs.
It's just essential to know that you need more data than just XYZ to define a robot position - XYZ is enough for a 3-axis CNC machine, a 5-axis machine already requires the definition of XYZ plus a tool axis. With the robot, you at least have to define XYZ, plus tool axis, plus the rotation around the tool axis (in KUKA|prc: orientation). So you either define a position via a plane (fulfills the requirements) or via three points, with the first base point defining the tool center point (XYZ), the second point the tool axis, and the third point the orientation around the tool axis. You can switch between plane mode and 3-point mode by right-clicking a movement component.
Even with the endeffector clearly defined, there are still 8 different ways how a robot could approach that positon (see status/turn in the KUKA manual).
If you want to have the robot follow a line, you either have to divide the curve into many planes, or into many "triplets" of points. Some of KUKA|prc components take care of the work (e.g. divide by distance, which requires a base curve, a guide curve, and an orientation point - it gets the base points from dividing the base curve, the guide points from dividing the guide curve, and the orientation from the point).

Hope this makes it a bit clearer!
Best,
Johannes

Hello!

No problem, I moved the topic!
It depends if you have got previous experience with Grasshopper and what you would like to do with KUKA|prc. You've already seen the tutorial section which is helpful for playing around with existing definitions, the first post there also contains a PDF tutorial. We also do quite a few workshops each year, though I can't provide any fixed dates for 2014 yet.
So what are your plans?

Best,
Johannes

Hello,

The current non-member version is from September 2013, you can download it from here:
http://www.robotsinarchitecture.org/kuka-prc

Or is there a particular reason why you're using an older version?

Best,
Johannes

Hello,

Which version of KUKA|prc are you using? If you go into the KUKA|prc settings, it will show the version number in the About section.
I'm not really aware of a bug in that area and just tested it myself. You can also attach your GH file in the forum - the attachment option is underneath the text input field.
For KUKA robots you can enter a number between 0 and 2 (m/sec) for linear movements and 0 to 100 (in %) for PTP movements. Just note that if the robot cannot reach the specified speed, it will just move slower!

Best,
Johannes

Hello,

Hmmm... That would definitely be interesting, though I do not really have any experience with custom controllers. The problems are most likely in the details, e.g. getting all axes to move perfectly in synch so that you can achieve straight toolpaths.
Keep us updated!

Johannes

Great to have you here, Freddy!

[NOTE: This example uses an older version of KUKA|prc!]

NOTE: This example uses an older version of KUKA|prc!




Title: Using different adaptive strategies for the robot's linear axis
Level: Advanced
Description: The new adaptive linear axis strategies allow finetuning of the robot's rail strategy, e.g. continuous readjustments or only partial readjustments when required.
Requirements: Rhinoceros 5, Grasshopper 0.9.0072, KUKA|prc

LINEAR AXIS FUNCTIONALITY IS ONLY AVAILABLE IN PRC-MEMBER VERSIONS (20131017 or newer) ONLY

Hello,

At the moment, support for linear rails is in, but it needs some more work, i.e. automated algorithms for ideal placement. That is on our immediate to-do list. Rotary tables will be in as well, but that will take a bit longer.
Regarding the video: While we've worked with that robot before, this isn't one of our projects. To my knowledge the toolpaths were generated in SprutCAM and then postprocessed using KUKA CamRob - it gives you the choice of either having a fixed rotation for each file, or a dynamic adjustment of the rotation values. See http://www.ddg.tuwien.ac.at/index.php?idcatside=378 for some more information.

Best,
Johannes

In order to see the member section, you have to be tagged as a member. If you or your institution are members of the Association for Robots in Architecture, please register at the forum and send an eMail with your chosen username to johannes@robotsinarchitecture.org
We will then add you to the Member group!

Thank you!

Hello,

I've posted an example in the Tutorials section, see http://forum.robotsinarchitecture.org/index.php/topic,24.0.html
It takes a curve and parametrically divides it into arcs and lines, depending on the angle of the arc's three points.

Just note that you may need the KUKA|prc Trial version that we're going to post later today to work with the file!

Best,
Johannes
Association for Robots in Architecture

[NOTE: This example uses an older version of KUKA|prc!]

NOTE: This example uses an older version of KUKA|prc!



Title: Parametrically dividing a NURBS curve into linear and circular movement commands
Level: Advanced
Description: Divide a NURBS curve into linear and circular movements, reducing file size and improving interpolation compared to a long sequence of just linear movements.
Requirements: Rhinoceros 5, Grasshopper 0.9.0072, KUKA|prc