schematics

Altium supports variants directly and intuitively, configurations and internal or external revision control IIRC. It can also do some diff functions. You can generate a report showing the differences between variants.

If you need PDF schematics then I guess you'd have to generate different schematics for each variant. Components that are not fitted show up on the schematics for variants, but they are X'd out or greyed out or whatever (there are some options).

The process allows creating power supplies with different input and output voltages and current ratings without doing separate schematics.

And we can use high-reliability parts if the customer asks for them. Sometimes a customer specifies that certain parts come from a specific manufacturer,

Our techs wind up redlining the values of the parts on their schematics that don't match the current BOM. Yours might redline every part.

I used to be able to say "Naw, they just staple a copy of the BOM to the schematic.". Now they just open two files on their computer.

Bob

Our capture tool allows design variations. It's about the only thing it does reasonably well.

I show a value of "OPEN" for unstuffed parts. Actually, it's a flag but I substitute it for the value. If the part gets stuffed, the flag gets turned off and the value turned on.

How so? If you're under (ECO) control, these errors should be impossible. The BOM controls the build. It doesn't (have to) reference a schematic.

John Larkin schreef op 06/04/2015 om 09:34 PM:

IMHO a schematic should always show the right values because you use the schematic to repair or debug a device. Also the schematics are what people save. The BOM just gets lost. A couple of years ago I did a redesign for a customer. The BOM was lost over the years (the company got split at some point) and it turned out some component values in the schematic where wrong. It took quite some effort to figure out what the right component values where because they where a tradeoff between several variables.

If you have multiple versions then you should somehow be able to produce a schematic with the right values.

We save the BOM and the schematic and the ECOs on the same server, and they get backed up together. So if we lose one, we lose them all, and there's no problem!

A couple of years ago I did a

A good ECO not only changes the values, it says why. And exactly what the effectivity is, namely which assemblies to change. It might change a single unit.

Given a product that has several revs (we have got up to rev J on one) and several dash numbers (say, eight) and some ECOs along the way, we'd have to archive scores of distinct schematics for one product, and it would be a chore to produce the exact schematic for BlueWidget-6J serial number 999.

Configuration control is a nuisance; or maybe a nightmare. There are people who have careers doing nothing but config control.

Amen! I sure wish all engineers would understand why this is necessary.

Considering that nowadays the BOM comes rolling out of the schematic and not the other way around I never found that to be a problem. At least not since the days of electronic file formats. I was lucky that my very first employer in the 80's already did that, using Futurenet-Dash.

It was not unusual to have to support half a dozen versions of a board and more than a dozen for systems. Mainly because it's expensive medical gear that is very long lived. This means that service folks have to have access to the correct schematics even for a machine from the days of Methusaleh.

I have always wondered what could possibly motivate someone to seek a career in a documentation department. But the people I met in those departments where generally very smart and seemed happy with their job. And without them it would all be a mess.

I've pounded this into my engineers so many times, they practically start every ECO with a novel. Poems next maybe.

PADS generates a BOM that's (almost) in our format, which does the initial grunt work. But it needs a lot of editing. We show mounting holes as parts, but they don't belong on the BOM. And we have to add spacers and such that are not on the schematic. We often need a bunch of comments, too, like INSTALL THE FOLLOWING BEFORE LUNCH or whatever.

After that, the BOMs becomes the prime controlling docs, and we don't update the released schematic. It works.

We don't expect field service at the part level, and customers don't get schematics. Well, one does, and that encourages them to mess with my circuits and wreck boards. They tend to solder and not think. They are not good at either.

They tend to be very earnest, too.

What gets printed on paper? Now things are organised but what happens if you decide to sell half the company? Who is in charge of the data? When a company is functioning normally there is no problem but when a company gets split or other mayhem happens you'll see a lot of information is stored in the grey cloud (people's brains) and knowledge on how data on servers is organised is less well known than it should be.

A certain design for one of my customers is at revision 18 and they already ordered the 19th en 20th revision. A changelog with what & why is changed is on a page in the schematic. With every release the version number is incremented (even if some changes are just some values).

Any time anybody wants a hardcopy, they print one. B-size, on our networked digital copier. We just got a color one, so it's tempting to start doing schematics in colors.

Now things are organised but what happens if

Actually, we haven't planned much for that situation. We're more concerned about losing hard drives, or fires, or earthquakes.

The company librarian formally releases docs, and logs them, and takes appropriate actions, like updating a BOM after an ECO.

When

The server situation is obvious. On the networked M:\LIB\ folder, where each product has a subfolder. The sub-folders are obvious, too. The file naming convention is pretty simple, and the whole thing is summarized in the M:\PNP\ (Policies 'n Precedures) folder.

Oracle this ain't! Companies who run the Oracle software can't find their butts in the dark.

Yeah, I guess some people do that, but that's a lot of docs to manage.

There is no perfect solution to this problem.

We use OrCAD with the CIS option, which allows as many build variants as you like. It links the schematic parts to your company parts database (MSSQL or whatever) using ODBC. Never used PADS but I would think they'd have a similar option available.

Looks like it does: Page 2, 'Component Management'

ISTR you wrote your own parts database engine. I've never looked at the API for ODBC but I can imagine that writing a driver for it from scratch would be a bit of a challenge...

CIS is, like the rest of OrCAD, a bit clunky and not very well integrated with the rest of the package, but it works well enough for us. The BoM export is very configurable and the output is, with a bit of prettifying, usable as the final document.

We don't do many BoM variants, say 3 at most per board. We do a few re- issues for part obsolescence and such, in this case both the BoM and the (PDF) schematic get superseded. It's a lot easier for the repair techs to refer to the values on the schematic than to flip back and forth between schematic and BoM. The revision level of every board is on a sticker the contract manufacturer puts on the PCB.

These days almost nothing. Except when there has to be a signature in real ink for some legal reasons. Then often only the signature page is printed and filed.

The documention department, typically linked to Reg/QC. If not then the new company isn't being operated correctly.

My last employer was sold three times by now and AFAICT nothing got lost. Of course, being a medical devices manufacturer we always ran a tight ship. Not just because FDA demands that but because it makes sense.

I tend to print out the pcb and then the cad file for the front/back panel. I then check that all the holes line up, And everyone agrees where the edge of the box is.

Hey, can a get a pcb into *.dxf format and look at them both in cad?

George H.

PADS can import/export DXFs. We go both ways, PADS interchanging with Autocad and Solidworks. Everything lines up these days.

This is where transparent view helps but unfortunately most CAD vendors do not understand the value of that.

Except once where guys from the UK specified something in mils and the American tool and die makers didn't realize they meant millimeters with that. About $800 later everyone realized the mistake.

These days I generate a 3D .step file from the PCB and place it in Solidworks.

The usefulness of that is directly proportional to how good your models (enclosure and 3D component body) are, and that can take a lot of effort to do well, but it sure helps with checking for interference on facing boards in a tight enclosure, looking for clearance against curved internal surfaces and that kind of thing.