Troubleshooting

This page lists common Robots failure modes and where to look first. If a problem happens while generating code, start at Create Program: it is the main validation boundary and should report errors before unsafe or misleading code is emitted.

Robots Tab Is Missing

Check:

1. Rhino 8 is installed.
2. Robots was installed through _PackageManager.
3. Rhino was restarted after installation.
4. Old manual Robots.gha or Robots.dll copies were removed from the Grasshopper Components folder.

If a Grasshopper file was created with an older version, obsolete components may load but fail immediately with a replacement message. Replace them with the current component named in the message.

Sample Opens With an Assembly Dialog

If Rhino shows an assembly-not-found dialog while opening a sample, close the dialog and let the file finish loading. Grasshopper should repair the reference after the Robots package is loaded.

If the file still fails, restart Rhino after installing Robots and reopen the sample.

Robot Library Does Not Appear

Check:

• The XML and 3DM files have the same base file name.
• Local libraries are in the local Robots folder.
• The library XML has valid syntax.
• The robot system, tool, or frame name exists in the XML.
• The library manager is not showing an unexpected Local override.

Local libraries override downloaded libraries with the same file name. If you expected the online copy, remove or rename the local XML and 3DM pair.

See Robot libraries for the XML and 3DM conventions.

Robot Loads but Meshes Are Missing

Check:

• The XML model value matches the 3DM layer name.
• The mechanism parent layer uses the expected pattern, such as RobotArm.ABB.IRB120.
• Child layers are named 0, 1, 2, and so on.
• Geometry is mesh geometry, not blocks, curves, surfaces, or unrelated Rhino objects.

Collision meshes are optional. If collision mesh layers are absent, display meshes are used for collision checking.

Create Program Has Errors

Errors mean generated code is unavailable or should not be used.

Common causes:

• A Cartesian target is unreachable.
• A target is outside joint limits.
• A target is near a singularity or has no valid configuration.
• External-axis values are missing or have the wrong count.
• A frame coupling is invalid for the selected robot system.
• A motion type is unsupported by the selected manufacturer.
• A command cannot be represented by the postprocessor.
• A controller-managed Fanuc tool or frame is missing its number.
• The program name or generated identifier is invalid for the controller.

Use Program Simulation, Deconstruct Program Targets, and the target index reported by the error to narrow the problem down.

Create Program Has Warnings

Start from the warning text reported by Create Program, then compare it with the checked-program behavior in Program Parameter.

Common warnings include:

• The first target was changed to a safer motion form.
• A configuration change was detected.
• A speed limit changed the expected duration.
• Acceleration settings make velocity-only timing optimistic.
• Target data was cleaned or normalized.

Warnings are part of the review process. Do not hide them just because code was generated.

Cartesian Target Solves to the Wrong Pose

Check:

• The target plane orientation, not only its origin.
• The previous target or previous joints.
• Explicit configuration flags.
• Whether a joint target would be clearer for that pose.
• Whether the robot is near a singularity or joint wrap boundary.

Many robots can reach the same TCP plane with several joint configurations. The solver needs context to choose among them.

Program Simulation Does Not Animate

Check:

• The input is a checked Program, not custom code.
• Create Program has no blocking errors.
• Time is in the expected range.
• Normalized is true if you want Time to run from 0 to 1.
• You are using the pass-through Program output from Program Simulation for downstream visualization such as Simple Trail.

Custom-code programs cannot be simulated because Robots no longer has target-level motion data after the code is replaced.

Collision Results Look Wrong

Check:

• Mesh indices match the Program Simulation mesh order.
• The environment mesh is included as the last mesh when supplied.
• Environment Plane is -1 for static world geometry.
• Collision groups are not accidentally testing unrelated parts.
• Step sizes are small enough for the geometry and motion.
• Collision meshes are not too simplified or misaligned.

Collision checking is sampled. A clear result is useful, but it is not proof that a real cell is safe.

Generated Code Is Missing

Generated code is only available when Create Program completes without errors. Check the Errors output first.

Also check whether the program was replaced by Custom Code. Custom-code programs carry text through the Robots pipeline but cannot be checked or simulated as normal target-based programs.

Remote Upload Does Not Work

Check:

• The manufacturer supports Remote Connection.
• The controller IP or SFTP URL is correct.
• The controller is reachable from the computer running Rhino.
• The controller is in the required remote or external-control mode.
• Required vendor runtime software is installed.
• The Log output from Remote Connection shows the failing step.

Remote support exists for ABB, UR, and Franka Emika. Other manufacturers should use Save Program and the controller's normal transfer workflow.

Generated Code Does Not Match the Controller Setup

Check:

• The selected robot library matches the physical robot and controller.
• Tool and frame numbers match controller-managed data.
• IO numbers or names match the controller IO map.
• Program name and file names are valid for the controller.
• The selected manufacturer supports the motion type, commands, external axes, and multi-file behavior you are using.

See Manufacturer support for controller-specific notes.

Asking for Help

When asking in GitHub Discussions, include:

• Robots version.
• Rhino version and operating system.
• Robot manufacturer, model, and controller.
• The exact error or warning text.
• Whether the issue happens before Create Program, during simulation, during code generation, or on the real controller.
• A minimal Grasshopper file or screenshot when possible.

Do not include controller passwords, private IP ranges that matter, license keys, or proprietary production code in public issues.