Messages

Hello,

But if you compare the two screenshots you shared, the new model is of much higher resolution?
If you need to go even higher, you would have to define a Custom Robot. I can help with that, if needed. The integrated robots have to take a middle ground between resolution and performance.

Regarding the singularity, you can change the Singularity Factor in the Analysis graph window if it is not sensitive enough. Otherwise I can also take a look at the file - if it's confidential, you can send it to me via email as well, of course.

Note that the goal of the singularity checker is to identify areas where the axis speed is exceeded. Maybe you are going through a singularity but slow enough that it isn't a problem. Are you running the robot at 100% AUT speed? That can also help. Of course you need to be careful so that a proper speed is used, as the robot will try to exactly match the programmed speed. But the robot runs "best" on 100% AUT, compared to let's say 20% T1.

Best,
Johannes

Hi,

You must have enabled the low-resolution robot model in the Advanced Settings - then it will show up nicely again.
There is no real reason to use that unless you are displaying 100s of robots for some evolutionary optimization algorithm.
And KUKA|prc should highlight potential singularities in yellow in the Analysis graph! Please take a look if that matches with your experience!

Best,
Johannes

Hello,

I guess you are referring to singularities, in your case most likely when the wrist (A5) is close to 0, so around when the object reaches the height of the robot?
Unfortunately there is no easy fix, the best levers are to change the position of your work object and the angle of the tool holder. But that only postpones the singularity to another point in the process.

Beyond that there isn't that much you can do, singularities are inherent to the standard industrial robot kinematic setup. Technically you could try to use tightly spaced PTP motions on areas where singularities occur (with a switch in posture where A5 transitions), but I would say that something like this is only useful, if you produce an object many times and you can afford the time to hand-tune everything, with some verification cycles on the actual robot.

Regarding the screenshot: In Rhino, right-click the name of your viewport in the upper left corner of each viewport. Like "Perspective". Then go to "Capture" and select either Clipboard or File. In the next window you can then also set a multiplier for the resolution.

Best,
Johannes

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