KUKA LBR iiwa Sunrise: Troubleshooting prc XML Errors

Overview

Driving a KUKA LBR iiwa from a Grasshopper/KUKA|prc toolchain means exporting an XML motion file, moving it to the controller via USB, and letting a Sunrise Java application parse it through the KUKA|prc library. Three failure classes dominate first commissioning: workspace/base mismatch faults reported on the smartPAD as Arbeitsraumfehler, Java null-pointer exceptions thrown the moment the XML is parsed, and unit confusion between the degrees used in Grasshopper and the radians consumed by Sunrise.

This reference walks each failure to root cause and gives the verification steps that confirm the fix before you enable Automatic mode.

Failure 1: Arbeitsraumfehler / Work Envelope Error on XML Load

Symptom

The Grasshopper simulation runs clean, the XML exports without complaint, but the moment the Sunrise application loads the file from the USB drive the pendant reports a work envelope error and the application aborts before the first motion.

Root cause

The toolpath is generated relative to a base frame in the CAD/Grasshopper environment, but the base object placed in the Grasshopper definition does not correspond to the base frame trained on the robot. A common trap in the shipped example definitions is that the robot in the example is not located at the world origin. If you build your own scene assuming the robot sits at the origin, every posted point is offset by the example's robot transform, which pushes the commanded Cartesian targets outside the reachable envelope of the 7-axis arm.

Resolution sequence

1. Open the example definition and read the actual position/orientation of the robot component. Do not assume origin placement.
2. Rebuild your scene so the Grasshopper base object geometry is coincident with the physical base frame you trained in Sunrise Workbench (same origin, same orientation of X/Y/Z).
3. Confirm the base is trained on the robot, not just declared. A declared-but-untrained frame yields a default identity transform and silently relocates the whole path.
4. Verify the base name string in the Sunrise Java application matches the name in the Sunrise Workbench object template tree character-for-character. The lookup is by string; a case or whitespace difference fails.
5. Re-post the XML, reload, and re-run.

Failure 2: Null Pointer When the Application Calls the prc Library

The iiwa's biggest advantage over a KRL controller here is that the Sunrise application is ordinary Java running under Sunrise Workbench, so you can debug it exactly like any other Java program instead of guessing from pendant messages.

1. Switch Sunrise Workbench into the Debug perspective.
2. Set a breakpoint on the line that throws — typically the call that hands the tool name, base name, and I/O group to the KUKA|prc library.
3. Run to the breakpoint and inspect each argument in the variables view to identify which reference is null.

The three usual culprits:

Parameterizing tool and base

Hard-coding the tool and base names in the Java application means every scene change requires a Workbench rebuild and redeploy. If your workflow needs operators to swap tools without redeploying, restructure the application to read the tool and base identifiers from the loaded XML (or from a small companion configuration file on the USB drive) and resolve them at runtime via the same name-based lookup. Validate the resolved objects for null immediately after lookup and abort with a readable message rather than letting the exception surface as a raw pendant fault.

Failure 3: Degrees vs Radians — the Redundancy Angle Trap

KUKA|prc always works internally in degrees. There is no user-facing degree/radian switch in KUKA|prc. On export, it converts to whatever the target platform expects — and Sunrise expects radians. So seeing radian values in the posted XML while Grasshopper displays degrees is correct behavior, not a bug.

The practical consequence is on the redundancy angle (E1) of the 7-axis LBR:

• Enter the E1 value in degrees in Grasshopper. KUKA|prc handles the conversion.
• If you enter radians by mistake, the value is treated as degrees and is numerically much smaller, so you observe far less elbow reconfiguration than intended — a classic "the redundancy input does nothing" complaint.
• Also confirm the angle display units configured in Sunrise Workbench so you are comparing like with like when you read joint values back off the pendant.

Optimizing the redundancy angle

KUKA|prc does not automatically resolve the E1 redundancy — the optimal elbow position is highly application-dependent. A workable approach today is to drive E1 from an evolutionary solver (Galapagos) inside Grasshopper, using a fitness function built on the output of the KUKA|prc Analysis component. Useful objectives to minimize:

• Total process/cycle time
• Collision count reported by the Analysis component
• Proximity to joint limits across the toolpath
• Singularity/axis-reversal events

Sweep E1 as a single slider for a constant-elbow strategy, or as a small set of sliders interpolated along the path if the process needs the elbow to migrate.

Setting the Default XML Directory in the File Chooser

On a shared robot, letting the file dialog open in the user's Documents folder invites operators to load the wrong XML. The dialog is a JFileChooser subclass exposed as PRC_FileChooser, instantiated from the CORE_ChooseXML() routine in PRC_Core.

Why setCurrentDirectory("E:") is rejected

JFileChooser.setFileFilter() takes a FileFilter object and compiles fine. setCurrentDirectory() does not take a String — it takes a java.io.File. Passing a string literal produces a "method is not applicable for the arguments" compile error in Workbench. Likewise, constructing new PRC_FileChooser("E:\\") fails with "constructor is undefined" unless that subclass actually declares a String constructor.

Working fix

// In PRC_Core, after the chooser is created:
fileChooser.setCurrentDirectory(new java.io.File("E:\\"));
fileChooser.setFileFilter(filter);

This compiles and pins the dialog to the USB volume. The cleaner long-term fix is to edit PRC_FileChooser.java itself — it extends JFileChooser, so set the default path inside its constructor (or add a String-argument constructor that wraps the path in a File). That keeps the customization in the file-chooser class instead of scattering it through PRC_Core, and it survives library-side edits to the core routine.

Commissioning Checklist After a Long Shutdown

If the cell has been idle for years and Sunrise Workbench plus the surrounding software stack were reinstalled, verify the software layer before blaming geometry:

1. Confirm the Sunrise Workbench version matches the controller's installed Sunrise version — a mismatch produces obscure synchronization and deployment failures.
2. Confirm all required Sunrise technology options/packages used by your application are installed and licensed on the controller.
3. Re-synchronize the project to the controller and confirm the deployment completes without warnings.
4. Re-verify tool and base frames on the physical robot. Touch-up data does not survive a controller reimage.
5. Run one short, low-speed XML in T1 with the operator's hand on the enabling switch before any Automatic-mode run.

Verification

FAQ