Problem

STATUS CODE 201: When attempting to inventory a robot, the following error is generated: "Robot inventory failed: Unable to open robotic path (201)."

Error

Unable to open robotic path.

Solution
Overview: When attempting to inventory a robot, the following error is generated: "Robot inventory failed: Unable to open robotic path (201)."

Troubleshooting: This error can occur for various reasons including:

The library door is open. The library is offline, or performing a scan (scans often occur when upon closing of the door). The library is not in SCSI mode. Conflicting software (like robtest) is running and has locked the SCSI path. The SCSI path to the library has changed and Veritas NetBackup (tm) does not know about it.

Log Files: N/A

Resolution: This problem can be resolved or diagnosed with the following steps: 1. Verify the library door is closed and locked. 2. Verify the library is online, according to the Robot's LCD display or web interface. 3. If applicable to the library, verify the library is in SCSI mode and ready to accept commands from a SCSI interface, as opposed to the LCD interface. 4. Run the following command on the robot control host. This is the machine that the robotic

arm is physically attached to, that is listed as the Robot Control Host in NetBackup:
<install_path>\veritas\netbackup\bin\bpps

See if robtest.exe is listed in the output of this command. If robtest.exe is running, end the process. 5. On the machine acting as the Robot Control Host, open the Windows Device Manager and see if the Medium Changer object is still listed; it must be listed for NetBackup to work. Note: A listing of "Unknown Medium Changer" should be expected for most libraries. If the medium changer is listed without errors, proceed to step 6. 6. Run the following command to see if the robot is still communicating with the OS.
<install_path>\veritas\volmgr\bin\tpautoconf -r

A correct response will look similar to this:

C:\Program Files\VERITAS\Volmgr\bin>tpautoconf -r TPAC45 M4 DATA MagFile 3.05 RBD12A0007 2 0 0 0 Changer0 - -

7. If tpautoconf -r works, use the NetBackup Administration Console to re-browse for the robot object on the Robot Control Host. If robot, server or storage area network (SAN) components were rebooted, the SCSI path to the robot could have changed. The OS is plug and play and can adapt, but NetBackup is not. Re-browsing for the robot object will update NetBackup's Device Databases with the new SCSI path to the robot object. If the tpautoconf -r command is not successful after following the prior steps, it is likely that the Windows operating system cannot properly see the robot. It may be necessary to power cycle the robot and/or robot control host, check cabling, or check the Windows System Event logs for further information on why the robot is not responding.