Cascading

Optimizing cascading at work is a difficult problem. There is an output improvement for some tools when like material is run back to back to back.  There is a balance to be struck between flexibility (I can run whatever I want whenever I want) and output.  I configure the systems that make those decisions, but one of the toughest parts is seeing the impact of those configurations and assessing how we are doing.

Each different toolset has different requirements for cascading, a different recipe structure, and different cascade limitations.  So setting up one script that can handle all of them was a big undertaking.  I achieved this by writing a Python script with a few different SQL queries that could have variables subbed in to account for all of these differences.  Unfortunately, I can't share any of that script publicly, but the (redacted) output for one toolset is here:

The idea is to give tool engineers and manufacturing engineers the ability to see how specific tools (top left) or cascade groups (bottom left) are performing.  Users can filter down to a specific group to see tool interactions.  The script also diagnoses the most likely causes for a cascade break based on tool status and the type of lot that was introduced immediately after.  

The script is made up of several SQL queries that pull from multiple different databases.  It then combines the results and analyses them before outputting them to a separate database.  Those results are then pulled into Power BI shown above.