Messages

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

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

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

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