The Expert

Welcome to the macro fat engineering podcast. We are your hosts Parker Elman and Steven Craig. This is episode 266. So in a couple weeks when is this actually, this is a great way to start the podcast. I saw this email pop up on my work email because I subscribe to macro fed stuff. And I popped up and I'm thinking about it like, yeah, when is this? I don't I didn't even see what it was. It's March 10. At 2pm. Eastern Time, there's a design for manufacturing bility webinar that Chris church who is the other co founder, macro fab, and Edwin, Rob blood doe. So how are you? I think that's correct. from Autodesk. We'll be doing a webinar, it's gonna be about design for manufacturability. And their topics are going to cover fiducial essentials via and pad blind buried vias verse back drilling as a trap stack ups, Edge clearances, annular rings, all manners of basically DRC and DFM checks that look like Eagle covers in their DRC tool. We'll go figure it's Autodesk. Right. So go sign up for that. I'm probably going to sign up for it. Just listen to it on, you know, while I'm working. So yeah, that's that sounds. Sounds good. I'll probably sign up for that, too. We've we've talked about most of these things on the podcast here throughout the last couple 100 episodes. Exactly. I'm looking forward to it. Hopefully, you know what I think I think I've met Edwin before, because he looks familiar. Let's, uh, once again, that is March 10. From two to 3pm. Eastern. Yeah. I think I met Edwin at a San Mateo Maker Faire back in 2009. Maybe, um, he looks really familiar. And we were talking about eagle and that was back when I wasn't using Eagle I was using free PCB. That CAD tool. Yay. Those ones are fun. There's ones that lock you into their Gerber export. So this is an open source PCB tool. Is it open source? I don't remember. But the the website definitely looks like locks you back into 1995. Made This was a I O it is open source, a free open source PCB editor for Microsoft Windows. But it did like one to 16 layers, which I only did like two layer boards, but there was there was no schematic editor. I think I've talked about this. Oh, you just did it all straight on the board. You made netlist in the text editor. Oh, man, that's brutal. And then you could do a netlist through the PCB editor to and then you would route boards. Did it actually provide ratlines based on your netlist net lines? Yeah, okay. netlist. Yeah. But yeah, I built a couple of my first products using that tool. Wow. Latest News 2011. The user form is back up. We don't know what the problem was. We heard a default mode and blamed it on Microsoft. So this design for manufacturing webinar, we'll have a link up in the show notes. So you can go and sign up for that. And I guess macro fab.com/blog will get you to the show notes. Exactly. Or slash podcast. Oh, right. My bad podcast slash or slash blog slash podcast. Choose your own adventure? Yes. Through the URLs. Okay. Um, so today, I don't think we'll be talking for DFM, but more like DFT designed for testing. And this is kind of like a I'm kind of going through my, I've done like products before in the past.

But this is kind of like my first DAB in the last couple years that one like this, I'm talking about the pentatonic pinball platform, and all the other boards that go with it, like RGB lights and stuff like that.

It's always kind of like coming up with an idea of okay, what's my test procedures going to be like, and let's have knowing what I know, eight years down the line from start macro fab, right. And so I guess we'll just jump right into that. Yeah. So this is kind of like, my like, kind of like Cliff Notes, I guess on what Should you think about when you're doing your first production run and what you should think about when building a test procedure? So the first thing is take lots and lots of pictures. Because what's the old? What do you call those at? We it's a picture's worth 1000 words. What is that statement called? Oh, adage, right? I think it's an old proverb or short statement X, expressing a general truth. So yes, an adage,

adage, okay? Because it doesn't make any sense when you translate into a different language.

The cost of a picture is 1000. Words, yes. So take lots of pictures. I really like taking pictures and then drawing on them with like arrows and text on the picture, because it's looking at picture and then pointing out this is this is a lot more. It's easier to convey than having a picture and then trying to explain what you're trying to point out in text with that picture. So there's those memes were like, a useless red, red circle memes. But people will send you something in like have the important thing circled in red. Do that with your test instructions, though. I like to do black text with white surrounding like outline kind of like the mean text format. Because you can put basically white text with black outline or black text with white outline on any color, and it has enough contrast to standout. So you can easily read it. Keep the test procedure up to date as you're developing it, like develop it at the start. Like basically, I started doing it when I had the schematic done for my board. So that I have the schematic done. And I'll start writing the test procedure for it on that. So as I'm doing the layout, I can add either add, if I need to add like a connector, or test points or something like that to the board, I can do that then instead of at the very end and be like, Oh, now I need like eight test points somewhere in my layout. And it doesn't fit right.

Keep it version controlled. 100%. Yeah, you're probably gonna talk more about documentation side later, that I see that on your list. Yep. So I'm gonna skip that section of mind. If you are able to hand off the test procedure to a colleague, especially one that like maybe doesn't have any idea of what your product is, and have them run through the procedure. Or better yet have like your kid run through it like like a Lego instructions, or, or some basically someone who is not associated with the project at all, because that's going to be where, because that's basically what's going to be happening with your test procedure is gonna be handed to someone who has no idea what this thing is. And they have to test it

100% For work with your CM on your test procedure, start early, especially with your prototypes, because you might be thinking, okay, my prototypes don't need to be tested, because they're going to be tested when they come back to the lab, or come back to the company. But work with your CM at the beginning with that test procedure with those prototypes, and maybe start implementing some of the testing with the prototypes, like, Hey, can you just beat tested with the multimeter powered up, make sure it doesn't smoke, that kind of stuff, just so that your CM starts to get familiar with your product

with like, how it looks and how does it hook up and connect to power supplies and that kind of stuff. In that's actually a big one here at Microsoft because that's like Part A big part of my job at Microsoft is working closely with our clients to flush out all their procedures and fix your designs. So the earlier I can get brought on board to a product or project, the better that ends up being in the end. And the faster to you know, I had I had a meeting with a client today. It was actually like a a recap meeting we had finished an entire project with them. And they they set up a meeting where they're like hey, we just want to review the entire project we would like to tell you some things that would be helpful for you the next time and we want you to tell us stuff that would be helpful for us next time and they asked us they're like okay, this was this was our first time doing cm run PCB stuff. And they were like, if we want to do this again, how, how early should we we rope you into the process and I was like, there is no such thing as too early. Like, if you have a concept for a product, like start time Talking to your CM, then, yes. It's amazing how, because how early on coming up with ideas for testing improvements, or assembly improvements can be worked into your design that early in a concept. Even things that are as simple as like, oh, this CM has a huge stock of this connector, I can use that for board to board connection as opposed to going and searching for one you just rapidly in or you just you just made your design cycle a lot quicker because you don't have to go search for a dumb connector, and you know, you're gonna be able to have it as soon as you want it. Yes, stuff like that. So this is this is another one that another idea that I would say

the majority of customers I've worked with, never think about this until I bring it up. And it is what is the acceptable fallout from your production? Zero, right? Yeah, that's what most people will say is zero. Now we can, we can totally write a contract that is yes, you will get zero failure products, it's going to cost more, because we have to eat because there's gonna be Fallout, most time it's from tolerance backups, or really wonky manufacturing defects that you can't find.

I say you can't find you can find that with enough deconstructive surgery on a board. But that's once again, that goes back to what you just said cost its causes, it's all about costs. So what is the acceptable fault for your production. And this is where you won't know this, if you're just building prototype right away. Okay, this is where scaling up your production, from prototype to production, helps ironing out these QA procedures for your product and figuring out other random, I think we were talking in, in the McWrap, Slack channel, about one in a million issues, the one in a million chance like a tombstone happening, or something like a tombstone components, it will happen, it will happen. It's just a really low percentage. Well, when you start scaling up those, those one in the millions, I'm putting air quotes, because it's less than that. We're see Threepio when you need them, that give us the odds. Those start to crop up and you can start writing procedures early how to handle those. My one example of like a one and million is

we had some boards, I had a board fail for customer, just like this past week. And we Ayomide it couldn't find the defect at all. Okay, I could not find this defect at all. It was just failing their tests, all their other boards are passing tests were like, hey, the testers good. Oh, that's good. Couldn't figure it out, sends it to the customer. And then the customer had to send it to her lab to do because they tested it failed. And then they deconstructed it. And they found that one of the components, the lead was just hovering slightly hovering above the solder pad. And so the two D aeoi. didn't pick that up. Because actually, when you look at the pictures and aeoi, it looks like a perfectly good fit. You couldn't you'd have to do a 3d aeoi to capture it.

And so we put that into our procedure of that product. Is it there's a test failure? Then do a 3d aeoi on the board? There's basically how do you how do we go forward on figuring out what the issue is. Because these boards were expensive enough to where you can spend that much engineering time to get a failed board working. Now, that's that's my next thing is keep your target price in mind when you're doing your test procedures. Because this comes back to the pin guitar, and RGB boards. The pennant tour is fairly expensive board because it's medium volume boards, quantity to boards, and there's less stuff on it and it's a big board. So having a robust test procedure that makes sure it's working correctly and having a a in reducing fault that way is very important. On the flip side though, the RGB boards, which are like an LED and some fr four and a connector,

those are need to be like under $1. So it's one of those Okay, testing procedure is none, right? Like it goes into the pinball machine and if it doesn't work, you just toss it because you're you're just testing them increases the price enough to where it doesn't make sense anymore. Now we might I might revise that if like, I get, like 20% back from a fab, and they're all bad, or 20% are bad.

But I would say that's probably more of a process issue and not, you know, a manufacturing issue, I guess manufacturing issue in processes are just saying, but I guess I'm separating that out in terms of like a setting on a machine like a reflow. oven or, or a component issue? Well, when it comes to the client, an issue is an issue. It doesn't one issue is the same as 100 issues. They all call it manufacturing issue. But behind the doors of the CME, it gets separated into a bunch of different buckets, process being one of them, processes being one of them. Yeah. I know, I'm like, I'm thinking like the client, and that jumped immediately into the CM head, right there. And there's one thing on this list I wanted to bring up. It's not in here.

And it's when you have a test procedure, and you have it, if you have a section where a board can fail out, please let your CM know what that means. When it says something fail, like, let's say, motor drive failed, like as part of your test, and it spits out motor drive failed. Let the cars let's see him know what they can do to figure out what caused that? Is that a component issue? What part of the circuit is the is the reason? Is it because of a connector? Let them know how they can troubleshoot it, instead of just being like, fix it please. Right? Or just not having any idea how to fix it.

That's like, that's something that no one thinks about is it's a pet peeve, right? Yeah, that one's big on my list. Yeah, if you have a failure reason, give us why it failed. So I kind of want to boil, test procedures all down into into one simple thing. And to me test procedures boiled down into understanding the other person. So if you're giving a test procedure to somebody, make sure you have an abundance of empathy for that person. In other words, put yourself in their shoes. And everything that you ask or don't ask of that person. Like, consider the way that they interpret it, consider the way that they are gathering your information, and doing something with your information. Because something, something that a lot of us engineers, I think, forget is that we get so nitty gritty and into the details on our on our little pet project that was assigned to us. And we know everything about it, and we are the expert about it, we are so intelligent about it, that we forget that other people have no freaking clue what your thing even is. And so just have even a mild amount of understanding that the person you're giving this all to has no clue anything about your product. And it's your job to let them know everything about your product. And when you're talking to an engineer at a CME, you know, you're you're paid for your eight hour job to make your little widget and make it as perfect as possible that the engineer at the CME is paid for their job to handle multiple of you. And not just you. So you just as much as you would hate it, to get a whole bunch of just garbage information about your project CRMs have to deal all the time with getting partial information and having to sift through data. So all that boiled down, it's not just I'm not here to flog engineers and say everyone's doing a bad job. I'm just here to say, have a bit of an understanding for the engineer that has to distill all of your information into something usable for someone else. And and applying a little bit of that to how you write your documentation goes a long, long way. And so I kind of wrote a handful of things that are going to be a parrot of what Parker said, and maybe a little bit more in depth. But but all the bullet. It's funny because Parker and I wrote our notes separately, and we're writing effectively the same thing. And it's not just because we work together. It's because we work in the industry, doing industry, generally the same thing. Right. So the first chunk that I kind of want to cover is what I call elements of a good test procedure. These are things that as you're writing a test procedure, just keep these in mind So first thing is, it's almost impossible to have too much information on your test procedure. And, of course, within reason like, you don't need to describe the in detail the functionality of your of your device, you just need to have enough information for people to gather what needs to be done. So once again, you know your little passion project your your widget that you that you've spent your, you know, the last few years of your life designing, go, go have a beer with your buddy and describe the functionality today to him over a beer and like get nitty gritty with it. But go to your CSM and describe how to use it, or how to test it in detail. That's what they want to know. So, remember that your CM, whoever's working at your CM can always distill your information down. So if you give them more information, they can sift through that and create something that works for their internal documentation. If you give them less, that's just always less, it's not going to be enough. They can't make up information. Well, they can do that every day. Yeah. Just just yeah, they can always say like, oh, this is all good information for me as the engineer to know. But for my operator, they only need to know points, you know, one, five and 10, you know, something like that. So provide more information, the CM can always make that whatever worked for their internal documentation. And, and understand that at a typical cm, you're gonna have typically one person that they call the expert. And like, Parker would be the expert on whatever, you know, customer he's working with. So he's the expert, he knows all the nitty gritties of the technical side of things. And then Parker will take that information and give it to the operators and he'll he's not going to give every bit of information to the operators, they'll give the thing that's important to the operators, set them up such that they can be successful. So just understand that everyone you talk to at SCM probably hasn't reviewed your project to every little detail, there's probably one person who has. And then there will be multiple operators, who they themselves will have some expertise in your project, but they probably don't know everything about it. In fact, if you go talk to a lot of operators, they're like, oh, it's the it's the red board with that one weird. They might not even know the name of your board. And they're the one who's working on or your customer name, right? Yeah, they might not like, they will literally just come up with names for this kind of stuff. And that's okay. Because the expert, the person who is the expert at your CM, they're the one who is controlling the information as it goes around. Here's another big one, you have no idea when your documentation is needed. Like, great example, let's just say you're, you you worked for 10 years at a company, you established all of this, you know, all of these products and whatnot. And then for whatever reason you get laid off. But that company still needs to manufacture your product five years later, or whatever, your documentation could still be incredibly valid, it might be in fact, crucial for that company, you have no idea when your documentation is going to be needed. You. Maybe you halted production with your CM, and they let go a handful of people, but a few years later, they need to reinstate your product, they need to pull up your documentation and find a new under an air quotes here expert, they need to go through the information and reset up your stuff, you have no idea when it's when it's going to happen. So don't do things like create documentation that is fixed on particular people, or locked in people's minds create your documentation. So it's comprehensive, and holistic enough that anyone can pick it up at any time and work out what they need to. And here's a big one. For me, this is a giant pet peeve assume the reader. And that includes me and Parker, or any engineer, you talk to just assume that they have basic skills. And what I mean by basic skills is like, if you say something like, oh, read something with a meter, that's okay, or navigate windows, that's okay. Things like that. But like, don't assume that the operator at your CM will write scripts for you don't assume that the operator will be able to calculate things for you. Or anything that's above basic level. The um, that's not saying that those things couldn't be done. Just don't assume that. In other words, don't don't give documentation late in the game. They're already manufacturing your boards and you're like, Oh, here's my test procedure. And they're like, Oh, God, we can't give this to anyone. We have to assign an engineer full time to you to do just the test. Testing Procedure, that's a, that's a fantastic way to make your costs go through the roof. So all of those are what I call elements of a good test procedure, just keep those in mind. And all of these things are things. before you've even written the first word of your test procedure. Just think about these things. Once again, it always points back to like, understand the guy on the other side of the wall that you're throwing your documents at. Yeah, so one of the big things on on that assuming basic skills thing is if, because most test procedures nowadays involve a computer, like running, hooking up to your computer, and either installing software like firmware, flashing it with a programmer, that kind of stuff. If it takes longer than five minutes to install on a Windows box, or it can't be installed on Windows box, provide that to the CME or get in early enough in the game. So you're talking to their, quote, expert, unquote. And so you can get that stuff set up ahead of time.

An operator is not gonna spend longer than five minutes installing software for you. Because that's not their job. It's not their job to install software. Whoever that expert is, it's probably the expert is, but you need to get ahead of the game because that expert is working on lots of things, like 20 customers. So right, right, and they're having to do this for all of the customers. And the reason why I bring that up a lot is, a lot of times we will get test procedures. That's just like, a script. And we don't know what language the script is written in yet. Yeah, I'm most Simon's Python. Most time, but a lot of times it's something else. It's like, get this running. It's like, well, what platform what? What's important now is like, what Python? Did you write it for? What version 2.7? Or is it three is like three is up to 3.9? Now, and some of them are done. The threes are slightly different.

That's up to is very important to document on not just necessarily your test procedure, but how does your test procedure get set up? On setup is a huge, huge thing. In fact, okay, so when it comes to writing a test procedure, I sort of point back to remember how you had to write lab reports. And you got judged on how you wrote lab reports, not necessarily just the content, but how the content was presented represented. I think, okay, more than what they're trying to get you to learn in school about like the end result of a lab report, writing a lab report. A good lab report, is great practice for like writing a test procedure, because even though a lab report half the time isn't saying how to do something, it's saying how you did do something, they're still very similar,

I would say there. So how I write tests, it's actually interesting you bring this up, because I just thought about it, is I write test procedures like that, though, not how to do something. But what was the how you did it? Yeah. That's how I kind of write it. It's a slight distinction. But it's an important one, that I basically do a step and then go write what I just did.

So at the top of your test procedure, I suppose like, everyone has a different way of formatting, but I kind of prefer it this way, at the top of your test procedure. There's a handful of things that I think that if they just exist, they cover so much territory and make everyone's life easier. And it's actually what Parker just said, is basically your setup, the very top is all the things that are set up. And I'm not talking about setup for every time you run the test procedure that's guaranteed needs to be there to but set up for the very first time you've ever seen this document ever. What is the setup? So a handful of those things are, you'd be surprised about this, the product or the assembly name, like oh man, just have the name of the thing you're testing on the document you're testing, you don't have it be the name of the document, like literally just write it up at the top, you are testing an XYZ product. You'd be surprised how much you don't get of that where like the file name will be like 15 characters and then the product name or whatnot, that as soon as an operator sees that their eyes glaze over like it needs to be bold written up at the top. Guaranteed 100% mixture, Parker said this earlier, have your your documentation revision control. So you are testing XYZ product and right underneath that Rev. I don't care, whatever you your rev system is just put it there. Ooh, lots of Oops. Okay, and then this is another thing that that is super helpful if you have multiple revisions of your board, put a list of all board revisions that this test procedure applies to. Because whatever test procedure, you have mine apply to this rev and the last one, but not the one before that, or the one that's coming up. Exactly, exactly. Just make it. So it's really easy for me to open up the document and see, okay, this is the right one. Okay, the next thing that I would love to see is a map or an image of your product, with terms or items on it. So like, let's say you have an assembly that has three boards, one board is called board X. One board is called board puck. And then another board is called Lucy, have a picture that points and said, This is board x, this is Puck, and this is Lucy, you'd be surprised how far that goes. Just to say like, here are the definition of my terms. These are the things and I'm going to say this later in the intersection, but be consistent all the time. If you call a board, Lucy, then anytime in the in the test procedure that you referenced, Lucy, just always say Lucy, don't say anything else. And that might require you going through and proofreading your test procedure multiple times to say like, oh, did I do this consistently? just tried to make it very clear.

So on that, yeah, on that note is because I've been building a lot of tests, procedures and tests equipments that are going out to our partner factories. And that's actually so you get a so how I have them set up now is you get like a pelican case. Okay, I'm not buying Pelican cases or buying like the off shelf like no name brand one. But one of those shows up at their fab. And they open it up. And the first thing they see is this front page. Yep. That is what this what the case is got numbers on the outside, like identification numbers, but so they know like, Oh, this is box XYZ three to four.

When they open up, it says, this is the product it's testing. This is what the test procedure. And then what's app that is a manifest what's in the test tester. Like, there's supposed to be a scanner, there's a laptop, there's a charger, there's USB cables, and these are the kinds of USB cables that are in here, that kind of stuff. And I've actually gotten to the point where I actually assigned part numbers to those things. And so I just referenced the part number, so not to say, oh, grab your Honeywell scanner, XB 4392 and scan the thing. I'm like no, just just say it's a hand scanner. Right? Right. Yeah. But But somewhere. In some documentation, you should say a hand scanner. Is this part number? No, that says on the front page get right, right. Yeah, on the front page. It's like, the laptop is assigned this number. I'm not gonna call it that number all the time. But just for your reference, that's what it is called on the front page. Great. Yeah, that's super helpful. And I mean, you could go even further and get a label gun and label the hand scanner hand scanner and stick it to there. Like, oh, yeah, there, it is impossible to make things too stupid. And I'm not trying to say that people are stupid at all, I'm just saying like, there's no possible way to make it too easy. Just shoot for that. So So another thing in this top section that I think is actually really important, is including a list of all software necessary. So if if, like, let's just pretend like you have something where a customer is asked, Hey, whenever a product is done, I want you to write a serial number in an Excel sheet will then Excel needs to be a list of software on there. You know, or I need, we're right, we're running a Python script. Python needs to be on there or just I've written a custom program put you the name of your, your program, anything, it doesn't matter. You can make assumptions like a computer is going to have windows you don't have to write operating system is Windows, you could but just that's one safe to, to assume. But what that does is it helps that expert when they're going to set up a computer, maybe they even have to purchase a computer. They're also like, Oh, these are the things I need to install to have it ready for game day whenever production goes. And then just like Parker said, if you have like Python, right, I need Python on there and the revision of Python must be this. What modules do you need installed that kinds of even better though is if provide those provide those actually one of my favorite things I've had customers do is provide a bootable flash drive with their OS and all their stuff installed on it. So all I had to do is put that into any computer and boot up that flash drive. And usually it's like a boot to a Linux distro. Like a live disk. That saves so much time. That generally works pretty well. Yeah. So in addition to the software, if you have any files that are required for your thing, write a list of every single one, put a put a list for every single file. So let's say you have a firmware file, that's my product 123 dot hex, like put that write that down, you are going to need a file called this and, you know, put the revision letter on there. Or let's say your product has an SD card or something that has an ISO that needs to be burned to that SD card, write the name of the ISO. Just make it extremely explicit. And don't be afraid to just write the actual name that as it appears on your screen, like it needs to be exact. And then once again, be consistent with everything you do. If you if later on in your your test procedure, you say we need to flash this firmware to this, call out the name of that firmware, as it's written on that front page on that initial like, here's the things you're going to need just always Table of Contents effectively. Yeah. So then, when it comes down to actually writing what I call the meat and taters of the test procedure, there's a handful of things that that I feel make everyone's life easier. So underneath all of those things up at the top, I think a list of required equipment. So just like you put software, have a list of equipment, you're going to need a multimeter. And, if necessary, describe the multimeter and add at least this much accuracy and or, or whatever. Or if you know, even better yet, if you've already talked to your CM and they say hey, we have fluke 80 sevens, well then write down you need a fluke 87 here. If you're in talks with your CME early say, hey, what equipment do you have? Maybe the CME is like, oh, yeah, we don't have anything, we've got nothing. Okay, great, well, then now, you know, you need to go buy some meters or some scopes, or whatever you need in order to execute with the list. And a big thing on this, I see it here says be granular here, all the way down the cables, I was about to mention cable 100%. If your thing has a USB, a to a cable, right down USB A to A k, like literally all the way down to every single item. And and I like if somebody has Amazon links or something like that to like, this is the cable I bought, or whatnot, like, include those in there. What, like I said earlier, this is all information that goes to that, quote, expert. This is stuff that the operators don't need to see. So when I say it said earlier that the expert can distill information down, these are all things that they can rip out on the test procedure and then just provide the actual executable steps to the operator. But these are still things in my opinion, that should be in the test procedure that gets sent to the CME, correct, right. Yeah, your your CME is going to build their own set of instructions for their line, right? They're not just going to print this out and hand it to somebody and be like, good luck. Yeah, well, they'll do that to the expert. So yeah, no, the expert would do that to him. him or herself? Well, yeah, for sure. So yeah, break be granular, every single item that you sent, like Parker said, with the with hit the Pelican case, every single item in there has a number or somehow it's referenced and units are what's in the you have a manifest out of the box. That's perfect. So list every single step as you're writing it out. So try to do things chronologically, do this, then do this, then do this 123, like walk down, avoid parallel as much as possible. Like, there shouldn't actually even be any parallel. If if a test procedure requires a lot of parallel action, then perhaps the design needs to be revisited. There. And test procedures really shouldn't have forking paths. Except for failures, failure analysis, both say Right, so So let me let me let me kind of step back one second on that. I think you can have parallel things as long as it's not up to the operator to decide the parallel action. Yeah, like if you have a script that's running stuff in the background, I don't care if it's going through 15,000 parallel options, that doesn't that doesn't matter. But if the operator has to make a decision, and like, Oh, I'm gonna going down this path if XYZ happens where this path that seems like it probably could be adjusted such that you have one path to walk down. The The one caveat to that is a failure mode. A failure mode is always a fork, it's always a parallel. So, if, if Well, let me go on what we'll go to failures in a second, because there's one other thing that I want to mention before that, and this is one that I think is missed all the time. And it's the most critical to me, is Pass Fail criteria, and being reasonable about Pass Fail criteria. What um, let's, let's take a simple example, let's say, you ask an operator to measure a voltage, we already assumed that they have basic knowledge. So okay, they can grab a meter and they can measure a voltage, don't have something like, measure. If point is 5.000 volts, you will fail every single item, it has to be target, show a target 5.000, show a tolerance and say if it's within this upper and lower boundary, then you're good. Always have a criteria that has a past condition, and a failed condition. The past condition means you go on to the next step, which we already said, listing your steps, go down to the next one, the fail criteria is when you have your parallel branch. If something fails, don't just say it failed, say what to do with it, if it fails, and the what to do with it might be put it in a bucket. But it also might be Oh, it failed. Maybe something needs to be checked, then if it failed. So maybe there's something else that you need to do specifically there, but give instruction on what happens. If you have a pass fail criteria, and you don't have a what to do if it fails, then the criteria means nothing really?

Correct? Yeah, it just means that it becomes E waste, right? Right, they'll just throw it away. And it will and you also don't learn anything about why it failed. Or how much of your product is falling out because that this goes back to what I was talking about earlier is having criteria. And this is this is use your example. You have your measuring voltage of five volts plus minus, let's say half a volt, because that's the USB spec. So what if it's 5.6 volts? That's a fail. So sure it's fail. But why is it how does the CME figure out what they did wrong for it to fail? And this goes back to to scaling up. When you start scaling up, you start finding weird issues like this, of tolerance seen between components. And a lot of times when you are trying to measure these voltages like this, it's mostly for like, it's like for tuning or you make making sure yeah, you're it's calibrated correctly.

A lot. I think Stephens products lots of they build has a lot of tuning involved like trim pot setting that kind of stuff. Are the stuff that we do macro. There's some products that do but most of it does not. So when it misses that voltage, there's not much we can do on our end except be like, like, you're like holding it up to the customer. Like, what happened more information, please, as tears go down. Yeah. And trying to figure out like what, like, we built this board to your specifications, and it failed your test and we can't find anything wrong with it. And why is that? And that's not a point of the CM trying to point fingers, the CM is trying to be trying to figure out, do they have a process issue that they can't figure out. And the and I will say that is majority of those that I've run into, it always starts falling down like tolerance issues, tolerance, that cup issues in like, mass quantities, like changing a resistor to a five from 5% to 1% fixes that problem. But, but cm can't figure that out alone. They need to know what to look for. Right, right. And actually, so back to the whole understanding thing. The the CME is trying to understand your product, but they don't have the intimate knowledge that you do. You need to understand the CME because they don't have the intimate knowledge that you do. Don't immediately just say, well, you built it wrong. Especially if it's a problem like Oh, it's 5.6 volts versus in the spec is 5.5. That means something's probably operating correctly. It's just out of spec or whatnot. So don't just immediately pounce on your CM and be like, Well, you guys screwed it up, figure it out. out like, that's a really great way to sour relationship. Be oh man, how long ago was that? That was that's a really great way to get fired by your CM. Oh, yeah. Wasn't a marketing term that Max had used a long time ago, probably in one of their monthly newsletters or something. Yeah, yeah. So I guarantee I've told this story at one point in time, I've probably told him to Parker, but maybe even on the podcast, but it was it's so etched into my mind, because it was it was really poignant for me. At my first job, we had written a test procedure for one of our products. And we did exactly this where we wrote our spec is we want this number, but we're okay with a range around that number. So plus minus some amount. After we had written that test procedure, we saw that all of our products in this entire product line were on the low side of the spec, every single product was on the low side of the spec. And we're like, Wait, nothing has changed about our product, we didn't change the design, we just rewrote the test procedure. Well, what we realized was, we put a boundary on our like, we our target was, say, five volts, and our range was 4.5 to 5.5. Well, what we had realized is that there was a trim pot on on our board, and all of our operators were turning that trim pot coming from beneath. And as soon as they reached the lower limit, they were like, well, it's in limit, so they stopped. So they were calibrating all of our products to the lower limit. And that's that was acceptable, because we said it was acceptable. But it bias to the average of all of our products low, which is a little bit annoying. And the way we fixed it is we put the target number as the low spec. And we allowed a positive tolerance on that such that all of our operators then turn that trim pot until it was perfectly in spec and all of our stuff average was exactly where we want it to be. Keep those kinds of things in mind. Because operators are not going to say like, oh, well, the target is five volts, I'm going to spend all day trying to get to five volts. No, as soon as they reach your spec caller, they're done, they've done their job, they'll move on to the next one. And that's not them being rude or mean or inconsistent. That's them trying to do exactly what you asked for. So be really mindful when you write your criteria as to how that criteria is actually obtained. Then, and then Parker mentioned this earlier, pictures are worth 1000 words 100% You can almost not have, like I said earlier, not enough information, you can not almost not have too many pictures, if something happens, or is supposed to happen, have a picture of it. And I even mean, if if your fancy schmancy script that you wrote that like does all the work for you. If that script is supposed to output something, have a picture of what that screen looks like, when it outputs that thing because, okay, so 100% command line is a great way to make an operator just go cross eyed, like an engineer can sit and look at Windows command line and decipher all the 1000s of characters that fly by 99% of operators have no clue what's going on. And they're looking for that one little bit of text that you ask them to say we're just like, Test complete, or is this pass or whatever? Fine. Like that's okay, but have a picture of that. Also, if, if you've written a failure mode into your script, have a picture of the failure mode and say, If it fails, because of this, this is the screen you will see. And like maybe even like Parker said, like highlight it in red or whatnot, like just make it super clear. That goes back to what I'm saying about understanding operators probably have, in their personal life have probably never touched command line in their life. So you asking them to run your fancy script and command line is the only time in their life they've ever seen command line. They they probably never even programmed before. So it's all new to them. Don't make the assumption that they have any clue what your special characters are that you wrote into your script. And then if anything is to be marked or saved. So like let's say, let's say you provide results. Yeah, the results but let's say you provided a sticker printer, or whatnot. And like after a pass fail, it prints a past sticker and the serial numbers on there. I can have an entire podcast about stickers. show a picture where you want that sticker to go on the board. Like say right here. I want it to go here. And look, I'm being dead serious about this. If you care about the angle that that sticker goes on or how perfectly it gets placed on your board, create a jig, create a jig or create a picture, showing it like, I like my stickers being like this and show a picture of a board with the sticker cockeyed at a weird angle be like don't do this. Because if you don't provide those pictures, your board will show up with at least a cockeyed sticker somewhere in your in your list. Especially if you're doing you know millions of boards, you're gonna get lots of cockeyed skicka stickers on your boards. And you just cannot provide enough information. And that might not even be completely distilled down to the to the operator from whoever the expert is, they might just be like, Hey, guys, we have to put the stickers on perfectly straight and do training for days on end of like, put the stickers on straight. They might not even see those pictures. But if you don't provide the pictures, and you just say, put a sticker on the board, who knows where it's going? And who knows where it's what angle it'll be at? No. So now we're running up in like 50 plus minutes, so I'm not gonna talk about I'm gonna talk about stickers next week. Holy crap. That's like, yeah, stickers are a whole nother beast. That labels man. Yeah. So I mean, hopefully this was all. Hopefully it didn't sound like we're just trying to beat people up on this, but I hope not. Yeah, I what this is really coming at is like, I've been on both sides of this argument. And, and I have sympathy and empathy for both sides. Yes. That's the big thing is like, we have both made products that had to get tested. And we have tested other people's products. And this is kind of like, okay, what have we learned in eight years? Yeah, macro what the podcast is, what, five years? maxpreps? Almost eight. Podcasts is what five years old now? Oh, there's one more thing real quick. I didn't I didn't mention this, this will be this will be a quick one. Do not maybe not DO NOT but But I say do not. Do not suggest hot fixes. So in other words, like if a board fails, just touch up this one solder joint real quick, like the operator doesn't need to be distracted and go try other things. Especially if there's 1000 boards sitting behind that one that they're trying to do a hot fix on real quick. If something fails, it gets set aside and it gets addressed separately, perhaps with a separate document or a different operator or a different operator, right, maybe they pass it to somebody whose job is to do the hot fix, but whoever is the one who's doing your, your continuous operation don't suggest hot fixes to them. I would say that's more on the CM side of distilling your information down because you can have the hotfix in there for I have fairly path touch up this leg like because it's probably a cold solder joint or whatever. It should actually be more on the CM job their expert to take that out and set that up for the for their line. So

I actually kind of disagree with you on that one.

But you just said that the the CM gets to choose. I'm saying don't write this for the operator as if like I'm the customer writing it to the operator say this operator should do this hotfix I think the CME should choose that. Okay, yeah, the CME should figure out how that process works. So that was the macro fed manufacturing podcast, engineering podcast but we talked about manufacturing well test manufacturing is our time. So we were your host Mark Edelman, Steven Greg, let everyone take it easy Thank you. Yes, you our listener for downloading and listening to our podcast. If you have a cool idea, project or topic, let Steven I know. Tweet us at Mac fab at Longhorn engineer or at analog E and G or email us at podcast at Mac fab.com Also check out our Slack channel. You can find it at Mac fab.com/slack And if you enjoy this podcasts, let a friend or enemy know frenemies frenemies.