Patent Publication Number: US-9406330-B1

Title: Method for HDD disk defect source detection

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims the benefit of U.S. Provisional Application Ser. No. 61/836,725, filed Jun. 19, 2013, the entire contents of which are herein incorporated by reference as if fully set forth herein. 
    
    
     TECHNICAL FIELD 
     This invention relates to the field of magnetic media technology, and more specifically, to defect source detection for hard disk drive (“HDD”) disks. 
     BACKGROUND 
     A HDD disk (or platter) is the magnetic storage medium on which data is stored on the HDD. User-accessible information is magnetically recorded on the magnetic surface of a HDD disk in disk sectors, the smallest size of controllable data in a HDD. Defects or defect patterns may arise on the surface of the disk as it is processed and handled by a plurality of processing stations during manufacture of the disk For example, disk defects can be water stains caused by water in the groove in an insufficiently dried cassette. The stain can be caused by any one of the grooves of the cassette. 
     Quickly determining the processing station or stations responsible for disk defects is desirable, particularly during yield crisis periods. Current methods of identifying the source (processing station) of disk defects can be time-consuming and not easily adaptable to the different processing stations. For example, in one existing process for detecting whether sputter pins cause defects in a disk, the disk needs to be rescanned using an Optical Surface Analyzer (OSA) to identify the sputter pin location. The OSA scan can then be compared with an existing map of the disk&#39;s defects to determine if the sputter pins caused defects on the disk&#39;s surface. This existing process may take over an hour and is only adapted to detect sputter pin defects. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present application is illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which: 
         FIG. 1  illustrates a HDD disk processing system in an example disk manufacturing environment in accordance with one embodiment of the technology described herein. 
         FIG. 2  illustrates an example disk after processing in the system of  FIG. 1 . 
         FIG. 3  is a high-level block diagram illustrating an example disk defect detector and troubleshooting device that may be used in the system of  FIG. 1 . 
         FIG. 4  illustrates an example station defect mapping application for defect source detection in a disk. 
         FIG. 5  is an operational flow diagram illustrating an example process used for defect source detection in a disk processed through the system in  FIG. 1 . 
         FIGS. 6A-6D  illustrates station defect pattern image templates that may be used in the process of  FIG. 5 . 
         FIG. 7  is a screenshot of an example defect mapping application that may be used in accordance with the process of  FIG. 5 . 
         FIG. 8  is another screenshot of an example defect mapping application that may be used in accordance with the process of  FIG. 5 . 
         FIG. 9  illustrates an example computing module that may be used to implement various features of the system and methods disclosed herein. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, numerous specific details are set forth to provide a thorough understanding of various embodiment of the present disclosure. It will be apparent to one skilled in the art, however, that these specific details need not be employed to practice various embodiments of the present disclosure. In other instances, well known components or methods have not been described in detail to avoid unnecessarily obscuring various embodiments of the present disclosure. 
     In accordance with the present disclosure, systems and methods are illustrated for efficiently detecting defect causation on a HDD disk processed through a plurality of processing stations. 
       FIG. 1  illustrates a HDD disk processing system in an example disk manufacturing environment in accordance with one embodiment of the technology described herein. Unprocessed disks  101  may be handled by one or more disk processing stations  102  during the manufacture of disks  101 . After processing through one or more disk processing stations  102 , processed disks  101  may develop surface defects such as scratches, dirt, or water stains because of problems with one or more processing stations  102 . A disk defect detector  104  may scan for any surface defects or defect patterns during any processing stage. If defects are detected on processed disks  103 , disk defect source detector  105  may be used to determine the cause of the defects, for example, a particular disk processing station  102 . The cause of disk defects may then be determined and remedied. 
     System  100  may be implemented in a single disk manufacturing facility that processes the disks and performs defect testing to determine if there are issues with processed disk  103  or disk processing stations  102 . Alternatively, system  100  may be implemented in distributed facilities. For example, in one implementation the processing of disks is handled by one facility (e.g. manufacturing plant) and the defect testing and troubleshooting of processed disks  103  is handled by another facility (e.g. quality control plant). These facilities may be remotely distributed. These facilities may additionally implement additional processes for assembling HDD that include the manufactured disks. 
     Disk  101  comprises any disk that may serve as a magnetic storage medium in a HDD of any form factor. For example, disk  101  may have a form factor of 65 mm or 95 mm (i.e. 2.5″ or 3.5″). Disk  101  may be two-sided (data recordable on both sides). Moreover, disk  101  may be manufactured as part of an assembly of multiple disks in one HDD. 
     A disk processing station  102  is any machine or tool that contacts the surface of disk  101  during its manufacture. For two-sided disks, disk processing station  102  may contact both surfaces (sides). A disk processing station  102  may be, for example, a sputtering device such as a magnetron sputtering device that deposits a magnetic film on the disk surface. During sputtering, disk  101  may be held in place by two or more sputter pins that contact its surface. As another example, a disk processing station may be a UV saddle for holding a disk in place as it undergoes a UV irradiation process. The UV saddle circumferentially contacts the outer edge of the disk along a circular segment of the disk. Other exemplary disk processing stations  102  may include shipping cassettes, robot paddles, modular clean line combs or modular dryer combs. 
       FIG. 2  illustrates an example disk  103  after processing in the system of  FIG. 1 . Disk  103  comprises an inner region  220  for mounting on a HDD spindle and outer surface region  210  where data may be recorded once the disk has undergone sufficient processes for data recording. In this exemplary illustration, defects  214  formed on the surface of disk  103  because of processing through one or more processing stations  102 . A defect  214  is any scratch, stain, contamination, or unwanted surface formation that formed on the surface of disk  103  during processing. As is further described below, defects  214  in the disk sectors  215  of disk  103  may be mapped to a disk defect image. 
     Disk defects  214  may be caused by the disk surface contact points of disk processing stations  102 . For example, disk defects can be scratches or contaminants caused by burrs on the robot paddle that loads the disk into a cassette. In another example, disk defects  214  can be sputter pin voids caused by contaminants on the disk holder pins of the sputter device. In yet another example, disk defects  214  may be water stains caused by water in the groove of an insufficiently dried cassette. 
     Disk defects  214  may assume a particular pattern because they are caused by a processing station&#39;s disk surface  210  contact points. For example,  FIG. 2  illustrates three defect sets (each set comprising three defects) that are approximately equidistant and similarly distributed along the surface  210  of disk  103 . The illustrated defects, for example, can be caused by a sputter device with three disk holder pins. As is further described below, knowledge of the expected defect pattern for a particular disk processing station  102  may be implemented in a process for quickly identifying the processing station  102  responsible for disk defects  214 . 
       FIG. 3  is a high-level block diagram illustrating an example disk defect detector  104  and disk defect source detector  105  that may be used in the system of  FIG. 1  to detect disk defects and determine their source. Disk defect detector  104  may comprise a storage  301 , a disk defect processing tool  303 , a disk receiver  305 , and connectivity interface  307 . Disk receiver  305  may comprise any tool configured to receive a disk for defect testing, for example, any disk defect testing tool with a disk read/write head. Defect processing tool  303  may be used in combination with disk receiver  305  to scan for disk defects. In one implementation, more than one disk defect detector  104  is used to perform disk defect testing. In this implementation, this plurality of disk defect detectors  104  may be integrated as a disk defect detector assembly. The disk defect detector assembly may comprise more than one disk receiver  305  and one or more disk defect processing tools  303 . 
     In this exemplary implementation, defect processing tool  303  scans for defects over all sectors in the disk (entire surface area). In another implementation, defect processing tool  303  may scan for defects over a partial surface area of the disk. If a disk defect is detected, defect processing tool  303  may identify the defect&#39;s location on the disk by disk sector identifier, circular sector and radius, disk track number and angle, or any coordinate set (e.g. polar) that may be used to map the disk defect location onto a disk surface image or polar map. The set of identified disk defect locations for a disk may be stored as a single file recorded in storage  301 . Alternatively, the set of identified disk defect locations for a disk may be stored as a single file recorded on one or more sectors of the disk. This file (set of identified disk defect locations) may be referred to as a disk defect data set. 
     Connectivity interface  307  may be included to provide a wired or wireless communications link with disk defect source detector  105  for communicating data such as a disk defect data set for use by one or more applications ran by disk defect source detector  105 . 
     Disk defect source detector  105  may comprise a station defect mapping application  314 , a user interface  316 , a storage  318 , and a display  320 . Disk defect source detector  105  may be any hand-held computing device (tablets, PDA&#39;s, smartphones, cellphones, palmtops, etc.); workstations or servers; or any other type of computing device configured to run station defect mapping application  314 . User interface  316  may be configured to allow user input into station defect mapping application  314  for display on a display  320 . In one implementation, troubleshooting device  105  and disk defect detector  104  may be integrated as a single device. 
       FIG. 4  illustrates a station defect mapping application  314  for defect source detection in a disk. Station defect mapping application  314  may comprise an application interface  401 , a disk defect image module  402 , a station defect image template module  403 , and a mapping module  404 . These modules may be integrated in any combination. Application interface  401  may allow a user of defect mapping application  314  to interact with the application via user interface  316  and perform operations such as selecting a disk defect data set and other application parameters such as a disk form factor, a graphical coordinate set, and a station defect pattern image (described below). Mapping module  404  may be configured to interact with disk defect image module  402  and station defect pattern image template module  403  to graphically map a disk defect data set and station defect pattern image onto a disk surface image, polar map, or other graphical representation of a disk surface. Together, these modules may allow a user of station defect mapping application  314  to quickly determine a source (processing station) of disk defects. 
       FIG. 5  is an operational flow diagram illustrating an example process  500  used for defect source (disk processing station) detection in a disk processed through the system in  FIG. 1 . Some or all of the operations in process  500  may be implemented by disk defect source detector  105  using station defect mapping application  314 . Alternatively, the operations in process  500  may be implemented by an integrated device comprising disk defect detector  104  and disk defect source detector  105 . 
     At operation  502 , one or more station defect pattern images (or station image templates) are created for one or more disk processing stations  102 .  FIGS. 6A-6D  illustrates four exemplary station defect pattern images  610  through  640 . A station defect pattern image maps the disk surface contact points of a disk processing station  102  onto a disk surface. As discussed above, these disk surface contact points may cause unwanted surface defects such as scratches, stains, or contamination. A disk surface image  605  may be included in a station defect pattern image for reference. The mapped disk surface contact points may be mapped to scale. Alternatively, the mapped disk surface contact points may not be mapped to scale if, for example, they are used as a template for display on an application user interface to approximately indicate the disk surface area a disk processing station  102  contacts. 
       FIG. 6A  illustrates a station defect pattern image  610  for a sputtering device with three pins  611 .  FIG. 6B  illustrates a station defect pattern image  620  for a sputtering device with four pins  621 .  FIG. 6C  illustrates a station defect pattern image  630  for a disk shipping cassette with four disk circumferential contact areas  632  through  635 .  FIG. 6D  illustrates a station defect pattern image  640  for a robot paddle with disk circumferential contact area  640 . 
     In some implementations, a plurality of defect pattern images may be created for a single processing station. For example, each station defect pattern image for a disk processing station may correspond to a different set of contacts points on the processing station. Alternatively, the same contact points on the processing station may produce different station defect patterns depending on the cause of the defects (e.g. dirt obscuring the contact points or wear on the contact points). 
     After a station defect pattern image is created, it may be added to storage  318  or a memory for reuse by station defect mapping application  314  in disk defect source detector  105 . Accordingly, operation  502  may be performed only if station defect pattern images are not available for every disk processing station  102  used to process a disk. As new disk processing stations  102  are added to disk processing system  100 , additional station defect pattern images may be dynamically created for use by defect mapping application  314  in disk source detector  105 . Thus, system  100  and process  500  are adapted to add new disk processing stations  102 . 
     At operation  504 , a disk defect data set (i.e. the defects of the processed disk) is mapped onto a disk defect image. At operation  506 , the disk defect image may then be displayed on display  320 . A disk defect image graphically represents the location of disk surface defects. The disk defect image may be represented, for example, on a polar graph or two-dimensional Cartesian graph.  FIG. 7  is a screenshot  700  of an example defect mapping application  701  displaying a disk defect image after operation  506 . In this example application, the disk defect image is represented on a polar graph. Example application  701  also displays the disk defect data set used to create the disk defect image. The disk defect data set, in this example, represents each defect location as a circular sector and radius pair. 
     At operation  508 , a station defect pattern image is selected. The station defect pattern image may be manually selected by the user of station defect mapping application  314 . The selected station defect pattern image may then be overlaid with the disk defect image (operation  510 ).  FIG. 8  is another screenshot  800  of example defect mapping application  701  and illustrates a station defect pattern image overlaid over a disk defect image on a polar graph. In this example application, a three pin sputter device defect patter image is overlaid over a disk defect image. In some implementations, a second station defect pattern image may be simultaneously overlaid over the disk defect image with the first overlaid station defect pattern image. 
     At operation  512 , the overlaid station defect pattern image and disk defect image may be compared to determine if they correspond. The two overlaid images may correspond if the mapped disk defect locations are located on the same disk sector or general disk surface area as the mapped disk processing station disk surface contact points. Because there may be an angular displacement between the two disk-surface (circularly) mapped images, during comparison the disk defect image may be angularly rotated about its center (0 to 360 degrees). Alternatively, the station defect pattern image may be angularly rotated about its center (0 to 360 degrees). 
     If the overlaid images correspond (i.e. there is a match), then the disk processing station  102  with station defect pattern image has been identified as the source of disk defects. If the two overlaid images do not correspond (i.e. there is no match), operations  508  through  512  may be repeated with other station defect pattern images until a match is found. The degree of correspondence necessary to find a match between the two images may be user defined or predefined by image comparison algorithms. 
     In some implementations, each operation in process  500  may be performed in response to user input into station defect mapping application  314 . Alternatively, some or all of the operations may be automated such that station defect mapping application  314  takes a disk defect data set and automatically compares it with a set of station defect pattern images. 
       FIG. 9  illustrates an example computing module that may be used to implement various features of the system and methods disclosed herein. 
     As used herein, the term module might describe a given unit of functionality that can be performed in accordance with one or more embodiments of the present application. As used herein, a module might be implemented utilizing any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logical components, software routines or other mechanisms might be implemented to make up a module. In implementation, the various modules described herein might be implemented as discrete modules or the functions and features described can be shared in part or in total among one or more modules. In other words, as would be apparent to one of ordinary skill in the art after reading this description, the various features and functionality described herein may be implemented in any given application and can be implemented in one or more separate or shared modules in various combinations and permutations. Even though various features or elements of functionality may be individually described or claimed as separate modules, one of ordinary skill in the art will understand that these features and functionality can be shared among one or more common software and hardware elements, and such description shall not require or imply that separate hardware or software components are used to implement such features or functionality. 
     Where components or modules of the application are implemented in whole or in part using software, in one embodiment, these software elements can be implemented to operate with a computing or processing module capable of carrying out the functionality described with respect thereto. One such example computing module is shown in  FIG. 9 . Various embodiments are described in terms of this example-computing module  900 . After reading this description, it will become apparent to a person skilled in the relevant art how to implement the application using other computing modules or architectures. 
     Referring now to  FIG. 9 , computing module  900  may represent, for example, computing or processing capabilities found within desktop, laptop, notebook, and tablet computers; hand-held computing devices (tablets, PDA&#39;s, smart phones, cell phones, palmtops, etc.); mainframes, supercomputers, workstations or servers; or any other type of special-purpose or general-purpose computing devices as may be desirable or appropriate for a given application or environment. Computing module  900  might also represent computing capabilities embedded within or otherwise available to a given device. For example, a computing module might be found in other electronic devices such as, for example, digital cameras, navigation systems, cellular telephones, portable computing devices, modems, routers, WAPs, terminals and other electronic devices that might include some form of processing capability. 
     Computing module  900  might include, for example, one or more processors, controllers, control modules, or other processing devices, such as a processor  904 . Processor  904  might be implemented using a general-purpose or special-purpose processing engine such as, for example, a microprocessor, controller, or other control logic. In the illustrated example, processor  904  is connected to a bus  902 , although any communication medium can be used to facilitate interaction with other components of computing module  900  or to communicate externally. 
     Computing module  900  might also include one or more memory modules, simply referred to herein as main memory  908 . For example, preferably random access memory (RAM) or other dynamic memory, might be used for storing information and instructions to be executed by processor  904 . Main memory  908  might also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor  904 . Computing module  900  might likewise include a read only memory (“ROM”) or other static storage device coupled to bus  902  for storing static information and instructions for processor  904 . 
     The computing module  900  might also include one or more various forms of information storage mechanism  910 , which might include, for example, a media drive  912  and a storage unit interface  920 . The media drive  912  might include a drive or other mechanism to support fixed or removable storage media  914 . For example, a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive might be provided. Accordingly, storage media  914  might include, for example, a hard disk, a floppy disk, magnetic tape, cartridge, optical disk, a CD or DVD, or other fixed or removable medium that is read by, written to or accessed by media drive  912 . As these examples illustrate, the storage media  914  can include a computer usable storage medium having stored therein computer software or data. 
     In alternative embodiments, information storage mechanism  910  might include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into computing module  900 . Such instrumentalities might include, for example, a fixed or removable storage unit  922  and an interface  920 . Examples of such storage units  922  and interfaces  920  can include a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, a PCMCIA slot and card, and other fixed or removable storage units  922  and interfaces  920  that allow software and data to be transferred from the storage unit  922  to computing module  900 . 
     Computing module  900  might also include a communications interface  924 . Communications interface  924  might be used to allow software and data to be transferred between computing module  900  and external devices. Examples of communications interface  924  might include a modem or soft modem, a network interface (such as an Ethernet, network interface card, WiMedia, IEEE 802.XX or other interface), a communications port (such as for example, a USB port, IR port, RS232 port Bluetooth® interface, or other port), or other communications interface. Software and data transferred via communications interface  924  might typically be carried on signals, which can be electronic, electromagnetic (which includes optical) or other signals capable of being exchanged by a given communications interface  924 . These signals might be provided to communications interface  924  via a channel  928 . This channel  928  might carry signals and might be implemented using a wired or wireless communication medium. Some examples of a channel might include a phone line, a cellular link, an RF link, an optical link, a network interface, a local or wide area network, and other wired or wireless communications channels. 
     In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to transitory or non-transitory media such as, for example, memory  908 , storage unit  920 , media  914 , and channel  928 . These and other various forms of computer program media or computer usable media may be involved in carrying one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on the medium, are generally referred to as “computer program code” or a “computer program product” (which may be grouped in the form of computer programs or other groupings). When executed, such instructions might enable the computing module  900  to perform features or functions of the present application as discussed herein. 
     Although described above in terms of various exemplary embodiments and implementations, it should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead can be applied, alone or in various combinations, to one or more of the other embodiments of the application, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus, the breadth and scope of the present application should not be limited by any of the above-described exemplary embodiments. 
     Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; the terms “a” or “an” should be read as meaning “at least one,” “one or more” or the like; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future. 
     The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent. The use of the term “module” does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic or other components, can be combined in a single package or separately maintained and can further be distributed in multiple groupings or packages or across multiple locations. 
     Additionally, the various embodiments set forth herein are described in terms of exemplary block diagrams, flow charts and other illustrations. As will become apparent to one of ordinary skill in the art after reading this document, the illustrated embodiments and their various alternatives can be implemented without confinement to the illustrated examples. For example, block diagrams and their accompanying description should not be construed as mandating a particular architecture or configuration.