RoboTeam Commands: Setup Is Missing, Not Robot Motion

RoboTeam commands can stay disabled even while both robots jog together. Start with the programming setup: create the workspace, select the target robot, and add the RoboTeam optional package to both robots. Treat the BASE_DATA[1] message separately by attaching the slave base frame to the master robot's mountplate node, not A6.

Read the two symptoms separately

The panel can show coordinated motion while the Logic section contains disabled or unavailable RoboTeam commands. You can also receive a BaseFrame attachment error when you program ordinary jogged motions.

Those symptoms come from different configuration layers. Fixing one does not automatically clear the other.

Separate jogging from command activation

Coordinated jogging proves that the simulation can resolve a master-slave motion relationship. It does not prove that the programming editor has loaded the RoboTeam command set for the selected robot.

The Logic palette is context-sensitive. It needs a created workspace, a robot selected within that workspace, and the required optional package associated with the robot configuration. In a two-robot RoboTeam, check both robot configurations. A valid network mapping alone does not activate programming commands.

The BaseFrame error belongs to the kinematic attachment layer. The flange-side mechanical reference required here is the robot's mountplate node. Axis 6, exposed as A6, represents an axis reference and is not the attachment target requested by this check. That is why the slave may appear to follow during jogging while programmed motion still fails validation.

Run the checks in order

Start here. Do not rebuild the network mapping merely because the commands are greyed out; coordinated jogging already shows that the mapping is doing useful work.

1. Read the full output message. If it names BASE_DATA[1] and mountplate, handle the frame attachment before testing programmed motion again.
2. Open the programming workspace. Confirm that a workspace has been created rather than working only from the simulation or network view.
3. Select the robot in that workspace. The command palette must have a robot context before robot-specific Logic commands can become available.
4. Inspect both robot configurations. Confirm that the RoboTeam optional package has been added to the master and the slave. Network membership is not a substitute for package assignment.
5. Check the project name. If it uses an option-package name, rename it to a neutral project name and reload it. Pay attention to any warning displayed during loading.
6. Return to the Logic section. Select each robot in turn and check whether the RoboTeam commands become available.

Changing motion points, reteaching paths, or repeatedly jogging the pair will not activate a missing command package. Those fixes waste time until the workspace and package checks pass.

Correct the frame and command setup

1. Open the slave robot's base-frame configuration and locate BASE_DATA[1].
2. Set its Node attachment to the master robot's mountplate. For the reported configuration, the required target is KR 120 R2700-2 #2::mountplate.
3. Remove any attachment to KR 120 R2700-2 #2::A6. The visible movement of the slave does not make that node correct for BaseFrame validation.
4. Create the programming workspace if it does not exist, then add or select the robot within it.
5. Add the RoboTeam optional package to both participating robot configurations.
6. Reload the project after changing package assignments or resolving a project-name collision, then select the robot and reopen the Logic section.

Use the same node rule when another robot model reports the equivalent fault: follow the error's named robot and attach the applicable base frame to that robot's mountplate. Do not copy the example robot path blindly; select the actual master instance in the project tree.

Verify each layer independently

1. Verify frame validation. Start the simulation and confirm that the BASE_DATA[1] attachment message no longer appears.
2. Verify command registration. Select the master in the programming workspace and confirm that the RoboTeam commands are active in Logic. Repeat the check with the slave selected.
3. Verify basic programmed motion. Run a short programmed move before building the full coordinated sequence. The output panel must remain clear of BaseFrame errors.
4. Verify coordinated behavior. Execute the smallest RoboTeam sequence that demonstrates the required master-slave relationship. Compare the simulated relative pose with the configured relationship.
5. Repeat the run. If geolinked results vary, record the motion, selected robot, output messages, and the point at which synchronization diverges.

Passing the jog test is only one verification. The repair is complete when the frame check passes, the commands appear for the correct programming context, and a programmed coordinated move runs without the attachment error.

Avoid the recurring traps

• Do not use A6 for this BaseFrame attachment. The required node is mountplate.
• Do not equate network membership with command availability. Check the workspace, robot selection, and optional package.
• Do not configure only one robot. Inspect the package assignment on both members of the RoboTeam.
• Do not ignore load warnings. A project named after a KUKA option package can block or confuse option loading.
• Do not use path edits to diagnose a missing Logic command. Motion geometry cannot register an editor command set.
• Do not treat every simulation mismatch as a frame error. After the frame and package configuration pass, remaining geolinking variation may come from synchronization between the underlying robot-motion modules and Windows services.

Keep the diagnostic layers separate: editor activation, kinematic attachment, then simulation synchronization. Change one layer at a time and rerun the smallest failing test.

FAQ