Messages

Hi Kailey,

I wrote back with some troubleshooting steps.
My best guess at the moment is that the robot model isn't the right one.

Best,
Johannes

Hi,
Thanks for the detailed description, that is indeed strange.
Generally with a tool like yours, B=-90 is correct, that is what I would expect to work.
Could you please send me your GH/3DM file plus the generated SRC output? Either here as an attachment or to johannes@robotsinarchitecture.org
Then I can take a look!
Best,
Johannes

Hello,
It seems that you created your toolpath once and then shifted it multiple times in Z to create the multiple step downs. I think that is what is causing the tool to move up and down.
I would try the following: that after the "Trim with BRep" component you take the start point of each curve, take it's Z value and then sort the curves according to that. If the order within a layer is critical, you could then sort again depending on e.g. the distance to the center of the element, so that it goes from outside to inside.
Best,
Johannes

Hello,
I just tried it here and it just makes a tiny movement and then goes to the end position.
I've attached my file. How does it look on your side?
Best,
Johannes

Hi Charlie,

The DKP500 just seems to have a different standard orientation than the DKP400. I'll send you a build with DKP500 and the KR8R1440-2 arc HW in a few hours.

Best,
Johannes

Hi Charlie,

Hmm... I don't have a DKP at our lab - I will have to drop by at the local KUKA HQ sometimes, there is one in the tech center. It might be easiest for now to put together a custom DKP - see attached. It's a bit hacky, but the data inputs should be clear. Then you can set your values accordingly.

That being said, the exact value of the root point doesn't matter that much as long as it is physically/virtually at the right location in both cases. As in your case the positioner location is fixed anyways, you can match it once. Your base defining the toolpaths is relative to the moving part of the turntable, so the base values themselves don't depend on the root point.

At least that is my understanding.

Best,
Johannes

Hello,

Where are you changing the positioner root frame? If you right-click the positioner component you can - in your case - change the A value and it will rotate it (or more accurately the robot in relation to the positioner).
When you say -826, do you mean the height of the floor, measured from the positioner? I measured the DKP and that sounds plausible, or at least not off by a lot.

A good way to verify the position of a turntable (without using the built-in calibration tools) is to equip the robot with a well-defined tooltip and then get the global, Cartesian position of the same point on the turntable using different E1 values for rotation (e.g. 0, 120, 240). In Rhino/GH you can then create a circle from 3 points and extract the center point.

Note that KUKA|prc assumes that you are using an Offset Base - don't use those values for that, because then the coordinate system rotates along and you get the identical values, no matter the rotation. So switch into a global coordinate system instead.

Best,
Johannes

Hello,

You've got PTP motions that do not define the posture of the robot:
PTP {X 1.00,Y 1.00,Z 158.50,A 0.00,B 90.00,C 141.64,E1 0.00,E2 141.64,E3 0.0,E4 0.0,E5 0.0,E6 0.0}

That is technically possible, but not a good idea.
In your example I guess you could search for "E6 0.0" and replace it with "E6 0.0, S 'B110'" - change the status to what you want it to be.

Best,
Johannes

Hi,

I've got an internal example that uses the DKP400. In that case, the centre of rotation is 347mm below the top of the turntable. I'll send it to the eMail address in your profile.

Best,
Johannes

Hello,

The core problem with so many DOF is that there are infinite solutions, so finding a "best" solution is tricky.
In general, KUKA|prc works with an offset base when using a positioner, so the coordinate systems are being moved by the positioner within the robot's workspace. You can replicate that movement with just two rotations, taking the offsets from the relevant positioner (see data sheet, or let me know what value you need!). The solver is optimized and non-generic, so we do not use DH values directly internally.

Without knowing what exactly you are using the robot for, the challenge for that kind of optimization is the different speed of the axes. So just optimizing for the least amount of axis movement doesn't lead to an optimal solution.

Unfortunately, I don't have a suitable 2-axis optimization code that I could share.

Let me know if e.g. you need to connect KUKA|prc to additional software systems etc.

Best,
Johannes

[Parametric Robot Control]

Hello All,

Some of you have been testing and using the new Parametric Robot Control (PRC) for a while now, so we're happy to introduce it on the forum. In a nutshell, it is our experimental cousin to KUKA|prc, but does not replace it – they can coexist nicely.

Our idea behind the new PRC is that we want to make robotics as accessible as possible, across many different environments and domains. To support this, all the core logic runs in a separate server process and communicates with clients via the web technology gRPC.

We are still huge fans of Grasshopper and therefore the Grasshopper (1 and 2!) implementations are our reference integrations, but there are also prototypes showing how PRC can be integrated into web interfaces, Blender, Fusion, Adobe software and more. Because the interfaces are well documented, AI agents can relatively easily interpret them and perform these integrations (semi) automatically.

While we call it a "Server", it is simply a single executable file with no large external dependencies (no need for ROS or other platforms) and you can run it on the same PC/Mac that you work on. Grasshopper even autostarts it for you when you drag a Core component onto the canvas.

Using PRC, we have developed workflows where Python manages the dataflow while Grasshopper handles path planning and optimization. We have also implemented our own MCP servers that allow you to simulate and check robot data coming from an LLM. You can tell that we are very excited about the possibility space opened up by PRC!

Its rewritten architecture allows us to integrate complex new features much faster and more easily - a good example of this is preliminary support for ABB, UR, Neura, and Igus code generation. It will not yet have the same level of reliability as our KUKA code, so your feedback is very much appreciated.

It runs nicely on both Windows and macOS, with a 99.9% identical feature set and UI.

We have also put together some documentation to make things easier. You can find it at prc.robotsinarchitecture.org. If you are a developer, you can take a look at the example code of the integrations on GitHub. An tutorial video for users is available on YouTube.

Regarding licensing: We do not yet have a 100% detailed plan for what features will be available in a Community Version. At the moment, some features such as support for more robot brands are only available with a license/membership. Also, the two membership management systems are not yet linked. So even if you have an existing Robots in Architecture membership, you would still need to send me an email so that I can unlock a full PRC license for you. Sorry about that - we will fix that soon.

PRC requires Rhino 8 to run, but it also worked on Rhino WIP without problems. On Windows you need Windows 10 or 11. The macOS version is built for ARM (M1 upwards) but the developer version of the server should also run on Intel Macs and even Linux - it's just .NET.

We would greatly appreciate your feedback and are already extremely curious what kind of new applications will be powered by PRC! That being said, we will keep supporting KUKA|prc, so there is no need to switch.

Best,
Johannes

Hi Ege,

Of course, it's not a problem to provide a trial license. Please send me an email to johannes@robotsinarchitecture.org

Best,
Johannes

Hello,
I just checked and the KR120 R3900K is available in both the Quantec 1 and 2 version on my end. The member version gets more frequent updates, so that could be a reason.
However you mention being on a trial version with limited features - basically there are only two feature sets, Community and Full (member/commercial). So it might be that your temporary license isn't installed properly if you do not see the Custom Robot component. Where did you get the trial license from?
Regarding aligning the tool: Assume that the Rhino origin is the robot flange - so the tool should be placed at the zero position. Also, I recommend using the Rhino command ReduceMesh to get the resolution down to around 5000 faces, otherwise it can impact performance.
Best,
Johannes

Hi,

Well, don't quote me on that, but the robot has got its own "real-time" memory from where it can run all its programs - this is why you need to copy them there and cannot just push them over via a fileshare. That memory is limited. I have seen some ways to increase that, but you can mess up your robot software, so make a backup image first.
Possible solutions are: KUKA techpackages like DirectoryLoader that can automatically load and run programs and CNC which simply does not have a relevant filesize limit. There are also non-KUKA solutions like OrangeApps PointLoader that stream commands instead of loading it all into memory.

Hope that helps!
Best,
Johannes

Hmmm... Are there any other files on the robot drive (R1...)?
I would delete all larger programs except for the current one. Take care that there are also some necessary default programs in the program folder that you shouldn't delete!
Best,
Johannes