SL150 - Initialization Failure, Robot Z Home Sensor Initialization Error, Fault Code 9135

Asset ID:	1-72-1532413.1
Update Date:	2017-12-04
Keywords:

Solution Type Problem Resolution Sure

Solution 1532413.1 : SL150 - Initialization Failure, Robot Z Home Sensor Initialization Error, Fault Code 9135

Applies to:

StorageTek SL150 Modular Tape Library - Version All Versions and later
Information in this document applies to any platform.

Symptoms

This was the error, that was seen in the log:

2013-02-18T20:36:27.784 0000 0.0.0.0.0 5084 "Director - initResponse() directorSelfInit; srv_z_sweep: first move up past z home sensor failed. Failed to see Z home sensor, reached z range limit 11167 steps; End of Text"
/usr/local/bin/Ifm 519 robot error

2013-02-18T20:36:27.789 0100 0.0.0.0.0 5084 "IfmInitThread:Failure to Initialize...reason==Failed to detect the Z Home Sensor during Z Sweep - GOING INOP" 3202 ifm error

2013-02-18T20:36:28.800 3750 0.0.0.0.0 3755 "Process /usr/local/share/sbin/snmptrapd murdered by signal 11" 3750 processMgr error

Op Panel reports the following:

Fault Code 9135, Robot Z Home Sensor Init Error, Module 1 Chassis Robot

OP screen message

The way the initialization went was that the robot moved down, and then up, and it appeared to kind of bang against the chassis ceiling a few times, making a bit of a noise, and then error light was lit and it stopped there.

Changes

New Install of library.

"EXPANSION MODULE Addition or replacements", or after servicing that required USB cable disconnects at either end of the USB cables.

Cause

Sensor in base module not seated properly.

Could be multiple USB cables not being connected between Robot and every Module (KLE card).

Solution

Besides the Z home sensor being checked, the following have been found to also cause the 9135 Fault Code. These items should be checked prior to the base module being replaced. (Update 3-Apr, 2015)

Z – Range obstructions. Anything that causes the robot to not drop to the floor of the library could cause a 9135 error. This could be the shipping lock not being unlocked, shipping clip not being removed, a tape sticking out of a cell too far, one of the suspension cables coming off of the pulley and binding, the Z motor gears binding, etc. In these cases the robot and magazines should be taken out so that you can check for obstructions. The hand can also be moved to the middle of the robot and then the robot can be put back into the library. With the power off, remove the shipping lock and assure the hand will drop to the floor of the library. If the robot can't drop down and thus doesn't trip the Z home sensor flag on any modules.

Module Communication. USB cables plugged in, KLEs seated, power on in all modules. This is the same principal as the Z range or obstruction issues in that if an Expansion module isn't communicating to the controller then the Z home sensor will never be tripped.

The cable that connects the Z home sensor to the back of the KLM card should be checked to make sure the connections on the Z home sensor and the KLM are connected and fully seated. This should be checked on each module.

Investigated the robot CRU and found no obvious issues. Then checked if the left side sensor in the chassis was installed on the correct side, as there has been issues with the sensor installed facing the wrong way, but that was not the case here.

This then led me to notice, that this sensor still looked a bit different than in the modules below (they all have the same sensor). It was looking like it's not correctly seated. This was very hard to spot. You actually needed to remove all the magazines to be able to compare to other sensors, and to have maximum lighting/visibility. Even then you needed an extra flash to pick this up.

After pushing the sensor to what appeared to be normally locking position, the library then booted up normally with the existing robot CRU. No part replacements were needed to solve this.

Note: (3-Apr, 2015)

If you do end up checking the above items and nothing is found and a Base Module Chassis is replaced but does not fix the issue, then watch the robot initialize again to see if it moves. If it does then how and where exactly does it move? If all troubleshooting efforts are exhausted, replace the robot. The original Base Chassis should be placed back into the library so we do not end up with a corrupt S/N in the library.

Information provided by Aki Stenberg

Attachments

This solution has no attachment