FPSAPP.SCH_REF_P_DISPATCH_DURABLES

Data Dictionary

FPSAPP Views

> FPSAPP.WIP_WAFER_HIST_LOOP

View FPSAPP.SCH_REF_P_DISPATCH_DURABLES

In Photo, there are either internal reticle library (IRL) tools where individual reticles can be loaded or unloaded independently of other reticles or multi-reticle pod tools where up to six reticles are loaded or unloaded together and are tied to each other via the pod they are stored in. There are some tools, including ASML TwinScans, that have both, which means that reticles can be loaded and unloaded independently but we want to batch loads and unloads using the multi-reticle pods to avoid making repeated trips back and forth. This means we need take into account the current reticles in the IRL and pod and the capacity of both when deciding what to unload and load between them. The scheduler manages the lot and reticle usage on the tool but currently does not handle batching the moves for the IRL via pods. The following group of database objects aim to do that and are documented together for easier reference. Database objects and their purpose: SCH_REF_P_DISPATCH_DURABLES - View that reads Scheduler output and determines what reticles should be moved to and from a tool's IRL. SCH_P_DISPATCH_DURABLES - Table that stores the output from the SCH_REF_P_DISPATCH_DURABLES view so that applications accessing the data will receive a much quicker response than reading from the view directly which takes ~30 seconds to run. SCH_P_TRK_DURABLES_IRL - View that provides the actual reticle management plan for a pod that will feed an IRL tool. Important note, this view determines what reticles to load and unload from reticle storage and the pod, not the tool IRL since that will be handled directly between the tool EI and FPS DWH and not presented on the Reticle Management page. NMV_IRL_NEXT_DESTINATION - Procedure to be called by tool automation to provide reticle load and unload commands for the IRL. After a pod is kitted (reticles loaded and unloaded as needed) using the info from SCH_P_TRK_DURABLES_IRL above, we are now ready to load and unload reticles from the tool IRL. If managed automatically this procedure will be called to provide these instructions. NMV_IRL_NEXT_DESTINATION_CHK - Wrapper procedure to call NMV_IRL_NEXT_DESTINATION and print the results for checking. NMV_W_IRL_MOVES_OVR - Table that allows external system moves to be provided or which can be manually edited for testing purposes. To initiate moves from this table via NMV_IRL_NEXT_DESTINATION instead of the Scheduler, set i_mode = 2 in NMV_IRL_NEXT_DESTINATION. NMV_W_IRL_NEXT_DEST_LOG - Log table of calls to and returns from NMV_IRL_NEXT_DESTINATION.

Column	Comment
FACILITY	Facility is included in almost every join in the DWH so this represents a definitive split. A route must have all steps on tools in the same facility. A tool must process all lots in the same facility. If your site has multiple buildings where lots run on routes using tools in multiple buildings then everything should be one facility. For example, multiple Fab buildings. But if your site has independent facilities like Fab and Test and Assembly where lot may progress from one to the next but on different routes then these should be different facilities. Since this column is in virtually every table it is critical that the value here is exactly matches what is in the MES if the MES has facility. Use facility_display for the display friendly name displayed in applications. See site_name comment for client/site/facility example. (* inherited from FPSINPUT.GEN_FACILITIES)
CARRIER	RFID of the cassette or FOUP the lot is currently in. (* inherited from FPSINPUT.MHS_CARRIERS)
CARRIER_CLASS	Carrier class indicates what the carrier is able to carry. It is also an important field in EQP_PORTS but each port has a single defined carrier class and only carriers of this class should go to the port. The value must be one of those defined by FPS in FPSADMIN.MHS_CARRIER_CLASSES which include POD or CAST or BOX. This would be used as a filter on what carriers could be selected when a carrier is needed. For example, when a lot is split we need to find another carrier for the split lot and we select the best carrier in the carrier_class of CAST. But if we need to unload a reticle then we select the best carrier in the carrier_class of POD. (* inherited from FPSINPUT.MHS_CARRIERS)
POD_FAMILY	This column is optional and only applies to pods/durables and not cassettes/lots. Certain durables must be stored in a specific group of pods and this is designated with this column. (* inherited from FPSINPUT.MHS_CARRIERS)
LOCATION	Location of a carrier or lot or durable which comes directly from the tracking system used at the site. This could be a port or internal tool location or tool or rack or stocker or zero footprint storage or room or really anywhere. Many non-automated sites allow users to manually enter locations into their system. Therefore unless we know for sure that the source data implements a size limitation, it is recommended to always trim the value in the ETL to 32 characters to fit into the column size and avoid load errors. For ports, location is the full name of the port which is unique across the entire site and usually includes the tool name. Please see the comment in the port column which explains the difference between location and port. Rack locations are similar. (* inherited from FPSINPUT.MHS_RACK_LOCATIONS)