Author Topic: Common practices and schemes for schematics and PCB's versioning  (Read 1749 times)

0 Members and 1 Guest are viewing this topic.

Offline VinzCTopic starter

  • Regular Contributor
  • *
  • Posts: 217
  • Country: be
  • See you later, oscillator.
Hi guys.

Out of curiosity. I'd like to know what your conventions for naming PCB's vs schematics are. I'm aware that disziplin! is key to properly manage projects, just like consistent naming conventions are key in software development. Here are a few of my points of questioning. Note: I'm using the term "revision" but you could use what suits your habits, so just describe what you're doing in general. Here are a few of my questioning points:
  • Do you use anything else than a "revision" marking? In software development, for instance, we often use major + minor + build version numbers, though not limited to that set.
  • Do you use numerals or alphabetic revisions? or a mix of both? Or something else?
  • When do you change that revision?
  • Do you keep separate/distinct revisions for PCB and schematics?
  • If a schematics is edited, what about the related PCB revision?
  • Do you change the revision only of the schematics that was edited or are all related schematics bumped to that revision as well?
  • How about multiple PCB's for a project?
Would you mind commenting and describing your practices? I'm looking for a scheme that's not too complicated (yes, that's a matter of personal perception, I know :D) to manage by hand or by script otherwise. Also note that I'm using GIT for tracking my changes, both for schematics and PCB designs.

Thanks a whole bunch for any hint and/or suggestions.
« Last Edit: May 17, 2022, 12:10:23 pm by VinzC »
 

Offline Terry Bites

  • Super Contributor
  • ***
  • Posts: 2353
  • Country: gb
  • Recovering Electrical Engineer
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #1 on: May 17, 2022, 03:24:24 pm »
Document it from day one. Only fools jump in.
The simple way is to give the PCB the name of its function and the product its for. Don't be cryptic or use codes it never protects you're product.  Keep records of all versions and revisions and bugs and improvement ideas. Keep a record of who made your PCB and the batch numbers.  Always a date for a version number eg V1.0, V1.1 V1.1 with a rev# if its the same thing but with some bugs fixed. Probably your initials and the company name.

Keep all CAD and artwork.  Photograph all of it and note down the assembly sequence. Set out a test procedure. Keep BOM, suppliers names and cost info. Bundle in all data sheets for components that you have used or thought about using. Then 2 years down the line you'll be able to look in the mirror with out a feeling of deep regret. Doh!

If you're sending out to be made then there will be all the accounts, manafacture and test procedure detail to add as well!
 

Offline VinzCTopic starter

  • Regular Contributor
  • *
  • Posts: 217
  • Country: be
  • See you later, oscillator.
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #2 on: May 17, 2022, 03:30:02 pm »
Thanks for your insights but I think you've gone [waaaaay] too broad without answering my main question, which is: how do you manage/link/relate your revision numbers/naming between schematics and PCB's?
« Last Edit: May 17, 2022, 03:32:27 pm by VinzC »
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #3 on: May 17, 2022, 03:37:41 pm »
Out of curiosity. I'd like to know what your conventions for naming PCB's vs schematics are. I'm aware that disziplin! is key to properly manage projects, just like consistent naming conventions are key in software development. Here are a few of my points of questioning. Note: I'm using the term "revision" but you could use what suits your habits, so just describe what you're doing in general. Here are a few of my questioning points:
  • Do you use anything else than a "revision" marking? In software development, for instance, we often use major + minor + build version numbers, though not limited to that set.
  • Do you use numerals or alphabetic revisions? or a mix of both? Or something else?

First I will say that the PCB and the schematic get separate part numbers and can have different revision levels.

Part numbers are just an incrementing numeral, assigned by the person who has the keys to the MRP system.

Revisions are letters, with the exception of the initial release which is simply '-' (dash). They indicate the release level of the item. Our rule is that a PCB must be released in our system if it will be fabricated. Actually the rule is that anything that goes out of house to a customer must be released entirely.

For other things, especially firmware (firmware gets a part number in our system), we have this notion of "prelease" revisions, indicated by +1, +2, etc. Prerelease is not "official." It basically corresponds to "OK, I think this is good, so let me give it to someone else for testing." The code for this prerelease is of course a tag in the source-code control repository. But it's not official. When the code is ready for release to customers, then it gets a proper revision number and again a tag in the repo.

Quote
  • When do you change that revision?

For released product, if there is a change to the design, then ECOs are written and when that is all handled, the revision is bumped, say from - to A or B to C.

Now say we build a first-article board and the schematic calls out resistor values. During test we decide we need to change a couple of resistors. The schematic (and the resulting BOM) are marked up with the new value, and the new schematic gets its pre-release bumped up, so now it's rev +1. When it's final, again an ECO is written and when finished the schematic will get a new revision say rev A.

Do note that all old versions (and pre-release versions) are archived. Nothing is thrown away.

Quote
  • Do you keep separate/distinct revisions for PCB and schematics?
Absolutely. It's very common for schematics and PCBs to get out of sync with regards to part values. A PCB may be on rev - but the schematic and BOM have advanced to rev B because of changes. The point is that the new parts can get put on the old board.

Quote
  • If a schematics is edited, what about the related PCB revision?
If the physical board layout does not change, then its revision does not change. The board doesn't care that a resistor value went from 10k to 12k.

Quote
  • Do you change the revision only of the schematics that was edited or are all related schematics bumped to that revision as well?
If you are referring to multiple pages in the same schematic, all of the pages get a revision bump. The pages are not separate as such. The top-level sheet will have the change log with the revision, and the page or pages changed will to have their change log section updated.


Quote
  • How about multiple PCB's for a project?

A higher-level assembly document (which itself gets its own part number and revision history) calls out each PCB in the product, as well as everything necessary to actually build it.

« Last Edit: May 17, 2022, 03:44:35 pm by Bassman59 »
 
The following users thanked this post: VinzC

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #4 on: May 17, 2022, 03:40:20 pm »

The simple way is to give the PCB the name of its function and the product its for. Don't be cryptic or use codes it never protects you're (sic) product.

For the purposes of a purchasing person ordering boards and parts, giving the PCB a name doesn't make sense. That person doesn't care. They're given a BOM with part numbers. 

 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #5 on: May 17, 2022, 04:06:38 pm »
Assembly :

product number -  revision - variant

variant : BOM change ONLY ! value changes , installed/not installed. for example installed options. bare PCB is unchanged (unless revision is in effect).
revision : netlist and or layout change.

someproduct-A-03   : variant 3 , original design
someproduct-B-03  : still variant 3 , newer design

Bare board

productnumber-revision
someproduct-A
someproduct-B

So the bare board and the assembly share the same name and revision.

that way you can pick up a board and immediately know what you have in hand. only the installed options change. but you do know what design to open.
« Last Edit: May 17, 2022, 04:10:44 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline coromonadalix

  • Super Contributor
  • ***
  • Posts: 5795
  • Country: ca
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #6 on: May 17, 2022, 04:48:40 pm »
I would add   

keep  all version(s) / boms/ pcb revisions etc ... changes history for a few years, you never know if one pcb may ''come back'' to haunt you  loll 

I can't recall how many years you have to do so,  in my company it's a minimum of 10 years for ISO purposes (medical stuff) ...

stay simple for the products identifications : like the previous threads


PSU001-rev01
RF-A-R01
RF-B-R01

Sometime we had  what we called  APLHAS, prototypes pcb's not put into productions, BUT they where RED board(s), that way we knew they where from the R&D department and not the official blue's or green

The blue's   where from xxxx 
The greens  from another xxxx source

Even had some yellow ''ish''  boards too


You will need to manage the pcb makers / source too,  we had many manufacturing problems with a known maker, tons of failing pcb traces, shorts in the pcb layers  etc ...



 
The following users thanked this post: free_electron

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #7 on: May 17, 2022, 05:17:04 pm »
keep  all version(s) / boms/ pcb revisions etc ... changes history for a few years,
disc space is cheap.. NEVER delete anything. it will come back and bite you. and keep copies of old installers of the CAD tool used as well ! so you can read the damn files when needed.

i learned that very early on.
-ring-
Q we are looking for the design files for project xyz.
A never heard of it.
Q it's like ten years old.
A before my time.
Q most likely stored in our archive can you check.
A hold on ....
A it's not on the server.
A there's still a bunch of tapes here ... nope
A ... i found some reel-to-reel tapes.... damn. the tapedrive is long gone...
several days pass where an old tape is shipped to a company to read it and write it on a magneto-optical disc. ( this is 1991 ....)
A found some files but they are a later revision than what is asked for. there was a readme file that says the earlier version was stored on a discpack....
A found the discpack ... anyone know of a company that still has the "washing machine" to read it ?  http://q7.neurotica.com/Oldtech/Media/Diskpack1L.jpg
several days pass....
Ok, we got the files. now does anyone remember what cad program was used to make this layout ? File dates are from the late 70's ...

Fortunately the stream data was GDS so it could be read using a different program (Cadence Opus). we never managed to find anyone that could read the schematic files. they had to be redrawn from paper copies and the netlist crosschecked with the recovered layout files.

This was a pin diode driver for some radar. we built several thousand of these chips and sent them for qualification. the acceptance tests lasted over 10 years ... by that time not only had we lost the computers, the software and the files, the production process ( 2 micron bicmos )  was long gone from our fab and the masks were gone too.. as were the original designers. Now they placed an order for several million of these chips ... had to move heaven and earth to recreate the masks.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 
The following users thanked this post: thm_w

Offline VinzCTopic starter

  • Regular Contributor
  • *
  • Posts: 217
  • Country: be
  • See you later, oscillator.
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #8 on: May 19, 2022, 10:17:34 am »
[...]
-ring-
Q we are looking for the design files for project xyz.
A never heard of it.
Q it's like ten years old.
A before my time.
Q most likely stored in our archive can you check.
A hold on ....
A it's not on the server.
A there's still a bunch of tapes here ... nope
A ... i found some reel-to-reel tapes.... damn. the tapedrive is long gone...
several days pass where an old tape is shipped to a company to read it and write it on a magneto-optical disc. ( this is 1991 ....)
A found some files but they are a later revision than what is asked for. there was a readme file that says the earlier version was stored on a discpack....
A found the discpack ... anyone know of a company that still has the "washing machine" to read it ?  http://q7.neurotica.com/Oldtech/Media/Diskpack1L.jpg
several days pass....
Ok, we got the files. now does anyone remember what cad program was used to make this layout ? File dates are from the late 70's ...[...]
I hear you, alas. We must admit humans and technology actors all made sure that happens and *will* happen again. As if reliability, availability, longevity, sustainability, maintainability no longer meant anything. In the long term.
« Last Edit: May 19, 2022, 10:33:15 am by VinzC »
 

Offline VinzCTopic starter

  • Regular Contributor
  • *
  • Posts: 217
  • Country: be
  • See you later, oscillator.
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #9 on: May 19, 2022, 10:32:40 am »
Anyway thanks a lot to all for your insights. I now have slightly changed the way I manage my projects — turns out I don't have any professional electronics projects to manage anymore but I think it'll apply as well gently. I'll fine-tune and experiment a bit with it but I can already share a few points.

I'll definitely assign an independent revision number/scheme to schematics and PCB's. Before I asked here, I used to create a GIT branch with the initial revision name (e.g. rev-A). But it assumes a project is only comprised of one board, which is not always the case. Now I think I'll go with one branch per board and manage revisions as tags... or just branch names.

Using GIT for my  electronics projects — just like with all my software development projects — comes with archived history. I still have to figure out how I'll manage projects that are comprised of multiple boards but I have an idea I'd like to experiment.

Most of all I have found some use for manufacturer tags (you know, that little tag Dave hates so much ;) ): well, I use it to tag my boards in my repository to store the manufacturing date, which is given by GIT when you commit a change.

All of this of course relies upon all my project and data files being text files — hail to open source developers such as gEDA / Kicad, to name a few. Thanks to that I can do minor changes using nothing but an editor (e.g. revision bump, via diameter, clearance...)
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: Common practices and schemes for schematics and PCB's versioning
« Reply #10 on: May 19, 2022, 11:23:27 am »
Oh this is a favourite of mine. I built a large engineering process management system years ago on top of CoCreate and Oracle. Nearly murdered me.

Look higher up the process. What you need to do is look at how to identify all standard parts including your finished product. Your product then becomes a standard part which is assembled of other standard parts. Your boards are also standard parts. Your component stock is all standard parts. Then you can rationalise the whole system as an assembly of parts and a timeline of what happened to them including integration, qualification, supply management and testing. When you have to share this, NATO Stock Number comes into play etc etc.

This is completely overkill for personal projects and most small organisations though.

I don't actually version control projects heavily. If I do a release I'll push it to master on GitHub (everything is locally in git too, including documents) if it's to be shared and that's about it. In fact most projects only get 1-3 revisions. The rev 2/3 is only because I screwed up something in the board spin, which I'm learning not to do thanks to writing precondition checklists before ordering boards. Work on those rather than tracking heavily; the ROI on your time investment is higher than building a manufacturing level platform for personal projects :)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf