StorageTek SL150 Modular Tape Library
 

PLA-Support>Sun Systems>TAPE>Tape Hardware>SN-TP: SL150 Library
 

In this Document

Goal

Solution

References

Applies to:

Goal

This document will assist with how to troubleshoot a 9135 fault code condition.

Solution

What are the key things to know about 9135 error?

1. There is already a KB out there which is a valid and useful piece of information, but it was created based on one incident in the early life of the product. So one needs to understand the 9135 error from a fresh point of view to be able to work the SR properly. However, get familiar with the original KB first:
   
   SL150 - Initialization Failure, Robot Z Home Sensor Initialization Error, Fault Code 9135 (Doc ID 1532413.1)
   

2. The second thing to mention about 9135 fault code, is that it is seen in the library logs as result code 5084. See this sample:
   
   2015-05-13T19:20:43.728,     0.0.12.0.1, 519,            robot, /usr/local/bin/Ifm,  error, 0000, 5084, "Director - auditResponse() cmo_user_audit_cell: cmo_move_arm failed, cmo status = 5, result code = 5084, text = cmo_move_arm_with_retries: robot recovery failed after cmo move arm, result=5084; srv_z_sweep: first move up past z home sensor failed. Failed to see Z home sensor, reach"
   
   This will then populate the fault code 9135 to the Op Panel and the health log:
   
   Note: Recommended action says to replace the chassis before the robot!
   
   Note2: With library FW level 2.50 the recommendation states: “Check for robot motion/obstructions. Verify robot latch is unlocked. Check base module locate sensor. Inspect/replace base module chassis or robot“
   
   This is the official recommendation, in short, how to approach 9135 error situations.
   
   

3. About getting the service bundle in this condition:
   
   A) Library code 2.01 and below will allow you to collect a service bundle in this state.
   
   B) Library code 2.25 will not allow you to collect a service bundle in this state. This is due to a change in the library firmware where we changed the order in which services are started, and we lost the ability to get the service bundle if the library is not fully initialized.
   
   C) Library code 2.50 will allow you collect a service bundle as long as you can get into the BUI.
   

4. Then one key thing to realize is that even it says in the description that the issue is a failure to detect the home Z sensor(which is located in the base), the problem can be in any of the expansion module Z sensors.
   
   The reason this is the case, is that the way the library initializes, is that it drops to the floor, and then goes up and starts counting how many sensors it detects. All the Z sensors are the same, so it’s not getting a different signal from the base, than it’s getting from any expansion module. What it then does, it compares the # of sensors it picked up to the # of modules it sees via the USB connections and keeps this way a track of it’s position. If any of the sensors where damaged or bad, it does not realize it missed a sensor due the logic just described. It just assumes that the next sensor it found, was the next module. So once it gets to the base, it thinks it’s still an expansion module below it, and it thinks it needs to go up more (this is why the customer description is always that it ”bangs” against the roof of the library 3 times, and then gives up).
   
   So we cannot really say if the issue was in one of the expansion modules or in the base. If the configuration is only the base, then it’s more simple of course.
   
   Also an obstruction on the robots way down, will fool the library that it hit the floor, and makes it start to go up from that position. Then again, we find ourself in this same situation.
   

5. This means that the first thing to find out is the configuration (how many modules the customer has) and then check all the Z sensors in the configuration, including the base and the expansion modules and to see if there was anything to stop the robot from going all the way down. Observing the initialization in this situation is valuable. If the robot is never reaching the library floor, it’s either due to an obstruction or possibly a robot issue.
   
   If you then cannot find anything obvious and the robot actually goes all the way down, and the all the way up and stops there, then you are faced with a challenge to decide which module Z sensor might be bad. In larger configurations, I would start to narrow the configuration down by disconnecting all the expansion modules to see if the base alone will work and then start adding the expansion modules one by one, to find the faulty one.

6. The goal at this point is to find the faulty Z sensor, and order either a base chassis or expansion module chassis to fix the problem. 9135 has not been found to be caused by the robot expect in very rare cases where the robot cabling is causing the confusion where the robot is actually moving.
   

7. Once you identify the faulty Z sensor, you can then take a second look if cleaning or re-seating it might help. However, your first part that you replace in a 9135 situation should a chassis component, not the robot CRU.
   

8. Another thing you need to understand about Z sensor failures is that the library will only read the Z sensors when it does it’s initialization. So if this occurs in a reboot or during a firmware update, it’s normal. Then the assumption is that one of the sensors went bad in earlier states and this reboot only brought the issue up. You should think in which situation this started, and how long has the library been running since the last reboot. A second reboot is always a worth a try!
   
   This is why we may also see these in new installations or when adding an expansion module. Those are then strong indications that we are seing some of the known and documented quality/position issues with the Z sensors.
   
   

9. You might also find yourself in a situation where someone has already replaced and returned the robot CRU in 9135 condition and they cannot still get the library up. Then you may realize you need to have the base chassis replaced to solve the original problem. Then your challenge is that, by replacing the base chassis in this condition, you will corrupt the library serial number as it’s not been written to the new KLC card yet.
   
   Here’s a document to tell you how to get the library base chassis replaced, so that you will take the original USB stick from the chassis, and this way prevent the serial number for corrupting. Keep in mind, that you need to dispatch an FE for this task as it should be treated as a KLM replacement, which is a FRU.
   
   SL150 - Steps to replace the base chassis CRU and use the existing USB stick from the original base chassis KLM card (Doc ID 2020327.1)

References

This solution has no attachment