Questions on KUKA mxAutomation maintenance & compatibility with KSS 8.5.6 + stab

[BI KANG]

Hi everyone,

I'm currently using KUKA mxAutomation (mxA) with a KUKA robot running KSS 8.5.6, and I'd like to ask about current maintenance/support status and a couple of issues we're facing.

Maintenance / compatibility

Is mxAutomation still actively maintained?

Are there any updates/patches that specifically support older KSS versions like 8.5.x (8.5.6)?

Program reset when toolpath changes
During mxA operation, if we modify the subsequent toolpath (e.g., change later segments in Grasshopper), mxA seems to trigger a reset, and the robot restarts and re-runs the entire program rather than continuing from the current point.

Is there a recommended workflow or setting to avoid full re-run when only downstream paths are updated?

Any best practices for splitting programs, buffering, or incremental execution?

Rhino/Grasshopper performance degradation
If mxA runs for a long time, or if Rhino/Grasshopper stays open with mxA blocks, Rhino becomes very slow and sometimes crashes.

Are there known memory/performance pitfalls with mxA components?

Any tips (component settings, data management, recompute strategy, logging limits, etc.) to keep Rhino stable?

If needed, I can share exact versions (Rhino/Grasshopper, mxA, KRC/KSS details) and a minimal test definition that reproduces the behavior.

Thanks in advance.
Kind regards,
Kang Bi

Researcher, Robotic Construction / Robots in Architecture
The University of Kitakyushu, Japan
k-bi@kitakyu-u.ac.jp

[Johannes @ Robots in Architecture]

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

[BI KANG]

Dear Johannes,

Thank you for your prompt and helpful reply.

Regarding the membership: I am indeed using a licensed KUKA|prc/mxAutomation setup. It may not be registered directly under "The University of Kitakyushu" in your system. Would it be possible to check whether it is associated with our lab name, Fukuda Lab? Another possibility is that the license/membership was purchased under Qingdao University of Technology, as we currently have a close collaboration between the two universities and some software procurement has been handled through them.

On the performance topic: the slowdown is real and reproducible in my environment. I am working from a laptop (AMD 5900HX, RTX 3070, 32 GB DDR4) connected to the robot. The issue typically appears after about 2–3 hours of continuous mxA use, or when Rhino is kept open for a long session with mxA components in the definition. Restarting Rhino, or deleting and re-placing the mxA blocks, reliably "resets the timer" and the workflow becomes responsive again. When the slowdown occurs, Task Manager usually shows Rhino memory usage around 50–65% of total system memory (so it does not look like an obvious out-of-memory situation).


Also, thanks for pointing out the updating modes (default/queue/adaptive). I reviewed and tested the behavior when updating toolpaths: with relatively small edits, the system sometimes continues without forcing a restart, but the restart/cancel behavior can still occur intermittently. When I apply broader changes (e.g., larger portions of the command sequence/path), it almost always triggers a full restart of the project, or in some cases leads to the execution stopping. If you have guidance on how mxA determines whether an update can be handled incrementally versus requiring a reset (or any recommended workflow to make it more deterministic), that would be very helpful.

Best regards,
Kang Bi
Researcher, Robotic Construction / Robots in Architecture
The University of Kitakyushu, Japan

[Johannes @ Robots in Architecture]

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

[BI KANG]

Hi Johannes,

Thank you — that clarification helps a lot.

Yes, I am a member of the DAMlab project. My main responsibilities are robot system operation/maintenance within the team, end-effector/tool development (gripping + pneumatic nailing), and pushing forward our robotic timber construction projects. Would it be possible to add my account to the forum's member list so I can access the member-only support/features?

On performance: I will test your hypothesis about Rhino drawing/visualization. I'm using Rhino 8, and I will increase the mxA visualization and feedback update intervals to see whether it extends the stable runtime and improves responsiveness. After I validate it, I will report back with the results.

Regarding the adaptive mode use-case: our target is fully automated construction of timber building components/assemblies using a KUKA arm. We recently integrated an AprilTag-based visual localization system (QR-code markers) on/near the end-effector to estimate pose and support millimeter-level workspace correction. During construction, we try to monitor execution and compensate the remaining toolpath in (near) real time based on measured deviations (e.g., accumulated positioning error, wood part tolerances, or slight shifts during pick-align-fasten). Practically, this means we sometimes need to update downstream toolpath segments while the job is running.

At the moment, progress is slowed down because (1) Rhino/Grasshopper becomes sluggish after long sessions, and (2) updating the path often triggers a project reset (or occasionally stops execution), which makes iterative compensation difficult.

If you have guidance on how to parameterize the adaptive distance threshold for this kind of workflow (or recommended patterns, e.g., segmenting into shorter transactions/checkpoints to keep updates bounded), I'd be very interested.

Best regards,
Kang Bi
Researcher, Robotic Construction / Robots in Architecture
The University of Kitakyushu, Japan

[Johannes @ Robots in Architecture]

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

[BI KANG]

Hi Johannes,

Thank you — that makes sense.

Yes, our process is mainly sequential assembly (pick–align–fasten), so I agree it may be better to send individual movements/segments to the robot and keep the higher-level assembly logic outside of mxA. I will adapt our workflow in that direction.

I'll email you separately to request the links for the latest KUKA|prc / new mxAutomation integration you mentioned, and I'm very interested to try the Python-driven sequencing approach you used in the ACADIA workshop.

Best regards,
Kang Bi

[Johannes @ Robots in Architecture]

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

Best,
Johannes