Building a model to predict wafer defects from text dataHi team,
I have a customer asking if it is possible to build a predictive model to predict defects on the edge of wafers, when the wafer data is in text form? The goal is to use this model to optimize the parameter settings to minimize these edge defects.
I was wondering if anyone have come across this before as I imagine it could be a common problem. I've attached an example of the text data wafer map here.
Any help or advice would be appreciated! Thank you in advance
Re: Building a model to predict wafer defects from text data@Chris_Kirchberg and I have been trying to do exactly this with data from Kaggle/GitHub (item 9 in @russ_wolfinger's Torch Storybook). In that case, the maps look similar but are individual values in a Pandas data frame. The idea is straightforward, turn the character values into a matrix of numerical values, then use JSL to convert the matrix to an image. I've adapted the code to work with a single file and produce a window with the image. I suspect you'll want process a bunch of individual files and do something like store the images into a JMP Data Table column. Hopefully, the code can be easily adapted for this. I've made some assumptions based on the file in your post (e.g., header and footer lines to remove, the dot (.) representing the area outside the wafer, X as a defect, etc.). The other potential issue may be what is used as an EOL sequence. I did this on a Mac, so it was only newline (\!n). You may need to use a different sequence on Windows. There's a scaling constant at the top of the script to make the image bigger or smaller (used in the Scale JSL function towards the end). I've commented the code pretty extensively, but if you (or anyone else) have questions, let me know.
Re: Building a model to predict wafer defects from text data@Owen_Jonathan ,
Wanted to mention @Chunwei_Ma is currently working on image segmentation for the Torch add-in, which will provide predictions for individual pixels in images like this and could be just what the customer wants for edge defects.
If the problem can be formulated to predict one or more numbers or categories for the entire map (e.g. total number of edge defects), Torch can do it right now as in the examples from the Torch Storybook.
For creating the input images I like the approach of @DonMcCormack and @Chris_Kirchberg .. As a possible alternative the following may work:
- Split the strings into a separate column for each character using a script from TX Nelson and recode them to 0, 1, 2 via Cols > Standardize Attributes.
- Create a numeric Row indicator and remove the formula after creating it.
- Stack the data and parse the Label column to create a numeric Col variable
- Plot Row vs Col in Graph Builder and Color by Data (three distinct levels)
- Graph Builder red triangle > Save to Data Table to get a single image cell.
Looks like this would work over multiple maps in the same table by using another variable indicating each map and then make it a Wrap in Graph Builder. The final picture column with all of the maps is then ready to roll for image classification or segmentation (coming soon) in Torch.
Re: Building a model to predict wafer defects from text data@russ_wolfinger @DonMcCormack
Thank you both for the quick replies! Happy to see a Pro angle here.
Will test out both approaches. I'll keep you both updated for any questions.
Re: Building a model to predict wafer defects from text dataRandom question around this - how old is the equipment generating the data?
I wonder if there's not a way to pull it from a factory database so that it comes into JMP in an easier format. For instance, if you could get the data as columns of "Die X, Di Y, P/F, WaferID" then you could use graph builder to generate the images and then have graph builder send them straight to a JMP data table. They'd then be in the correct format for Torch without bothering with a bunch of text files.
Re: Building a model to predict wafer defects from text dataYes, this did led to some internal discussion about data quality. It seems to be an internal problem that the customer is currently tied with at the moment.
