One of Professor Dworak's graduate students looked into the weird Fastscan output and found that Fastscan will only register one fault as detected up to 255 times. This is probably due to industrial circuits not needing to know if a fault was detected more than that many times. However, our data needed that information and we had no idea that Fastscan had an upper bound, which made it incredibly inconvenient. I had to heavily modify the program that compiled the fastscan files and dofile to split up the data into sets of 255. This means that running 40,000 patterns created over 150 different files. Splitting up the patterns managed to give us different data (some faults were now listed as being detected 255+), but we were still getting patterns that managed to detected 0 faults! We did not managed to fix this problem by the end of the week. One last thing I did before I left was write a program to generate a new probability table based on the fault dictionary created after running my automation. This program gave us more accurate probabilities of each fault as each fault was now detected at least once. We would now know the maximum number of patterns needed to detect the hardest to detect fault.
My last week was very hectic and very much the complete opposite of how the first week went. My first week was spent trying to figure out this project and how I could fit into its complicated workflow. As a computer scientist who has spent much of her time focusing mostly on programming, getting over the hurdle of working with hardware for the first time was difficult and hard to conceptualize. But after the first week, everything seemed to fall into place. Perhaps this is how it will always feel when joining a project, and now I have one of the most valuable skills a computer scientist can have.