Messages

[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

Hi,

Unfortunately I have no information on the status of the Toolpath Optimizer plugin, have you tried contacting Parametric Zoo via their contact form?

Best,
Johannes

Perfect, I'll get back to you.
I have also unlocked your member access.

Best,
Johannes

Hi,
Is the process continuous, or sequential. As you mention assembly, I guess sequential?
In that case it might be better to only send individual movements to the robot, rather than having the entire assembly logic in the background.
We also have got a new version of KUKA|prc that is easier to automate, send me an email to johannes@robotsinarchitecture.org and I can send you some links to try out.
We used it for our ACADIA workshop and basically ran the sequence of scanning and assembly in Python, using Grasshopper for the pathplanning. It also uses a new mxAutomation integration, which could resolve some issues (but also introduce new ones...).

Best,
Johannes

Great! Thanks for the update!
Best,
Johannes

Hi,
Thank you, that information was helpful - there is a separate membership for the DAMlab project, are you involved in that?

Regarding performance, the usual problem would be memory running out. It is weird that you seem to run into a speed problem instead. I am thinking that it could be related to the drawing of the geometry in Rhino. In the mxA settings, there are values for the visualization and feedback update time in ms. - I would try increasing the values by 3x or so and checking if that increases the time until you get an error message. Are you using Rhino 8? If not, you could also install an evaluation version of Rhino and check if that helps with the problem.

Regarding the adaptive mode, there is a distance value that you can set. That being said, I was never 100% happy with the algorithm behind it. Can you describe your use-case in a bit more detail?

Best,
Johannes

I'm sorry, I don't quite understand where you need support. Is the simulation the way you like it but the robot works differently? In that case, the most usual mistake is that people do not calibrate the base of the robot as an Offset Base that rotates with the rotary table.
If you wonder why it is rotating at all in the simulation: You enabled the rotary axis solver in the KUKA|prc settings that tries to orient the tool along a given vector.
Finally, for the simulation slider only use 0-1.

Best,
Johannes

Dear Kang,

I haven't been able to find a membership for the University of Kitakyushu in our records, is it possibly under another name?
Please understand that we can only provide in-depth support for member-only features to users with an active membership.

In general we support all mxA versions, however the KUKA|prc build needs to be custom-built for that version - this is something that we do on demand for our users.
Our implementation of mxAutomation supports various updating modes that define its reaction to new data - cancel the current project and run the new one (default), queue it up (queue), try to adjust the current toolpath (adaptive), etc.
I'm not aware of memory leaks, usually .NET is pretty good at managing them. It would be good to look at the task manager to see if Rhino uses excessive memory. It also depends if that is just a long program, or if there are tons of updates. I haven't encountered it in our applications, in any case.

Best,
Johannes

The normal point limit is quite a bit higher than that, so I'm not sure if RAM is really the issue.
My guess is computational effort to plan a spline consisting of so many points. But that is just a guess.

Best,
Johannes

Basically you should be able to blend two splines, however with 1500 points each the brief pause may be the robot looking at all the points to calculate the trajectory. Do you have the same pause blending two splines with 10 positions?

As always the disclaimer to be careful around splines as they are efficient, "beautiful" paths, but they are not B-splines and the Grasshopper preview may not be accurate. They may also differ between two robots as they take the robot kinematics into account, as far as I know.

Best,
Johannes

Hmm... I don't think your code is accessing the softkeys, it just shows a dialog box. Which I think is the better approach than using the softkeys on the side.

I would also tend to make that accessible by all programs and then just call the method from the Custom KRL component in KUKA|prc.
Regarding the KRL, I'd say this is a typical AI question by now - possibly also taking a look at robot-forum!

Best,
Johannes