Issue link: https://iconnect007.uberflip.com/i/1293772
52 SMT007 MAGAZINE I OCTOBER 2020 it as a single design to the fab shop. When the assembler gets it, all the pick-and-place data will be correct, the ori- gins will all be correct, and we'll make sure none of the reference designators overlap. That's one thing we often have to regularly educate our customers on—espe- cially if they've worked with the cheaper bucket shops— because they know they're all getting built, thrown onto a common panel, and cut out. If you're hand assembling, you're fine. If you're getting a board that's not an array and it's one up, it doesn't matter. If you need the rails and panel, then that's something that you really want to think about. You could have the fab shop combine the Gerbers. They can do that, but unless they're rerouting them back out as individual subpanels, so that when they go to assembly the origin and XY data match, you're better off merging it yourself because your assemblers are going to have something that they have no easy way to program. Dan Warren: From a company standpoint, Jen just summed up everything really well. In my personal opinion, just don't do it. There are so many hassles in doing it. I'm very old school when it comes to this. There should be one board and one database. It's easier to manage the revisions and data. If you want to make a change to one, you don't have to make a change to both and fab them together. At Mon- soon, I do whatever the customer wants. If they want 30 boards in a panel, I'll do it. I'll advise them not to, but I'll do it. In many places I've worked, it was just a hard no. Kolar: People don't think about the fact that if we are combining them in one database, then we have to merge the schematics, too. We must have no conflicts between any reference des- ignators or net names. Put these all together. Throw them all on the same board. You don't think about the fact they have to make the schematic properly associ- ated with that. What I tend to encourage people to do, when they're really set on trying to save money building a few of each one, is to work with your fab vendor. Have them be independent databases. If it's the same stackup, the fab vendor can put multiple differ- ent sub-arrays on their overall working panel. You could have one array of board A, an array of board B, an array of board C, and your fab vendor knows how to optimize for that. Let them do what they're good at and make decisions on how to make it the most cost-effective. Warren: That would be a much better way to do it. Kolar: Assembly is such a painful time for a mistake to be found. We do so many manu- facturing jobs, and in a lot of cases, we didn't necessarily do the design for them. We're find- ing out last minute if a part wasn't fully spec- ified in the BOM, or it's not specified in the schematic, so you end up with the wrong one. One issue in assembly that commonly hap- pens will be an engineer edited the schematic, but they may have changed the value of a part in the schematic and didn't change the entire symbol, so the BOM is still incorrect. A mis- match between a manufacturer part number and value happens all the time. We try to catch those while kitting, but if missed, you find those out in assembly. From the project management perspective, assembly is where we lose time even more so than with fab questions. The machines are loaded, the assembler can't touch another board while their assembly line is loaded with this design, and you can count on the fact that it's going to be at least a day to mail them something else or order it. It's not, "Let me think about this and get you new data." You need physical things. Depending on how much time you have, they might not be able to just Jennifer Kolar